customer-discovery

顧客開発

何かを構築する前に、ビジネス仮説を体系的に検証します。リーンスタートアップとYCのアプローチの基盤となった、Steve Blankの顧客開発手法を習得しましょう。

このスキルを使う場面

• 誰も求めていないものを作るのを避けるために、新しい事業を始めるとき
• コードを1行書く前に、問題と解決策の適合性を検証するとき
• 新しい方向性を体系的にテストするために、ピボットを決定するとき
• 市場での検証を証明するために、創業初期の資金調達をするとき
• 検証済みの顧客ニーズに基づいて優先順位を付けるために、製品ロードマップを計画するとき
• なじみのない顧客セグメントを理解するために、新しい市場に参入するとき

手法の基盤

項目	詳細
出典	Steve Blank - 「The Four Steps to the Epiphany」（2005年）
基本原則	「顧客と最初に接したときに持ちこたえられる事業計画はありません。建物の外に出ましょう。」
重要な理由	スタートアップは、誰も求めていない製品を作るために失敗します。顧客開発では、資金が尽きる前に体系的に学ぶことで、推測に頼る必要がなくなります。

Claudeが行うことと、あなたが決めること

Claudeが行うこと	あなたが決めること
コンテンツのフレームワークを構成する	最終的なメッセージ
説得の手法を提案する	ブランドの語調
草案のバリエーションを作成する	バージョンの選択
最適化の機会を特定する	公開のタイミング
競合他社のアプローチを分析する	戦略的な方向性

このスキルでできること

1. ビジネス仮説を文書化する - 前提を検証可能な記述に変換します
2. 検証実験を設計する - 仮説が間違っていることを証明できるテストを作成します
3. 顧客との対話を構成する - 誤った肯定的結果ではなく、真の洞察を得ます
4. 問題と解決策の適合性を評価する - 進めるか、ピボットするか、中止するかを判断します
5. 学習ロードマップを作成する - 何を最初に検証するか優先順位を付けます
6. 検証の進捗を追跡する - エビデンスに基づく意思決定を維持します

使い方

新しいアイデアの顧客開発を始める

I'm starting customer discovery for [business idea].
Help me document my hypotheses and design validation experiments.
Use Steve Blank's Customer Development methodology.

顧客開発の進捗を評価する

Here's what I've learned from [X] customer interviews: [summary]
Evaluate my progress against Customer Discovery criteria.
Should I proceed, pivot, or go back to more interviews?

検証実験を設計する

I need to validate this hypothesis: [hypothesis]
Design a Customer Discovery experiment to test it.
What would prove it true? What would prove it false?

手順

顧客開発を支援する際は、Steve Blankの体系的なアプローチに従ってください。

ステップ1：ビジネスモデルの仮説を文書化する

## Business Model Canvas Hypotheses

Before talking to customers, document what you BELIEVE to be true.
These are GUESSES until validated.

### Customer Hypotheses
| # | Hypothesis | Confidence | Evidence |
|---|------------|------------|----------|
| C1 | Our target customer is [WHO] | Low/Med/High | [None yet] |
| C2 | They have this problem: [WHAT] | Low/Med/High | [None yet] |
| C3 | The problem is severe because [WHY] | Low/Med/High | [None yet] |
| C4 | They currently solve it by [HOW] | Low/Med/High | [None yet] |

### Value Proposition Hypotheses
| # | Hypothesis | Confidence | Evidence |
|---|------------|------------|----------|
| V1 | Our solution provides [BENEFIT] | Low/Med/High | [None yet] |
| V2 | Customers care about [FEATURE/OUTCOME] | Low/Med/High | [None yet] |
| V3 | We're differentiated by [UNIQUE VALUE] | Low/Med/High | [None yet] |

### Channel Hypotheses
| # | Hypothesis | Confidence | Evidence |
|---|------------|------------|----------|
| H1 | We can reach customers through [CHANNEL] | Low/Med/High | [None yet] |
| H2 | Customer acquisition will cost [ESTIMATE] | Low/Med/High | [None yet] |

### Revenue Hypotheses
| # | Hypothesis | Confidence | Evidence |
|---|------------|------------|----------|
| R1 | Customers will pay [PRICE] | Low/Med/High | [None yet] |
| R2 | Revenue model: [TYPE] | Low/Med/High | [None yet] |
| R3 | Lifetime value: [ESTIMATE] | Low/Med/High | [None yet] |

重要なルール： 実際の顧客から得た実際のエビデンスによって仮説が検証されるまでは、ビジネスが成立したとは言えません。

---

ステップ2：最初に検証する項目の優先順位を付ける

## Hypothesis Prioritization Matrix

Prioritize by RISK and IMPACT:

| Hypothesis | If WRONG, Impact | Current Confidence | Priority |
|------------|------------------|-------------------|----------|
| [H1] | Fatal/Major/Minor | Low/Med/High | P1/P2/P3 |
| [H2] | Fatal/Major/Minor | Low/Med/High | P1/P2/P3 |

### Priority Rules:
- P1: Fatal if wrong + Low confidence → Validate FIRST
- P2: Major if wrong + Low/Med confidence → Validate SOON
- P3: Minor if wrong OR High confidence → Validate LATER

### Your P1 Hypotheses (Validate These First):
1. ________________________________
2. ________________________________
3. ________________________________

These are your "leap of faith" assumptions.

---

ステップ3：検証実験を設計する

## Experiment Design Template

### Hypothesis Being Tested:
"We believe [CUSTOMER SEGMENT] has [PROBLEM] and would [BEHAVIOR]."

### Experiment Type:
- [ ] Customer Interviews (Problem Discovery)
- [ ] Solution Interviews (Solution Validation)
- [ ] Landing Page Test (Demand Validation)
- [ ] Concierge MVP (Solution Validation)
- [ ] Smoke Test (Demand Validation)

### Success Criteria:
**Validated if:** [Specific, measurable outcome]
**Invalidated if:** [Specific, measurable outcome]

Example:
- Validated: 8+ of 10 customers describe this exact problem unprompted
- Invalidated: Fewer than 5 of 10 mention this problem

### Sample Size:
- Minimum: [Number] customers
- Target segment: [Description]

### Data to Collect:
1.
2.
3.

### Timeline:
- Start: [Date]
- End: [Date]
- Go/No-Go Decision: [Date]

---

ステップ4：顧客開発インタビューを実施する

## Customer Discovery Interview Framework

### PHASE 1: Problem Discovery (First 5-10 interviews)

**Goal:** Understand the problem space, NOT pitch solutions

**Interview Structure:**
1. **Context** (5 min): Their role, background, day-to-day
2. **Problem Exploration** (15 min): Deep dive into the problem area
3. **Existing Solutions** (5 min): What they use today
4. **Impact** (5 min): How the problem affects them
5. **Wrap-up** (5 min): Referrals, next steps

**Key Questions:**
- "Tell me about your biggest challenge with [area]..."
- "Walk me through the last time you dealt with [problem]..."
- "What solutions have you tried? What worked/didn't work?"
- "How much time/money does this cost you?"
- "If this magically disappeared, what would change?"

**DO NOT:**
- Pitch your solution
- Ask leading questions
- Talk more than 30% of the time
- Ask "would you use/pay for..."

### PHASE 2: Solution Discovery (Next 5-10 interviews)

**Goal:** Test if your solution addresses validated problems

**Only proceed to Phase 2 if:**
- [ ] You've talked to 10+ potential customers
- [ ] Clear problem patterns emerged
- [ ] Problems are severe and frequent enough
- [ ] Customers are actively seeking solutions

**Solution Interview Structure:**
1. **Recap** (3 min): Confirm the problem you heard
2. **Solution Demo** (10 min): Show concept/prototype
3. **Reaction** (10 min): Their honest feedback
4. **Commitment** (5 min): Would they try/buy/refer?

**Key Questions:**
- "Does this solve the problem you described?"
- "What's missing?"
- "What would you pay for this?"
- "Would you be willing to pilot this?"
- "Who else should see this?"

---

ステップ5：結果を評価し、判断する

## Customer Discovery Scorecard

### Problem Validation

| Criteria | Threshold | Your Result | Pass? |
|----------|-----------|-------------|-------|
| # of interviews completed | 10+ | | Y/N |
| % who confirmed the problem unprompted | 70%+ | | Y/N |
| Problem severity (1-10 avg) | 7+ | | Y/N |
| Already spending money on solutions | 50%+ | | Y/N |
| Actively seeking alternatives | 30%+ | | Y/N |

**Problem Validated:** All Y → Proceed to Solution Validation
**Problem NOT Validated:** Any N → Pivot or dig deeper

### Solution Validation

| Criteria | Threshold | Your Result | Pass? |
|----------|-----------|-------------|-------|
| # of solution interviews | 10+ | | Y/N |
| Said "this solves my problem" | 70%+ | | Y/N |
| Willing to try/pilot | 50%+ | | Y/N |
| Willing to pay (some amount) | 30%+ | | Y/N |
| Gave commitment (deposit, LOI, intro) | 3+ people | | Y/N |

**Solution Validated:** All Y → Proceed to MVP
**Solution NOT Validated:** Any N → Iterate or pivot

### Decision Framework

問題が検証されなかった場合： → ピボット：別の顧客セグメントを検討するか？ → ピボット：別の問題を検討するか？ → 中止：この市場には可能性がないか？

問題は検証されたが、解決策は検証されなかった場合： → 改良：同じ問題に対する別の解決策を試す → 改良：別の機能やアプローチを試す

両方とも検証された場合： → 構築：実用最小限の製品 → 販売：構築前に先行販売する

---

ステップ6：学びを文書化し、仮説を更新する

## Customer Discovery Learning Log

### Round [#] Summary

**Dates:** [Start] - [End]
**Interviews Conducted:** [#]
**Customer Segments Covered:** [List]

### Validated Hypotheses ✅
| Hypothesis | Evidence | Confidence Now |
|------------|----------|----------------|
| [H1] | [Quotes/Data] | High |

### Invalidated Hypotheses ❌
| Hypothesis | Evidence | Next Step |
|------------|----------|-----------|
| [H2] | [Quotes/Data] | Pivot to... |

### Surprises / New Insights 🔍
| Insight | Implication |
|---------|-------------|
| [Learning] | [What this means] |

### Updated Business Model
[What changed based on learnings]

### Next Validation Round
| Hypothesis to Test | Experiment | Timeline |
|--------------------|------------|----------|
| [H3] | [Method] | [Dates] |

---

例

例1：B2B SaaS - HR テックスタートアップ

背景： 創業者は、中規模企業にはより優れた従業員オンボーディングソフトウェアが必要だと考えています。

入力：

「中規模企業向けの HR オンボーディングソフトウェアを作りたいです。顧客発見の進め方を整えるのを手伝ってください。」

出力：

ビジネスモデルの仮説：

#	仮説	誤っていた場合のリスク	優先度
C1	従業員数100～500人の企業では、人事マネージャーがオンボーディングを管理している	致命的	P1
C2	現在のオンボーディングは手作業で、時間がかかる（新入社員1人あたり5時間以上）	致命的	P1
C3	オンボーディングの質が低いと離職につながり、企業はそれを問題視している	致命的	P1
V1	ワークフローを自動化すれば、新入社員1人あたり3時間以上を削減できる	重大	P2
V2	企業は従業員1人あたり月額50～100ドルを支払う	重大	P2
H1	LinkedInを通じて人事マネージャーにアプローチできる	軽微	P3

P1 検証計画：

実験1：課題の発見

• 対象：従業員数100～500人の企業に勤める人事マネージャー15人
• 方法：30分間の電話インタビュー
• 質問：
  1. 「誰かを採用したときに何が起きるのか、順を追って教えてください……」
  2. 「そのプロセスで最も頭を悩ませることは何ですか？」
  3. 「新入社員1人あたり、オンボーディングにどれくらい時間がかかりますか？」
  4. 「現在、どのようなツールを使っていますか？」
  5. 「オンボーディングがうまくいかなかった場合、どのようなコストが発生しますか？」

成功基準：

• 検証：15人中10人以上が、手作業で時間のかかるプロセスだと説明する。8人以上が具体的な課題を挙げる
• 棄却：大半が「オンボーディングに問題はない」と答える、または採用1人あたりの所要時間が4時間未満

インタビューガイドのサンプル：

Opening: "I'm researching how mid-size companies handle employee onboarding.
Not selling anything - just learning. Mind if I ask some questions?"

Problem Exploration:
1. "When you hired your last employee, walk me through the onboarding process..."
2. "What took the most time?"
3. "Where do things typically go wrong?"
4. "Tell me about a time onboarding didn't go well..."

Current State:
5. "What tools or systems are you using for this?"
6. "What do you like about your current process?"
7. "What's frustrating about it?"

Impact:
8. "How does onboarding quality affect employee retention?"
9. "If you could wave a magic wand, what would change?"

Close:
10. "Who else should I talk to about this?"
11. "Can I follow up in a few weeks to share what I'm learning?"

---

例2：コンシューマーアプリ - フィットネス

背景： 創業者は、忙しい親向けのフィットネスアプリを作りたいと考えています。

入力：

「顧客発見インタビューを12件実施しました。以下がその概要です。進捗を評価してください。」

インタビューの概要：

• 30～45歳の働く親に12件のインタビューを実施
• 12人中10人が、もっと運動したいと回答
• 12人中8人が、時間がないことを主な障壁として挙げた
• 12人中6人が、以前フィットネスアプリを試したことがある
• 現在、何らかのフィットネスサービスに料金を支払っているのは12人中2人だけ
• 12人中4人が、新しいアプリを「おそらく」使うと回答

出力：

顧客発見の評価：

基準	しきい値	結果	合格？
完了したインタビュー数	10件以上	12件	✅
誘導なしで課題を確認	70％以上	83％（12人中10人）	✅
課題の深刻度	7以上	不明	⚠️
解決策への支出	50％以上	17％（12人中2人）	❌
代替案を積極的に探している	30％以上	不明	⚠️

分析：

良い兆候：

• 課題が強く確認されている（運動したいが、時間がない）
• インタビューを通じて一貫した傾向が見られる

警告サイン：

• 何らかのサービスに支払っているのは17％のみ（支払い意欲が低い）
• 「おそらく使う」は弱い兆候（確約ではなく、意見にすぎない）
• アプリを試した6人のうち、現在も支払っているのは2人だけ（解約率が高い）

不足しているデータ：

• 課題はどれほど深刻ですか？（1～10の尺度）
• 最近、どのようなものを試しましたか？
• いくらなら支払いますか？（予測ではなく、過去の行動）

診断： 課題は検証されましたが、市場は未検証です。

課題は実在します（忙しい親は運動したいと考えています）。しかし、証拠からは次のことが示唆されます。

• これを望んでいるとは言うものの、料金は支払わない
• 認知度は高いが、コンバージョン率と継続率は低い
• 「あるとうれしい」ものであり、「なくてはならない」ものではない

提案：作る前に、さらに深掘りする

次の5件のインタビューでは、以下に焦点を当てます。

1. 「実際に料金を支払い、使い続けたフィットネス製品について教えてください……」
2. 「以前使っていた［前のアプリ］を使わなくなったのはなぜですか？」
3. 「現在料金を支払っているお二人と、支払っていなかった頃とでは、何が違いますか？」
4. 「このアプリは月額20ドルだと伝えたら、どう感じますか？」
5. 「フィットネスが『あるとうれしい』ものではなく、『なくてはならない』ものになるには、何が必要ですか？」

判断： まだ作らないでください。このセグメント内で、より切実な課題を見つけるか、より強い購買行動を示すセグメントを見つけてください。

---

例 3：ピボットの判断

背景： 創業者は課題を検証しましたが、ソリューションは不評でした。

入力：

「課題は検証済みです。小規模事業者は簿記を嫌がっています。しかし、自動簿記ツールを見せたところ、反応は今ひとつでした。10人中3人が興味を示しました。ピボットすべきでしょうか？」

出力：

状況分析：

フェーズ	結果
課題の発見	✅ 検証済み
ソリューションの発見	❌ 失敗（30% < 基準値の70%）

ピボットする前に確認する質問：

1. 興味を示した3人はどのような顧客でしたか？

   • その人たちに共通する特徴は何ですか？
   • 同じ課題でも、深刻度が異なっていましたか？
   • 異なるサブセグメントでしたか？

2. 残りの7人が興味を示さなかったのはなぜですか？

   • 課題は正しいが、ソリューションが間違っていましたか？
   • ソリューションは正しいが、位置づけが間違っていましたか？
   • その人たちにとって、課題の深刻度が十分ではありませんでしたか？
   • すでに十分なソリューションを利用していましたか？

3. 具体的に、どの点が不評でしたか？

   • 「複雑すぎる」
   • 「すでに別のものを使っている」
   • 「本当の課題を解決してくれない」
   • 「価格が高すぎる」

ピボット判断のフレームワーク：

┌─────────────────────────────────────────────────────────┐
│                 SOLUTION FAILED                          │
│                                                          │
│  Is the problem still validated?                         │
│  └── YES → Solution Pivot (keep problem, change solution)│
│                                                          │
│  Were some customers excited?                            │
│  └── YES → Segment Pivot (narrow to excited segment)     │
│                                                          │
│  Did feedback suggest different problem?                 │
│  └── YES → Problem Pivot (keep customer, find new problem)│
│                                                          │
│  Is there any signal at all?                             │
│  └── NO → Consider stopping or major pivot               │
└─────────────────────────────────────────────────────────┘

次のステップの推奨事項：

1. 興味を示した3人に詳しくインタビューする

   • 具体的にどの点に興味を持ちましたか？
   • いくらなら支払いますか？
   • パイロットへの参加を約束してくれますか？

2. 「いいえ」と答えた7人の理由を理解する

   • 何があれば興味を持っていましたか？
   • 代わりに何を使っていますか？

3. 次のピボットを検討する：

   • セグメントのピボット： 興味を示したセグメントだけを対象にする
   • ソリューションのピボット： 同じ課題に対し、異なるソリューションを提供する（もっとシンプルなものがよいかもしれません）
   • チャネルのピボット： 同じソリューションを、異なる方法で提供する

4. 何かを構築する前に：

   • 有料パイロットを3件獲得するか、LOIを取得する
   • 「前払いでXドルお支払いいただければ、これを構築します」

---

チェックリストとテンプレート

顧客発見の準備状況チェックリスト

## Before Starting Customer Discovery

### Preparation
- [ ] Business Model Canvas hypotheses documented
- [ ] P1 hypotheses identified (highest risk)
- [ ] Target customer segment defined
- [ ] Interview questions drafted
- [ ] 15+ potential interviews scheduled

### Mindset
- [ ] Committed to learning, not selling
- [ ] Ready to hear "your idea is wrong"
- [ ] Willing to pivot based on evidence
- [ ] No code written yet (or willing to throw away)

### Resources
- [ ] 2-4 weeks allocated for discovery
- [ ] Note-taking system ready
- [ ] Team aligned on validation criteria

---

インタビュー追跡テンプレート

## Customer Discovery Interview Log

| # | Date | Name | Company | Segment | Problem Confirmed? | Solution Fit? | Commitment? | Key Quote |
|---|------|------|---------|---------|-------------------|---------------|-------------|-----------|
| 1 | | | | | Y/N | Y/N/NA | | |
| 2 | | | | | Y/N | Y/N/NA | | |
| 3 | | | | | Y/N | Y/N/NA | | |

### Running Totals
- Interviews completed: __/15
- Problem confirmed: __%
- Solution fit (if applicable): __%
- Commitments received: __

---

実行／中止判断テンプレート

## Customer Discovery Decision Point

**Date:** _______________
**Total Interviews:** _______________
**Hypothesis Being Tested:** _________________________________

### Evidence Summary

| Metric | Target | Actual | Pass? |
|--------|--------|--------|-------|
| Problem confirmation rate | 70%+ | | |
| Average severity score | 7+/10 | | |
| Currently paying for alternatives | 50%+ | | |
| Solution fit (if tested) | 70%+ | | |
| Concrete commitments | 3+ | | |

### Strongest Evidence FOR:
1.
2.
3.

### Strongest Evidence AGAINST:
1.
2.
3.

### Decision

- [ ] **PROCEED:** Build MVP / Start selling
- [ ] **ITERATE:** More interviews needed, adjust approach
- [ ] **PIVOT:** Change [customer/problem/solution]
- [ ] **STOP:** No viable market here

### If Proceeding, Next Steps:
1.
2.
3.

### If Pivoting, New Hypothesis:

---

スキルの対象範囲

このスキルが得意なこと

• 説得力のあるコンテンツを構成する
• コピーライティングのフレームワークを適用する
• 下書きのバリエーションを作成する
• 競合のアプローチを分析する

このスキルではできないこと

• コンバージョン率を保証する
• ブランドボイスの策定に取って代わる
• 特定のオーディエンスを把握する
• 最終承認の判断を下す

参考資料

• Blank, Steve. 『The Four Steps to the Epiphany』（2005年）- オリジナルの方法論
• Blank, Steve & Dorf, Bob. 『The Startup Owner's Manual』（2012年）- 拡張された実践ガイド
• Ries, Eric. 『The Lean Startup』（2011年）- 構築・計測・学習の背景
• Fitzpatrick, Rob. 『The Mom Test』（2013年）- インタビュー手法
• Osterwalder, Alex. 『Business Model Generation』（2010年）- BMC フレームワーク
• Maurya, Ash. 『Running Lean』（2012年）- リーンキャンバスのアプローチ

関連スキル

• mom-test - 正直なフィードバックを得るためのインタビュー手法
• lean-canvas - 1ページでビジネスモデルを文書化する
• jobs-to-be-done - 顧客が前進するために求めていることを理解する
• problem-interview - 課題の発見を深く掘り下げる
• solution-interview - ソリューションとの適合性を検証する

---

スキルのメタデータ（内部使用）

name: customer-discovery
category: validation
subcategory: methodology
version: 1.0
author: MKTG Skills
source_expert: Steve Blank
source_work: The Four Steps to the Epiphany
difficulty: intermediate
estimated_value: $5,000 startup consulting engagement
tags: [customer-development, validation, startups, YC, lean-startup, interviews]
created: 2026-01-25
updated: 2026-01-25