顧客インタビューを複数件実施し、議事録や録音も残した。それなのに営業は「明日の商談で何を変えるのか」、開発は「どの課題を優先すべきか」、経営層は「追加投資の根拠になるのか」が分からない。そんな状態では、調査結果を共有したとは言えても、意思決定につなげたとは言えません。
本記事では、BtoBの顧客インタビューで得た観察を、営業・開発・経営層が使える1ページの意思決定メモへ変える方法を整理します。調査対象者の選定、質問、分析、保管については別記事に譲り、ここでは「どう伝え、次の判断を残すか」に絞ります。
最初に「この報告で何を決めたいか」を書く
報告を作るとき、インタビューで印象に残った発言を先に並べたくなります。しかし、強い言葉ばかりが議論を支配すると、施策の正当化に都合のよい証言を探す作業に変わりかねません。
英国政府のGOV.UK Service Manual「Sharing user research findings」は、調査結果の共有によって、チームが設計を決定し、仕事の優先順位を決め、次の検証へ進めるようにすることを重視しています。これは行政サービス向けの手引きですが、複数部門が購買体験を改善するBtoB実務にも参考になります。
例えば「営業資料を拡充するか」「価格設計の見直しが先か」「失注理由を追加調査すべきか」を最初に明示します。まだ判断できないときは「今回の調査では決められないこと」を報告の結論にして構いません。
観察・解釈・施策を一つの文章に混ぜない
「顧客が価格に不満を持っているので、値下げが必要だ」と書くと、実際の発言と分析、施策の提案が区別できません。まず誰がどんな状況で何を言ったかを観察として記録し、考えられる理由を仮説として分け、そのうえで試す案を示します。
- 観察：調査対象者の一部が「稟議で価格説明を求められた」と述べた。
- 解釈：価格そのものだけでなく、社内説明資料の不足が影響している可能性がある。
- 反例：資料を十分に用意していても導入が遅れたケースが存在する。
- 提案：値下げを即決するのではなく、購買審査用の資料を小さく試し、案件の質問内容を追加確認する。
上の発言とケースは説明のための架空例です。実在の顧客調査結果ではありません。具体的な観察から仮説を整理する方法はBtoB顧客インタビューの分析方法で詳しく扱っています。
そのまま使える「1ページ報告書」の7項目
調査を社内の知識として残すときは、最初に以下の7要素を一枚にまとめ、個別の発言や詳細ログは参照先へ分けるのが有効です。これはGOV.UKを参考に、本サイトがBtoB組織向けに提案する編集ひな型であり、公式の標準書式や効果が実証された万能形式ではありません。
- ① 判断テーマ：何を決める会議なのか。決定権を持つ人と期限。
- ② 調査の輪郭：調査目的、募集方法、参加者の役割、件数、対象外だった顧客。
- ③ 主な観察：実際の行動と発言を要約し、調査IDなどで裏づけを辿れるようにする。
- ④ 解釈と反例：考えられる理由、別の説明、確認できていない点。
- ⑤ 事業上の意味：購買・導入・利用のどこに問題があり、誰に影響するか。影響額が未測定ならそのまま記す。
- ⑥ 次の検証：施策案、実施責任者、期間、評価指標、止める条件。
- ⑦ 参照・取扱い：調査記録への安全な参照先、共有してよい範囲、問い合わせ先。
重要なのは、一枚の資料にすべての証拠を埋め込まないことです。詳細な記録は、適切な権限を持つ人が別途確認できればよく、個人情報や取引先の機密を全社共有する必要はありません。
架空の例：失注理由は本当に価格なのか
以下は実在の案件ではありません。仮にBtoB SaaS企業が、失注企業4件と導入済み企業2件の関係者にインタビューしたとします。営業は「価格が高い」が主な失注理由だと予想していました。
しかし調査では、価格への懸念に加えて、セキュリティ審査の説明資料が不足していたという発言も出ました。一方、資料が十分でも意思決定が遅れた企業もあったとします。
この結果から「値下げは不要」とは言えません。価格の問題と社内合意の問題がどの程度影響するかを、この少数の調査だけでは推定できないためです。そこで報告書には、推定売上効果を盛り込まず、限定した案件で審査資料を試作し、営業が利用できたか、質問が減ったか、追加調査すべき点は何かを確認する提案を記載します。
一度の調査で経営判断をすべて確定しないことも、調査を意思決定につなげる大切な方法です。
営業・開発・経営で、同じ知見の見せ方を変える
営業にとって重要な情報は、次の商談で何を確かめればよいか、顧客が社内へ説明する際に何で困っているかです。特定顧客の発言を、ほかの顧客にも当てはまる販売トークとして一般化してはいけません。
開発・プロダクトにとって重要な情報は、機能の要望そのものより、顧客がどの業務で何を達成できなかったのかです。「顧客が機能を要求した」という事実は、必ずしもその機能の実装が正解であることを意味しません。
経営にとって重要な情報は、顧客課題の深刻さ、事業仮説への影響、意思決定の選択肢、追加調査や試験に必要な費用と時間です。少人数の聞き取りから市場全体の割合を推定したかのように報告しません。
反例と「まだ言えないこと」を必ず残す
例えば、6人の調査対象者のうち4人が似た課題を話したとしても、それが市場の3分の2に存在するという意味ではありません。対象者をどう募集したか、既存顧客に偏っていないか、企業規模や役割が違わないかで解釈は変わります。
英国政府の調査分析ガイドは、観察記録から発見事項を整理し、次に変えるものや追加で確かめる問いを区別しています。この発想を使えば、反対の証拠を「ノイズ」として捨てず、報告に組み込めます。
報告会を「参考になった」で終わらせない
発見事項を説明した後は、決定事項と保留事項を明記します。何を試すかだけでなく、何をまだ試さないかも合意できれば、調査が新しい仕事を無制限に増やすことを防げます。
- 決定：どの案を小さく試すか、見送る案は何か。
- 担当者：営業・マーケ・開発のうち、誰が試験を進め、誰が判断するか。
- 評価：実際の顧客質問や案件進行など、検証したい仮説に合う指標。
- 見直し条件：反例が増えた場合、対象とする顧客が変わった場合に何を再調査するか。
GOV.UKのユーザー調査計画ガイドは、得られた知見を計画会議や優先順位づけに取り込むことを勧めています。調査を継続的な学習の一部として扱う発想は、BtoBのGTMや顧客体験改善にも応用できます。
発言を共有するときは、権利と機密を優先する
顧客の発言が印象的でも、録音・文字起こし・企業名・導入計画を自由に社内外へ転送してよいわけではありません。調査時に説明した目的や共有範囲、契約、法令、社内ルールと整合する形で扱います。
録音や元データの扱いについてはBtoB顧客インタビュー記録の保管・再利用で詳しく説明しています。英国政府の参加者のプライバシー管理ガイドも参考になりますが、日本の法令や契約上の判断は個別に確認する必要があります。
まとめ：判断の質が、報告書の価値を決める
調査の価値は議事録の分量でも、発言のインパクトでもありません。少ない情報からでも、観察できたこと、別の解釈、確認できていないこと、次に検証することを分ければ、関係者が同じ土台に立てます。
1ページ報告書の目的は、複雑な現実を簡単な答えに変えることではなく、複雑さを失わずに次の判断を可能にすること。そのために、裏づけに戻れる参照先と責任者も残しておきます。
確認資料と、本サイトによる応用の範囲
- GOV.UK Service Manual「Sharing user research findings」：研究結果をチームの判断や優先順位へ接続するための指針。
- GOV.UK Service Manual「Analyse a research session」：観察、発見事項、行動案の整理。
- GOV.UK Service Manual「Plan user research for your service」：意思決定と調査を結び付ける設計。
- GOV.UK Service Manual「Managing user research data and participant privacy」：参加者の記録・情報を保護するための実務。
英国政府のサービス設計ガイドを参考にしましたが、1ページ報告書の7要素やBtoBの例は本サイトによる提案です。架空の顧客事例を実証データとして扱わないでください。
調査の前後をつなぐ関連記事
対象者を選ぶにはBtoB顧客インタビューの対象者選び、質問の仕方はインタビューの聞き方、結果の読み解きはインタビュー分析、記録の扱いは記録の保管・再利用を参照してください。