プロダクトマネージャー（PM）という仕事は、デザインを作る立場ではないが、デザインに関わり続ける立場だ。ユーザーストーリーを書き、仕様を定義し、デザイナーに依頼し、出てきたデザインをレビューする——UIデザインは常に仕事の中心にある。なのに、UIを「作る」ことは自分の仕事ではないという感覚がずっとあった。
Google Stitch を使い始めたのは、「PMでも使える」という評判を聞いたからだ。デザインツールとしてではなく「UIを言語で操作するツール」として。3ヶ月使い続けた結果、仕事の何が変わって何が変わらなかったかを書く。
結論から言うと
Google Stitch を使い始めて最も変わったのは「デザイナーへの依頼の質」だった。仕様書に文字で書いていた要件を、Stitch で視覚化してから渡すようになったことで、認識齟齬と手戻りが大幅に減った。また「このUIは実現できるか」という判断を自分でできる場面が増え、デザイナーへの相談の前に自分で検証できるようになった。
PMがデザインに関わる場面と課題
PMとしての日常業務の中でデザインが絡む場面を整理すると、大きく4つある。①新機能の要件定義（「こういう画面が欲しい」を言語化する）、②デザインレビュー（デザイナーが作ったUIを評価する）、③ステークホルダーへの提案（UIのイメージを経営層や営業に伝える）、④エンジニアとの仕様確認（実装範囲と画面の対応を確認する）。
この4つのうち、私が特に難しさを感じていたのは①と③だった。①の要件定義で「言葉だけで伝える」ことの限界は常に感じていた。「シンプルなダッシュボード」「直感的に操作できる設定画面」という言葉は、書いた本人と読んだデザイナーで全く違うイメージを持つことがある。
言葉だけの仕様書が生む「解釈のズレ」
私が担当した案件で、「シンプルな通知設定画面」を依頼したところ、デザイナーが作ったUIと私のイメージが全然違っていた、というエピソードがある。どちらも間違っていない。ただ「シンプル」の解釈が違っただけだ。この認識齟齬の修正に2回分のデザインスプリントを費やした。
Stitch を使い始めてからは、要件定義書に「参考UI（Stitch生成）」を添付するようにした。「シンプル」を言葉ではなく視覚で共有することで、方向性の確認が最初のやりとりで完結するケースが増えた。
ステークホルダーへの説明に使う難しさ
経営層や営業へのUI説明は、Figmaのワイヤーフレームを見せても「完成形のイメージがわかない」と言われることが多かった。Stitch の出力は「完成に近い見た目」で出るため、非デザイナーでも直感的にイメージできる。提案の場で Stitch のスクリーンショットを資料に入れてから、「もっと具体的に見せてほしい」という要求が減った。
具体的にどう使っているか
PMとしての Stitch の使い方は、デザイナーとは少し違う。私は以下の3つのシーンで使っている。
要件定義のビジュアル化
新機能の要件定義をするとき、まず言語で仕様を書く。その後、Stitch でその仕様のUIを2〜3パターン生成して仕様書に添付する。デザイナーへの依頼では「このパターンを参考にしてほしい」という使い方だ。「参考UI」として機能させることで、デザイナーへの解釈の幅を適切に絞れる。
大事なのは「これが答えではなく方向性の参考」という前置きをすることだ。Stitch の出力をそのまま「これで作って」と渡すのではなく「このくらいのシンプルさ・情報量のイメージ」という文脈で使う。デザイナーの判断の余地を残しながら、方向性のズレを防ぐ使い方が機能している。
競合・ベンチマーク調査との組み合わせ
競合プロダクトのUI調査をするとき、Stitch を「仮説検証ツール」として使うようになった。競合サイトを見て「こういうUIが増えているな」と感じたとき、Stitch で同じ方向性のUIを生成し「これをウチに取り入れるとしたらどうなるか」を素早くイメージできる。
仕様書に「業界トレンドのUI参考：Stitch生成例」を添付するようになってから、企画レビューで「他社はどんなUIにしているか」という質問への回答がビジュアルで示せるようになった。議論の具体性が上がった。
ユーザーインタビューの前の仮説UI作成
ユーザーインタビューやユーザビリティテストの前に、仮説UIを見せてフィードバックを得ることがある。以前は「Figmaで作ってもらう→テスト実施」の間に数日かかっていた。Stitch で仮説UIを素早く作ることで、「明日のインタビューに間に合わせる」ことが可能になった。
インタビューで見せるUIのクオリティは「完成品に近い見た目」が重要で、ワイヤーフレームより Stitch の出力の方がユーザーの反応が具体的になる傾向があった。特に「この情報は必要か」「このボタンの意味がわかるか」という問いへの回答の質が上がった。
デザイナーとの関係に起きた変化
Stitch を使い始めてから、デザイナーとのやりとりが変わった。良い方向に変わった部分と、新しい課題が生まれた部分がある。
良い変化：最初の認識合わせが速くなった
デザイナーへの依頼時に「こういうイメージです」とビジュアルを添付することで、最初の認識合わせの会議が半分以下の時間になった。言葉だけで方向性を合わせようとすると「シンプルってどのくらいシンプルですか？」という確認が必要になる。視覚があれば「ここまでシンプル、という意味です」が一目で伝わる。
また、デザイナーが「それはデザインとして良くないです」というフィードバックを出しやすくなった。言葉で「シンプルに」と言われると反論しにくいが、ビジュアルに対してなら「このレイアウトは情報が欠けています」という具体的な指摘ができる。双方向の対話が早くなった。
新しい課題：「PMがUIを決めようとしている」という受け取られ方
一方で、デザイナーから「PMが作ったUIを直す仕事になっている」という不満が出たことがあった。Stitch の参考UIを「方向性の参考」として渡したつもりが、「これを直してください」という依頼として受け取られた。
これはツールの問題ではなく、コミュニケーションの問題だ。「これは私がイメージを確認するために作ったものであり、デザインの決定権はあなたにある」という前置きを毎回明確にすることで、関係性が改善した。Stitch を使う側の「役割認識」と、相手への「文脈共有」がセットで必要だと学んだ。
PMが Stitch を使ううえで意識していること
PMとして Stitch を使い続けるうえで、自分の中でルール化していることがある。
- Stitch の出力は「答え」ではなく「問い」として使う——「こういうUIもありますか？」という問いかけの道具として機能させる
- デザイナーへの参考UIは「方向性の共有」であり「決定の押しつけ」ではないことを毎回明示する
- Stitch で作ったUIのファイルを「仕様書の付録」として保存し、後から振り返れるようにする
- 「Stitch でUIを作れる」ことと「UIデザインができる」は別物と認識し、デザイナーの専門性を尊重する
よくある質問（FAQ）
Q1. PMがデザインツールを使うことへの抵抗はありましたか？
A. 最初はありました。「PMがデザインをいじるのはデザイナーの領域を侵すのでは」という懸念です。でも Stitch を使うのは「デザインを作るため」ではなく「コミュニケーションのため」という認識に変えることで、抵抗感が消えました。
Q2. デザイン経験のないPMでも Google Stitch は使えますか？
A. はい、使えます。むしろ「デザインの専門知識がない」PMほど、Stitch で仕様のビジュアル化をする価値が高いと感じています。言葉だけで伝えることの限界を、最も強く感じているのがデザイン非専門職だからです。
Q3. Stitch でPMが気をつけるべきことは何ですか？
A. 「出力をそのままデザイナーに渡さない」ことです。Stitch の出力をデザインの答えとして扱うと、デザイナーの専門性を活かせなくなります。「方向性の参考」として渡し、詳細設計はデザイナーに委ねることが重要です。
Q4. Stitch を使うことでデザイナーへの依頼数は変わりましたか？
A. 依頼数は変わりませんが、「確認・修正」のやりとり回数が減りました。最初の一回で方向性が合いやすくなったため、同じ結果を出すためのサイクル数が減った、という変化です。
Q5. Stitch で作ったUIをステークホルダーに見せることはありますか？
A. はい、積極的に使っています。ただし「AI生成の参考イメージです、実際のデザインはこれから作ります」という文脈を必ず添えます。この一言がないと「もう完成した？」という誤解が生まれることがあります。
Q6. PMとして Stitch の一番の価値は何でしたか？
A. 「仕様とUIの間の翻訳コストを下げること」が最大の価値でした。言葉で書いた仕様を視覚に変換する中間工程が、認識齟齬と手戻りの温床でした。Stitch はこの翻訳を自分でできるツールとして機能し、デザイナーとのやりとりの質と速度を同時に改善してくれました。
まとめ
PMが Google Stitch を使う意義は「デザインを作ること」ではなく「コミュニケーションを改善すること」にある。言葉だけで伝えていた要件をビジュアルで補完することで、デザイナーとの認識齟齬が減り、ステークホルダーへの説明が具体化し、ユーザー検証の速度が上がった。
デザインツールに触れることへの心理的ハードルは、使い始めてみると思ったより低かった。PMとして「デザインができる」を目指す必要はない。「UIをビジュアルで伝えられる」だけで十分に価値がある。まだ試したことがないPMには、まず要件定義書に1枚の Stitch スクリーンショットを添付するところから始めてみることをすすめたい。
