
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
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年ぶりにコードレビューをしてもらったんですね。
この時に「お前、本当に成長したね、感動したわ」って言われて、僕はこの時めちゃくちゃうれしかったです。ひたすら前進していろんなことを学び続けていますが、僕は最強のフロントエンドエンジニアというタスキはちゃんと受け継げていたみたいです。
僕は今デザイナーではあるんですが、これからも社内で最強のフロントエンドエンジニアのタスキをかけて学び続けていきたいなと思っています。以上です。ご清聴ありがとうございました。
(会場拍手)
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10