顧客インタビューを20件実施し、議事録も要約もそろえました。それでも役員会で「この事業は続けるのか」と聞かれ、答えが出ません。顧客インタビューの失敗は、会話が途切れたときより、情報が集まったのに判断できないときに表面化します。
原因は、質問のうまさだけではありません。仮説の当事者ではない人に会い、未来の意向を聞き、自社サービスを先に説明し、判定条件を決めないまま好意的な発言だけを拾ってしまいます。設計のどこかが欠ければ、20件の面談が20件の感想で終わります。
この記事では、顧客インタビューで起きる失敗を10パターンに分け、相手選び・問いの設計・場のつくり方・解釈と意思決定の4局面から、次の面談前に直せる形にまとめました。
顧客インタビューの失敗は「聞き方」より設計で決まる
インタビュー当日に挽回できる範囲は限られます。相手が仮説の当事者でなければ、丁寧に聞いても、当事者ではない人の一般論が集まるだけです。
よくある始まり方は、「ニーズを確かめたい」という曖昧な目的です。話を聞かせてくれそうな知人を集め、質問は前日に作ります。すると「あったら便利ですね」という答えは増えますが、その人が買う理由までは分かりません。
失敗が入る局面は4つです。
- 相手選び:誰の、どの行動を確かめるのか
- 問いの設計:過去の事実を聞く質問になっているか
- 場づくり:説明や誘導で発言を変えていないか
- 解釈と意思決定:何が分かれば続け、何が出れば止めるのか
この順で確認すると、当日の進行だけを反省して終わらず、次の設計を変えられます。
顧客インタビューの失敗パターン10選
10パターンは、症状から原因を探せるよう、相手選びから意思決定までの順に並べています。
番号 | 失敗パターン | 起きる局面 | 会議で現れる症状 |
|---|---|---|---|
1 | 仮説の当事者ではない人に会う | 相手選び | 一般論しか出ない |
2 | 会いやすい人だけに会う | 相手選び | 全員が好意的に答える |
3 | 属性が同質すぎる | 相手選び | 発言の違いが見えない |
4 | 未来の意向を聞く | 問いの設計 | 「使うと思います」が集まる |
5 | 誘導質問で答えをつくる | 問いの設計 | 仮説と同じ言葉が返る |
6 | 課題の存在を直接確認する | 問いの設計 | 困りごとが実在するように見える |
7 | 自社サービスの説明から入る | 場づくり | 商談になり、現状が聞けない |
8 | 発話の原文を残さない | 場づくり | 要約の根拠を確認できない |
9 | 判定条件を事前に決めない | 解釈 | 良い感想だけを成功と読む |
10 | 結果を意思決定につなげない | 意思決定 | 報告して終わる |
最初に確認するべきは1番です。相手が違えば、その後の質問や分析が正しくても、無関係な人の感想しか得られません。8番と10番は、面談自体は終わっているため見逃されやすく、次の案件でも同じ失敗が続きます。
顧客インタビューの相手選びで起きる失敗
参加者の条件は、面談当日には直せません。役職名だけで集めず、確かめたい行動と意思決定の位置まで書きます。
1. 仮説の当事者ではない人に会う
仮説の当事者は、その課題を実際の業務や生活で経験し、解決策に金銭や時間を使う判断へ関わる人です。ここを外すと、「困っている人はいると思います」という第三者の推測が返ります。
BtoBでは、利用者、決裁者、購買部門を混同しやすいものです。現場の利用者は困っていても予算を持たず、決裁者は予算を持っていても日々の作業を知りません。購買部門は条件を確認します。同じ質問でも、3者の答えは違います。
条件は「情報システム部長」より、「直近1年にSaaSの新規導入を稟議へ上げた人」と行動で書きます。役職が合っているだけの人を外し、確かめたい意思決定を経験した人に会えるからです。
2. 会いやすい人だけに会う
取引先、社内の別部署、知人、既存顧客は声をかけやすい一方、関係を壊さないよう強い否定を避けることがあります。全員が前向きに答え、集計上は需要があるように見えても、購入判断とは別です。
参加者一覧に、既存の関係がない人を入れてください。何割が正解かを先に決める必要はありません。0人のまま終えないことが出発点です。好意を示す理由と、実際に買う理由を分けて読めます。
3. 属性が同質すぎる
同じ業界、企業規模、導入経験の人だけを集めると、回答の違いが出ません。「全員が同じことを言った」のではなく、同じ条件の人にしか聞いていない可能性があります。
人数を増やす前に、回答が割れそうな属性を2軸選びます。たとえば企業規模と導入経験の有無です。各組み合わせに参加者を置けば、需要が強い条件と弱い条件が見えます。
Nielsen Norman Groupが2000年に公開した5人のユーザビリティテストに関する論考は、画面上の問題を見つけるための議論です。新規事業の需要を確かめる顧客インタビューへ、人数だけをそのまま当てはめる話ではありません。
顧客インタビューの問いで起きる失敗
質問の失敗は、丁寧な言い方かどうかではなく、いつのことを聞いているか、何を証拠に置くかに出ます。未来の希望より過去の行動、本人の評価より実際に払った金銭や時間を聞きます。
4. 未来の意向を聞く
「このサービスを使いますか」「いくらなら買いますか」と聞くと、回答者はその場の期待で答えます。発言した通りに予算を取り、導入するとは限りません。
質問を過去形に変えます。「最後にこの作業をしたのはいつですか」「そのとき何を使いましたか」「どこで止まりましたか」。価格なら、「同じ目的に現在いくら払っていますか」「誰が承認しましたか」と聞けば、実際の支出と決裁過程を確認できます。
Rob Fitzpatrickの『The Mom Test』も、相手の意見や将来予測より、過去の行動を聞く質問設計を説いています。好意的な感想を集めるのではなく、行動の事実へ戻る考え方です。
5. 誘導質問で答えをつくる
「この作業は面倒ではありませんか」「短縮できたらうれしいですよね」。質問に期待する答えが入っていると、相手は同意しやすくなります。議事録には「課題を確認」と残っても、質問者が答えをつくっただけです。
質問文を面談前に書き、仮説を知らない人にも読んでもらいます。「面倒か」ではなく、「この作業は前回どのような手順で進めましたか」と変えれば、負担の有無を回答者の行動から読めます。
6. 課題の存在を本人へ直接確認する
「この課題はありますか」と聞けば、回答者は質問に沿って困りごとを考えます。そこで出た「あります」を、そのまま購入理由にはできません。
見るのは、すでに何を払っているかです。外部サービスへの支払い、担当者の毎週の手作業、表計算ソフトでつくった回避策。こうした行動があれば、その課題へ対処する優先度が見えます。
「いま、どのように対処していますか」「そのために何人が何時間使いますか」と聞きます。答えが「特に何もしていない」なら、少なくとも現在の優先順位は高くありません。
顧客インタビューの場づくりで起きる失敗
相手と質問が合っていても、説明の順番と記録方法で情報が変わります。面談を終えることではなく、あとから発言の根拠へ戻れる状態までを設計します。
7. 自社サービスの説明から入る
冒頭でサービスを説明すると、その後の会話はサービスへの評価になります。本来聞きたかった業務の現状も、提示した機能に引っ張られます。
業務実態を聞く時間と、解決案への反応を見る時間を分けてください。同じ面談で行うなら、現在の作業、困った場面、既存の対処法を先に聞き切り、その後で説明します。順番を戻さないことが肝心です。
8. 発話の原文を残さない
「価格に懸念あり」という要約だけでは、高いのか、予算の取り方が分からないのか、稟議が通らないのかを区別できません。3つの問題には、別の打ち手が必要です。
録音する場合は、目的と利用範囲を伝えて同意を得ます。文字起こしと要約を分け、分析するときは原文へ戻ります。半年後に仮説が変わっても、発言の前後関係を読み直せる状態が必要です。
顧客インタビューの解釈と意思決定で起きる失敗
面談が正しく終わっても、読み方と会議の出口が決まっていなければ、一次情報は意思決定へ届きません。
9. 判定条件を事前に決めない
20件のうち3件が強い関心を示し、17件の反応が薄かったとします。条件を先に決めていなければ、3件を「有望顧客」と読むことも、17件を「需要なし」と読むこともできます。担当者に都合のよい説明が、あとから選ばれます。
面談前に、仮説を支持する条件と、取り下げる条件を書きます。たとえば「10件中、直近3カ月に同じ課題へ支出した人が3件未満なら、対象者か仮説を見直す」と置いてください。数字そのものはチームで議論できます。先に決めることに意味があります。
10. 結果を意思決定につなげない
報告が「分かったこと」の一覧で終わると、役員は次に何を決めるのか分かりません。結果は、続ける、条件を変えて続ける、止めるのいずれかへつなげます。
条件を変えるなら、対象者、課題、解決案のどれを変え、いつまでに何を確かめるかまで書きます。次の判断日がなければ、追加インタビューだけが続きます。
失敗パターンが混入する検証フェーズ
課題探索では、1番の「当事者ではない人」と6番の「課題を直接確認する」が起きやすくなります。仮説が粗く、誰に会うかを行動で定義できていない段階だからです。
解決案の検証では、4番の未来意向と7番のサービス説明が増えます。見せるものができると、現状を聞く前に説明したくなります。好意的な反応が、そのまま需要見込みへ置き換わります。
事業性を判断する段階で表に出るのは、9番の判定条件と10番の意思決定です。ただし、不備が入ったのは面談前です。判断会議で突然起きた問題ではありません。
8番の原文を残さない失敗は、どの段階でも起きます。記録方法は最初に決めたまま放置されやすいため、案件の節目で見直してください。
10パターンを防ぐチェックリスト
面談前に7項目、面談後に3項目を確認します。当日の話術より、前後の設計で防げる項目のほうが多いからです。
実施前
- 確かめたい仮説を1文で書いたか
- 相手を役職ではなく、過去の行動で定義したか
- 既存の関係がない参加者を含めたか
- 回答が割れそうな属性を2軸決めたか
- 誘導がないか、質問文を第三者が読んだか
- 未来の意向を、過去の行動を聞く質問へ変えたか
- 仮説を支持する条件と取り下げる条件を決めたか
実施後
- 同意を得た範囲で発話の原文を残したか
- 要約だけでなく、原文へ戻って分析したか
- 続ける、条件を変える、止めるの判断と期限を書いたか
飛ばしやすいのは、実施前の7番です。自分の企画を止める条件を自分で書くため、後回しにしたくなります。しかし、ここが決まれば、好意的な発言だけを拾う失敗と、報告して終わる失敗を同時に減らせます。
よくある質問
何件インタビューすれば十分ですか
件数だけでは決まりません。回答が割れそうな属性を選び、それぞれで新しい論点が出るかを見ます。同じ属性の人ばかりなら、少ない件数で回答がそろっても需要全体を確認したことにはなりません。
30分しかない場合、何を削りますか
自社サービスの説明と、社内で調べられる基礎情報を削ります。残すのは、直近の行動、そのときの対処法、払った金銭や時間を聞く質問です。録音や引用をする場合の同意確認は省けません。
社内の関係者だけでも検証できますか
質問の練習には使えますが、顧客需要の判断材料とは分けてください。社内の相手は企画の背景を知っており、質問の意図を補って答えます。実際の顧客と同じ条件ではありません。
まとめ
顧客インタビューが空振りする原因は、当日の話し方より、相手、質問、記録、判定の設計にあります。
- 相手は役職名ではなく、経験した行動で選ぶ
- 未来の意向より、過去の行動と現在の支出を聞く
- サービス説明の前に、現状の業務を聞き切る
- 同意を得た範囲で原文を残し、要約と分ける
- 仮説を支持する条件と取り下げる条件を、面談前に決める
- 報告は次の判断と期限まで書く
次の面談を設定する前に、参加者条件と判定条件の2行を先に書いてください。ここが曖昧なら、質問を増やしても判断材料は増えません。
