デザイナーとエンジニアの間にある「壁」は、多くの制作現場で長年の課題だ。デザイナーが作ったUIをエンジニアが実装しようとすると「これ、どうやって実装するの？」「このアニメーション、重くなるよ」「このフォント、ライセンス確認した？」というやりとりが必ず生まれる。
この壁を Google Stitch が変えるかもしれない——そう思って、エンジニアとデザイナーが同じツールを使って共同制作する実験をした。3ヶ月間の記録を整理する。
結論から言うと
Google Stitch を共通ツールとして使うことで、デザイナーとエンジニアの間の「翻訳コスト」が大幅に下がった。特に「この画面で何を実現したいか」の共通認識を早く作れるようになったことが大きかった。一方で、新しい課題として「Stitch の出力をどちらが責任を持って判断するか」という役割の曖昧さが生まれた。
実験の背景と前提
この実験をしたのは、3人チームだ。私（デザイナー）、フロントエンジニア1名、バックエンドエンジニア1名。担当プロジェクトはBtoBのSaaSプロダクトのUIリニューアルで、管理画面・ダッシュボード・設定画面など20以上の画面を再設計する大規模なものだった。
従来の制作フローは「デザイナーがFigmaで全画面を設計→エンジニアに渡す→フィードバック→修正→実装」だった。この方法では、Figmaに触れるのがデザイナーだけのため、エンジニアは完成したデザインを見て初めて「実装上の問題」を指摘できる。問題が発覚するタイミングが遅く、大きな手戻りが発生することが多かった。
Google Stitch を共通ツールとして選んだ理由
Stitch を選んだのは「エンジニアでも触りやすい」という直感からだ。Figmaはデザイナーツールとしての入門コストが高く、エンジニアが自発的に触ることは少ない。しかし Stitch は「自然言語でUIを指定する」という操作感で、プログラミングのコメント記述に近い感覚がある。エンジニアが「自分の言葉でUI要件を表現できる」可能性を感じた。
実際に試してみると、フロントエンジニアは「Flexboxで横並びにして、レスポンシブで縦積みに変わる3カラムレイアウト」というプロンプトを自然に書いてきた。デザイナーよりもエンジニアの方が、実装ベースのプロンプトが得意という発見があった。
実験の進め方
実験期間は3ヶ月。最初の1ヶ月はそれぞれ個別に Stitch を使って同じ画面のUIを作り、後から見比べる形式を取った。2ヶ月目からは同じ画面を一緒に作るペアワーク形式に移行した。最後の1ヶ月は「Stitch を起点にして、Figma・実装・コードレビューまでつなげる通し実験」を行った。
デザイナーとエンジニアで、Stitch の使い方がどう違うか
1ヶ月目の個別実験で、デザイナーとエンジニアのプロンプトの違いが明確になった。
デザイナーのプロンプトは「ビジュアル先行」だった。「ミニマルで情報密度が高い、B2Bアプリ向けのダッシュボード。カラーはブルーとグレーのモノトーン。左サイドナビゲーション付き」のように、見た目・トーン・雰囲気から入る。
エンジニアのプロンプトは「機能先行」だった。「ユーザーが月次レポートを確認する管理画面。グラフ2個（折れ線・棒グラフ）、データテーブル、フィルター機能、エクスポートボタンを含む」のように、何ができるかから入る。
どちらが良い悪いではなく、この2つのアプローチを組み合わせたプロンプトが最も質の高いUIを生成した。「見た目・トーン（デザイナー視点）＋機能・データ構造（エンジニア視点）」を両方含めたプロンプトは、実用的かつ見た目も良いUIを生み出した。
エンジニアが気づく「実装上の問題」が早くなった
2ヶ月目のペアワーク形式で最も効果が出たのは、「実装上の問題の早期発見」だった。Stitch でUIの初稿ができた段階で、エンジニアが「このドロップダウン、APIのレスポンス待ちの間どう見せる？」「このテーブル、100件以上になったときのページネーションは？」という問いを出すようになった。
従来のフローなら、Figmaで完成した画面を渡した後に同じ指摘が来る。その時点から修正すると大きな手戻りになる。Stitch の初稿段階でこれらの問いが出ることで、Figmaに入る前に要件が整理できた。これは想定以上の効果だった。
「共通言語」としての Stitch の効果
Stitch 上でUIを一緒に見ながら会話することで、「デザインの話をするための共通言語」が生まれた。従来は「デザイナーがFigmaで説明→エンジニアがイメージで受け取る」という非対称なコミュニケーションだった。Stitch を使うと「このプロンプトを変えたらこうなる」という試行錯誤を一緒にできる。UIの話を「操作しながら」できるようになった。
3ヶ月の実験で見えてきた課題
実験を通じて、良い変化だけでなく新しい課題も見えてきた。正直に書く。
「誰が最終判断するか」が曖昧になった
Stitch を一緒に使うことで、デザイナーとエンジニアがほぼ同じレベルでUIを作れるようになった。これは効率化の観点からは良いことだが、「最終的なUIの判断はデザイナーがする」という暗黙の前提が崩れた。エンジニアが「こっちの方が実装しやすい」と言い、デザイナーが「でもこっちの方が見た目が良い」と言う——この判断をどこで下すかが曖昧なまま進むことが増えた。
解決策として、「機能要件はエンジニアが、ビジュアル要件はデザイナーが最終判断する」というルールを明文化した。Stitch の生成結果をそのまま採用するかどうかは、画面の性質によって判断者を分けるようにした。
バックエンドエンジニアの関与が難しかった
フロントエンジニアはUIの操作感があるため Stitch への参加が自然だった。しかしバックエンドエンジニアは「UIを作る」という感覚がそもそも薄く、Stitch の使い方に戸惑った。「APIのレスポンス設計から考えたいのに、UIから入るのが違和感」という言葉があった。
バックエンドの参加は「Stitch で作ったUIを見て、APIの設計課題を指摘する」という役割に限定したところ、関与しやすくなった。すべての職種が同じ使い方をする必要はない、という気づきだった。
3ヶ月後の制作プロセスの変化
実験前後でチームの制作プロセスがどう変わったか、具体的に整理する。
- 変わったこと1：デザインレビューが早くなった——Stitch の初稿を共有するとエンジニアからすぐにフィードバックが来るようになった。「明日Figmaで見せる」から「今日Stitch で確認できる」への変化
- 変わったこと2：仕様の抜け漏れが減った——エンジニアがUIを実際に触ることで、設計段階で考慮されていなかった状態（エラー状態・空状態・ローディング状態）の指摘が早くなった
- 変わったこと3：会議の密度が上がった——「この画面をどうするか」の会議で、Stitch を操作しながら話せるようになり、「言葉だけで議論する」ことが減った
- 変わらなかったこと：Figmaの工数——Figmaに移してからの詳細設計・コンポーネント化の工数は変わらなかった。Stitch で「早く方向性を決められた」分、Figma作業の質が上がった感覚はある
よくある質問（FAQ）
Q1. エンジニアが Google Stitch を使うにはデザイン知識が必要ですか？
A. 基本的な使い方であれば不要です。プログラムを書くように「何を実現したいか」を言語化できれば、UIの初稿を生成できます。ただし、生成されたUIの質を評価するには最低限のUI/UX感覚が必要なため、デザイナーと一緒に使う形式が最もハードルが低いです。
Q2. Stitch を使うことでFigmaが不要になりますか？
A. 現時点では不要にはなりません。Stitch はビジュアルの方向性を決めるフェーズに強いですが、コンポーネント管理・デザインシステム構築・エンジニアへの実装指示にはFigmaの機能が必要です。Stitch とFigmaを組み合わせることで、それぞれの強みを活かした制作が可能です。
Q3. ペアワーク形式で Stitch を使う場合、どんなセットアップが必要ですか？
A. 特別なセットアップは不要です。画面共有しながら一方が操作し、もう一方がフィードバックする形式が最もシンプルでした。Google Meet や Zoom の画面共有で十分に機能しました。リモートチームでも問題なく実施できます。
Q4. デザイナーとエンジニアでは、Stitch を使ったプロンプトのクオリティに差がありますか？
A. 「差がある」というより「得意分野が違う」という表現の方が正確です。デザイナーはビジュアル要件、エンジニアは機能・データ要件のプロンプトが得意です。互いの視点を組み合わせたプロンプトが最も良い結果を出しました。
Q5. Stitch でのコラボレーションに向いていない職種はありますか？
A. 「UI自体に関心が薄い職種」は参加のモチベーションが下がりやすい傾向がありました。バックエンドエンジニアやデータエンジニアは「UIの生成」より「Stitch が生成したUIへの技術的な評価」という形で参加する方が自然でした。全員が同じ形で使う必要はなく、職種ごとの関与度を調整することが大切です。
Q6. Stitch を使ったコラボレーションを始めるにあたって最初にやるべきことは？
A. 小さなテーマで一緒に試すことです。「この1つの画面だけ、一緒に Stitch でたたき台を作ってみよう」という限定的な実験から始めることで、ツールへの慣れと協力プロセスの確認を同時にできます。最初から全画面を Stitch でやろうとせず、試験的な1画面から始めることを強くすすめます。
まとめ
エンジニアとデザイナーが Google Stitch を一緒に使った3ヶ月間は、想定以上に「職種間の壁を低くする」体験だった。完全になくなったわけではないが、会話のスタート地点が同じになったことで、コミュニケーションの質と速度が変わった。
UIデザインのコラボレーションに課題を感じているチームには、まず小さな実験として試してみることをすすめたい。Stitch は「使いこなすためのツール」というより「一緒に話すためのツール」として使ったとき、チームにとっての価値が最大化される、と感じている。
