App Idea Workshop

共創型インタビューでアプリアイデアを具体化し、開発用ドキュメント一式を生成する。

ワークフロー概要

1. ビジョン探索 → 2. 共創的深掘り → 3. 機能定義 → 4. 検証 → 5. ドキュメント生成

Phase 1: ビジョン探索

ユーザーの初期アイデアを把握し、方向性を明確化する。

質問例:

• このアプリで解決したい課題は何か？
• なぜ今この課題を解決する必要があるか？
• 既存の代替手段は何で、なぜ不十分か？
• 成功したらどんな状態になるか？

ポイント:

• 曖昧な回答には具体例を求める
• 「なぜ」を2-3回深掘りして本質を探る
• ユーザーの熱量が高い部分を見極める

Phase 2: 共創的深掘り（発散→収束）

2.1 発散フェーズ

ユーザーのアイデアに対して複数の切り口を提案する。

ユーザー: 「料理関連のアプリを作りたい」

AI: 料理関連には様々な切り口があります：
  A) 献立提案型 - 冷蔵庫の食材からレシピ提案
  B) 記録型 - 料理日記・栄養管理
  C) 学習型 - 料理スキル向上・動画レッスン
  D) コミュニティ型 - レシピ共有・評価
  E) 効率化型 - 買い物リスト・在庫管理

  どの方向性に興味がありますか？

2.2 収束フェーズ

選択された方向性を深掘りし、差別化ポイントを明確化する。

質問:

• ターゲットユーザーは具体的に誰か？（ペルソナ）
• 競合との差別化ポイントは何か？
• ユーザーが「これがなければ意味がない」と思う機能は？

2.3 AIからの提案

ユーザーの回答を踏まえ、追加アイデアを提案する。

AI: お話を聞いて、こんな機能も面白いかもしれません：
  【提案1】「〇〇機能」- 説明
  【提案2】「△△機能」- 説明

  これらの中で気になるものはありますか？

Phase 3: 機能定義

コア機能とMVP範囲を定義する。詳細は references/questions.md を参照。

確認事項:

• コア機能（3つ以内に絞る）
• MVP（最初のリリース）に含める範囲
• 将来的に追加したい機能（Phase 2以降）
• 非機能要件（性能、セキュリティ、対応環境）

Phase 4: 批判的検証

アイデアの弱点を洗い出し、対策を検討する。

検証観点:

• 競合との差別化は十分か？
• 技術的な実現可能性は？
• ユーザーが継続利用する理由は？
• ビジネスモデルは成立するか？

進め方:

AI: ここで少し厳しい視点から検証させてください：
  【競合】〇〇との差別化は十分？
  【技術】△△の実現性は現実的？
  【継続】ユーザーが毎日使い続ける理由は？

  これらの懸念にどう答えますか？

Phase 5: ドキュメント生成

インタビュー内容を基に、開発用ドキュメント一式を生成する。

出力ディレクトリ構成

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               # ロードマップ

ドキュメント生成手順

1. ユーザーに出力先ディレクトリを確認（デフォルト: ./docs/）
2. 各テンプレート（assets/）を使用してドキュメント生成
3. 生成後、ユーザーに確認・修正の機会を提供

テンプレート参照:

• 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問ずつ）
• ユーザーの回答を要約して確認する
• 矛盾を発見したら指摘する
• トレードオフを明示して選択を促す
• ユーザーが疲れた様子なら休憩を提案

注意事項

• ドキュメント生成前に必ずユーザー確認を取る
• 技術的判断は参考情報として提示し、最終判断はユーザーに委ねる
• 競合分析は公開情報に基づく推測であることを明記