mcpField
D
discovery-process

discovery-process

github.com/deanpeters生産性7.7k3.2k 回インストール2 週間前に更新
リポジトリ

discovery-process について

discovery-processは、問題設定、顧客調査、インサイトの統合、解決策の検討と検証を継続的なディスカバリーワークフローとしてまとめるプロダクトマネージャー向けスキルです。開発に着手する前に仮説を検証し、構築、方向転換、中止を判断できるよう支援します。

主な機能

  1. 01問題を定義し仮説を設定
  2. 02顧客インタビューを計画・実施
  3. 03インタビューとサポート・利用データを統合
  4. 04顧客の課題を整理して優先順位付け
  5. 05解決策を検証する実験を設計
  6. 06構築・方向転換・中止の判断を支援

活用シーン

  1. 01顧客の継続率や離脱の問題を調査
  2. 02新しい製品や機能領域を検討
  3. 03ロードマップ決定前に問題仮説を検証
  4. 04実験で解決策のコンセプトを検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/deanpeters/product-manager-skills --skill discovery-process

インストール後、Claude Code で/discovery-processを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

template.md
examples/
sample-lifesciences.md
sample.md

詳細

目的

問題の初期仮説から検証済みのソリューションに至るまで、問題の整理、顧客インタビュー、統合、実験の各スキルを構造化されたプロセスとして組み合わせ、プロダクトマネージャーの一連のディスカバリーサイクルを支援します。問題領域を体系的に探り、前提を検証し、本格的な開発に踏み切る前に確信を高めるために活用してください。「作れば顧客が来る」という思い込みを避け、顧客の実際の問題を解決できるようにします。

これは一度きりの調査プロジェクトではなく、通常は四半期ごとに1～2回のディスカバリーサイクルを実施し、デリバリーと並行して続けるディスカバリーの実践です。

入力

最適な入力： 出発点となる問題仮説。大まかなものでも構いません。 あると便利な情報： これまでの調査、顧客へのアクセス手段、スケジュール、ディスカバリーを通じて判断すべき事項。

呼び出し時に渡された内容（スキル名の後に続くテキスト、貼り付けたコンテキスト、追加された ARGUMENTS: 行など）は、すでに回答済みの情報として扱います。その内容を活用し、該当する質問は繰り返さないでください。

何も準備していなくても大丈夫です。 ワークフローは問題の整理から始まり、まず仮説を立てるところを支援します。

呼び出し例： Run discovery on this hypothesis: SMB admins abandon onboarding because the data-import step requires IT help they don't have.

主な概念

ディスカバリープロセスとは？

ディスカバリープロセス（Teresa Torres、Marty Cagan）は、構築前に問題領域を探り、ソリューションを検証するための構造化されたアプローチです。次のステップで構成されます。

  1. 問題を整理する — 調査する内容とその理由を定義します
  2. 調査を実施する — 定性的および定量的な根拠を集めます
  3. インサイトを統合する — パターン、課題、機会を特定します
  4. ソリューションを生み出す — 複数のソリューション案を検討します
  5. ソリューションを検証する — 実験を通じて前提をテストします
  6. 決定して記録する — 構築、方向転換、中止のいずれかを決定します
効果がある理由
  • プロダクトの意思決定に伴うリスクを低減します： コストのかかる開発に着手する前に前提をテストします
  • 顧客中心です： 社内の意見ではなく、顧客の実際の問題に基づいて意思決定します
  • 反復的です： 小さな実験を通じて、段階的に確信を高めます
  • 素早く学べます： 「進めない」判断につながる兆候を早期に見つけ、無駄な労力を減らします
アンチパターン（これは何ではないか）
  • ウォーターフォール型の調査ではありません： ディスカバリーは開発前に一度行うのではなく、継続的に実施します
  • ユーザーテストではありません： ディスカバリーでは問題を検証し、テストではソリューションを検証します
  • リリースの代わりにはなりません： ディスカバリーはデリバリーの判断材料になりますが、デリバリーに取って代わるものではありません
これを使う場面
  • 新しいプロダクトや機能の領域を探るとき
  • 継続率や解約の問題を調査するとき
  • ロードマップに組み込む前に、戦略的な取り組みを検証するとき
  • 継続的なディスカバリーを行うとき（毎週の顧客との接点）
これを使わない場面
  • 十分に理解されている問題（実行に進みます）
  • ステークホルダーがすでにソリューションに合意している場合（まず認識をすり合わせます）
  • 戦術的なバグ修正や技術的負債への対応（ディスカバリーは不要です）
ファシリテーションの基準

このワークフローをガイド付きの会話として進める場合は、やり取りのプロトコルとして workshop-facilitation を使用してください。

次の項目が定義されています。

  • セッションの事前案内と開始モード（Guided、Context dump、Best guess）
  • 平易な言葉によるプロンプトを使った、1ターンにつき1つの質問
  • 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
  • 割り込みへの対応と一時停止・再開の動作
  • 意思決定の場面での番号付きの推奨事項
  • 通常の質問に対する、番号付きの簡単に選べる回答候補（必要に応じて Other (specify) を含めます）

このファイルでは、ワークフローの手順と、ドメイン固有の出力を定義します。矛盾がある場合は、このファイルのワークフローのロジックに従ってください。

適用

入力項目をすべて記入できる構成については、template.md を使用してください。

このワークフローでは、複数のコンポーネントスキルとインタラクティブスキルを使用して、2～4週間で6つのフェーズを進めます。

フェーズ 1：課題を明確にする（1～2 日目）

目標： 調査対象、影響を受ける人、成功基準を定義します。

アクティビティ

1. 課題整理キャンバスを実施する

  • 使用するもの： skills/problem-framing-canvas/SKILL.md（インタラクティブ - MITRE）
  • 参加者： PM、デザイン担当者、エンジニアリングリード
  • 所要時間： 120 分
  • 成果物： 問題の定義と「How Might We（どうすれば～できるか）」の問い

2. 正式な問題の定義を作成する

  • 使用するもの： skills/problem-statement/SKILL.md（コンポーネント）
  • 参加者： PM
  • 所要時間： 30 分
  • 成果物： 仮説を含む構造化された問題の定義

3. プロトペルソナを定義する（必要な場合）

  • 使用するもの： skills/proto-persona/SKILL.md（コンポーネント）
  • 実施するタイミング： 対象となる顧客セグメントが不明確な場合
  • 所要時間： 60 分
  • 成果物： 仮説に基づくペルソナ

4. Jobs-to-be-Done をマッピングする（必要な場合）

  • 使用するもの： skills/jobs-to-be-done/SKILL.md（コンポーネント）
  • 実施するタイミング： 顧客の動機が不明確な場合
  • 所要時間： 60 分
  • 成果物： JTBD ステートメント
フェーズ 1 の成果物
  • 問題の仮説： 「私たちは、[ペルソナ] が [根本原因] により [問題] に苦労しており、その結果 [影響] が生じていると考えています。」
  • 調査の質問： ディスカバリーを通じて回答する 3～5 個の質問
  • 成功基準： 何をもって問題が妥当と確認、または否定されるか？
判断ポイント 1：調査を始めるためのコンテキストは十分にありますか？

はいの場合： フェーズ 2（調査計画）に進みます

いいえの場合： まず既存のデータを収集します：

  • サポートチケット、解約アンケート、NPS のフィードバックを確認する
  • プロダクト分析データ（離脱ポイント、利用パターン）を分析する
  • 競合調査、市場動向を確認する
  • 所要時間への影響： +2～3 日

フェーズ 2：調査計画（3 日目）

目標： 調査アプローチを設計し、参加者を募集し、インタビューガイドを準備します。

アクティビティ

1. ディスカバリーインタビューを準備する

  • 使用するもの： skills/discovery-interview-prep/SKILL.md（インタラクティブ）
  • 参加者： PM、デザイン担当者
  • 所要時間： 90 分
  • 成果物： 手法、質問、避けるべきバイアスを含むインタビュープラン

2. 参加者を募集する

  • 対象： ディスカバリーサイクルごとに 5～10 人の顧客（Teresa Torres：継続的ディスカバリー = 週 1 回のインタビュー）
  • セグメント： フェーズ 1 のペルソナに焦点を当てる
  • 募集チャネル：
    • 既存顧客（メール、アプリ内プロンプト）
    • 解約した顧客（退会インタビュー）
    • コールドアウトリーチ（LinkedIn、コミュニティ）
  • 謝礼： $50～100 のギフトカードまたは製品クレジット
  • 所要時間： 2～3 日（フェーズ 1 と並行）

3. インタビューを予定する

  • 形式： インタビュー 1 回につき 45～60 分（会話 30～40 分 + 予備時間）
  • 期間： 1～2 週間に分散
  • 録音： 同意を得て、統合分析のために録音する
フェーズ 2 の成果物
  • インタビューガイド： 自由回答形式の質問 5～7 個（Mom Test スタイル）
  • 参加者リスト： 予定済みのインタビュー 5～10 件
  • 統合分析プラン： インサイトを記録し、分析する方法

フェーズ 3：調査を実施する（第 1～2 週）

目標： 顧客インタビューを通じて定性的な根拠を収集します。

アクティビティ

1. ディスカバリーインタビューを実施する

  • 方法論： skills/discovery-interview-prep/SKILL.md（課題の検証、JTBD、スイッチインタビューなど）
  • 参加者： PM ＋ 任意のオブザーバー（デザイン、エンジニアリング）
  • 期間： 1～2 週間で 5～10 件のインタビュー
  • 重点領域：
    • 過去の行動（仮定ではなく）：「この課題を経験した直近のときのことを教えてください」
    • 回避策：「現在、どのように対処していますか？」
    • 試した代替策：「ほかの解決策を試しましたか？ なぜやめたのですか？」
    • 課題の深刻さ：「これによって、どれくらいの時間や費用がかかっていますか？」

2. 構造化されたメモを取る

  • テンプレート：
    • 参加者：[名前、役割、会社規模]
    • 状況：[課題を経験するタイミングや場所]
    • 行動：[何をするか、手順ごとに]
    • 課題：[不満、障害]
    • 回避策：[現在の解決策]
    • 引用：[顧客の言葉をそのまま記録]
    • インサイト：[パターン、意外な発見]

3. サポートチケットとアナリティクスを並行して確認する

  • サポートチケット： テーマごとに分類する（オンボーディング、機能の分かりにくさ、バグ）
  • アナリティクス： 離脱ポイント、機能の利用状況、コホートの行動を特定する
  • アンケート： NPS コメント、退会アンケート、機能リクエストを確認する
フェーズ 3 の成果物
  • インタビューの記録： 録音したセッションと詳細なメモ
  • サポートチケットのテーマ： 頻度の高い上位 10 件の課題
  • アナリティクスのインサイト： 行動に関する定量データ（例：「60% がオンボーディングのステップ 3 で離脱する」）
判断ポイント 2：飽和に達しましたか？

飽和＝3 件以上のインタビューで同じ課題が浮かび上がり、新たなインサイトがない状態

YES の場合（5～7 件のインタビューで飽和）： フェーズ 4（統合）に進みます

NO の場合（新しい発見が続いている）： インタビューをさらに 3～5 件設定します

  • 所要時間への影響： ＋1 週間

フェーズ 4：インサイトを統合する（第 2 週末）

目標： パターンを特定し、課題に優先順位を付け、機会を整理します。

アクティビティ

1. 親和図法（テーマ分析）

  • 方法：
    • 各インサイトや引用を付箋に書き出す
    • テーマごとにグループ化する（例：「オンボーディングの分かりにくさ」「価格への懸念」「モバイルからのアクセス」）
    • 出現頻度を数える（各テーマに言及した顧客の数）
  • 参加者： PM、デザイン、任意でエンジニアリング
  • 所要時間： 90～120 分
  • 成果物： 出現頻度を記したテーマ別クラスター

2. カスタマージャーニーマップを作成する（任意）

  • 使用するもの： skills/customer-journey-mapping-workshop/SKILL.md（対話形式）
  • 実施する状況： 課題が複数のフェーズ（発見、試用、購入、利用、サポート）にまたがる場合
  • 所要時間： 90 分
  • 成果物： インパクト順に機会をランク付けしたジャーニーマップ

3. 課題に優先順位を付ける

  • 評価基準：
    • 頻度： この課題に言及した顧客は何人ですか？
    • 深刻さ： どれほどつらい課題ですか？（無駄になる時間、失われる費用、精神的なストレス）
    • 戦略との適合性： この課題の解決は事業目標に合致していますか？
  • 方法： 各課題を、頻度、深刻さ、戦略との適合性の各項目で 1～5 点で評価する
  • 成果物： 対応する課題の上位 3～5 件を優先順位順に並べたリスト

4. 課題ステートメントを更新する

  • 使用するもの： skills/problem-statement/SKILL.md（コンポーネント）
  • 調査結果に基づいて改善する： 当初の仮説は妥当でしたか？ 必要に応じて調整します。
  • 成果物： 検証済みの課題ステートメント
フェーズ 4 の成果物
  • 親和図： 出現頻度を記したテーマ
  • 課題の上位 3～5 件： 頻度 × 深刻さ × 戦略との適合性で優先順位付け
  • 顧客の引用： 各課題につき顧客の言葉をそのまま記録した引用を 3～5 件
  • 検証済みの課題ステートメント： 証拠に基づいて改善したもの

フェーズ 5：解決策を生み出して検証する（第 3 週）

目標： 解決策の選択肢を探り、実験を設計し、仮定を検証します。

アクティビティ

1. Opportunity Solution Tree を生成する

  • 使用: skills/opportunity-solution-tree/SKILL.md（対話型）
  • 入力: フェーズ 4 で特定した上位 3 つのペインポイント
  • 参加者: PM、デザイン担当者、エンジニアリングリード
  • 所要時間: 90 分
  • 出力: 3 つの機会、各機会に対する 3 つのソリューション、POC の推奨案

代替案：Lean UX Canvas を使用する

  • 使用: skills/lean-ux-canvas/SKILL.md（対話型）
  • 適用する状況: OST よりも仮説主導のアプローチを優先する場合
  • 出力: 検証する仮説、最小限の実験

2. 実験を設計する

  • 各ソリューションについて: 「次に最も重要なことを学ぶために、最小限の作業でできることは何か？」を定義します。
  • 実験の種類:
    • コンシェルジュテスト: 10 人の顧客にソリューションを手作業で提供し、観察します
    • プロトタイプテスト: クリック可能なモックアップを作成し、10 人のユーザーでユーザビリティテストを実施します
    • ランディングページテスト: 偽の導線テスト（機能を提示し、関心度を測定します）
    • A/B テスト: 最小限のバージョンを構築し、ユーザーの 50％を対象にテストします
  • 成功基準: どのような指標や行動が仮説を裏付けますか？

3. 実験を実施する

  • 期間: 実験ごとに 1～2 週間
  • 参加者: PM＋デザイン担当者（プロトタイプの場合）、エンジニアリング（A/B テストの場合）
  • 出力: 定量的および定性的な検証データ
フェーズ 5 の成果物
  • ソリューションの選択肢: 3～9 個のソリューション（機会ごとに 3 個）
  • 実験結果: 仮説は検証されたか、否定されたか？
  • 顧客からのフィードバック: プロトタイプやコンセプトに対する定性的な反応
判断ポイント 3：実験でソリューションを検証できましたか？

YES（検証できた）の場合: フェーズ 6（決定と文書化）に進みます

NO（検証できなかった）の場合:

  • 次のソリューション案に切り替えます
  • アプローチを調整して実験を再実施します
  • 期間への影響: 1～2 週間追加

フェーズ 6：決定と文書化（第 3～4 週の終わり）

目標: 開発に着手する決定を下し、その決定を文書化して関係者に伝えます。

アクティビティ

1. 実行可否を決定する

  • 基準:
    • 課題は検証済みか？（フェーズ 3～4）
    • ソリューションは検証済みか？（フェーズ 5）
    • 戦略に適合しているか？（ビジネス目標に沿っているか）
    • 実現可能か？（エンジニアリングの対応能力、技術的な複雑さ）
  • 決定:
    • GO: ロードマップに追加し、エピックやストーリーを作成します
    • PIVOT: 代替ソリューションを検討します
    • KILL: 優先度を下げ、現時点では解決に取り組まないことにします

2. エピックの仮説を定義する（GO の場合）

  • 使用: skills/epic-hypothesis/SKILL.md（コンポーネント）
  • 参加者: PM
  • 所要時間: エピックごとに 60 分
  • 出力: 成功基準を含むエピックの仮説文

3. PRD を作成する（GO の場合）

  • 使用: skills/prd-development/SKILL.md（ワークフロー）
  • 参加者: PM
  • 所要時間: 1～2 日
  • 出力: 課題、ソリューション、成功指標をまとめた構成済みの PRD

4. 調査結果を共有する

  • 形式: 以下を含む 30 分の報告会：
    • 課題の検証（フェーズ 3～4 の知見）
    • ソリューションの検証（フェーズ 5 の実験）
    • 推奨事項（GO/PIVOT/KILL）
  • 参加者: 経営幹部、プロダクトリーダー、主要な関係者
  • 出力: 次のステップに関する合意
フェーズ 6 の成果物
  • 決定: GO、PIVOT、または KILL
  • エピックの仮説: （GO の場合）検証可能なエピックの記述
  • PRD: （GO の場合）正式な製品要件定義書
  • 関係者間の合意: 推奨事項に対する経営幹部の賛同

ワークフロー全体：エンドツーエンドの概要

Week 1:
├─ Day 1-2: Frame the Problem
│  ├─ skills/problem-framing-canvas/SKILL.md (120 min)
│  ├─ skills/problem-statement/SKILL.md (30 min)
│  └─ [Optional] skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md
│
├─ Day 3: Research Planning
│  ├─ skills/discovery-interview-prep/SKILL.md (90 min)
│  ├─ Recruit participants (2-3 days)
│  └─ Schedule 5-10 interviews
│
└─ Day 4-5: Conduct Research (Start)
   └─ First 2-3 customer interviews

Week 2:
├─ Day 1-3: Conduct Research (Continue)
│  └─ Remaining customer interviews (3-7 more)
│
├─ Day 4-5: Synthesize Insights
│  ├─ Affinity mapping (120 min)
│  ├─ [Optional] skills/customer-journey-mapping-workshop/SKILL.md (90 min)
│  ├─ Prioritize pain points
│  └─ Update problem statement
│
└─ Decision: Reached saturation? (if NO, +1 week more interviews)

Week 3:
├─ Day 1-2: Generate & Validate Solutions
│  ├─ skills/opportunity-solution-tree/SKILL.md (90 min)
│  └─ Design experiments
│
├─ Day 3-5: Run Experiments
│  ├─ Concierge tests, prototypes, or A/B tests
│  └─ Gather validation data
│
└─ Decision: Validated? (if NO, pivot to next solution, +1-2 weeks)

Week 4:
└─ Decide & Document
   ├─ Make GO/NO-GO decision
   ├─ [If GO] skills/epic-hypothesis/SKILL.md (60 min per epic)
   ├─ [If GO] skills/prd-development/SKILL.md (1-2 days)
   └─ Communicate findings (30 min readout)

総所要時間：

  • 短期プラン: 3 週間（インタビュー 5 件、実験 1 件）
  • 標準: 4 週間（インタビュー 7～10 件、実験 1～2 件）
  • 徹底プラン: 6～8 週間（インタビュー 10 件以上、複数回の実験）

例

一連のディスカバリープロセスの例については、examples/sample.md を参照してください。

簡単な例の抜粋：

**Problem:** Onboarding drop-off due to jargon
**Insight:** 6/10 users quit at step 3
**Decision:** Go with guided checklist experiment

よくある落とし穴

落とし穴 1：顧客インタビューを省略する

症状： 分析データとサポートチケットだけに頼り、定性的な調査を行わない

結果： 行動の背景にある「理由」を見落とし、誤ったソリューションを構築してしまいます

対策： データがある場合でも、ディスカバリーサイクルごとに必ず 5～10 人の顧客にインタビューします

落とし穴 2：誘導的な質問をする

症状：「機能 X を作ったら使いますか？」

**結果：**確証バイアスが生じ、顧客は礼儀として「はい」と答えます

対策：skills/discovery-interview-prep/SKILL.md の Mom Test の質問を使います（過去の行動に焦点を当てます）

落とし穴 3：十分な数のインタビューを行わない

**症状：**顧客 2～3 人にインタビューしただけで、ディスカバリーが完了したと判断します

**結果：**サンプルが少なく、代表性がありません

**対策：**3 人以上の顧客で同じパターンが見られるまでインタビューを続けます（通常、最低でも 5～7 回のインタビューが必要です）

落とし穴 4：分析による麻痺

**症状：**インサイトの統合に 6 週間を費やし、ソリューションに進めません

**結果：**成果物が生まれず、チームの勢いが失われます

**対策：**ディスカバリーの期間を 3～4 週間に区切ります。フェーズ 6 の後は、実行に移ります

落とし穴 5：ディスカバリーを一度きりの活動にする

**症状：**構築前に一度ディスカバリーを行い、その後はやめてしまいます

**結果：**変化する顧客ニーズや市場の変化を見逃します

**対策：**継続的なディスカバリー（Teresa Torres）：毎週 1 回の顧客インタビューを継続します

参考資料

関連スキル（このワークフローで統括）

フェーズ 1：

  • skills/problem-framing-canvas/SKILL.md（対話型）
  • skills/problem-statement/SKILL.md（コンポーネント）
  • skills/proto-persona/SKILL.md（コンポーネント、任意）
  • skills/jobs-to-be-done/SKILL.md（コンポーネント、任意）

フェーズ 2：

  • skills/discovery-interview-prep/SKILL.md（対話型）

フェーズ 4：

  • skills/customer-journey-mapping-workshop/SKILL.md（対話型、任意）

フェーズ 5：

  • skills/opportunity-solution-tree/SKILL.md（対話型）
  • skills/lean-ux-canvas/SKILL.md（対話型、代替手段）

フェーズ 6：

  • skills/epic-hypothesis/SKILL.md（コンポーネント）
  • skills/prd-development/SKILL.md（ワークフロー）
外部フレームワーク
  • Teresa Torres、『Continuous Discovery Habits』（2021）— 毎週の顧客との接点、OST フレームワーク
  • Rob Fitzpatrick、『The Mom Test』（2013）— 良いインタビュー質問の方法
  • Marty Cagan、『Inspired』（2017）— プロダクトディスカバリーの原則
Dean の取り組み
  • Productside Blueprint — 戦略的ディスカバリープロセス
  • [Dean にディスカバリー関連の資料がある場合は、ここにリンク]

**スキルの種類：**ワークフロー 推奨ファイル名：discovery-process.md 推奨配置場所：/skills/workflows/ **依存関係：**6 つのフェーズにわたる 10 以上のコンポーネントスキルと対話型スキルを統括します

コメント

Markdown 対応