インタビューを終えたのに、何も決められない
顧客インタビューを5件実施し、議事録も用意した。それなのに会議では「価格が高いと言われた」「導入が面倒らしい」と印象の強い発言ばかりが引用される――。この状態では、情報が増えただけで意思決定は進んでいません。
BtoBの顧客理解で重要なのは、聞き取った発言をそのまま「顧客ニーズ」へ昇格させないことです。誰が、どんな状況で、何を経験したのか。発言の事実と、そこから考えた仮説と、実行する施策を分離します。
英国政府のGOV.UK Service Manualも、ユーザー調査の分析では観察記録、パターン、発見事項、行動案を段階的に分ける進め方を示しています。以下はその原則をBtoBマーケティングの現場向けに応用した手順です。
1．分析前に「今回決めたいこと」を一つに絞る
最初に研究目的を一文にします。例えば「問い合わせ後に商談へ進まない理由は、資料不足か、社内合意の難しさかを確かめる」です。
「顧客の本音を知る」では抽象的すぎます。「製品の説明を増やすべきか」「情報システム部門向けの資料を先に用意すべきか」など、取り得る判断を明確にします。一方、顧客の語りに予想外の問題が出た場合に備え、仮説に当てはまらない発言も捨てません。
2．事実・解釈・判断を別々の列にする
まず、発言を小さな観察単位へ分解します。「価格が高い」だけでは情報が不足しています。「見積もり提出後、社内の購買審査で追加説明を求められた」「比較対象の製品には初期導入支援が含まれていた」という出来事まで確認できれば、仮説は変わります。
分析表の最低限の列は、①発言者IDと担当役割、②購買段階・状況、③観察できた発言または行動、④編集上の解釈・仮説、⑤反証・別解、⑥次に確かめること、です。企業名・個人名は可能な限り記録から切り離し、対応表が必要なら限定アクセスにします。
架空例：情報システム担当者P03が「導入前にセキュリティ部門へ説明できなかった」と語ったなら、観察は「社内説明資料が不足していた経験」。仮説は「技術的な確認資料が足りず、社内稟議が遅れた可能性」。行動候補は「セキュリティ審査用のFAQ試作」。しかし、これだけで「全顧客がセキュリティFAQを必要としている」とは言えません。
3．似た発言をまとめても、少数意見を消さない
複数の観察を、購買段階、部門、利用状況、障害要因などの切り口でまとめます。これがアフィニティ分析に近い作業です。GOV.UKの分析手順でも、まず個別の観察を出し、似たものをグループにし、その後で何が言えるかを判断しています。
ただし、BtoBでは「5人中3人が言ったから多数派」という処理は危険です。業種、役割、既存顧客か失注顧客かで構成が違うからです。極端な例として、導入決裁者が1人だけ指摘した法務上の障害は、実務担当者3人が挙げた小さな不便より、購買に重大な影響を持つかもしれません。
分類に当てはまらない発言、仮説を否定する発言、沈黙や回答不能も「ノイズ」と決めつけず、別欄に残します。
4．解釈の強さを「観察済み」「仮説」「未確認」に分ける
例えば「3人が導入説明の難しさを語った」は、その調査の観察事実として書けます。「導入説明の難しさが失注の主因」は、失注案件・受注案件の比較や追加調査が必要な仮説です。「この資料を公開すれば商談率が上がる」は施策効果についての予測であり、まだ実測ではありません。
レポートでは次のように記載します。
観察：研究対象の5件中、導入説明の難しさに言及したケースが3件あった。
仮説：社内説明に必要な情報の不足が意思決定を遅らせているかもしれない。
反例：別の2件では説明資料が十分でも審査期間は長かった。
次の検証：審査に要した日数と差し戻し理由を案件単位で照合する。
※上記の数値・ケースは手順を説明するための架空例であり、当サイトの実績や実在顧客の調査結果ではありません。
5．会議に持ち込むのは「発言集」ではなく判断案
分析結果からいきなり大規模な施策を始めるのではなく、費用と撤回のしやすさを考えます。たとえば「セキュリティFAQを2週間限定で試し、営業担当者が説明に使えたか、質問が減ったかを確認する」というように、小さな実装案を作ります。
結論を決める会議では、①確認できた事実、②候補となる解釈、③反例と未確認、④次の施策または追加調査、⑤判断を見直す期限と責任者、を一枚に整理します。顧客インタビューは施策を正当化する道具ではなく、間違った前提を早めに発見する機会です。
6．生成AIは分類補助に使い、判断の代行にはしない
生成AIには、許可されたデータだけを使って「観察文の重複候補を探す」「事実と解釈の混在を指摘する」「自分の仮説に不都合な発言を列挙する」といった補助を任せられます。一方、文章が滑らかでも、それが顧客の真意を証明するわけではありません。
個人情報、顧客の内部事情、契約情報、録音データ等を、利用条件を確認せず外部AIへ投入してはいけません。インタビュー時の同意で認められた目的・範囲と、所属組織のデータ取扱規則を満たす必要があります。GOV.UKの公式ガイドも、記録・個人情報を保護し、同意の範囲内で利用することを求めています。
チェックリスト：分析を終えたと言える条件
- □ 調査目的と判断対象が明確になっている。
- □ 元発言と編集上の解釈が別の列にある。
- □ 誰のどんな状況の発言かをたどれる。
- □ 反例・未回答・調査対象の偏りが残っている。
- □ 施策の根拠と限界を説明できる。
- □ 次に検証する行動、担当者、確認日を決めている。
- □ 公開・社内共有にあたり機密とプライバシーを守っている。
既存記事とのつながり
顧客の選び方はBtoB顧客インタビューの対象者選び、面談中の聞き方はBtoB顧客インタビューの聞き方で扱っています。本記事はその後工程として、インタビューで得た材料を実務判断へつなぐことに絞りました。定性データと数値の使い分けはBtoBで定性データをどう使うかも参照してください。
確認した外部資料
- GOV.UK Service Manual, Analyse a research session（観察・分類・発見・行動案の分離）
- GOV.UK Service Manual, Using in-depth interviews（調査目的・対象・記録の設計）
- GOV.UK Service Manual, Managing user research data and participant privacy（個人情報・同意・共有範囲）。
これらは英国政府のユーザー調査に関するガイドです。本記事のBtoB営業・マーケティングへの応用例および架空ケースの分析表は、本サイトによる編集上の提案です。
分析した結果をチームへ届けるには：観察・解釈・反例を整理した後は、BtoB顧客インタビュー結果の1ページ報告書で判断案へまとめます。録音・文字起こしや顧客情報の扱いは、調査記録の保管・再利用を参照してください。