はじめに
株式会社StoreHero CTOの鳥居です。
サービスやプロダクト開発で頻発する「リリース後の使いづらさ」。弊社も長らくこの課題に悩まされてきました。
この記事では、その課題に対する弊社が取り組んだ新しいアプローチについて紹介します。
AIを活用してDesignDocと要件定義から実際に動くUIモックアップを爆速で作成し、ステークホルダーとのミスマッチを軽減する手法です。
記事の内容サマリ
-
従来の課題
- ユーザーニーズの把握不足によるリリース後のギャップ
- 上記対策により、要件調査に時間がかかり開発期間が長期化
-
解決策
- ドキュメントテンプレートを用いて、暗黙知を徹底的に排除
- AI（LLM）で「DesignDoc」と「要件定義書」のたたきを自動生成
- 生成された文書をもとにAIで動的UIモックアップ作成
従来プロセスが抱えていた2つの課題
1. リリース後に浮き彫りになる “ギャップ” 課題
サービス開発ではよくあることですが、リリース後に 「イメージと違う」 という声がたびたび上がりました。
チーム内で振り返ると、ユーザーニーズや業務フローを十分に咀嚼できておらず、DesignDoc と実際の UI に乖離があったことが主因と判断しました。
2. 時間的コストの増大
ギャップを埋めるために、ニーズ調査・業務理解・UI 設計へ工数を集中しました。
が、その結果、開発期間が想定より大幅に延び、チャーン率の上昇や市場機会の逸失リスクが高まっていました。
AIを使った新プロセスで何が変わったか？
1. 要件の徹底的な文書化
まず、サービス機能要件の優先順位や背景などについて、これまで暗黙知として扱われがちな情報をすべて文書化するプロセスを導入しました。
テンプレートに関しては後述します。
2. LLMを活用したドキュメント生成
次に、1.で整理された文書をLLMに渡し、DesignDocと要件定義書を自動生成してもらいます。
ある程度LLMにも補完をお願いしながら作ると、実際にそれっぽいドキュメントを生成してくれました。
もちろん、的はずれな記述もところどころ出てくるためそれらは手動で調整していきます。
なお、DesignDocのフォーマットはこちらの記事の基本構成参考にさせていただいております🙇
DesignDocイメージ
要件定義書イメージ
3. AIによるUIモックアップ生成
最後に、生成されたDesignDocと要件定義書を基に、AIがUIモックアップを作成します。ここでのポイントは「実際に動く」モックアップという点です。静的な成果物ではなく、インタラクションを含む動的なモックアップによって、ステークホルダーは自分のイメージと実際のプロダクトのギャップを早期に発見できます。
UIモックは Cline ＋ Claude 3.7 Sonnet を利用して生成しました。
0 > 1 のモック作成はCline便利すぎですね！
デザインドッグと要件定義書から、UIモックを作って欲しいです。
まずはHTMLとJSだけで動作すればそれで問題ないです。
仕様は、このフォルダから以下の場所にあるはずです。
見えますか？
../../design_doc.md
../../requirements.md
作る画面は「〇〇を行うCRUD画面」と「〇〇で閲覧用のカレンダービュー」が欲しいです。
まずは、計画を立ててください
何度かやり取りしたうえで、初回の成果物としては本当に１時間足らずで完成してしまいます。
実際の成果物のイメージはこちら↓
もちろん、きちんと動作します。
ほぼ調整無しで、ドキュメントからここまで構築できるの革命すぎです…！
AIを活用した開発プロセスをうまく回す3つのポイント
実際にこのプロセスを導入する際のポイントをいくつか紹介します。
要件の文書化テンプレート
要件を文書化する際は、以下のような項目を含めるようにしています
- 機能概要: 機能や業務フローの概要
-
信頼度・貢献度のスコアリング
- 以下の項目に関して 1-5 でスコアリングします
- 市場インパクト貢献度
- チャーンレート貢献度
- EC事業者 売上貢献度
- グロースパートナー[1]運用マッチ度
- 実際に、グロースパートナーが運用するイメージがあるか
- 以下の項目に関して 1-5 でスコアリングします
- 5W1H: 「誰が、何を、なぜ、どこで、どのように」提供するか
- EC事業者のマッチング条件: マッチする／しない条件を明記
- 優先する理由: なぜ今、この機能が必要か
これらの情報が揃っていると、LLMはより具体的で実用的なドキュメントを生成できます。
LLMへの指示方法
LLMに指示を出す際は、単に「DesignDocを作成して」と言うのではなく、具体的な形式や含めるべき内容を指定することで、より質の高いアウトプットが得られます。
例えば：
「以下の要件に基づき、1. システム概要、2. UI/UXの詳細設計、3. データフロー、4. エッジケースの取り扱いを含むDesignDocと要件定義書を作成してください」
といった具体的な指示が効果的です。
UIモックアップ生成のコツ
UIモックアップをAIに生成させる際は、単一の画面だけでなく、ユーザーフローやインタラクションも含めて指示することが重要です。
また、それらを一気にお願いするのではなく、一つ一つ丁寧にお願いするのがキモです。
特にClineはコードの微調整に関して難易度が上がることが多いので、これを意識するだけでプロセスの時間が大幅に変わります。
また、生成されたモックアップはあくまでUI/UX確認のための叩き台として扱い、きちんとしたデザインを整えるのはまた別プロセスで行う想定です。
導入効果
実は、まだこれは始めたばかりの段階で「やっぱりUIで確認できるの良いね！」という感想にとどまっています。
が、このプロセスを導入した暁には以下のような効果を期待しています。
ステークホルダーとの認識齟齬の減少
実際に動くモックアップを早い段階で見ることができるため、ステークホルダーはイメージと実装のギャップを早期に発見し、修正を指示できるようになります。これにより、リリース後の「思っていたのと違う」という問題が大幅に減少するはずです。
開発サイクルの短縮
一見すると、要件文書の作成やAIによるモックアップ生成に時間がかかるように思えますが、実際には「作り直し」のコストが減ることで、全体の開発期間は短縮される傾向にあります。特に、複雑な機能や新しいUIパラダイムを導入する場合、この効果は顕著です。
フィードバックの質の向上
抽象的な文書やワイヤーフレームではなく、実際に動くモックアップに対してフィードバックができるため、ステークホルダーからより具体的で実用的な意見を引き出せるようになるはずです。
課題と今後の展望
現状UIモックの作成で終わっていますが、MCPサーバを利用できるとシームレスに実際のプロダクトコードに反映できるのではないかと思っています。
最近ではデザインとMCPサーバの事例が多数出てきており、それらを参考にして弊社でもよりこの辺りのプロセスを高速化していきたいです。
まとめ
DesignDoc から “動く UI モックアップ” を自動生成するワークフローは、
ステークホルダーとの認識ズレを最小化し、開発スピードを大幅に引き上げる強力なアプローチです。
ただし AI に丸投げするのではなく、
- 要件を丁寧に言語化する（暗黙知を無くす）
- 生成された成果物を人の目で検証し、より精度を上げていく
このステップを徹底することが成功の鍵と考えます。
今年に入ってからの生成AIの進化は デザイン・コーディングを含む開発プロセスそのものを塗り替えつつあるなという実感が感じられます。
変化のスピードは凄まじいものの、継続的にキャッチアップし続けることでより高い価値を持つプロダクトを生み出せるはずです。
本記事が、皆さまのプロセス改善の一助となれば幸いです！
-
EC事業者と共に、売上を上げるための支援を行うメンバーです ↩︎
Discussion