共感でつなぐ！デザイナーとエンジニアの連携をスムーズにして、最高のプロダクトを作ろう！
こんにちは。プロダクトデザイナーの氷室です。
ここ数年で、Figmaなどのプロトタイプツールや、Slackなどのコミュニケーションツールが劇的に進化し、一昔前と比較すると、飛躍的にデザイナーとエンジニアの連携がスムーズになりました。しかしそれでもなお、両者の連携がうまくいかないと感じることがあります。例えば「指定通りの実装にならない」「認識違いによる不要な手戻りが発生している」「価値観の相違から衝突している」などなど、昔ながらの問題が今なお頻発しています。
これはツールが進化しても、コミュニケーション不全が、以前と変わらず起こり続けているからだと思いますが、何故ツールでその埋め合わせが出来ないかというと、開発を取り巻く環境が、以前にも増して速いスピードで高度化・複雑化を続けているからだと思います。 特に大きく環境が変化していると感じる点は以下です。
リモートワークの普及により、人と人のつながりが希薄化している
デジタルプロダクトの品質に対して求められるハードルが年々高まってきている
各職域の専門性が向上し、他職種から見るとブラックボックス化している
専門性の向上に伴い開発人員が増加し、コミュニケーションパスが増大している
VUCAな環境（不確実で曖昧な環境）にアジャイルに対応していく必要がある
このような状況が日々スピーディーに進行しているため、ツールの力を借りても、時流に沿った形でコミュニケーションをしていくことが難しくなってきています。これを解決するためには、自分達で意識的に工夫しながら、連携を強化していく必要があると思いますが、私は以下図に示すようなシンプルな枠組みを意識し、出来る所から丁寧に実践していくことが重要ではと考えています。
今回はこの「段階に応じたデザインシステム」「最適なコミュニケーション」「共感」というシンプルな枠組みを通して、いかにしてデザイナーとエンジニアの連携をスムーズにしていくか、みなさまにご紹介できればと思います。
1）段階に応じたデザインシステム
デザインシステム（ここではデザイントークンやコンポーネントライブラリも含めます）はFigmaをはじめとするプロトタイプツールの進化に伴い、爆発的に普及しました。コンポーネントやスタイルの定義を行いながらデザイン・実装することは、あまりに効率的なので、デザイナーとエンジニアの連携を強化していく上では欠かせないものになりつつあります。
しかしその作り込みをどの「段階」まで行うかに関しては、曖昧なプロジェクトも多いと思います。この段階を見誤ると、不要な手戻りが発生したり、後々のビジネス面で打撃を与えかねないため、現在置かれている状況や予算などに応じて、しっかりと見定めていく必要があります。
まず、プロジェクトのフェーズとそれに適したデザインシステムの段階を、ざっくり図で表現すると、およそ以下のようなイメージになると考えています。
それでは、以下に詳しくご説明します。
【1-1】0→1フェーズでは、デザイントークンの作成から始める
プロジェクトの最初期である0→1フェーズでは、まずデザイントークンの作成から始めることをおすすめします。デザイントークンとは、色やタイポグラフィ、シャドウやマージンなど、そのプロダクトに用いる最小単位の値を定義したものです。デザインシステムにおける根幹であり、全体のスタイルを支える非常に重要な要素です。デザイントークンを双方が理解し合える形で命名し、ソースコードと連携すれば、一貫性のあるプロダクトをエンジニアと効率的に作っていくことが出来るでしょう。
デザイントークンは、仮に数ヶ月で開発を終えなければならないような、タイトで低予算なプロジェクトでも大いに活躍してくれる、有用でミニマムなデザインシステムだと私は考えています。
【1-2】0→1から1→10フェーズにかけて、コンポーネントを順次作成し、運用ルールを明確にしていく
デザイントークンを作り終えたら、ボタンやフォームなどのUIパーツを順次「コンポーネント化」していくことになると思います。汎用的なパーツはコンポーネントにして、デザイナー 、 エンジニア間で連携していくことで、デザイントークンと同じく、プロダクトの一貫性と開発効率の向上に寄与してくれるでしょう。
ただし、ボタンコンポーネントひとつとっても、非活性、プライマリ、セカンダリなど、様々な状態が存在します。これらを運用ルールまで含めて作成し、プロダクト全体を通して踏襲させていくには、相応の労力がかかります。以下に示すような足元の状況を考慮して、どこまで手をかけるべきか慎重に選択すべきでしょう。
MVP開発をしているPoCなどの小規模案件において、コンポーネントを丁寧に作り込むことが、コスト&リターンの観点から本当に有益か？
プロダクトのデザイン原則がぼんやりしている中で、単体のコンポーネントのみ解像度が高くなっているような、近視眼的な作りにならないか？
ダイナミックに事業推進していかなければならない1→10フェーズにおいて、細かなルール付けがかえって開発者の手を止め、サービスの勢いを阻害しないか？
「ルール」で縛る事で、デザイナーやエンジニアの創造性を奪ってしまわないか？
このように、実はコンポーネントの作成にはリスクも孕んでいます。なので、プロダクトが軌道に乗るまでは、コンポーネントを敢えて厳密に定義しない勇気も必要ではないかと思います。特に真面目で職人気質な人ほどこの落とし穴に陥りやすい気がします。事業の置かれている状況とうまくバランスしながら、コンポーネントを作成していくことをおすすめします。
【1-3】10→100フェーズで、成熟したデザインシステムを運用していく
サービスが安定軌道に乗り、多くのユーザーに利用される10→100フェーズになる頃には、ほとんどのコンポーネントがライブラリ化され、運用ルールやデザイン原則なども明確に定義された、「成熟したデザインシステム」が完成していることが望ましいです。
このフェーズに入る頃には、おそらくプロジェクトの人員も大幅に増加し、ブランドの目指すべき方向性も固まっていることが多いと思います。ここでブランドの世界観に沿ったデザインシステムを作り上げ、効率的に運用していくことで、ユーザーから確固とした信頼を獲得していけるのではないでしょうか。
個人的には、成熟したデザインシステムは、運用フェーズに入ってからが勝負だと考えています。一見するとデザインシステムを作り上げることが一つの到達点のようにも思えますが、それはまだ入口に立っているだけのこと。その先、地道にメンテナンスをしながら、先の見えない道を忍耐強く進んでいく覚悟がデザインシステムの管理者には必要だと思います。逆にそれがなければ、デザインシステムはあっさりと瓦解し、プロジェクトは混乱に陥るでしょう。
2）最適なコミュニケーション
物事が流動的に変化していくアジャイル開発においては、デザイナーとエンジニアが常に認識齟齬のないようプロダクトを開発していく必要があるため、コミュニケーションは欠かせません。都度よしなにコミュニケーションを取るのではなく、事前に全体のロードマップを確認しながら、双方でどのようなコミュニケーションが必要かを計画し、実行していく必要があると思います。
ここでは大きく、「UI実装前」「UI実装時」にカテゴリーを分け、それぞれどのようなコミュニケーションが有用であったか、私の経験を元にご説明します。
【2-1】UI実装前
UIの事前確認（あるいは共創）
UI設計時には、必ずエンジニアにも確認してもらいましょう。開発フェーズを考慮せずに、理想を追求したデザインを一方的にしてしまうと、それが後々の諍いの元になるのは容易に想像できます。
できれば、IAやワイヤーフレームの段階から共創していくことがおすすめです。以下のような、デザイナーだけでは気づかなった観点や、デザイナーだけでは考えつかなかったようなアイデアを提供してもらえるかもしれません。
実現性のあるUIになっているか
開発コストとリターンが適切なUIであるか
データのリレーションやセキュリティ上問題ないか
UX要件やビジネス要件を満たしたUIになっているか
無駄のない効率的な画面設計になっているか
デザインガイダンス
実装に入る前に、デザインに対する説明をプロジェクトに参画する全エンジニアを前にして行います。ユースケースの説明はもちろん、プロダクトのビジョン・ミッションやKPIなどのビジネス要件まで説明するとなおよいでしょう。上流からの要件が何故このデザインに落とし込まれたのかを論理的に説明し、納得してもらいましょう。特に途中参画のメンバーに全体感の説明を怠りがちだと思うので、オンボーディングしていくにあたっての必須フローとして固定化しておくのがおすすめです。
ドキュメンテーションのルールを策定する
仕様をどのようにドキュメンテーションしていくかも、スムーズな連携においては非常に重要になってきます。デザインシステムの段階分けと同じく、ドキュメンテーションの方法も段階分けしていくのがおすすめです。例えば小規模なプロジェクトやPoCなどにおいては、仕様を直接Figmaに明記していくのも、クイックに開発していく上では有効でしょう。逆に大規模な本番開発プロジェクトにおいては、些細な認識齟齬が、情報漏洩など重大なリスクにつながっていく可能性もあるため、少々煩わしくとも厳格に仕様を明記し、関係者一体となって認識を揃えていく必要があります。自分たちの置かれた状況を鑑みた、適切なドキュメンテーションが重要だと思います。
💡 ちょっとした創意工夫がチームを救う
日常のちょっとした創意工夫が、双方のコミュニケーションをスムーズにしてくれます。例えばFigmaに「会議メモ」「検討中」「思ったこと」といった付箋を、アートボードの近くに貼り付けておくだけでも、エンジニア含め多くの関係者が助けられるでしょう。些細なことでも、出来る所から実践していけるとGoodです。
【2-2】UI実装時
デザインシステム実装時
デザインシステムを用いる場合、基本的に各ページよりも先にデザインシステムを開発していくことになると思います。なので、まずはデザイナーからエンジニアにデザインシステムの説明を行いましょう。この時点で命名規則やコンポーネントの仕様などを漏れなくしっかりと説明します。デザインシステムはプロジェクト進行中にもアップデートされていくので、変更があれば都度共有し、双方のフィードバックを重ねながら開発を進めます。「Storybook」のような、実装したコンポーネントを一覧で確認できる環境があれば、双方の負担も楽になると思います。
画面単位での実装時
<実装着手前>
画面単位の実装に入る前も、UIの説明を行うのがベストだと思います。一見シンプルに思える画面でも、見落としていた仕様やエラーパターンなどがあるかもしれません。また、デザインガイダンスでは説明しきれなかったユーザーの細かなユースケースをより詳しく説明することで、一層プロダクトに対する理解を深めてもらうことができます。
<実装着手後>
実装後のフィードバックに関わるコミュニケーションもあらかじめ規定しておくと安心です。エクセルなどにフィードバック項目を淡々とまとめる方法もよいですが、フィードバックを可能な限り分かりやすくするために、差分を可視化することをおすすめします。例えば対象の画面をキャプチャした上で、それが元のデザインファイルと比較してどこに差分があるのか、アートボードの横に直接貼り付けて、分かりやすく提示するのも一つの手でしょう。
またFigma通りとは言え、実装後に「何か違う・・」と感じることも度々あるかと思います。そのような場合でも率直に意見を交わし、開発工数とトレードオフしながら最適と思える形で進めましょう。あらかじめ「ユースケース上のボトルネックになりそうな箇所は修正する。そうならない場合は後回しにする」などの約束事を決めておくのもいいかと思います。
💡 デザイナーもエンジニアのミーティングに参加しよう
例えばチームがスクラム開発を実践している場合、デイリースクラムやレトロスペクティブなどのミーティングを行なっていると思います。専門性の高い話も多いと思いますが、その場にデザイナーも参加し、日々の進捗や成果に対して建設的なフィードバックができると、一層チームに貢献できるようになるでしよう。
3）共感
段階に応じたデザインシステムを策定し、抜かりないコミュニケーションプランを策定したことにより、これまで以上にスムーズな連携ができるようになったと思います。 しかし、そこからさらに一歩踏み込んで連携をより強化していくためには、「共感」に基づく相互理解が不可欠であると私は考えます。お互いが共通の目的や課題意識を持ち、何に重きを置いて開発しているかを知るだけで、コミュニケーションがよりスムーズに進み、最終的にはプロダクトの品質が向上するのではないかと思います。
では双方が共感し、相互理解を深めるためには何が必要か。こちらも私の経験を元にご紹介しようと思います。
【3-1】前提情報を正しく認識する
まず、プロジェクトに対してお互いの持っている情報や認識に齟齬が出ないようにしておくべきでしょう。特にプロジェクトのビジョンやミッションすら共有できていないとしたら、どんなコミュニケーションも暖簾に腕押し状態になってしまいます。
開発に際しての資料は、ビジネス資料から要件定義書まで様々あると思いますが、それぞれの資料をしっかりとメンバーに連携して、認識齟齬が出ないようにしておきましょう。
ただし、すべての資料をくまなく見ても、一度に覚えられるはずもなく（そもそも見てもらえるかも分からず）、やがて要点を忘れ、開くのが面倒になり、資料の置き場すら忘れる‥といったことが起こりがちです（私もよくそうなります‥）。
なので、デザインドックスなどにこれら資料のサマリーをまとめ、1ファイルとして共有するのがおすすめです。このページを開けば、いつでもプロジェクトの全体概要を理解できる。そしてそこにリンクされている各資料に行けば、いつでも詳細を確認することができる。そのような全体概要を包含した資料があればとても便利だと思います。
【3-2】相互理解を促進する
前提情報に対する認識が揃った後は、お互いの理解をより深めていくことが重要だと思います。相手がどんなスキルを持ち、どんな経験をしてきたのか。何に重きを置き、どこを目指しているのか。このように相手の人となりを少し知るだけでも、警戒心や緊張感が薄れ、コミュニケーションがスムーズに進むのではないでしょうか。また、強みや弱みを知ることで、プロジェクト中で相談したり手助けしたりしやすくなります。相互に助け合い、絆を深めながら目標に向かっていく。プロジェクトにおける理想的な動き方の1つだと思います。
相互理解促進のために、ランチ会や飲み会などを開催するのも有効かもしれませんが、出不精で人見知りの人も多いので、例えばそれぞれの職歴や趣味、性格分析にいたるまで、人となりが分かる自己紹介シートを、プロジェクトページに作っておくというのも一つの手です。
またその他にも、相手が今回の開発に際して何にプライオリティ（優先順位）を置いているかを知るのも良いでしょう。
例えば、あるデザイナーは「よりよいユーザー体験の創出」に注力し、あるエンジニアは「納期までに要件通りに開発」することに注力していたとします。このような場合、開発途中に見つかったユーザビリティ上の修正事項をデザイナーは歓迎しますが、納期が変わらないのであればエンジニアは敬遠するでしょう。そこで不毛な言い争いが起こるのは馬鹿げています。
お互いのプライオリティを理解し、それぞれの職域を尊重した上で、様々な要因とトレードオフしながら落とし所を見つけていくことが重要です。
プライオリティを知ることで、相手の意見が腑に落ちることも度々出てくるでしょう。
【3-3】心理的安全性を醸成する
相互理解が深まればあと一歩です。チーム内の心理的安全性を強化し、プロダクトやプロジェクトのためなら、上下関係や職域を超えて、何を言ってもいいという雰囲気を醸成していきましょう。
特に最初の一歩が肝心です。どんな些細なことでも構わないので、あなたから声をかけてみてください。その積み重ねが忌憚のない意見を言い合える環境につながっていきます。
デザイナーもエンジニアも私の観測範囲では、内向性と引き換えに専門性を獲得している人が多いように思います。どちらも奥手だけど、心の中では職人として愚直にプロダクトと向き合いたいと思っている人が多いのではないでしょうか。だから相手のことを必要以上に恐れる必要はありません。遠慮なく声をかけ、正直に意見をぶつけ合いましょう。何よりそのような開発は純粋に楽しいと思います。
そのうち自然とエンジニアからデザインに対する改善要望が出たり、デザイナーから実装に対する改善要望が出たりします。「随分こいつ踏み込んでくるな・・」そう思えたら連携がうまくいきつつある証拠だと思います。私もプロジェクト中、エンジニアからの指摘を1つの指標にしています。指摘がないようなら、まだまだ心理的安全性が醸成されていないということだと思うので、声がけをより積極的に行うように心がけています。
コロナ禍以降のリモートワークの定着で、何となく開発現場の空気が硬直しがちのように思います。隣に同僚がいて、気軽に相談できるような環境は希少になってしまいました。オフィス勤務の時のように気軽に、そして持続的に意見交換できるようにするには、意識的な行動が必要です。一人一人が殻の内側にこもってしまわないように、定期的に引っ張り出していきましょう（あるいはぶち破っていきましょう！）
まとめ
ということで、デザイナーとエンジニアの連携をスムーズにしていくための方法を、今回は「段階に応じたデザインシステム」「最適なコミュニケーション」「共感」というシンプルな枠組みを通してご紹介しました。こちらをぼんやりとでも頭に入れていただき、少しずつでもいいので対応していくことで、双方の連携がより良い方向に進んでいくのではと思います。冒頭申し上げた通り、出来る所から丁寧に実践していくことが大事だと思います。
しかし何より重要なのは、業務改善と関係構築を、デザイナーとエンジニアの双方が、意識して持続的に続けていくことだと思います。その意識すらなくなった時、1番の被害者は何の罪もないプロダクト、そしてユーザーではないでしょうか。
みなさまの開発するプロダクトが全ての人に愛されるものになるよう、この記事が少しでもお役に立てれば幸いです。
弊社ではデザイナーを絶賛募集中です。少しでもご興味を持っていただけた方はお気軽にカジュアル面談にご応募ください！