デザインへの越境 - 全エンジニアへのFigma提供と効果

Product Engineering Night #8
https://product-engineer.connpass.com/event/349157/

Transcript

1. Product Engineering Night #8 デザインへの越境。 全エンジニアへのFigma提供と効果 取締役 CTO 丹羽 健
3. 受注 配車 帳票 労務 経営 ダッシュボード 解析 レポート 点検・整備 請求 ドライバー アプリ 業務の効率化 と 経営の高度化 を 同時に実現するオールインワンSaaS
4. PdEにとっての越境とは プロダクトエンジニアにとっての越境とは何か？ プロダクトエンジニアは「機能を作る人」ではなく、プロダクト体験の構造を創る人 š プロダクトエンジニアが向き合う3つの領域¤ š Technology：単なる実装ではなく、構造への反映r š UX Design：画面の美しさではなく、体験の論理| š Domain：業務そのものを理解し、制約を設計に落とすr š この3領域を“越境”できることでƒ š 意思決定のサイクルが自分の中で完結するようにな’ š 開発チーム内の翻訳コストが減り、認識齟齬が減る 越境とは手を広げることではなく、自分の中の思考の幅と行動を一致させる行為。
5. エンジニア x デザイン エンジニアがデザインを学ぶと何が良いのか プロダクトエンジニアはUIの実装者ではなく、情報構造の設計者
 デザインを理解することで “プロダクトの内部構造と外部表現を接続する” 能力を得られる  デザインの知識を持つことで、エンジニアは”  UIコンポーネントの再利用性と拡張性を設計できx  実装前の「認識のズレ」を図解や言語で調整できx  特にFigmaやFigJamの導入により、 ¡  「設計の曖昧さ」をモックで可視化することが可能になっ  エンジニア側から“デザインレビュー”を仕掛けられるようになった プロダクトエンジニアがデザインを学ぶのは、   “UIを作れるようになるため”ではなく、“体験を考えられるようになるため”である。
6. 組織的効果 エンジニアがデザインを学ぶことで起きた組織的効果 プロダクトエンジニアの越境により、チーム全体の“設計解像度”を引き上げられる。
 エンジニアがデザインの文脈を理解できることで、チーム内の会話の粒度が変わり、
 設計・実装・検証の全ての解像度が高めることができた。  UIの作り直しが明確に減Å  実装前にモックで認識統一されているた˜  要件定義の抽象度が上がっ¶  「どう動くか」より「どう使われるか」の議論ができるようになっ¶  再利用を前提としたUI構造提案が増え¶  PdE起点でデザインパターンを定義する流れが生まれ¶  エンジニアとデザイナーのやりとりが“レビュー”から“共創”に変わ¿  情報構造を議論できる共通言語が育った
7. Figma導入ステップ 「描いて考える」ためにFigmaを全エンジニアに提供 パワポや手描きでは、議論と認識共有が浅くなる。   “描きながら考える道具”と“考えを高度にビジュアル化する道具”を必要とした « 従来は手描き・パワポベースのやり取りが主だっx « “完成図”としてのUIではなく、“議論のたたき台”としてのモックが必要だっx « Figmaは意外と軽く使え、仮説の可視化と共有ができるツールとしても有¥ « Flexの考えを理解していれば、
 制約ベースで要素を配置できるFigmaはエンジニアにとって使いやすいツール´ « 結果的に、プロダクトエンジニアが「考えを描く」文化の出発点となった
8. Figma導入ステップ Figma導入のステップ①（準備フェーズ） まずは「サンプル」を整える。エンジニアが自走して学べる環境づくりから始めた t 副業デザイナーに依頼し、既存画面のFigmaモックを何パターンか作™ t 頻出UIパターンを抜き出して、簡易なパーツ群を整f t デザインシステムほど厳密ではないが、費用対効果の安い「参考図」としての役ƒ t Figmaは自由度が高いため、まず自由に使ってもらうのではなく、
 開発している画面のサンプルを元に、実利用する機能の理解から始めた。
9. Figma導入ステップ Figma導入のステップ②（実践フェーズ） 使って覚える流れを中心として、エンジニア全員でモック作成で練習大会。 講習だけでは身につかない。 「自分の案件でモックを描く」ことが、最も強い学習だった。 ¢ 全エンジニアにFigma有料アカウントを配† ¢ 2回のFigma利用方法勉強会を開催し、基本操作を共¡ ¢ 各エンジニアに「自分が担当した画面」をFigmaで描いてもらŸ ¢ 自身が担当する画面をモック化することで、
 フロントエンドのDOM構造との関連の高さや、デザイン構造の理解を深めていった
10. Figma導入による効果 Figma導入の直接的な効果 当たり前の話だが、モックを“描いて見せる”ことで、認識が揃い、スピードが上がった
 文字では曖昧だった仕様も、モックにすると一発で伝わる。   PdE・PM・CS・Bizの全員が同じ画面を前に議論できるようになった。 ‘ モックがあることで、言葉のすれ違いが激Ž ‘ 議論の前提が“空想ベース”から“画面ベース”に変わっz ‘ PdMやCSとの会話の精度が上がり、細かい要件の確定が早期© ‘ UIの「雰囲気」ではなく「構造」単位で議論できるように
11. PdEにとっての越境とは 余談：Figma導入による副次的効果 モックから始まり、構造の“見える化”が進みはじめた Figmaの導入はモックに留まらず、プロダクト設計そのものの可視化にまで波及している。 ‘ FigJamで業務フローやドメイン構造の整理が進ん ‘ ユーザー体験のジャーニーが図として共有されるようになっŸ ‘ PdEの中には、v0やCursor Agentでプロトタイプ → 検証まで進めた例u ‘ （プロトタイプ検証の後には、本実装は実施… ‘ 「図で考える」が文化として根づき始めている
12. PdEにとっての越境とは 今後の展望：LLMとUI設計の民主化 LLMや生成AIにより、UI/デザイン設計の民主化をもっと進めていく。 だからこそ、プロダクトエンジニアによる顧客体験への思考力と意思決定が重要となる。 Ä GPT + MCP によって、Figma・コード・設計が接続し始めてい¢ Ä 「モックを作って」「このUIに合わせてAPIを設計して」が現実になってい¢ Ä v0やCursor Agentのような生成UIツールも活用が進んでい¢ Ä しかし、それらはあくまで部品の出力装置にすぎな¦ Ä 「構造をなぜそうするのか」「この仕様で何が起きるのか」の理解・意思決定が重要Ô Ä 顧客体験の追求とプロダクト実装の整合こそが、
 プロダクトエンジニアが担うべき本質的価値である
13. まとめ まとめ：PdEにFigmaを配って得られたもの PdEにFigmaを配った結果、 “開発と体験”の距離が、縮まった。 Figmaは単なるツールではなく、図で考える思考のプラットフォームとなった。  PdEが自分でモックを描くことで‘  認識ズレを減らし、実装効率が上がっ|  UIの設計方針を自ら思考できるようになっ|  顧客検証までをエンジニア自身でも素早く回せるようになっ|  結果として、プロダクトの実装構造と体験の接続密度が上がっ|  チーム内の言語も「言葉」だけではなく「図」で語られるようになった