# App Idea Workshop

> Web/モバイルアプリのアイデアを共創型インタビューで具体化し、開発用ドキュメント一式を生成するスキル。「アプリのアイデアがある」「新しいサービスを考えたい」「仕様を固めたい」「アプリ開発の相談」と言った時に使用する。アイデア段階から開発着手可能なドキュメントまで一貫してサポート。

- Skill: `majiayu000/app-idea-workshop` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/app-idea-workshop`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/app-idea-workshop/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/app-idea-workshop

---


# 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](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/](assets/)）を使用してドキュメント生成
3. 生成後、ユーザーに確認・修正の機会を提供

**テンプレート参照**:
- [assets/01_product_overview.md](assets/01_product_overview.md)
- [assets/02_user_stories.md](assets/02_user_stories.md)
- [assets/03_functional_spec.md](assets/03_functional_spec.md)
- [assets/04_screen_flow.md](assets/04_screen_flow.md)
- [assets/05_non_functional_req.md](assets/05_non_functional_req.md)
- [assets/06_competitive_analysis.md](assets/06_competitive_analysis.md)
- [assets/07_risks_assumptions.md](assets/07_risks_assumptions.md)
- [assets/08_roadmap.md](assets/08_roadmap.md)

## インタビューのコツ

- 一度に質問を投げすぎない（1-2問ずつ）
- ユーザーの回答を要約して確認する
- 矛盾を発見したら指摘する
- トレードオフを明示して選択を促す
- ユーザーが疲れた様子なら休憩を提案

## 注意事項

- ドキュメント生成前に必ずユーザー確認を取る
- 技術的判断は参考情報として提示し、最終判断はユーザーに委ねる
- 競合分析は公開情報に基づく推測であることを明記

