discovery-interview-prep

目的

リサーチの目標、顧客セグメント、制約、手法について適応的に質問し、顧客インタビューの準備をプロダクトマネージャーに案内します。これを活用して、効果的なインタビュープランを設計し、的を絞った質問を作成し、よくあるバイアスを避け、限られた顧客接点から最大限の学びを得ましょう。ディスカバリーインタビューから、確証バイアスや表面的なフィードバックではなく、実行可能なインサイトが得られるようにします。

これは台本ジェネレーターではありません。方法論、質問のフレームワーク、成功基準を含む、個別に調整されたインタビュープランを作成するための戦略的な準備プロセスです。

入力

特に有効な情報： リサーチの目標 — 顧客から何を学ぶ必要があるか。 あると役立つ情報： 顧客セグメント、アクセス上の制約（インタビューの件数、実施期限）、現在抱えている仮説。

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

何も準備できていなくても大丈夫です。 このスキルでは、まずインタビューの主な目標を尋ね、その後、追加の質問で内容を絞り込みます。

呼び出し例： 6か月後にエンタープライズ顧客が解約する理由を理解するためのインタビューを準備してください。2週間で5件のインタビューが可能です。

主要な概念

ディスカバリーインタビューの準備フロー

次の手順を踏む対話型プロセスです。

1. プロダクト／課題の背景情報（マーケティング資料、前提など）を収集する
2. リサーチの目標（何を学ぼうとしているか）を定義する
3. 対象となる顧客セグメントとアクセス上の制約を特定する
4. インタビューの方法論（Jobs-to-be-Done、課題の検証、乗り換えインタビューなど）を推奨する
5. 質問、避けるべきバイアス、成功指標を含むインタビューのフレームワークを作成する

効果がある理由

• 目標重視： インタビューの進め方を、学ぶ必要がある内容に合わせます
• 適応型： プロダクトの段階（アイデア段階か、既存プロダクトか）とアクセス上の制約に応じて、方法論を調整します
• バイアスへの配慮： よくある落とし穴（誘導的な質問、確証バイアス、ソリューションを先に考えること）を明らかにします
• 実行可能： すぐに使えるインタビューガイドを作成します

アンチパターン（これは該当しません）

• ユーザーテストの台本ではありません： ディスカバリーは課題を学ぶこと、テストはソリューションを検証することです
• セールスデモではありません： 売り込まず、耳を傾けて学びましょう
• 大規模なアンケートではありません： 幅広いアンケート（100人以上）ではなく、少人数（5〜10人）を対象とする、深い定性的インタビューです

こんな場合に使用します

• プロダクトディスカバリーを始める（課題領域を検証する）
• 既存プロダクトのポジショニングを変更する（新しい市場について理解する）
• 解約や利用離脱を調査する（継続利用に関するインタビュー）
• 機能のアイデアを、構築前に評価する
• 顧客開発スプリントの準備をする

こんな場合には使用しません

• プロトタイプのユーザーテストを行う場合（代わりにユーザビリティテストのフレームワークを使用してください）
• 大規模な定量調査を行う場合（アンケートや分析を使用してください）
• すでに課題がわかっている場合（ソリューションの検証に進んでください）

---

ファシリテーションの基準

このスキルでは、デフォルトの対話プロトコルとしてworkshop-facilitationを使用してください。

このファイルでは、次の内容を定義しています。

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

このファイルでは、ドメイン固有の評価内容を定義しています。競合がある場合は、このファイルのドメインロジックに従ってください。

適用

この対話型スキルでは、各ステップで3〜4個の番号付き選択肢を提示し、最大4つの適応的な質問をします。

---

ステップ 0：コンテキストを収集する（質問の前に）

エージェントの提案：

インタビュー計画を設計する前に、まずコンテキストを集めましょう。

自社製品について（既存または計画中）：

• 課題に関する仮説、または製品コンセプトの説明
• ターゲット顧客セグメント（分かっている場合）
• 既存の調査結果（サポートチケット、解約データ、ユーザーフィードバック）
• 製品のウェブサイト、またはポジショニング資料
• 検証しようとしている主要な前提

既存の課題を調査する場合：

• 顧客からの苦情、サポートチケット、または解約理由
• 顧客が離脱したり、困難を感じたりする理由についての仮説
• 顧客が乗り換える競合製品や代替手段

新しい課題領域を探索する場合：

• 類似製品や隣接するソリューションを探してください
• 競合他社の資料、顧客レビュー（G2、Capterra）、またはコミュニティでの議論（Reddit、フォーラム）をコピーしてください
• これらを使って仮説を組み立てます

この内容を直接貼り付けることも、簡単な説明から始めることもできます。

---

質問 1：調査の目的

エージェントの質問： 「これらのディスカバリーインタビューの主な目的は何ですか？（何を知る必要がありますか？）」

次の 4 つの選択肢を提示します：

1. 課題の検証 — 「課題が存在し、解決に値するほど深刻であることを確認する」（新しい製品アイデア向け）
2. Jobs-to-be-Done の発見 — 「顧客が何を達成しようとしているのか、そして現在のソリューションがなぜうまくいかないのかを理解する」（製品戦略向け）
3. 継続率／解約の調査 — 「顧客が離脱したり、利用を開始しなかったりする理由を明らかにする」（解約に課題がある既存製品向け）
4. 機能の優先順位付け — 「顧客にとって、どの課題や機能が最も重要かを検証する」（ロードマップの計画向け）

または、独自の調査目的を説明してください（具体的に、答えようとしている問いを記載してください）。

ユーザーの回答： [選択または自由記述]

---

質問 2：ターゲット顧客セグメント

エージェントの質問： 「誰にインタビューしますか？（できるだけ具体的にしてください。）」

次の 4 つの選択肢を提示します（Q1 に応じて調整）：

例（Q1 = 課題の検証の場合）：

1. 課題を定期的に経験している人 — 例：「毎週、請求書を手作業で処理している小規模事業者」（課題を感じる頻度が高い）
2. 課題を解決しようとしたことがある人 — 例：「競合ソリューションを 2 つ以上試して解約したユーザー」（失敗の理由を理解する）
3. ターゲットセグメントに属する人（課題を認識しているかどうかを問わない） — 例：「請求業務を課題と認識していない人も含む、すべてのフリーランサー」（潜在的なニーズを発見する）
4. 最近、課題を経験した人 — 例：「過去 30 日以内に解約した顧客」（記憶が新しいうちに聞く）

または、具体的なターゲットセグメントを説明してください（役割、企業規模、行動、属性など）。

調整のヒント： 提供された資料にあるペルソナや顧客セグメントを使ってください。

ユーザーの回答： [選択または自由記述]

---

質問 3：制約

エージェントの質問： 「これらのインタビューには、どのような制約がありますか？」

次の 4 つの選択肢を提示します：

1. アクセスが限られている — 「インタビューできる顧客は 5～10 人のみで、2 週間以内に結果が必要」（スタートアップや短いスケジュールでよくある状況）
2. 既存の顧客基盤がある — 「アクティブな顧客が 100 人以上おり、容易に募集できる」（成熟した製品の強み）
3. コールドアウトリーチが必要 — 「既存顧客がいないため、LinkedIn、広告、コミュニティを通じて一から募集する必要がある」（新製品ならではの課題）
4. 社内の関係者のみ — 「日常的に顧客と接している営業チームやサポートチームにインタビューできる」（代理調査。理想的ではないものの、現実的な方法）

または、具体的な制約を説明してください（予算、時間、アクセス、チームの対応能力など）。

ユーザーの回答： [選択または自由記述]

---

質問 4：インタビュー手法

エージェントが質問します： 「目標（[Q1]）、対象セグメント（[Q2]）、制約（[Q3]）に基づいて、おすすめのインタビュー手法をご紹介します。」

状況に応じて、3～4個の選択肢を番号付きで提示します（Q1～Q3に基づいて調整）：

例（Q1＝問題の検証、Q2＝問題を頻繁に経験する人、Q3＝アクセスが限られている場合）：

1. 問題検証インタビュー（Mom Test 形式） — 仮定の話ではなく、過去の行動について質問します。次の点に焦点を当てます：「[問題を経験した]最後のときのことを教えてください。何を試しましたか？どうなりましたか？」（最適な用途：問題が実在し、深刻なものかを検証する）

2. Jobs-to-be-Done（JTBD）インタビュー — 顧客が何を望んでいるかではなく、何を達成しようとしているかに焦点を当てます。次のように質問します：「何を達成しようとしていましたか？どんな代替手段を検討しましたか？なぜ X を選んだのですか？」（最適な用途：動機や乗り換え行動を理解する）

3. 乗り換えインタビュー — 最近、競合他社や別の選択肢から乗り換えた顧客にインタビューします。次のように質問します：「新しい解決策を探すきっかけは何でしたか？以前のツールから離れる『押し出す力』は何でしたか？こちらを試すよう『引きつけた力』は何でしたか？」（最適な用途：競争上のポジショニングや満たされていないニーズを理解する）

4. タイムライン／ジャーニーマッピングインタビュー — 顧客の経験全体を時系列に沿ってたどります。次のように質問します：「この問題に初めて遭遇したときのことを教えてください。その後どうなりましたか？どのように解決しようとしましたか？」（最適な用途：全体像やペインポイントを明らかにする）

番号を選ぶか、手法を組み合わせる（例：「1 & 2」）か、独自の手法を説明してください。

調整例：

• Q1＝継続率／解約の場合 → 「退会インタビュー」または「（自社製品から離れる）乗り換えインタビュー」を優先します
• Q1＝機能の優先順位付けの場合 → 「Opportunity solution tree インタビュー」または「Kano モデルインタビュー」を優先します
• Q3＝社内関係者のみの場合 → 注意書きを追加します：「代理調査（営業／サポート担当者への聞き取り）は何もしないよりは有効ですが、できるだけ早く実際の顧客で検証してください」

ユーザーの回答： [選択または自由記述]

---

出力：インタビュープランを生成する

回答を収集した後、エージェントが状況に合わせたインタビュープランを生成します。

# Discovery Interview Plan

**Research Goal:** [From Q1]
**Target Segment:** [From Q2]
**Constraints:** [From Q3]
**Methodology:** [From Q4]

---

## Interview Framework

### Opening (5 minutes)
- **Build rapport:** "Thanks for taking the time. I'm [name], and I'm researching [problem space]. This isn't a sales call—I'm here to learn from your experience."
- **Set expectations:** "I'll ask about your experiences with [topic]. There are no right answers. Feel free to be honest—critical feedback is most helpful."
- **Get consent:** "Is it okay if I take notes / record this conversation?"

---

### Core Questions (30-40 minutes)

**Based on your methodology ([Q4]), here are suggested questions:**

#### [Methodology Name] Questions:

1. **[Question 1]** — [Rationale for asking this]
   - **Follow-up:** [Dig deeper with...]
   - **Avoid:** [Don't ask leading version like...]

2. **[Question 2]** — [Rationale]
   - **Follow-up:** [...]
   - **Avoid:** [...]

3. **[Question 3]** — [Rationale]
   - **Follow-up:** [...]
   - **Avoid:** [...]

4. **[Question 4]** — [Rationale]
   - **Follow-up:** [...]
   - **Avoid:** [...]

5. **[Question 5]** — [Rationale]
   - **Follow-up:** [...]
   - **Avoid:** [...]

**Example (if Methodology = Problem validation - Mom Test style):**

1. **"Tell me about the last time you [experienced this problem]."** — Gets specific, recent behavior (not hypothetical)
   - **Follow-up:** "What were you trying to accomplish? What made it hard? What did you try?"
   - **Avoid:** "Would you use a tool that solves this?" (leading, hypothetical)

2. **"How do you currently handle [this problem]?"** — Reveals workarounds, alternatives, pain intensity
   - **Follow-up:** "How much time/money does that take? What's frustrating about it?"
   - **Avoid:** "Don't you think that's inefficient?" (leading)

3. **"Can you walk me through what you did step-by-step?"** — Uncovers details, edge cases, context
   - **Follow-up:** "What happened next? Where did you get stuck?"
   - **Avoid:** "Was it hard?" (yes/no question, not useful)

4. **"Have you tried other solutions for this?"** — Reveals competitive landscape, unmet needs
   - **Follow-up:** "What did you like/dislike? Why did you stop using it?"
   - **Avoid:** "Would you pay for a better solution?" (hypothetical)

5. **"If you had a magic wand, what would change?"** — Opens space for ideal outcomes (but treat with skepticism—focus on past behavior, not wishes)
   - **Follow-up:** "Why does that matter to you? What would that enable?"
   - **Avoid:** Taking feature requests literally

---

### Closing (5 minutes)
- **Summarize:** "Just to recap, I heard that [key insights]. Did I get that right?"
- **Ask for referrals:** "Do you know anyone else who experiences this problem? Could you introduce me?"
- **Thank them:** "This was incredibly helpful. I really appreciate your time."

---

## Biases to Avoid

1. **Confirmation bias:** Don't ask "Don't you think X is a problem?" → Ask "Tell me about your experience with X."
2. **Leading questions:** Don't ask "Would you use this?" → Ask "What have you tried? Why did it work/fail?"
3. **Hypothetical questions:** Don't ask "If we built Y, would you pay?" → Ask "What do you currently pay for? Why?"
4. **Pitching disguised as research:** Don't say "We're building Z to solve X" → Say "I'm researching X. Tell me about your experience."
5. **Yes/no questions:** Don't ask "Is invoicing hard?" → Ask "Walk me through your invoicing process."

---

## Success Criteria

You'll know these interviews are successful if:

✅ **You hear specific stories, not generic complaints** — "Last Tuesday, I spent 3 hours..." vs. "Invoicing is annoying"
✅ **You uncover past behavior, not hypothetical wishes** — "I tried Zapier but quit after 2 weeks" vs. "I'd probably use automation"
✅ **You identify patterns across 3+ interviews** — Same pain points emerge independently
✅ **You're surprised by something** — If everything confirms your assumptions, you're asking leading questions
✅ **You can quote customers verbatim** — Actual language = authentic insights

---

## Interview Logistics

**Recruiting:**
- [Based on Q3 constraints, suggest recruitment channels]
- **Example (if Q3 = Limited access):** "Reach out to 20-30 people to get 5-10 interviews (33% response rate is typical)"
- **Example (if Q3 = Existing customers):** "Email 50 customers with $50 Amazon gift card incentive"

**Scheduling:**
- 45-60 minutes per interview (30-40 min conversation + buffer)
- Record if possible (with consent), or take detailed notes
- Schedule 2-3 per day max (you need time to synthesize)

**Synthesis:**
- After each interview, write key insights immediately (memory fades fast)
- After 5 interviews, look for patterns (common pains, jobs, workarounds)
- Use `problem-statement.md` to frame findings

---

**Ready to start recruiting and interviewing? Let me know if you'd like to refine any part of this plan.**

---

例

例 1：適切なディスカバリーインタビューの準備（問題の検証）

ステップ 0 - コンテキスト： ユーザーが仮説を共有します：「フリーランサーは、支払い遅延の催促を手作業で行うために時間を無駄にしている。」

Q1 の回答： 「問題の検証 — 支払い遅延の催促が解決に値するほど深刻な問題かを確認する」

Q2 の回答： 「問題を頻繁に経験する人 — 月に 5 社以上のクライアントに請求書を発行するフリーランサー」

Q3 の回答： 「コールドアウトリーチが必要 — 既存顧客がいないため、LinkedIn、Reddit、フリーランサーのコミュニティを通じて参加者を募る必要がある」

Q4 の回答： 「問題検証インタビュー（Mom Test 形式） — 仮定の話ではなく、過去の行動に焦点を当てる」

生成されたプラン： Mom Test 形式の質問 5 個（支払い遅延を最後に催促したときのこと、現在どのように対応しているか、これまで何を試したかなど）、避けるべきバイアス（誘導尋問、仮定の質問）、成功基準（具体的なエピソード、過去の行動、3 件以上のインタビューで見られるパターン）が含まれます。

これが有効な理由：

• 目標が明確です（問題が実在するかを検証する）
• 対象セグメントが具体的です（月に 5 社以上のクライアントがいるフリーランサー）
• 手法が目標に合っています（検証に適した Mom Test）
• 質問は希望ではなく、過去の行動に焦点を当てています
• 成功基準を測定できます

---

よくある落とし穴

落とし穴 1：顧客が何を望んでいるかを尋ねる

症状： 「どんな機能を作ってほしいですか？」

結果： 問題ではなく、機能の要望が返ってきます。顧客は解決策を知りません。

対処法： 過去の行動について質問します：「X に苦労した最後のときのことを教えてください。」

---

落とし穴 2：話を聞かずに売り込む

症状： 20 分かけて自社の製品アイデアを説明する

結果： 顧客は気を遣って好意的に答えなければならないと感じます。率直なフィードバックが得られません。

対処法： （必要であれば）最後の 5 分になるまで解決策に触れないでください。顧客の問題に焦点を当てます。

---

落とし穴 3：適切でない人にインタビューする

症状： 友人や家族、またはその問題を経験していない人にインタビューする

結果： 当たり障りのないフィードバックしか得られず、真のインサイトが得られません。

対策： その問題を定期的に、かつ最近経験した人にインタビューします。

---

落とし穴 4：インタビューを 1～2 件で終える

症状： 「2 人に話を聞いたら、気に入ってくれた。さっそく作ろう！」

結果： サンプルが少ないと、確証バイアスが生じます。

対策： 最低 5～10 人にインタビューします。単発のフィードバックではなく、パターンを探します。

---

落とし穴 5：インサイトを記録しない

症状： インタビュー後、記憶に頼る

結果： 詳細を忘れ、発言を誤って記憶し、パターンを見つけられません。

対策： （同意を得たうえで）録音するか、詳細なメモを取ります。各インタビューの直後に内容をまとめます。

---

参考資料

関連スキル

• problem-statement.md — インタビューで得たインサイトを使って問題提起をまとめます
• proto-persona.md — インタビュー対象のセグメントを定義します
• jobs-to-be-done.md — インタビューにおける JTBD の方法論

外部フレームワーク

• Rob Fitzpatrick、The Mom Test（2013）— 回答にバイアスを与えずに、適切な質問をする方法
• Clayton Christensen、Jobs to Be Done — 動機を理解するためのインタビュー方法論
• Teresa Torres、Continuous Discovery Habits（2021）— オポチュニティ・ソリューション・ツリーのインタビュー

Dean の取り組み

• Problem Framing Canvas（インタビュー結果を統合）

---

スキルの種類： インタラクティブ 推奨ファイル名： discovery-interview-prep.md 推奨配置場所： /skills/interactive/ 依存関係： problem-statement.md、proto-persona.md、jobs-to-be-done.md を使用