顧客インタビューで「この機能は便利だと思いませんか?」と聞けば、肯定的な答えを得られるかもしれません。しかし、その反応だけで開発・営業・マーケティングの投資判断をするのは危険です。重要なのは、顧客がどんな状況にあり、何を試し、どこで意思決定が止まったかを確かめることです。
この記事では、インタビューを自社仮説の「答え合わせ」にしないための質問設計、記憶と事実の違い、架空の商談例、調査後の記録、生成AIの安全な使い方を整理します。質問数を増やすためではなく、次の意思決定を改善するためのガイドです。
1. なぜ「欲しいです」という答えを、そのまま需要とみなせないのか
顧客の「使いたい」「価格が下がれば検討したい」は、意見や期待として尊重するべき情報です。ただし、購入の確約や社内稟議の通過を保証しません。製品の利点を前提にした問いを使うと、相手がその前提に沿って答える可能性もあります。
誘導しやすい質問:「この機能で作業が半分になれば導入したくなりますよね?」
より中立的な質問:「最近、その作業が難しかったのはどんな場面でしたか?」
英国政府のユーザー調査ガイド「Using in-depth interviews」も、開かれた中立的な質問、実際のエピソード、相手の言葉を掘り下げる聞き方を勧めています。これは顧客が必ず正確に回答するという保証ではなく、調査の質を高めるための方法上の指針です。
2. 過去の行動を聞いても、それだけでは事実と確定できない
「未来への予想より、直近の経験を聞く」は有用な出発点です。ただし、人は過去の行動なら嘘をつけないという考え方は正確ではありません。意図的な虚偽だけでなく、記憶の抜けや後からの意味づけも起こり得ます。
FivushとGrysmanによる自伝的記憶のレビューは、記憶の痕跡と再構成の両面を論じています。Bradburnらの過去の出来事に関する質問への回答研究も、想起が難しいときに部分的な記憶から推論して回答することを説明しています。どちらもBtoBの購買を直接調べた研究ではなく、記憶を絶対視しないための根拠として参照しています。
- 意見・希望:「もっと安ければ買うと思う」。将来の期待として扱う。
- 本人が語る経験:「先月、上司が予算を認めなかった」。重要な一次情報だが、本人の説明であると記録する。
- 別途確認できた記録:稟議履歴、問い合わせ日時、商談メモなど。記録自体の欠損や解釈にも注意する。
相手の言葉を尊重することと、情報を検証することは両立します。「本人がそう話した」という確認済みの事実と、「本当に原因がそれだった」という分析上の推定は別です。
3. 調査目的を決め、具体的な場面から聞く
最初に調査で何を確かめたいかを言語化します。「商談が止まる理由を知る」と「新製品のニーズを見極める」では、対象者も質問も異なります。先に決めるべきなのは調査の問いであり、望ましい答えではありません。
直近の行動をたどる7つの質問
- 「最近、その問題が起きたのは、いつ・どのような場面でしたか?」
- 「それまでは、どうやって対処していましたか?」
- 「別のやり方を探そうと思ったきっかけは何でしたか?」
- 「最初に何を調べ、その後どんな順番で動きましたか?」
- 「競合製品・内製・現状維持を含め、どんな選択肢を比べましたか?」
- 「社内では誰に相談し、どんな懸念や条件が出てきましたか?」
- 「最後にどう判断し、今も解決していないことはありますか?」
7問すべてを順番通りに聞く必要はありません。重要な出来事が出たら、いつ、誰と、何を行ったかを具体化します。言葉が曖昧なら追加で尋ね、わからなかった項目は未確認として残します。相手の話の流れを壊さず、想定外の論点を掘り下げる余地も残してください。
4. 架空のBtoB事例:価格が高いと言われたら
以下は説明用の架空例です。クラウドサービスの商談後、顧客から「価格がネックでした」と言われた場面を考えます。これだけで「値下げが必要」と結論を出すのは早計です。
避けたい質問:「価格を下げれば契約できますよね?」
聞き直す質問:「社内で比較した際に、どんな数字や条件が論点になりましたか?」
「誰が費用を見積もったか」「現状維持では何が困るか」「情報システム部門や決裁者から別の懸念は出たか」を尋ねれば、価格そのもの、費用対効果の説明、導入リスク、優先順位など複数の仮説を区別できます。
調査者はここで「本音を暴いた」と宣言しません。仮説を並べ、追加で確認すべき人・記録・案件を整理します。見つかった反例や聞けなかったことも、重要な調査結果です。
5. 聞いた話を「営業で使える証拠」に変換する
インタビューを終えたら、印象に残る発言を一つ抜き出すだけでなく、以下を一枚の記録に残します。これは調査結果をGTMや営業活動へつなぐための本記事の実務用ひな型であり、効果が実証済みの普遍的な手法という意味ではありません。
- 対象と状況:どの役割の人が、どんな課題や検討段階について話したか。
- 発言:直接引用と、編集者がまとめた要約を区別する。
- 確認できた行動・記録:発言を裏づける資料、日時、観測事実を整理する。
- 仮説:こちらが推測した理由と、ほかにあり得る説明を分ける。
- 反例・未確認:意見の異なる関係者、失注例、回答がなかった点を残す。
- 次の判断:何を追加で確かめ、誰がどの施策を変え、いつ確認するか。
たとえば「決裁時の比較資料が足りない」という仮説が出たなら、すぐに資料を大量制作するのではなく、実際の失注案件と受注案件で、どんな情報が使われたかを比較します。定性データと定量データを往復させる考え方も参考になります。
6. AIは客観性の保証ではなく、質問と記録を点検する補助
生成AIは誘導的な質問の候補を発見し、記録を整理し、仮説に反する情報を探す補助には使えます。しかし、文脈の誤読や事実の捏造も起こり得るため、AIの判定をそのまま顧客の本音や客観的事実として公表してはいけません。
調査前後に使えるAIへの問い
- 「質問案の中で望ましい答えを暗示している箇所を挙げ、中立的な言い換えを示してください」
- 「許可された記録から、本人の発言、調査者の推測、追加確認が必要な点を分け、根拠となる発言箇所を示してください」
- 「有力な仮説と矛盾する発言や、別の説明を探してください。根拠がなければ不明としてください」
録音や文字起こしには安全管理が前提です。参加者への説明、必要な同意、利用目的、保存期間、共有先、社内ルールを確認します。外部のAI・文字起こしサービスを使うなら、機密情報や個人情報の取扱いも検討します。英国政府の研究参加者への同意の案内と録音・記録の実務案内は参考になりますが、法令上の判断は適用法と自組織の規定に従ってください。
7. 仮説を棄却することも、保留することも成果になる
インタビューの価値は、想定どおりの答えを得ることだけではありません。仮説が間違っていたと分かれば、不要な投資を避けられる可能性があります。一方、一人の意見が違っただけで市場全体の戦略を覆す必要もありません。
BtoBでは複数の担当者が意思決定に関わるため、実務担当者、推進者、購買・情報システム部門、決裁者などの視点を区別することが重要です。受注した顧客だけに聞かず、失注・保留・未回答のケースも検討してください。
- 誰に訴求するかを見直す:GTM戦略へ。
- 顧客の購買組織を理解する:顧客理解・購買プロセスへ。
- 商談への引き継ぎ条件を決める:営業・マーケティング連携へ。
- 改善したかを検証する:KPI設計へ。
まとめ:「答え合わせ」ではなく、確かめられる問いを増やす
よい顧客インタビューは「相手の無意識を言い当てる技術」ではありません。顧客の状況を聞き、語られた出来事と確認できた事実を分け、別の説明も検討するための調査です。
次のインタビューでは、自社機能の評価を聞く前に、直近の出来事を一つ尋ねてみてください。そして「分かったこと」「まだ分からないこと」「次に確認すること」を別々に記録します。それが顧客理解を事業判断につなぐ出発点になります。
参考資料と確認範囲
下記は中立的な質問、記憶の限界、調査の同意と記録について参照した資料です。掲載した実務ひな型の効果を直接検証したものではありません。心理学論文は公開抄録を確認しており、本文全文の精査とは区別しています。
- GOV.UK, Using in-depth interviews — 調査の計画、中立的な質問、掘り下げ方。
- Fivush & Grysman (2023), Accuracy and reconstruction in autobiographical memory — 自伝的記憶のレビュー、公開抄録。
- Bradburn, Rips & Shevell (1987), Answering autobiographical questions — 過去の想起と推論、公開抄録。
- GOV.UK, Getting informed consent for user research — 参加者への説明と同意。
- GOV.UK, Taking notes and recording user research sessions — 記録とプライバシー保護。
聞き終えた後のステップ:インタビューの発言をそのまま「顧客ニーズ」と決めず、観察と仮説に分けることが重要です。「BtoB顧客インタビューの分析方法」では、発言の分類、反例、次の施策・追加調査へのつなぎ方を整理しています。
