BtoBマーケティングのN=1調査とは?一社の購買行動から仮説を見つける方法

アンケートで平均の傾向を把握しても、なぜ顧客が選んだのか分からない。反対に、一人の顧客へ深く話を聞くと、見えていなかった業務や意思決定の障害が分かることがあります。

こうした個別の状況へ注目する考え方は、マーケティングで「N=1」と呼ばれることがあります。ただし、一人の声が市場全体を代表するわけではありません。 BtoBで役立てるなら、個別の顧客から仮説を発見し、異なる顧客や実際の行動によって確かめるプロセスとして使う必要があります。

N=1で分かることと、分からないこと

一人の顧客へ詳しく話を聞くことで、業務が発生した背景、解決方法を探した過程、比較した選択肢、組織内での承認、導入後に困ったことなどを具体的に学べます。これは顧客の行動を説明する仮説を作るうえで価値があります。

一方、「市場の65%が同じ課題を持つ」「この製品なら成約率が20%上がる」といった割合や効果の推定を、一人のインタビューから行うことはできません。定性調査は行動の背景を理解するための方法であり、統計的な割合の測定とは目的が違います。

Nielsen Norman Groupの2021年の解説も、定量的なUX研究では母集団への推定に必要なサンプル数と誤差を考える必要があると説明しています。同資料の「40人」という目安は、特定の仮定のもとでの定量的なユーザビリティ研究に対するもので、BtoBインタビューへ機械的に当てはめる基準ではありません。

平均値は不要ではない――問いが違う

CRMの受注率、製品利用ログ、サポート件数といった数字は、特定の条件下で何がどれくらい起きたかを理解する助けになります。ただし平均値だけでは、例外的な業務フローや導入を止める関係者の存在が見えにくい場合があります。

一社の深掘りから未知の障害を見つけ、複数案件のデータでそれがどの程度起きているかを確認する。反対に、集計で不自然な変化が見つかったら個別事例へ戻る。この往復が重要です。

英国政府のサービス設計ガイドも、利用者が誰で、何を達成しようとし、実際にどう行動するかを理解し、開発過程を通じて継続的に調査することを勧めています。行政サービス向けの助言ですが、顧客の必要を机上の仮定で決めつけないための基本姿勢として参考になります。

BtoBでは「N=1の人」だけでなく「一社の意思決定」を見る

個人向けの購買と異なり、BtoBでは現場担当者、部門責任者、情報システム部門、購買・法務、経営層などが別々の条件で意思決定に関わることがあります。商談担当者の一人だけを聞いて「この会社はこう考えた」と確定しないようにします。

一社を深掘りするときには、その会社で課題が発生してから検討・承認・導入に至る過程を再現します。その過程で担当者ごとに何を判断したか、どこで止まったか、なぜ代替案が選ばれたかを確認します。

  • 発端:いつ、どの業務で問題が生じたか。誰が最初に気づいたか。
  • 探索:現状維持、内製、既存ツール、他社製品など何を候補にしたか。
  • 要件:必要な機能だけでなく、セキュリティ、費用、運用、契約上の制約は何か。
  • 合意:誰が何を懸念し、どんな資料や検証が必要だったか。
  • 結果:導入・見送り・保留のいずれになり、その後何が起きたか。

この五つの区分は本記事の編集上の実務整理であり、英国政府ガイドがBtoB購買について同じ五段階を定義したという意味ではありません。また、すべての案件がこの順番で進むわけでもありません。

インタビューでは「仮想の希望」より「過去の具体的な出来事」

深いインタビューでは、「どんな機能があれば買いますか」という未来の希望だけを聞くと、実際には選ばれない機能の提案が並ぶことがあります。そこで、直近の具体的な行動を思い出してもらいます。

  • 最後にその業務で困ったのはいつでしたか。その場面で誰が何をしましたか。
  • 最初はどの方法で解決しようとしましたか。なぜ別の方法を探しましたか。
  • 比較した候補と、それぞれを評価した条件を覚えていますか。
  • 誰が導入に必要な承認・検証を行いましたか。何が不足していましたか。
  • 結果として何を選びましたか。今振り返って未解決の問題はありますか。

英国政府のインタビュー手法ガイドも、面接の目的に応じて質問を準備し、誘導や回答の偏りに注意することの重要性を説明しています。インタビューの発言は貴重ですが、記憶違いや合理化の可能性もあるため、許可された範囲で実際の作業記録と照合します。

調査記録は「発言」「行動」「解釈」「未確認」に分ける

  • 発言:相手が実際に語った内容。要約と逐語引用を分ける。
  • 行動:操作履歴、提出した資料、会議の日時、承認の流れなど、確認できる事実。
  • 解釈:なぜその行動になったかという調査担当者の仮説。
  • 未確認・反証:ほかの説明の可能性、追加で見たい証拠、違う結論になりうる条件。

例えば「上司が慎重だった」という話を聞いても、上司が購入を妨害したと推測だけで決めつけるべきではありません。費用の説明が不足したのか、セキュリティ上の条件があったのかを確認します。顧客情報や録音を扱う際は、同意・契約・閲覧権限に従って保管します。

架空例――一社の失注分析から見つかった仮説

次は実在企業の商談記録ではない架空例です。あるBtoB SaaS製品の商談が失注しました。CRMの入力欄には「価格が高い」とだけ記録されています。

しかし、担当者へ具体的な経緯を聞くと、情報システム部門の要件確認が長引き、導入時期までに契約手続きを完了できなかった可能性が出てきます。価格も障害だったかもしれませんが、それだけを失注原因にするのは早計です。

この一社の調査から、「セキュリティ資料の提示時期が案件進行を妨げていないか」という仮説を得られます。しかし、それが市場全体で頻繁に起きるという証拠にはなりません。他の失注・保留案件でも同様の遅延があったかを確認します。

N=1を市場理解へつなげる四つの検証

  • 比較する顧客を増やす:受注した顧客だけでなく、失注・保留・利用停止した顧客も調べる。
  • 異なる立場の声を聞く:同じ会社でも現場と管理者が違う事情を説明することがある。
  • 行動の記録を探す:見積依頼、審査、契約までの時間、機能利用などの客観的な記録と照らす。
  • 反証を明記する:仮説が違うと判断する条件、調査対象の偏り、まだ分からない範囲を残す。

顧客調査の目的によってサンプル設計は変わります。統計的な割合を推定したい場合は、対象母集団、抽出方法、必要精度に合った定量調査を別途計画します。「何人調べれば絶対に正しい」という共通の数字をここで設定しません。

AIは記録の整理を補助できるが、顧客の代わりにはならない

生成AIにインタビューの内容を整理させるときは、実際の発言と、AIが補った推測を分けます。「顧客は変化を恐れている」などの心理的な説明を、AIがもっともらしく作っただけでは根拠になりません。

企業・個人の機密情報を外部サービスへ送る際には、利用目的・契約・同意・権限を確認します。AIは質問案の作成、矛盾点の指摘、仮説の列挙などに使い、人が出典と文脈を確認します。

まず一社を深掘りするための簡単な記録表

実務では「案件ID/対象業務/課題発生時期/関与部署/比較した代替案/確認した事実/本人の発言/解釈/反証条件/次の調査先」の十欄を用意すると、最初の案件を整理できます。個人名が不要な場合は記録せず、機密性の高い情報は閲覧権限を制御してください。

顧客の発言と行動を分ける詳しい方法はBtoB顧客インサイトの見つけ方、社内の意思決定まで視野を広げるにはBtoB顧客理解・購買プロセスも参照できます。

まとめ――一社を深く理解し、答えを決めずに検証する

N=1の強みは、市場の平均値では見えにくい仕事や意思決定の文脈を具体的に知ることです。弱みは、一社で起きたことをそのまま市場全体の事実として扱えないことにあります。

一社の出来事を丁寧に再現し、仮説と根拠を分け、他の案件で確かめる。N=1は市場の最終的な答えではなく、良い問いを生み出す出発点として使うのが適切です。

参考資料・出典

五つの購買場面、四区分の調査記録、十欄の記録表、架空例は本記事の実務上の提案です。上記機関が同一の表やBtoBでの成果を実証したという意味ではありません。

ほかの記事を探す

記事の訂正・出典情報は、お問い合わせから該当記事のURLと根拠資料をお知らせください。