フレームワーク活用ガイドひとことで言うと#
「自分たちの思い込み」ではなく顧客の現実に基づいてプロダクトを作るために、オフィスを出て顧客に直接会い、課題仮説を検証するプロセス。スティーブ・ブランクの名言「ビルの中に事実はない。外に出ろ（Get out of the building）」がすべてを表している。
押さえておきたい用語#
- 顧客開発（Customer Development）
- スティーブ・ブランクが提唱したスタートアップの4段階プロセスのこと。カスタマーディスカバリーはその第1段階にあたる。
- 課題仮説（Problem Hypothesis）
- ターゲット顧客が抱えていると自分たちが信じている課題を指す。この仮説が正しいかをインタビューで検証する。
- アーリーアダプター
- 課題が深刻で、不完全な解決策でも積極的に試してくれる初期の熱心な顧客層である。カスタマーディスカバリーではこの層を見つけることが重要。
- 代替手段（Workaround）
- 顧客が自社プロダクトがない状態で課題をどう解決しているかのこと。Excel、手作業、競合製品など。代替手段の存在は課題の深刻さの証拠になる。
カスタマーディスカバリーの全体像#
こんな悩みに効く#
- 「これは売れるはず」と信じて作ったのに、誰も使ってくれない
- 顧客が本当に困っていることと、自分たちの想定がズレている気がする
- インタビューはしているが、何を聞けばいいのかわからない
基本の使い方#
まず自分たちが信じている仮説を明文化する。ここが曖昧だとインタビューがただの雑談になる。
書き出すべき仮説:
- 顧客仮説: 誰がターゲットか？（具体的なペルソナ）
- 課題仮説: その人はどんな課題を抱えているか？
- 解決策仮説: どうすれば課題を解決できるか？
重要: この段階では解決策に固執しない。「課題が本当に存在するか？」を検証するのが最優先。解決策はあとから変えられるが、存在しない課題を解決するプロダクトは救えない。
仮説で設定したターゲットに最低10人は会う。5人だと偏りが出る、20人を超えるとパターンが見えてくる。
インタビューの鉄則:
- ソリューションを売り込まない — 自分の製品の話は最後まで出さない
- 過去の行動を聞く — 「使いたいですか？」（ダメ）→「前回この課題にどう対処しましたか？」（良い）
- お金と時間の話をする — 「この課題を解決するためにいくら払ったことがありますか？」で本気度がわかる
おすすめの質問テンプレート:
- 「〇〇について、一番大変なことは何ですか？」
- 「最後にその問題に困ったのはいつですか？具体的に教えてください」
- 「今はどうやって対処していますか？それの何が不満ですか？」
インタビュー結果を整理して、仮説が正しかったか判定する。
分析のポイント:
- 共通するキーワードを抽出する（3人以上が同じ言葉を使ったら注目）
- 課題の深刻度をランク付けする（「あったらいいな」vs「今すぐ解決したい」）
- 既存の代替手段を把握する（Excelで我慢している、手作業でやっている等）
仮説と現実のギャップが見つかったら、仮説を修正して再度インタビューする。このループを「課題が確かに存在する」と確信できるまで回す。
以下の条件を満たしたら、カスタマーディスカバリーは「完了」と判断できる。
- 10人中8人以上が同じ課題を挙げる
- その課題に対してお金や時間を既に使っている（課題の深刻さの証拠）
- 既存の解決策に明確な不満がある
- ターゲット顧客に繰り返しリーチできる手段がある
この段階で初めて「何を作るか」の議論に移る。順番を間違えると、誰も欲しがらないものを精巧に作り込むことになる。
具体例#
状況: 従業員8名のスタートアップが「社内のナレッジが散逸している」という課題を解決したいと考えた。
初期仮説: 「50〜200人規模のIT企業のマネージャーは、チームの知見がSlackに埋もれて困っている」
インタビューで判明した現実（15人に実施）:
- マネージャーは確かに困っているが、本人が一番困っているわけではなかった
- 一番困っていたのは入社3ヶ月以内の新人。質問するのが申し訳なくて、過去のSlackを1時間以上さまよっている
- 既存の対処法はNotionやConfluence。だが書く人がいないのが真の問題
- 「検索ツール」より**「書かなくてもナレッジが蓄積される仕組み」**を求めていた
仮説の修正:
- ターゲット: マネージャー → 入社1年未満のメンバー（＋オンボーディング担当者）
- 課題: ナレッジが散逸 → 「聞きたいけど聞けない」問題
- 解決策: 検索ツール → Slackの会話を自動で構造化するツール
この方向転換は15名のインタビュー（3週間、費用約20万円）で得られた。当初の方向のまま開発していたら、ターゲットと課題の両方を外していた。
背景: 大手IT企業出身の3名が「飲食店の予約管理をDXする」サービスを構想。高機能な予約管理SaaSを計画。
初期仮説: 「席数30〜80のレストランのオーナーは、電話予約の管理に週5時間以上を費やし、月額1万円のツールに価値を感じる」
インタビュー結果（レストランオーナー・店長12名）:
| 仮説 | 現実 |
|---|---|
| 予約管理に週5時間 | 平均2.5時間。「そこまで困っていない」 |
| 電話予約が負担 | 電話は常連との大切な接点。無くしたくない |
| 高機能ツールが欲しい | 「機能が多いと使いこなせない」が8名 |
| 月額1万円に価値 | 月3,000円が上限。年商規模が違う |
本当の課題: 予約管理ではなく**「ドタキャン（当日無断キャンセル）」**。月平均4.2件、被害額は月5〜8万円。全員がこれを「最大の痛み」と回答。
ピボット: 「高機能予約管理SaaS」→「ドタキャン防止に特化した予約確認自動リマインド＋デポジット機能」（月額3,000円）
12名のインタビューで、「自分たちが解きたい課題」と「顧客が本当に困っている課題」のギャップを発見した。ドタキャン防止に特化した結果、初月から契約率42%を記録し半年で120店舗に導入された、という成果がその裏付けになっている。
背景: 介護業界出身のエンジニアが、介護記録のデジタル化サービスを構想。人口5万人の町で8つの介護施設にインタビュー。
初期仮説: 「介護施設の管理者は、紙の記録からデジタルに移行したいが、適切なツールがない」
インタビューで判明した現実（施設管理者8名、現場スタッフ12名）:
- 管理者8名中5名が「デジタル化は進めたい」と回答 → 仮説は部分的に正しい
- しかし現場スタッフの85%がデジタル化に抵抗感。「入力に時間がかかると利用者さんと向き合う時間が減る」
- 最大の課題は記録のデジタル化ではなく、「夜勤スタッフへの申し送り」。口頭で20分かかり、伝え漏れが月平均3.2件発生
- 既存の代替手段: A4の申し送りノート（手書き）。読みにくい、書く時間がない
仮説の修正:
- ターゲット: 施設管理者 → 夜勤・日勤の引き継ぎ担当スタッフ
- 課題: 記録のデジタル化 → 申し送りの伝え漏れ防止
- 解決策: 総合記録システム → 音声入力で申し送りを自動構造化するアプリ
20名のインタビュー（4週間）で、「経営者が欲しいもの」と「現場が本当に必要としているもの」の乖離を発見。音声入力型の申し送りアプリは8施設中6施設がトライアル導入し、伝え漏れが月3.2件から0.4件に減少した。
やりがちな失敗パターン#
- インタビューで自分のアイデアを売り込む — 「こういう機能があったら使いますか？」と聞くと、相手は気を使って「いいですね」と言う。それは検証ではなく営業。自分のソリューションの話は封印する
- 友人や知人だけに聞く — 身近な人は本音を言いにくい。できるだけ利害関係のない人を探してインタビューする。LinkedInやイベント、紹介経由で見知らぬ人にアプローチする
- インタビュー件数が少なすぎる — 3人に聞いて「パターンが見えた」と思い込むのは危険。最低10人、できれば20人に話を聞く。N数が増えると最初は見えなかった共通項が浮かび上がる
- 「顧客が欲しいと言ったもの」をそのまま作る — 顧客は自分のニーズを正確に言語化できない。行動と文脈を観察して、発言の裏にある本当の課題を推察する
まとめ#
カスタマーディスカバリーは「何を作るか」を決める前に「何が本当の課題か」を突き止めるためのプロセス。建物の外に出て、顧客の現実を自分の目で確かめよう。10人にインタビューすれば、会議室で100時間議論するより確かな答えが見つかる。