2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
SEからエンジニアに目覚め、デザイナーに転身した冒険譚(全1記事)
リンクをコピー
記事をブックマーク
甲斐田亮一氏:ありがとうございます。「SEがエンジニアに目覚め、デザイナーに転身した冒険譚」というタイトルで発表します。
最初に自己紹介で、日本事務器という会社でフロントエンドエンジニアとデザイナーを兼務している甲斐田といいます。エンジニア的なことを話すと、普段はTypeScriptを使ってReactを書いていて、デザイン的なことを話すと、FigmaとかSketchを使ってWebデザインをやっています。
最初にちょっと宣伝させてください。会社では「fudoloop(フードループ)」というサービスを作っていて、全国の青果市場の卸さんと、全国の生産者さんたちをつなぐサービスを作っています。卸の人たちの「『予想』よりも『予測』を元に仕入れと販売のマッチングを」をコンセプトに、fudoloopは適正価格で青果物を販売先さんに届けるというものを作っています。宣伝は以上です。
みなさんは、なぜエンジニアになりましたか? 僕は、なんとなくエンジニアになりました。
なんとなく始まった僕のSE人生は、とくにプログラミングが好きというわけでもないし、好きな言語もないし、作ってみたいと思うものもありませんでした。エンジニアとしての経験ももちろんないし、なんかこれからずっとExcelで設計書作ってプログラミングしていくんだろうなって思ってました。
僕は、いわゆるSE、職業エンジニアでした。そんな僕は、会社にその時に1人だけいたフロントエンドエンジニアの下につくことになりました。
この先輩には本当にいろんなことを教えてもらって、当時2016年なので、ES2015が流行りだした時期で、ES2015でReact、Reduxを教えてもらって、GitやNode.js、Mochaとか本当にいろいろなことを教えてもらいました。
すごいエンジニアと一緒に働くことで技術力はメキメキついていったんですが、だがしかし、「俺、4月からいなくなるから」と言われました。
このとき「マジで終わった」と思いました。僕は10月に配属されたので、先輩に約半年間ずっと教えてもらってたんですが、4月からは1人でやらなきゃいけない事実をいきなり突きつけられて、「マジで人生終わった」と思いました。
その先輩からは、最後の出社日にこう言われたんですね、「明日からは、君が社内で最強のフロントエンドエンジニアだ、がんばれ」と。この時、僕は「いつ先輩に会っても、胸を張って社内で最強のフロントエンドエンジニアと言えるようになろう」と、そう決心しました。
この時タスキを渡されたことで、フロントエンドエンジニアとしての自分が芽吹き始めました。
ここから本当の苦悩が始まります。
どんな苦悩があったかというと、1人しかいないので、相談できる人もいないし、聞ける人がいないし、「キャッチアップどうしよう」「質の良いコードを書きたい」とかいろいろあったんですが、本当にいろんな苦悩が日々日々かさばり続けていきました。
とくにキツかったのが「質の良いコードとは?」「もっと良い書き方あるのでは?」「正しい実装とは?」「アーキテクトはどう考えれば……」の4点でした。
自分が書いてるコードが正しいのか、良い実装なのかがわからない、でもコードの品質は下げたくないという、この二律背反にずっと苦しめられながらコードを書いていきました。
僕がやってきたことは、とにかくコードを書きまくることでした。そして、自分だけの偏ったコードにならないように、他社のエンジニアさんと交流してブラッシュアップしていく。
また、あまり多くを学びすぎない。これはどういうことかというと、フロントと一言でいってもVue.js、React、Web Components、ESLint、webpackなど僕たちが扱うものはたくさんあります。これら全てを学ぼうとすると全部中途半端な知識になってしまう。だから、今の自分にとって本当に必要な知識だけを取捨選択して学び、特化するということをやってきました。
他だと、(Redux作者の)Dan先生みたいなTwitterで有名な人をフォローするとか、公式リポジトリをウォッチする、勉強会でLT枠で応募しまくるとかですかね。僕の中でLTは特にいいなと思っていて、話すことによって言語化することで頭の中で整理されます。また、中途半端な知識であまり教えたくない、発表したくないので改めて勉強します。その中で新しい発見があったりもしました。
後ろを振り返ることなく、ひたすら勉強していくうちに、フロントエンドに僕はハマっていって、気づけば自走ができるエンジニアになっていました。
この時、エンジニアとしての自我が僕には生まれていました。
職業エンジニアについて少し言及したいんですが、よく「職業エンジニアって変われるの?」と聞かれたりします。僕は難しいと思っています。僕たちのような自走できるエンジニアが変わるためのきっかけを与えることはできるんですが、結局はその人自身なんですよね。その人が本当にフロントエンドを好きにならないと、言語を好きにならないと、自分で学び始めるということをしないので、本人次第だなと僕は思っています。
ただ、これだけは言いたいのは、職業エンジニアってけっこうネガティブなイメージが蔓延してるんですが、僕はそんなことはまったく思いません。いろんなエンジニアがいて楽しいじゃないですか。
職業エンジニアが悪いって言われるのは、「勉強してない」とか「自走できない」とか言われてるんですが、世の中のエンジニア全てがそうなったって考えたら、それはそれでカオスだなと思いますね。新規参入のハードルが高くなって人がよりつきづらくなるんじゃないのかなと。やっぱりそういう人たちも必要だなと僕は思っています。
今、僕はデザイナーに転身してからは、ユーザーインタビューやジャーニーマップを作ったり、よりユーザーの近くでイケてるサービスをエンジニアリングするようになりました。
「イケてる」って何かなという話なんですが、エンジニアが考えるユーザーのイケてる感と、デザイナーが考えてるユーザーのイケてる感。エンジニアもデザイナーもユーザーのためにサービスを作っていくという点は変わらないと思うんですが、この「イケてる感」はちゃんと一致していますか?
というのも、UXデザイナーは、ユーザーのシナリオを通してUIデザインに落とし込んでいきます。ジャーニーマップを作るまでにも、デザイナーとPM間で話し合って、サービスとしてどうグロースするかの方向性を決めて、「こういう機能が必要だな」と考えて、ユーザーにGenerativeインタビューをしに行きます。
インタビューした結果からユーザーのペインとインサイト(隠れた心理やニーズ)を洗い出して、未来のカスタマージャーニーマップを書き起こします。そこから機能に落とし込めるものをソリューションとして考え出していきます。
次にソリューションに沿ったプロトタイピングをデザイナーが作って、Usabilityインタビューに行って使いやすいかどうかを検証して、PM・デザイナー間で話し合って、OKであればUIデザインに書き起こすというフローを踏んでいきます。
僕たちエンジニアやユーザーが見ているUIって、UIの見た目からだけでは測れない、ユーザー像や一連のストーリーを以ってデザインされています。これがUXデザイナーが思うイケてる感だと僕は思っています。
「ユーザー像やストーリーって何?」という話なんですが、これはあくまで一例なんですが、例えばそのユーザーが慣れ親しんでいるアプリやサービスは何か。どういう手順で操作しているか。なぜ手順なのか、などが挙げられます。ユーザーはアプリやサービスを使う時に、決まった手順で操作していることが多いです。
その中でユーザーは課題を持っていたり、あるいはその操作に対して煩わしさを感じていたりします。ここで、なぜ「その手順になったのか」という理由がわかります。じゃあそこから、操作に詰まった時にユーザーはどう行動しているのか、諦めるのか、それとも体験的により良いものを自分で考えているかなど、それを聞くことによってわかることができます。
また、こういった煩わしい操作を改善する際には、ユーザーは見た目や操作の変化に順応できそうかなども考える必要があります。
例えば、僕たち若い層はけっこう変化に柔軟に対応できると思うんですが、こういう言い方はあれですけど、それが60歳、70歳のちょっとリテラシーが低い人とか、変化に順応していくのが難しいような人たちであれば、それはデザインとして変えない方がいいのではないか。変えてしまうとユーザーはインパクトを感じて離れていってしまうのではないかなども考えないといけません。重要なのは見た目じゃなくて、ユーザーへの共感度です。
エンジニアは仕様を固めて実装して、機能を作ります。それに対してUXデザイナーは、ユーザーや業界を知って、機能を創ります。サービス寄りの話には、ユーザーへの共感度がないと話にぜんぜんついていけません。
実際、僕はエンジニアからデザイナーに転身して、PMデザイナー間で「こういう機能が必要だね」とか、カスタマージャーニーマップを作ったりしていったりしたんですが、話についていけないんですよね。それはユーザーを知らないし、業界についても知識がない。ユーザー目線に立つための土台がないから立てませんでした。
PM・デザイナーが今まで積み上げてきた知識や体験を僕は知らないから話についていけませんでした。というのを経験をしていると、同じものをつくってるようで、全然違うものをつくっているような感覚に陥ります。
僕が思ったのが、エンジニアってシステムのデザインはできるんですが、サービスのデザインもできる人が少ないなと。エンジニアもサービスに関心を持つことが大事だと僕は考えています。
僕たちエンジニアも、なんか「サービスが成長していってうれしいな」とか、「ユーザーに使ってもらってうれしいな」と思うんですが、よりユーザーの声を知って、ユーザー目線に立つことで、この感じ方が変わるかもしれないです。
僕はむちゃくちゃ変わりました、ユーザーの生の声を聞くことによって、何気ない一言がむちゃくちゃうれしかったりっていったようなことがありました。
最後ちょっとエモい話をしたいんですが、最近、僕がずっとフロントエンドを教えてもらってた先輩と仕事する機会ができまして、お互い2年ぶりに一緒に仕事をして、2年ぶりにコードレビューをしてもらったんですね。
この時に「お前、本当に成長したね、感動したわ」って言われて、僕はこの時めちゃくちゃうれしかったです。ひたすら前進していろんなことを学び続けていますが、僕は最強のフロントエンドエンジニアというタスキはちゃんと受け継げていたみたいです。
僕は今デザイナーではあるんですが、これからも社内で最強のフロントエンドエンジニアのタスキをかけて学び続けていきたいなと思っています。以上です。ご清聴ありがとうございました。
(会場拍手)
関連タグ:
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05