新しい B2B 購買委員会：会議室に本当にいるのは誰か

5年前であれば、ミッドマーケットの SaaS 案件に関わるのは、推進者と予算の決裁者くらいでした。今では同じ案件がセキュリティ審査、IT アーキテクチャ、法務、財務、そして少なくとも1つのエンドユーザー委員会を通過します。購買委員会は、多くのベンダーのセールス活動が追いつくより速く拡大しました。その結果、サイクルは長くなり、予期せぬブロッカーが増え、口頭で合意したはずの案件が失注します。

これはセールスプロセスの問題ではありません。企業がソフトウェアを購入する仕組みそのものの構造変化です。売る側であれ評価する側であれ、誰が実際に会議室にいるのかを理解すれば、意思決定への向き合い方は大きく変わります。

5〜8人のステークホルダーという現実

2019年、Gartner の調査は、典型的なエンタープライズ向けソフトウェア購入には6〜10人の意思決定者が関与すると推定しました。この数は減っていません。むしろ顔ぶれはいっそう複雑になっています。

現在、ミッドマーケットからエンタープライズの B2B ソフトウェア案件の多くに登場するのは次の顔ぶれです。それぞれが実際に何を評価しているのかも合わせて見ていきます。

Champion（推進者）：課題を見つけた現場の責任者であることがほとんどです。CRM 案件なら、VP of Sales や Head of Revenue Operations であることが多いでしょう。宿題を済ませ、デモを重ね、強い選好を持っています。役割は社内で意思決定を売り込むことです。リスクは、プロジェクトが失敗すれば自分の名前が残ることです。しっかりした CRM 購入チェックリストがあれば、最初のデモの前に推進者が社内向けの説明を組み立てやすくなります。

Economic Buyer（予算承認者）：予算を握る CFO や VP Finance です。評価するのは ROI、投資回収期間、そして更新時に何が起きるかです。機能比較表を読んでいるわけではありません。彼らが問うのは、3年間でいくらかかるのか、18か月後にまた乗り換えることになったら自社にいくらの損失が出るのか、です。

IT / アーキテクチャ：重要性が増しているのに、過小評価されがちです。セキュリティ態勢、API の互換性、データモデル、そしてこのツールが連携上の負債を生まないかを評価します。モダンなデータスタックを運用している企業では、IT は形式的なチェックではなく、本物の技術的拒否権を持っています。

セキュリティ / CISO / DPO：規制産業や EU に顧客を持つ企業では特に重要です。これらのステークホルダーは、5週間の案件の4週目になるまで CRM の商談に登場しないこともあります。その時点で追加される要件の解消に、さらに6週間かかることがあります。

法務と調達（Procurement）：契約条件に注目します。データ処理契約、SLA、解約条項、責任上限などです。大企業では、これらがビジネス側の評価とは完全に独立したスケジュールで進みます。

エンドユーザー：パイロットグループや諮問委員会を通じて意見を聞かれることが多い層です。懸念は他と異なります。直感的に使えるか、自分のワークフローに合うか、6か月も新しいことを覚え続ける羽目にならないか、といった点です。

Executive Sponsor（経営スポンサー）：すべての会議に出席するわけではなくても、最終判断を左右する意見を持つ上級リーダーです。多くは戦略との適合を評価します。このベンダーは自社の方向性に合っているか、長く続く関係を築けるか、という視点です。

以上が7つの役割です。従業員500人の会社なら、この7人は別々の人物かもしれません。5,000人の会社では、その役割のいくつかに部門全体が控えています。

隠れた拒否権

上記のステークホルダーは、運営の行き届いた案件サイクルであれば多くの場合見えています。表に出しにくいのは、隠れた拒否権です。CRM の商談には現れないのに、プロセスの終盤で案件を沈めかねない役割のことです。

エグゼクティブアシスタント：経営スポンサーへのアクセスを握っています。その関係を築いていなければ、面談のリクエストはキューの中で止まったままです。

IT 部門内の技術的な推進者：IT ディレクターではなく、API ドキュメントや連携品質を実際に評価するシニアエンジニアです。正式な承認権限はなくても、厳しい技術レビューを出して勢いを止めることができます。

隣接システムの予算責任者：自社ツールがデータウェアハウスや請求システムに触れるなら、それらを所有する人が非公式の拒否権を持ちます。連携プロジェクトは、その人のロードマップに載るからです。

前職で競合製品を使っていた人：非公式ですが、確かに存在します。CFO が Salesforce を使う会社に3年在籍し、その製品を無条件に信頼しているとすれば、正式な役割がないまま会議室に声が1つ増えることになります。

こうした隠れた拒否権を把握するには、能動的なディスカバリーが必要です。LinkedIn では見つかりません。推進者にこう尋ねることで見つかります。「この決定の行方に、ほかに利害を持つ人は誰ですか？」

企業規模による委員会構成の違い

委員会の構造は、売上規模や従業員規模によって大きく変わります。

SMB（従業員100人未満、売上1,000万ドル未満）：購買の意思決定に関わるのは、多くの場合3人です。推進者、CEO または COO、そして時折 IT 寄りの担当者です。サイクルは短く、推進者と Economic Buyer が同一人物のこともあります。法務レビューは最小限です。リスクはスピードにあります。評価が足りないまま決めると、更新時に後悔することが少なくありません。

ミッドマーケット（従業員100〜1,000人、売上1,000万〜2億5,000万ドル）：委員会の複雑さが急増する規模です。通常、財務、IT、法務、事業部門にまたがって5〜8人のステークホルダーがいます。IT はガバナンスを強めつつあります。財務は複数年契約の条件を精査します。セキュリティは今や本格的な機能です。推進者は、小規模な会社では経験しなかった社内政治をさばかなければなりません。

エンタープライズ（従業員1,000人超）：8〜15人のステークホルダーは珍しくなく、案件の緊急度にかかわらず、正式な調達プロセスが手間を増やします。ベンダー管理チーム、優先ベンダーリスト、コンプライアンス審査によって、数か月かかることもあります。それ以前のステージが完了していないまま法務レビューに進んだ案件は、ここで恒久的に止まることが多くあります。

ステークホルダー影響マップ

誰が会議室にいるかを把握するだけでは足りません。その影響力の構造まで理解する必要があります。それをマッピングするためのフレームワークを紹介します。

特定したステークホルダーを、2つの軸に基づいて4つのセルのいずれかに配置します。

意思決定力（高または低）：その人の承認で案件を前に進められるか。発注書に署名したり、予算を承認したり、正式にコミットしたりできるか。

ブロック力（高または低）：他の誰が承認していても、その人は案件を止められるか。セキュリティ、法務、データ保護の役割は、意思決定力を持たないのにブロック力が高いことがよくあります。

結果として得られる4つの象限は次のとおりです。

象限1（意思決定：高 + ブロック：高）：案件を決める人たちです。早期に足並みをそろえてください。彼らが納得していなければ、ほかのことは何も意味を持ちません。

象限2（意思決定：低 + ブロック：高）：隠れた拒否権の保持者です。承認は必要ですが、あなたの推進者にはなってくれません。軽視すれば痛い目に遭います。6週目に現れて、誰も準備していない質問をする CISO は、象限2の失敗です。

象限3（意思決定：高 + ブロック：低）：技術評価を委任した予算責任者です。クロージングでは重要ですが、それ以前のプロセスでは他者の意見に頼っています。

象限4（意思決定：低 + ブロック：低）：エンドユーザーと技術評価者です。選好を形づくり、社内のストーリーを生み出しますが、正式な権限は限られています。それでも味方につけてください。購入後に新しいツールをチームに教える人が、現場での成功か失敗かを決めます。

ベンダーにとっての意味

Forrester の B2B 購買調査によると、B2B 購入を完了するまでに必要なやり取りの回数は、2019年以降およそ2倍になっており、その大きな要因は委員会構造の拡大です。マルチスレッディングはかつて、大型案件向けの高度なエンタープライズセールス手法でした。今ではミッドマーケット以上のあらゆる案件で最低条件です。

多くの CRM ツールは、商談の中に一対一のコンタクトレコードを作ります。SDR が推進者を見つけてコンタクトを作成し、そのコンタクトに対してアクティビティを記録します。決定が、それぞれ異なる時期に異なる情報を必要とするメンバーからなる委員会によって下される場合、こうした単線的なアプローチは通用しません。

これにうまく対応している CRM は、購買委員会の機能を商談オブジェクトに組み込んでいます。Salesforce の Account Engagement、HubSpot の複数コンタクト対応のディール段階、Pocus や Demandbase といった新しいツールは、ステークホルダーのカバレッジを明示的に追跡しようとしています。今お使いの CRM がマルチスレッディングにネイティブ対応していないなら、次の更新の前に、商談オブジェクトの構造で Rework と Salesforce を比較してみる価値があるかもしれません。ただし、ツールの進化は、ほとんどのチームの実際のプロセスより先を行っています。機能があることと、チームがそれを使いこなしていることは別です。

実際のマルチスレッディングとは、次のようなものです。案件が最初の2回の打ち合わせを超えて進む前に、推進者の協力を得て、上記の重要な象限のそれぞれで少なくとも1人を特定しておくことです。案件開始から30日たっても接点が推進者だけなら、その案件は停滞する可能性が高いといえます。

10分間のディスカバリー演習

最初の2回のディスカバリーコールで委員会構造を明らかにするための、再現性のある方法を紹介します。

課題と現状を把握したら、推進者に尋ねてみましょう。この流れは、運営の行き届いたセールスチームが初期の打ち合わせで購買委員会の構造を探るために使うクオリフィケーションのフレームワークと直結しています。

1. 「御社でこのような決定を下すとき、ほかに意見を出すのは通常どなたですか？」（プレッシャーを与えずに、委員会全体の話を切り出せます。）
2. 「IT やセキュリティの方で、早めに状況を共有しておきたい方はいらっしゃいますか？」（5週目に現れる前に、隠れた拒否権の保持者を浮かび上がらせます。）
3. 「予算を握っているのはどなたで、私が答えられるよう準備しておくべき直接の質問はありますか？」（Economic Buyer と、財務側の初期の懸念を特定できます。）
4. 「私が知っておくべき既存のベンダーとの関係はありますか？」（競合や関係性の力学が見えてきます。）
5. 「プロジェクトだけでなく、あなた個人にとっての成功とはどのようなものですか？」（推進者の組織としての動機と、個人的な利害を切り分けられます。）

これらの質問に特別なテクニックは要りません。必要なのは、デモのサイクルに深く入り込む前に尋ねる規律です。多くのベンダーは動き出すのが遅すぎます。隠れた拒否権の保持者が現れる頃には、セールスエンジニアはすでにカスタムのデモ環境を作り終えており、方向転換には費用がかかります。

買い手側が押さえておくべきこと

買い手側の立場であれば、上記の委員会構造はベンダーだけの問題ではありません。自社のガバナンスの問題です。案件が失敗するのは、必ずしもベンダーが間違っていたからではありません。評価プロセスに適切な人を十分早く巻き込まなかったために、ブロック力を持つ誰かが、本来は1週目に解決できたはずの懸念を8週目に持ち出すからです。

最も効率のよい買い手は、委員会のマッピング、意見の収集、推奨案の取りまとめを担う評価オーナーを1人指名します。その人は必ずしも推進者ではありません。公平な社内プロセスを運営できるだけの組織内の信頼を持つ人です。

新しいプラットフォームを評価するなら、最初のベンダーデモの前に、上記のステークホルダー影響マップの自社版を作ることから始めてください。誰が象限2の人たちなのかを把握し、たとえ非公式でも早めに巻き込みましょう。2週目に CISO と行う30分のプレビューコールのコストは、7週目のセキュリティに関する質問が引き起こす6週間の遅延よりはるかに小さくて済みます。

今後の方向性

購買委員会は縮小せず、拡大し続けるでしょう。B2B の意思決定に関する McKinsey の調査は、パンデミック後でも、買い手の選好がデジタルで自主的な評価へと恒久的にシフトしていることを示しています。これは皮肉にも、ベンダーが会議室に入る前に、より多くの社内調整を必要とします。多くの企業では、AI ガバナンス要件が新たなステークホルダーの区分を加えつつあります。職場の AI が生むガバナンスギャップは、ソフトウェア調達プロセスに直接入り込んでいます。データプライバシー規制により、これまで不要だったソフトウェア評価にも DPO が正式に関与するようになっています。さらに、既存のベンダーとの関係が膨大になったことで、企業が SaaS ツールを5つしか使っていなかった頃にはなかった厳しさで、ベンダーポートフォリオを管理する IT チームが増えています。いまや130のツールを抱える会社も珍しくありません。

現代の購買委員会の構造を理解することは、セールスの戦術ではありません。テーブルのどちら側にいても、効率的な評価を進めるための前提条件です。これにうまく対応できる企業は、案件の停滞に費やす時間が減り、より良いソフトウェアの意思決定ができます。そうでない企業は、口頭で合意したはずの案件がなぜ成約しないのかと首をかしげ続けることになります。

関連記事

• 成功を予測する POC と、全員の時間を無駄にする POC：誰が会議室にいるのかがわかったら、全員が信頼できる評価の進め方を確認しましょう
• ミッドマーケット企業におけるソフトウェアスプロールの本当のコスト：委員会が長年にわたって承認するツールが増えすぎると何が起きるのか