この記事は freee Developers Advent Calendarの７日目です！
こんにちは、freeeでデザイナーをしていますfkadyといいます！ タイトルの通り、freeeにはエンジニアとして新卒入社したのですが、2020年の1月からデザインチームに異動しています。
そこで今回は「なぜデザインチームに異動するに至ったのか」そして「異動して何を感じたのか」の２つをお伝えできたらなと思います。
なぜデザインチームに異動するに至ったのか
一言で言うと「プロダクトに関わるどの部分に一番こだわりたいのかと考えた時に、デザインの部分だと思い至ったから」なのですが、 まずはそう思うに至った経緯をお伝えします。
エンジニアとしてキャリアをスタートするまでの流れ
そもそも自分はデザインやコンピューターサイエンスの専攻ではなく、学生時代のある時「Webサービスがつくれたら面白そうだな」と思い、独学をし始めました。 まず興味を持ったのはHCIやBehaivor Designといった分野で、最初はUI/UXデザイナーになろうと考えていました。しかし、「グラフィックデザインなどの専攻をしている人が多そう」というイメージが当時はあり、そういった思い込みからデザイナーを目指そうとするのは諦めていました。
一方で「Webサービスをつくる」のに、エンジニアリングも体験してみたい気持ちもあり、プログラミングを学び始めました。すると、何かを作れることはもちろん、普段使っていたサービスの見え方も変わっていく面白さを感じました。 自分がデザインとして学んでいた事はプロダクトに関わるどの職種でも役立ちそうだったので、エンジニアとして働きながらデザインの知識も活かしていきたいと考えていました。
エンジニアとして働いてみて感じた事
freeeのエンジニアとしてはインターン期間を含めると約3年働きました。自分が開発に携わった機能が世に出ていくのは純粋に面白く感じていましたが、職種による縦割りも少し感じていました。 プロダクト開発の工程は大まかに「何を作るのか」「どうUIに落とし込むのか」「どう作るのか」がありますが、当然ながらエンジニアとしては「どう作るのか」の部分にメインに関わります。
元々「デザインの知識を活かしながら開発していきたい」と考えていましたが、働いていくうちに「『どう作るのか』以前の部分の方にもっとこだわりたい」という気持ちも強くなっていました。
一方で、エンジニアと一口に言っても人それぞれ興味関心は違います。「アーキテクチャーにこだわりたい」「最適化していきたい」など様々ですが、「デザインへのこだわりが強い」というタイプは意外と少ないのかなと、働き始めて周りを見渡すことで感じていました。
異動タイミングについて
職種による縦割りや「『どう作るのか』以前の部分の方にもっとこだわりたい」という気持ちから、いつかは職種を変えて仕事でデザインをしたいなと思いつつ、それをいつすべきかは結構悩みました。
こういう時の考え方は人それぞれと思いますが、「今自分が一番こだわりたい（情熱がある）所に携われる」のが良いなと思います。 情熱のある方が成長の速度も上がるし、何より仕事していて楽しいはずです。
なので、「エンジニアとしてもう少し技術力を伸ばしてから...」と先延ばしにするのはやめようと思い切りました。 エンジニアをやっている人はそれが自分にとってベストな職種と考えて、仕事をしているはずですし。
そんな考えを持っていた所、開発メンバーの社内異動制度がはじまりました。そこで、デザインチームへの異動を希望し今に至ります。
異動後について
異動後の業務では大きく「プロダクトデザイン」と「デザインシステムの運用」の２つに関わっています。
「プロダクトデザイン」では、デザイナーはリサーチとUI設計を担当し、PMやエンジニアと一緒に実際の機能を作ります。 この記事では、「プロダクトデザイン」で実際に関わった機能の紹介、そこでの気づきについてお話ししたいと思います。
幸いにも、関わったプロジェクトのいくつかが、会社のYouTubeで取り上げられていたので紹介させていただきます。
1、未来に起こりうる入出金を、資金繰り表に反映させられる機能
２、納税額を試算し、資金繰りの参考にできる機能 www.youtube.com
いきなり1人でデザイナーとして入ったプロジェクトでしたが、こうして世へリリースできました。 異動して成果を出せるのかは、やってみないとわからなかった事なので、デザイナーとしてやっていく自信にもなりました。
エンジニア経験や実装面の知識は活きているのか
エンジニアからデザイナーに異動して活かせることはあるのか？と思われるかもしれません。
デザインのフェーズは大きく分けて「どんな価値を提供すべきか（要件）」をリサーチを元に考える、「機能としてUIに落とし込む」の２つがあります。 後半の「機能としてUIに落とし込む」はエンジニア経験や実装面の知識が活かせていると感じており、いくつかの例を挙げてみたいと思います。
機能の実現方法の見通しが立つ
当然ながら「どんな価値を提供すべきか（要件）」を定めただけでは機能やUIは出来上がりません。
UIが、ユーザーが画面を介して情報を見たり操作したりするものである以上、「何のデータがどんな形で存在し、どう使えるのか」を想像できる必要があります。データへの理解は、オブジェクト指向UIを考えることにも役立ちます。
また、アプリケーションはアップデートされながら、使い続けられていくものです。追加変更していく際には「既存に提供している機能を読み解く」事も必要です。作り直したり別に用意しなくとも、既存の機能に少し手を加えて要件の実現が可能だったという事もあります。
「どんな価値を提供すべきか（要件）」を定めた後に、アプリケーションに目を向け「何のデータがどんな形で存在し、どう使えるのかを把握」「既存に提供している機能を読み解く」とできると、UIにより実現性を持たせられるはずです。この辺りは、実装面の知識があるとより考えやすいのではと思っています。
UIがどう実装されるのかに想像が及ぶ
要件をUIに落とし込んだ後に、実装に着手することになります。
満たしたい価値が提供できるだけでは良いUIではないと自分は思います。 解決したい課題が同じだとしても、どんなUIで解決するのかによって実装工数には差が出てしまいます。
実装方法や工数が意識できると、「一見複雑な要件だが、このUIなら工数を肥大化させずに実装できる」「多くの実装を要するが、要件を満たすには必要不可欠」「この変更なら工数が小さい/大きい」などと考えられます。
価値を満たすための必要十分はUIは何かと考えられることは、プロジェクトを進める上でのMVPとも関わりますし、大事だと思っています。
UIの状態変化に対する理解
当然ながらUIは見るだけのものではありません。 Webアプリケーションはインタラクティブなので「操作」が行われるし、Webとして「通信」を行い、アプリケーションとして様々な「処理」をするなど、色んな状態があります。
それぞれの状態を考慮し、UIとして「ユーザーにどんなフィードバックを返すべきか」「時には処理をユーザーに対しては隠蔽すべきか」などと考える必要があります。この辺りも、実装経験があるとより意識しやすい点なのではと感じています。
開発側とのコミュニケーションコストが下がる
当たり前の事ですが、コミュニケーションには「相手に伝える」「相手の言う事を理解する」によって成り立ちます。
先に挙げたような考慮をUIに落とし込み、相手（エンジニア）に伝わる言葉でUIの意図を伝えられます。 また、相手（エンジニア）からの「実装する上で困難な点がある」「こんなやり方もある」といった意見に対しても、それらを鵜呑みにすることなく「相手（エンジニア）の言う事を理解する」ことができます。
まとめ
もっと「何を作るのか」「どうUIに落とし込むのか」にもっとこだわりたいと、デザインチームに異動しました。
UIに落とし込む際は実装面の考慮を入れる必要もあり、いくつかの面でエンジニア経験が活きていると感じています。
ただ、「UIを考える上で実装面の考慮を入れる」に関しては「自分には強みがある」で終わるのではなく、組織として「実装経験がないデザイナーでも実装面の考慮を入れてUIに落とし込める」となるのが望ましいはずです。これはデザインシステムやUI/UXガイドラインを整備していくことで実現していきたいと思っています。
異動して1年が経ち慣れてきたところですが、この先取り組みたいことも見えてきました。今後も、より大きな成果に向けてチャレンジしていきたいです。
長い文章になりましたが、ここまで読んでくださりありがとうございました！
明日は、freee Tech Nightの司会も務めるのぶじゃすさんの記事です、ご期待ください！！
