はじめに
株式会社グッドパッチ でエンジニアインターン中のちげと申します。趣味でデザインをやっている寒ブリとブラタモリが好きなフロントエンドエンジニアです。現在、Strap というオンラインホワイトボードサービスの開発に携わっています。
Strap を開発しているエンジニアには「エンジニア主導デザイン」というタスクの種類があります。エンジニア主導でデザインを行うタスクです。私もエンジニア主導デザインに取り組みました。
エンジニアがどんな場合にどのようにしてデザインタスクを進めていくのか。そしてその価値とは何なのか。「概要編」と「体験談編」の2つの記事に分けて紹介していきます。体験談編はこちらからどうぞ。
今回は（おそらく）Strap 独自である「エンジニア主導デザイン」文化がどんなものなのか、インターン生の視点からご紹介します。
エンジニア主導デザインとは
エンジニア主導デザインとは、エンジニア主導でデザインを行うタスクです。エンジニアがデザインを考えた方が効率的に要件を詰められると想定された場合に、エンジニア主導デザインのタグがタスクに付与されます。
エンジニアがデザインを考えた方が良いタスクの判断基準は、以下の3つです。以下の文は、PBIのテンプレートに明記されており、タスクを決定する際に判断しやすくなっています。
【エンジニア主導でデザインタスクを取れるか】 [ ] 技術によるデザインの制約が発生しないか [ ] UIが既存のサービス、アプリと比べて一般的に推測可能なものかどうか [ ] 新規のデザインアセットがいらないか
※この判断基準は今後の業務でよりわかりやすいものにアップデートする予定だそうです。
基準1. 技術によるデザインの制約が発生しないか
一つ目の判断基準「技術によるデザインの制約が発生しないか」は主に、デザインを行うときに、技術的な知識が必要な場合のことを指しています。
パフォーマンスや実装コストの観点で、採用する技術仕様やコードの内容によっては、UIデザインの自由度に制限がかかる場合があります。そのようなタスクの場合、デザイナーとエンジニアが密に連携する必要があり、コミュニケーションコストも高くなります。場合によっては、UIデザインの出戻り修正になる可能性もあります。であれば、技術選定から含めてどんなUIがいいかをエンジニアが考えた方が早そうです。
このように、そもそもUIデザインの自由度を理解したエンジニアが自ら、技術的制約のあるUIの設計を行うことでタスクを効率良く進めることができます。
基準2. UIが既存のサービス、アプリと比べて一般的に推測可能なものかどうか
二つ目の判断基準「UIが既存のサービス、アプリと比べて一般的に推測可能なものかどうか」は、エンジニアが推測できるレベルのデザイン、またはエンジニアがデザインしやすいデザインに限定するためのものです。
「エンジニア主導デザイン」になるかどうかは、ユーザーのユースケースと操作の仕様が決まっている状態で判断されます。すでに決定している操作の仕様と、似たデザインのツールがある場合は、エンジニアでも完成形のUIデザインが想像しやすく、タスクを進めやすいです。やることが書き出せていて、デザイン上の不明な点がほぼないものが当てはまります。
そのためエンジニア主導デザインは主に、サービスの独自性にはならない機能のデザインで効果が発揮されます。サービスの独自性になるコアな部分のデザインは、デザイナーのタスクになっています。
基準3. 新規のデザインアセットがいらないか
三つ目の判断基準も、エンジニアがデザインするときのやりやすさを考慮するためのものです。すでに存在するアイコンやコンポーネントを利用できる場合、その部分についてはデザイナーにデザインを依頼する必要がありません。ある程度ベースにある過去のデザイン資産を活用して、UIを設計できるものが当てはまります。
エンジニア主導デザインのメリット
デザインをエンジニアが主導する形態のメリットとして、主に以下の二つが挙げられます。
1. デザイナーのリソースを有効活用できる
Strapチームにエンジニア主導デザインというタスクが生まれた当時、開発チームのデザイナーのリソース不足が背景にあったと聞いています。メインのサービスデザインだけでなく、細かいデザインタスクやインタラクションまで全て少数のデザイナーのタスクになっていました。この問題を解決するために、「エンジニアがデザインした方が良いもの」を判断する土台が作られていったようです。
上記「基準2」でも触れた通り、デザイナーはサービスの独自性になるコアな部分のデザインに注力した方が、戦力的に頼もしいですよね。私はコーディングだけでなくデザインもやりたい人間なので、エンジニアインターンでUIデザインもできて楽しかったです。WIN-WINですね！
2. 実際の動作を見て見ないとユーザー体験が具体化できない場合に効率的
実際に動くプロトタイプを操作してみないと、ユーザー体験がわからない場合があります。例えば、作ってみると意外に動作が重たかったり、デザイン上の盲点が見つかったりすること、ありませんか？
また、アニメーションがあったり、操作が多くユーザーの入力によって動的に動いたりする仕様の場合は、Figma や Illustrator を使った静止画デザインがやりにくいことも多く、手間がかかります。
エンジニアが主導でデザインを行うと、その過程で実際に動くプロトタイプが完成し、それを直接操作、体験できるため、ユーザー体験のインタラクションの部分を素早く評価、検証できます。その評価や実際の動作をデザイナーに共有して認識を合わせるため、設計後の静止画デザインを修正する手間がなく、効率よく進められます。
特にグッドパッチでは、エンジニアのデザインに対する評価、検証の質が高いと感じます。評価や検証に関しては、デザインにも精通したエンジニアがいるグッドパッチだからこそ質が担保できる部分かもしれません。
エンジニア主導デザインのデメリット
1. エンジニアの作業量が増える
単純に、デザインもプログラミングもするのでエンジニアの作業量が増えます。エンジニアよりもデザイナーの人数が多い場合や、一時的にエンジニアリングにリソースを割きたいタイミングではエンジニア主導デザインは適していないかもしれません。
エンジニア主導デザインは、デザイナーとエンジニアのタスク量を天秤にかけたらデザイナー側が重いよね、という場合にその調整を行うものでもあります。デザイナーにタスクが偏っていたらエンジニア主導デザインの採用は一考の余地があるでしょう。
2. デザインに対する適切な理解がエンジニアに必要
エンジニアがデザインしやすいデザインに限定されているとはいえ、デザインに対する基礎知識は必要だと思います。なぜなら私の経験上、エンジニアは開発しやすいデザインを無意識に選んでしまうからです。
もちろん工数の釣り合い調整という点では開発しやすいデザインも有用ですが、デザイナーにとっては、開発のしやすさよりもユーザー体験を重視します。エンジニアも、ユーザーの目的に寄り添えているかという視点を持って、デザインや開発を行うことが重要です。グッドパッチでは周りのエンジニアもそのような視点を持って開発しておりデザインを重視する環境なので、同じ目線で相談したりフィードバックをもらいながら、初めてのエンジニア主導デザインにチャレンジできました。
エンジニアがデザインの考え方に精通していると、デザイナーに任せた方が良い部分の判断基準がわかるという点でも有利です。タスクの効率化に寄与できます。
まとめ
ここまでの話をまとめると、エンジニア主導デザインとは、ざっくりした仕様が決まっている段階で、エンジニアが実際に実装しながらUIデザインを進める手法です。
本記事ではエンジニア主導デザインのメリットをいくつか紹介しました。それらのメリットが享受できるであろう特定の条件も設定していて、意思決定も楽に行えるようにシステム化しています。
もし「デザインもやりたいな」というプログラマさんがいたら、エンジニア主導デザインを取り入れてみてはいかがでしょうか。
「体験談編」では、「エンジニア主導デザイン」タスクを行った実際の体験談をお話ししたいと思います。「体験談編」もぜひご覧ください。
また、グッドパッチではチームメンバーと職種を超えてコラボレーションしながら開発していただける仲間を募集しています。 カジュアル面談からでもぜひご応募ください。
