Product Discovery Skill

プロダクトの方向性を決める 8つの基盤情報 をヒアリング + コードベース分析で整理し、 product-context.md として出力する。

このドキュメントは、ペルソナ作成・LP設計・機能優先順位決定など、 あらゆるプロダクト意思決定の入力として使える。

なぜこのスキルが必要か

ペルソナ作成やマーケティング戦略を始める前に、以下が曖昧だと手戻りが発生する：

• 「誰向けのプロダクトか」が決まっていない → セグメント設計が空中戦になる
• 「競合との違い」が言語化されていない → 差別化の訴求ができない
• 「なぜ自分が作るか」が整理されていない → ストーリーが弱くなる

8つの基盤情報

必須（これがないと下流の意思決定ができない）

#	項目	問い	情報源
1	課題仮説	世の中のどんな問題を解決する？	ユーザーに聞く
2	ソリューション方向性	どうやって解決する？	コード + ユーザー
3	市場スコープ	どの地域・言語・業界を狙う？	ユーザーに聞く
4	原体験	なぜ自分がこれを作るのか？	ユーザーに聞く

あると精度が上がる

#	項目	問い	情報源
5	ビジネスモデル仮説	どう稼ぐ？	コード + ユーザー
6	競合・代替手段	ユーザーは今どうしてる？不満は？	ユーザーに聞く
7	プロダクトの現状	構想段階？MVP？成長期？	コード + ユーザー
8	差別化ポイント仮説	競合と何が違う？	ユーザーに聞く

---

ワークフロー

Phase 1: コードベース分析（該当する場合）

コードベースが存在する場合、以下のファイルを読んで自動で情報を抽出する。 コードがない場合（構想段階）は Phase 2 に進む。

読むべきファイル（優先順）:

1. README.md → プロダクト概要、機能リスト
2. package.json / Cargo.toml / pyproject.toml → 名前、説明、依存関係
3. CLAUDE.md → 開発方針、アーキテクチャ
4. ランディングページのコード（app/page.tsx, index.html 等）→ 訴求メッセージ
5. 環境設定ファイル → 使用サービス（決済、認証、AI等）からビジネスモデルの手がかり
6. DB スキーマ → データ構造からプロダクトの中核機能を推測

抽出する情報:

• プロダクト名
• コア機能の一覧
• 技術スタック
• 外部サービス連携（決済、AI API 等）
• 既存のユーザー向けテキスト（LP コピー、説明文）

抽出結果を「分かったこと」「推測（要確認）」「分からないこと」に分類する。

Phase 2: ユーザーヒアリング

AskUserQuestion を使って、Phase 1 で埋められなかった項目をヒアリングする。

ヒアリングの原則:

• コードから分かったことは確認として提示する（「〇〇という理解で合ってますか？」）
• 一度に聞く質問は 最大4つ まで（AskUserQuestion の制限）
• 必須4項目を先に聞き、あると良い4項目は後から聞く
• 選択肢を用意できる質問は選択肢を出す。自由回答が必要なものは Other で対応
• ユーザーの回答が曖昧な場合、掘り下げの質問を追加で行う

ヒアリング順序:

Round 1（必須項目）:

質問1: 課題仮説

このプロダクトは、どんな課題を解決しますか？ （コードから推測した場合）「〇〇という課題を解決するプロダクト」という理解で合ってますか？

質問2: ソリューション方向性

どうやってその課題を解決しますか？他のツールとの違いは？ （コードから推測した場合）機能一覧を提示して確認

質問3: 市場スコープ

メインのターゲット市場はどこですか？ 選択肢例: 日本市場 / 英語圏 / グローバル / 特定の業界

質問4: 原体験

なぜ自分がこのプロダクトを作ろうと思いましたか？きっかけや原体験は？

Round 2（あると良い項目）:

質問5: ビジネスモデル仮説

どうやって収益化する予定ですか？ 選択肢例: SaaS 月額 / フリーミアム / 買い切り / OSS + Open Core / 未定

質問6: 競合・代替手段

ユーザーは今どうやってこの課題を解決していますか？その方法の不満点は？

質問7: プロダクトの現状

今のプロダクトの状態は？ 選択肢例: アイデア段階 / プロトタイプ / MVP / リリース済み / 成長期

質問8: 差別化ポイント仮説

競合や代替手段と比べて、一番の違いは何だと思いますか？（まだ仮説でOK）

Phase 3: 整理と出力

ヒアリング結果を product-context.md として出力する。

出力先の決定:

• リポジトリがある場合: {リポジトリルート}/docs/product-context.md
• リポジトリがない場合: ユーザーに保存先を確認

出力時のルール:

• 必須4項目は必ず埋める。ユーザーが「分からない」と言った場合は [未定義 - 要検討] と明記
• あると良い4項目は、情報があれば埋める。なければセクション自体を「未整理」と明記
• コードから推測した情報は [コードから推測] タグをつける
• ユーザーの言葉をできるだけそのまま使う（言い換えすぎない）
• 事実と仮説を区別する

---

product-context.md テンプレート

# Product Context: {プロダクト名}

> 作成日: {YYYY-MM-DD}
> 最終更新: {YYYY-MM-DD}

## 1. 課題仮説

**解決する課題:**
{ユーザーの回答}

**この課題を持つ人:**
{誰がこの課題を持っているか}

**課題の深刻度:**
{あれば: どれくらい困っているか、頻度、代替手段の有無}

## 2. ソリューション方向性

**プロダクト概要:**
{何をするプロダクトか、1-2文で}

**コア機能:**
- {機能1}
- {機能2}
- {機能3}

**技術スタック:** {該当する場合}

## 3. 市場スコープ

**地域:** {日本 / 英語圏 / グローバル / その他}
**言語:** {日本語 / 英語 / 多言語}
**業界:** {特定業界 / 汎用}
**優先順位:** {Phase 1 でどこを狙うか}

## 4. 原体験

**なぜ作るのか:**
{ユーザーの原体験、きっかけ}

**自分自身の課題体験:**
{自分がユーザーとして感じた不満や課題}

## 5. ビジネスモデル仮説

**収益モデル:** {SaaS / フリーミアム / OSS + Open Core / 買い切り / 未定}
**価格帯:** {想定があれば}
**ターゲット顧客:** {個人 / チーム / 企業}

## 6. 競合・代替手段

**ユーザーの現在の解決方法:**
- {代替手段1}: {不満点}
- {代替手段2}: {不満点}

**直接競合:**
- {あれば}

## 7. プロダクトの現状

**ステージ:** {アイデア / プロトタイプ / MVP / リリース済み / 成長期}
**既存ユーザー:** {いればその規模・特徴}
**利用データ:** {あれば}

## 8. 差別化ポイント仮説

**一番の違い:**
{競合・代替手段との最大の差別化要因}

**なぜ代替手段では不十分か:**
{ユーザー視点での不満}

---

## メモ・補足

{ヒアリング中に出た補足情報、今後検討すべき点}

---

既存のコンテキストファイルがある場合

docs/product-context.md や .claude/persona-creation/*/context.md が既に存在する場合、 それを読み込んで不足項目のみヒアリングする。全項目を最初から聞き直さない。

他のスキルとの連携

このスキルで作成した product-context.md は以下のスキルの入力として使える:

• persona-creation: ペルソナ作成の前提情報として
• user-journey: ジャーニーマップのプロダクトコンテキストとして
• aso-optimize: ASO 最適化のプロダクト理解として
• feature-discussion: 機能検討のプロダクト方針として

各スキルを使う際、「product-context.md を読んでから始めて」と指示すると、 前提情報が揃った状態でスタートできる。