「共通言語をどう作るか」。プロダクト開発におけるデザイン×エンジニアリング【Design Bazaar ショートレポート #03】
「Design Bazaar -デザインコラボレーション-」は、デザイン起点でのコラボレーションをテーマにしたオフラインイベントです。2023年10月24日に、東京・虎ノ門「THE CORE KITCHEN/SPACE」で開催されました。
マネジメント・エンジニア・プロダクトマネージャーとデザイナーのコラボレーションを軸に、世の中に価値を生み出すデザイン組織やプロダクト開発について探求した本イベント。
Session3では、エムスリー株式会社 大月雄介氏、Visionalグループ 株式会社ビズリーチ 福田佳世子氏、株式会社ディー・エヌ・エー 松田涼氏の3名に、プロダクト開発におけるデザイナーとエンジニアの連携についてお話しいただきました。この記事では、そのサマリーをお届けします。
Session 03 ：
プロダクト開発に求められるデザイン x エンジニアリング
登壇者
モデレーター：
株式会社ROUTE06
プロフェッショナルサービス本部 デザインマネージャー
熊野 亜由美
▼デザイナー×エンジニア、どのように目線を合わせるか
それぞれの役割を担うからこそ、プロダクト開発の過程で生じるデザイナーとエンジニアの乖離。各社が直面した課題とその乗り越え方についてお聞きしました。
──デザイナーとエンジニアのコラボレーションという観点で、これまで直面した課題はありますか。
エムスリー大月氏：
弊社はギークなエンジニアやフルスタックなエンジニアが多いのが特徴的、かつデザイナーもそこに一人、多くて二人しか関わらないのが結構ユニークなポイントかなと思っていて。
そういう状況の中だと、まず自分というキャラクターを知ってもらうことだったり、『何ができる人なんだろう』ということを知ってもらわないと、どうコミュニケーション取ったらいいか分からないということが起きてしまうのが課題の一つでした。
── 自身のキャラクターを知ってもらう。
エムスリー大月氏：
「クラウド電子カルテ」というサービスに最初入ったんですけど、デザイナーが何年も居ない状態が続いていて。デザイナーが何をできるか分からないっていうところからスタートしたので、まずはメンバーと1on1したりとか、とにかく話すことを起点にやってきました。
そこである程度人間性が分かって、お互いに分かり合えたところで実際にプロジェクトで機能を作っていくことをスタートしました。ただ、やっぱりそこでこだわりが衝突することは起きてしまうので、今度はとにかくユーザーにたくさん会って、デザイナーとエンジニアの共通言語を作ることに取り組みました。
こだわりって自分のことしか見えてない時があると思うので、僕がユーザーの代弁者としてユーザーや事業を軸に話して、そことこだわりを掛け合わせることで、コラボレーションしやすくなりましたね。
Visional 福田氏：
さっきちょっと控室で大月さんとも話したんですけど、逆にうちはチームメンバーがすごく多いんですよね。そういった中で、エンジニア、デザイナーもそうですし、PMであったりとか、開発に携わるみんなの共通言語がないことが課題でした。
例えば、デザイナーは目視で#000と#333のブラックのカラーが見分けつくんですけど、エンジニアは難しい。その結果、#000と#333のテキストがプロダクト内に一緒に共存しちゃうみたいなこととか、もう本当に細かなことなんですけどそういうことがありました。
── すごく分かりやすい例ですね。解決方法として具体的にどういった取り組みをされましたか。
Visional 福田氏：
デザイナーの共通言語として、多分#000とか#333で会話しても伝わると思うんですけど、やっぱりエンジニアやPMの方はなかなか難しい。なので、パレットとしてカラーを用意して、そこに対してタイポグラフィベースみたいな感じできちんとトークン化するということをエンジニアと共にやっていく。どういう命名がいいですか、というのをきちんと目線合わせをしながら丁寧につぶしていくっていうことをやっていきました。
DeNA 松田氏：
今担当してる「Voice Pococha」ってFlutterっていうフロントの言語で組んでいて、バックがRubyなんですけど。ユーザーさんが顔を出しません、映像が流れません、なのでテキストでコミュニケーションを取るサービスなんですね。ただ、Flutterって日本語がめちゃくちゃ苦手なんですよ。
現状はだいぶ改善したんですけど例えば絵文字を実現できなかったりとか絵文字が異様にちっちゃくなっちゃうみたいな。
── それはまた、謎の仕様が。
DeNA 松田氏：
そういう仕様がめちゃくちゃあって、デザイナーとエンジニア間で初めて使用する開発言語だったので。なので、Figmaで作ったデザインをどう表現できるのかが実装してみなきゃ分からないみたいな状態に陥ってしまっていた。というのが結構デザイナーとエンジニア間で起こる問題で、かつ1度解決したからといって、この間もFlutterが大幅アップデートしたんですけど、そしたらまた日本語がめっちゃ崩れたんですけど。
なので、デザイナーからもエンジニアに対して「いや、これはこう崩れてるからどう改善したらいい」っていうのもアプローチするようにしてるし、逆に今それをエンジニアさんも知ってくれてるので、エンジニア側がFlutterアップデートしたら多分バグりますみたいなのを、事前にお知らせしておいてくれて。
なので次のアップデートではこういうふうに日本語を直しましょうみたいな話とか、まだ発展途上の言語なので、Flutterでできることできないことが結構たくさんあるんですけど、そういったところをすり合わせを随時しながら
やっていくっていうのが現状ちょっとできてきたんですけど。
やっぱり最初は、エンジニアさんは分からない。実装した後に絵文字ちっちゃくても気にしなかったりとかする方もいらっしゃるので、「いやちっちゃいんだけど」みたいな話とかをコミュニケーションを取るのが結構大変だったかなと思ってます。
▼デザインと実装の「乖離」とコミュニケーション
── デザインと実装に乖離が発生したとき、どのようにコミュニケーションをとっていますか。
DeNA 松田氏：
Voice Pocochaの場合は、Figmaでマスター、インディベロップメント、マージドという3つのデータを管理しています。
マスターのデータはほぼ100%世の中に出てる全画面がデザインで作られている状態を良しとして、実装されているものとFigmaがちゃんと合致しているのかどうかをめちゃくちゃ重要視しながら開発しています。インディベロップメントで開発・実装して、それをデザインQAとQAを行って、見た目通りに実装されてることを確認できたらマージドに移すという運用です。
マスターにデータを移してマージドに落としていくっていう作業をちゃんとみんなやろうねって話をしていて。エンジニアさんとやり取りしながら、完成したものをマージドに移していくっていう作業を行いつつ、実機とデザインの差分を洗い出したり、なくしていくっていう作業を結構してます。
── 実際に扱っているデータと運用、ぜひ一度見てみたいです。ビズリーチではいかがですか。
Visional 福田氏：
そうですね。乖離を生まない為に、未然に防ぐ仕組み化をうちのチームでは特にしていますね。トークン設定をエンジニアと一緒にする。で、そのトークンの管理はデザイナーが行うし、Figma上からFigmaTokensを使ってGitHub上にプッシュするみたいなことも全てデザイナーが一貫してやっている。
トークンの管理はデザイナー、Storybookでのコンポーネントの管理もデザイナーみたいな感じで、エンジニアが迷わなくて済むように、きちんとデザイナーがそこに入り込むというようなことをやってます。
テスト駆動開発もそうなんですけども、デザイナーが作ったデザインを元にテスト設計をみんなで開発の初めにやるっていうことをして、「未然に防ぐ」を結構やってますね。
── なるほど、すごく参考になります。エムスリーではいかがですか。
エムスリー大月氏：
デザインシステムを作ってると、そのルール通りに開発してくれることが主としてあると思うんですけど、たまにずれてたりとか、そのずれが意図的なのかどうかを見る目はデザイナーの方があると思っていて、意図がある時はエンジニアからももちろん相談してくれるし、僕からも「これ何なんですかね」って相談します。
意外と意図があるかないかっていうだけだと思うので、そこを見極めるっていうことだけはしていて。意図がある時はちゃんと聞いてみて、その結果デザインの方を改善した方がいいということも結構あるし、お互いに密にコミュニケーションを取り合ってやってるような感じですかね。人が少ないので。
── まさにコラボレーションですね。デザインデータのコンポーネントの粒度と実装のコンポーネントの粒度に乖離が発生することがあると思うのですが、そういった場合はどこまで追従しますか。もしくは乖離を起こさないような工夫があれば教えてください。
Visional 福田氏：
うちはトークン設定からコンポーネント設定まで本当にエンジニアの方と一緒にやるんですよ。ペアデザインぐらいの感じで一緒にやるので、実際に実装されるコンポーネントの粒度と、Figma上にあるコンポーネント粒度と、もちろんStorybook上で管理されてるコンポーネント粒度が綺麗に揃っていることを結構重視して作ってますね。設計段階から。
── たとえばデザイナー的にはこのデザインデータが作りやすいからこちらに寄せたいけど、でも実装しやすさではそちらに寄せたいみたいな時の揺れが起こった時、どちらが強いというのはありますか。
Visional 福田氏：
どっちも強い、どっちも意思があるんですよ。難しいですね。でも、やっぱり都度すり合わせるっていうところと、コンポーネントを作る上での大元の指針みたいなのをきちんと定めて目線合わせをするっていうことが大事なのかなと思ってますね。
──お二人はいかがですか。
エムスリー大月氏：
新規事業だったら、ずれてもなんとでも。とにかくやっぱり早く価値検証したいってところですね。
後から「リファクタ会やろうか」って一緒に集まってやればいいだけだと思うし、関係者がどんどん多くなってくるとやっぱそういう時間を取らないといけないなっていう時は何回もあって、その揺り返しは何回もありますね。
一回だけじゃなくてまたリファクタして、でもたまにちょっと暴れてみてみたいな。この繰り返しを何回もやってる。
DeNA 松田氏：
そうですね。先ほどお伝えした通りデザインのマスターが実装のマスターになっているので乖離はほぼないんですけど、さっきのエンジニアとデザイナーどっちが強いって話でいくと、我々的にはFlutterが一番強いんですよ。
デザイナーはやりたい、エンジニアもやりたい。でもFlutterでは実現できませんというのが起き得るんで、そうなったらそっちでみたいな。
最優先する事項はFlutterでどう実現できるかみたいなところを基軸にしながら話せるので、そこでの揺れが逆に起きづらいのかなとは思ってます。
──たしかに、実現できるものを作っていく上で避けて通れないポイントですね。ここまで共通認識の作り方についてお聞きしましたが、これまでの背景を知らない人、たとえば新しいエンジニアの方が増えたとき、ナレッジシェアはどのようにされてますか。
エムスリー大月氏：
オンボーディングする時にリファクタから入ってみるのも手かなと思っていて。属人化されたものを整理するところから入っていけば、自ずと共通言語がプロジェクトを通して生まれてくるのかなと。そういう意図的なプロジェクトを作るしかないのかなって思ってますね。そういう時は。巻き込みやすいようなプロジェクトを設計するしかないのかなっていう気がしてますかね。
Visional 福田氏：
うちは結構自主的に勉強会とかを開くメンバーが多くて。去年入った新卒のメンバーとかも、在籍年数の長い方も含めたエンジニア向けにFigma勉強会やりますよってみんな集めてFigmaの勉強会したりですとか。逆にエンジニアさんの方からトークン設定ってエンジニアはこういうこと考えてるんだよみたいなことを勉強会という形でデザイナーにインプットしてくれたりとか。そういう動きが結構うちは活発ですね。それでわりとフラットにしていくみたいなことはしてますね。
──メンバーが自主的に開催するのは良いですよね。DeNAではいかがですか。
DeNA 松田氏：
我々に関しては、プロダクトだけじゃなくて、キャラクターを使ってるサービスだったりもするので、デザインデータ全般のことを新しく入る人には学んで欲しいというところがあるので。その月に入った人に対して、1時間の3コマ〜4コマぐらいのクリエイティブの講義を用意していて。
キャラクターはこういう属性なんですとか、プロダクトはこう作ってるんですとか、例えば実装してデザインQAをして、リリースしてマスターにマージしますみたいな話を最初にしないと伝わらなかったりするので、そういったところを講義っていう形で担当セクションごとに分かれて資料を作りながらエンジニアさんにお伝えします。
それこそFigmaさんがアップデートすると思うんで、そのタイミングでまた資料書き直して、というのをやったりしてますね。
▼質疑応答
──「デザインとフロントエンド、密に一緒にやると、デザイナーが実装までやる、フロントエンドがデザインまでやるような開発フローにしたくなりますか？」
Visional 福田氏：
領域をぼかしていく開発体制を作っていくみたいなニュアンスの方がうちのチームは近いかもしれないです。ここまでがフロントエンドのフロー、ここまでがデザイナーのフローみたいに区切らないで、ぼかしていく。どっちもやるよみたいな感じですね。
──なるほど。松田さんはデザインの段階で実際にFlutterにさわることはありますか。
DeNA 松田氏：
Flutter自体がちょっと特殊というか、出てきはじめたぐらいから開発をスタートしたので。最初にFigmaのテキストを日本語と英語で入れて、それをエンジニアに全部1.0倍1.1倍1.5倍とか全部出してもらって、行間も何パーセントみたいなものをとりあえず一覧化して出して、隣でエンジニアと一緒に見ながら、言ったものをばーって作ってもらいながら、この1.0倍にしようとか、1.1倍にしようみたいな話を初期の開発フェーズでやってはいました。
自分がやるより絶対エンジニアが手を動かした方が速い。うちのエンジニアたち優秀な人が多いので。私も簡単なフロントは書けるんですけど、やっぱりうちのエンジニアやばい人が多いので、その人たちと比べると任せた方が絶対クオリティが上がるっていうのがうちの答えだと思ってます。
──大月さんはいかがですか。結構やられてるかなと思ったんですが。
エムスリー大月氏：
やるときはやるし、やらない時はもうデザインまでって決めるし、そのチームとかその時のバイブスみたいなのってあるじゃないですか。「今僕やっちゃおうかな」でやる時もあるし、めちゃくちゃAngularとReactが混在してて理解するのに時間かかっちゃうから、だったら自分はデザインを徹底して、ルールまで作って、後は任せたってやっちゃうとか。本当にエンジニアの状況によって、あと技術スタックとかの状況によって動き方とか、バイブスって言葉にしちゃったんですけど、やってます。
──三者三様な回答ですね。大月さん、福田さん、松田さん、本日はありがとうございました。
▼まとめ
デザイナーとエンジニアのコラボレーションは、その役割の違いから時に乖離が発生します。チーム特有の制約に対して、大事にすべきことの優先順位を明確にして、共通言語をいかに作り浸透させるのか。チームの規模やプロダクトの特徴に合わせた各社の工夫を垣間見ることのできるセッションでした。
▼セッション動画のご案内
この記事でご紹介したセッション動画全編をYouTubeでご覧いただけます。
Photo: 大竹宏明
｜関連記事｜