ソフトウェア開発を加速させるエンジニアとデザイナーの関係性
プロダクト開発の現場では、デザイナーとエンジニアのコミュニケーションが不可欠です。
コミュニケーションする際には、デザインファイルや仕様書、あるいは抽象的な図をもとに議論が行われます。
そんな時、プロダクトを作るという立場では同じであれど、「デザイン」と「エンジニアリング」という別の立ち位置と観点で物事を見ているために意見がぶつかり合うこともしばしば発生します。ですが、そんな時にコミュニケーションを諦めてしまえば、仕様漏れや設計意図が正しく伝わらないような事態が起きたり、より良いインタラクションを生み出す機会を失うなど、品質低下を招いてしまいかねません。
こちらの記事では、UIデザイナーとしてエンジニアとWebアプリケーション開発を協業するなかで、自分なりに意識していることを紹介していきます。
記事の最後に、実際に今一緒に働いているエンジニアメンバーから聞いたこのまま続けてほしいこと・もっと良くしてほしいところも掲載しておりますのでぜひご覧ください。
目次
前提として意識したこと
敬意と信頼を持つ
異なる観点をもつメンバー同士が対話をする上では、お互いに歩み寄る姿勢が大切です。デザインとエンジニアリングの観点、どちらかが蔑ろにされるようなことがあってはプロダクト指針やユーザー体験が考慮された品質の高いソフトウェアはできないと考えています。（納期やフェーズによってどちらかを優先する場合を除きます🗓）
UIデザイナーとしての指針を持ちつつ、職種にこだわらない
理想的な体験を実現するために重要なポイントは、「デザイナーだから」「エンジニアだから」という理由で、相手の領域に対する言及を諦めないことです。その一方、エンジニアから意見を求められた場合に、仕様などを決断できるようにUIデザイナーとしてプロダクト指針やユーザー体験を踏まえた上での指針を持ち合わせておくべきだと思います。
共通言語を作る
コンポーネントなど、会話する際に使用する用語の定義を共通にします。
他にも、デザイナーとエンジニアで同じ言葉だとしても違う意味で使っている場面もあるので、その度に認識をすり合わせることが必要です。
実装開始前のプランニング
仕様に関する決断を全て言語化しておき、端的に伝える
どんな機能的な価値があるかなど、決断はできるだけ全て言語化しておき端的に伝えたいです。無論、考えうる状態・条件分岐・デバイス差分・文字溢れ…などなどについても考慮済みの場合は、ここで共有できていることが重要だと思います。
ただ理想は、信頼関係が構築されるうちに全てを機能的な価値だけで会話せずに、かっこいいから✨いい感じだから😊のような感情的な価値ベースでも会話ができる状態です。ですが、まずは明確に意図を伝えることが大切です。
懸念も伝える
懸念が発生したタイミングで全て伝え、できるだけ後出しにしないようにすると、メンバーが効率よく仕事ができるようになると思います。
理想も伝えるが、度合いを分けて伝える
懸念を伝える際には、理想についても同時にで伝えるようにしています。
「画面実装が面倒そうだが、ユーザー体験を考慮するとこのUIが理想的だ」と感じたら、まずは理想型のパターンから伝えています。スケジュールや実装コストからして難しかったとしても、最大限意図を反映できる方法を探るようなコミュニケーションにつなげることができます。
特に理想ベースの要望に関しては、必須なのか暫定的な判断なのか度合いを明確にして伝えることが重要だと考えています。
- 必須: 絶対にこうしたい、こうすべき理由がある
- 暫定的な判断: 一旦こうしておきたいが、別の可能性を模索する余地がある
なぜなら、度合いを分けて伝えることを意識していない場合、「2 暫定的な判断」の温度感だった理想が「1 必須」の温度感で伝わってしまうようなディスコミュニケーションは大いにあり得ます。そしてもしもここでディスコミュニケーションが起きると、手戻りが起きるリスクも発生してきます。
今後の拡張性と柔軟性
コンポーネントや仕様の汎用性と具体性を考慮し、今後の運用メンバーや開発体制、スケジュールを考えた上での意思決定を行っておけるとよいと思います。
この会話はやはり、どちらかの職種の観点だけでは不可能で、デザイナーとエンジニアの連携具合が鍵になってくると考えます。
実装中の議論
トレードオフを理解する
やりたいことを全て実現するのは、難しいことがほとんどです。
何がどう影響し合ってエンジニアリング上で不都合が起こるのかのか、不明点があれば確認する。「なぜかダメらしい」で終わらせずにそれらの条件をできる範囲で理解してから、今何を優先するのかを明らかにしたいです。その上で方針を示して仕様を決断するとよいと考えています。
設計ルールに沿わないUIが出てきた時はルールを疑う
設計ルールと照らし合わせた時、UIがルールから外れてしまうことはどうしても起きてしまいます。プロジェクト当初に作った設計ルールが完璧であることは稀なので、逐一設計ルールを見直していくことが必要です。
初期段階から設計ルールを外れた例外を作ることは、デザインとしても実装としても負債につながるため、設計ルールを変更するかUIを変更することで対応するようにコミュニケーションします。
一緒に働いているメンバーからのフィードバック
以上、デザイナーである私の視点からエンジニアメンバーとのコミュニケーションにおいて意識していることをご紹介しました。
では、実際にグッドパッチのエンジニアメンバーは、どのように感じているのでしょうか。私が現在一緒に働いているエンジニアメンバーからフィードバックを寄せてもらいました。以下の2点について尋ねています。
- Keep
- このまま続けてほしい
- ここは特に助かる
- 他のデザイナーにも伝えたい
- Wish
- もっとこうなったら素敵
- 他のデザイナーにも伝えたい
👍Keep
フロントエンドエンジニア (中途7年目)
UIコンポーネントやデザイントークンの設計に関しては、構造的かつ効率的に実装できるように一貫性を持ちながらUIデザインをしてくれており、とても助かっています。
また、エンジニアに対して自ら積極的にコミュニケーションを取り、実装がスムーズに進むようにFigmaを素早く修正してくれるのも有り難いです。
日々のコミュニケーションからデザインとエンジニアリングを分離しない思想が伝わってくるので、一緒にモノづくりしていて楽しいですね。
フロントエンドエンジニア (新卒2年目)
特に意識的な部分から来るUIデザイナーとしての意見とエンジニアリング面に対する譲歩のバランス感がいいなと感じています。
どちらも蔑ろになってはいけないと思うので、そこを意識的にコントロールしているのは細かい工夫以上にいいなと思いました。
私も楽しいです！今後ともよろしくお願いします。
🙏Wish
フロントエンドエンジニア (中途7年目)
とてもエンジニアに寄り添ってくれてると感じていますが、ときにはエンジニアに嫌がられらとしても理想のUIを実現するために粘った議論ができると、より磨きがかかると思いました。
理想を実現するためにはエンジニアの粘りがとても重要なので、良い関係性は必要不可欠ですが。
また、エンジニアもUIデザイナーが考えたものをただ作るだけではなく、エンジニアなりの工夫を加えてブラッシュアップされるのが理想だと思います。
フロントエンドエンジニア (中途2年目)
（webアプリケーション開発の場合は）「webブラウザ」というプラットフォームの特性、制約について理解が深まると、よりエンジニアとのやりとりが減ってクオリティが上がるかもと思いました。
ありがたい…。今後ともより良いプロダクトのために少しずつ頑張ります！
おわりに
グッドパッチには「エンジニアリングとデザインは分離し連携しない」という考え方ではなく、デザインとエンジニアリング両方の視点が合わさることが品質向上につながるという考えがあり、それに共感したメンバーが在籍しています。
質の高いユーザー体験を叶えるために、デザインとエンジニアリングの力が合わさった状態での開発が理想的だと思います。コミュニケーションがうまくいかないことがその障壁とならないよう、異なる専門性による観点の違いを乗り越えて、より良いソフトウェア設計の実現を目指していきましょう。
最後になりますが、デザイナーとエンジニアの協業を通してソフトウェア設計をしたい方はぜひ気軽にご連絡ください！