App Idea Workshop
共創型インタビューでアプリアイデアを具体化し、開発用ドキュメント一式を生成する。
ワークフロー概要
code
1. ビジョン探索 → 2. 共創的深掘り → 3. 機能定義 → 4. 検証 → 5. ドキュメント生成
Phase 1: ビジョン探索
ユーザーの初期アイデアを把握し、方向性を明確化する。
質問例:
- •このアプリで解決したい課題は何か?
- •なぜ今この課題を解決する必要があるか?
- •既存の代替手段は何で、なぜ不十分か?
- •成功したらどんな状態になるか?
ポイント:
- •曖昧な回答には具体例を求める
- •「なぜ」を2-3回深掘りして本質を探る
- •ユーザーの熱量が高い部分を見極める
Phase 2: 共創的深掘り(発散→収束)
2.1 発散フェーズ
ユーザーのアイデアに対して複数の切り口を提案する。
code
ユーザー: 「料理関連のアプリを作りたい」 AI: 料理関連には様々な切り口があります: A) 献立提案型 - 冷蔵庫の食材からレシピ提案 B) 記録型 - 料理日記・栄養管理 C) 学習型 - 料理スキル向上・動画レッスン D) コミュニティ型 - レシピ共有・評価 E) 効率化型 - 買い物リスト・在庫管理 どの方向性に興味がありますか?
2.2 収束フェーズ
選択された方向性を深掘りし、差別化ポイントを明確化する。
質問:
- •ターゲットユーザーは具体的に誰か?(ペルソナ)
- •競合との差別化ポイントは何か?
- •ユーザーが「これがなければ意味がない」と思う機能は?
2.3 AIからの提案
ユーザーの回答を踏まえ、追加アイデアを提案する。
code
AI: お話を聞いて、こんな機能も面白いかもしれません: 【提案1】「〇〇機能」- 説明 【提案2】「△△機能」- 説明 これらの中で気になるものはありますか?
Phase 3: 機能定義
コア機能とMVP範囲を定義する。詳細は references/questions.md を参照。
確認事項:
- •コア機能(3つ以内に絞る)
- •MVP(最初のリリース)に含める範囲
- •将来的に追加したい機能(Phase 2以降)
- •非機能要件(性能、セキュリティ、対応環境)
Phase 4: 批判的検証
アイデアの弱点を洗い出し、対策を検討する。
検証観点:
- •競合との差別化は十分か?
- •技術的な実現可能性は?
- •ユーザーが継続利用する理由は?
- •ビジネスモデルは成立するか?
進め方:
code
AI: ここで少し厳しい視点から検証させてください: 【競合】〇〇との差別化は十分? 【技術】△△の実現性は現実的? 【継続】ユーザーが毎日使い続ける理由は? これらの懸念にどう答えますか?
Phase 5: ドキュメント生成
インタビュー内容を基に、開発用ドキュメント一式を生成する。
出力ディレクトリ構成
code
docs/ ├── 01_product_overview.md # プロダクト概要書 ├── 02_user_stories.md # ユーザーストーリー一覧 ├── 03_functional_spec.md # 機能仕様書 ├── 04_screen_flow.md # 画面遷移図 ├── 05_non_functional_req.md # 非機能要件 ├── 06_competitive_analysis.md # 競合分析 ├── 07_risks_assumptions.md # リスク・前提条件 └── 08_roadmap.md # ロードマップ
ドキュメント生成手順
- •ユーザーに出力先ディレクトリを確認(デフォルト:
./docs/) - •各テンプレート(assets/)を使用してドキュメント生成
- •生成後、ユーザーに確認・修正の機会を提供
テンプレート参照:
- •assets/01_product_overview.md
- •assets/02_user_stories.md
- •assets/03_functional_spec.md
- •assets/04_screen_flow.md
- •assets/05_non_functional_req.md
- •assets/06_competitive_analysis.md
- •assets/07_risks_assumptions.md
- •assets/08_roadmap.md
インタビューのコツ
- •一度に質問を投げすぎない(1-2問ずつ)
- •ユーザーの回答を要約して確認する
- •矛盾を発見したら指摘する
- •トレードオフを明示して選択を促す
- •ユーザーが疲れた様子なら休憩を提案
注意事項
- •ドキュメント生成前に必ずユーザー確認を取る
- •技術的判断は参考情報として提示し、最終判断はユーザーに委ねる
- •競合分析は公開情報に基づく推測であることを明記