エンタープライズ営業のチャンピオン論を合意形成の構造から再整理。推進者・運用当事者・情シスの3者で案件停滞を読み解き、RFIからRFPへ進める実務視点を人事管理システムの具体例とともに解説します。

結論:エンタープライズ営業で案件が止まる理由は、強いチャンピオンが不在だからではありません。止まるのは、顧客社内で推進者・運用当事者・情シスの役割分担が噛み合わず、論点共有・必要材料・次アクションが回っていないからです。チャンピオンを"1人の味方探し"として捉えるのではなく、合意形成を支える役割構造として見直すことが、RFIからRFPへ進める実務的な近道です。
エンタープライズ営業の現場では、案件が止まるたびに「チャンピオンが弱い」という言葉が出ます。たしかに、それが一因の案件はあります。ただ、それだけでは思考停止になります。なぜなら、エンタープライズ営業は"1人の強い味方"で押し切るゲームではなく、顧客社内の合意形成が回り始めたときにだけ前へ進むゲームだからです。特に、RFIからRFPへ寄っていく手前のフェーズでは、この構造がよりはっきり出ます。営業が見るべきなのは「誰がチャンピオンか」というラベルではありません。見るべきなのは、誰がどの領域の検討を回し、誰がどの領域の運用の現実を握り、誰がどの領域の通過条件を決めているかです。この記事では、エンタープライズ営業のチャンピオン論を整理し直し、案件停滞をほどく実務の視点まで落としていきます。
営業フレームワークでは、チャンピオンは「顧客社内で影響力と信頼を持ち、案件を前に進めてくれる存在」として語られます。MEDDICCでも、チャンピオンは社内で力と影響力を持ち、案件進行を助ける意思と能力がある人物として整理されています。この定義自体は、いまでも有効です。営業が不在の場所で自社案を前に進めてくれる人がいるかは、案件の質を見るうえで重要な論点だからです。[出典:MEDDICCのChampion定義]
問題はここからです。多くの営業論では、チャンピオンは1人の重要人物として語られます。ただ、エンタープライズ営業(エンタープライズセールス)の現場に出ると、実際には1人に収まらないことにすぐ気づきます。
たとえば、従業員数5,000名規模の企業に人事管理システムを提案する場面を考えてみてください。検討会議を立ち上げたのは人事企画の課長。ただし、実際の人事データを日々扱い、入退社処理や異動対応を回しているのは人事オペレーション部門の担当者。さらに、既存の基幹システムとの連携やシングルサインオンの条件を握っているのは情報システム部です。
この3者は、全員が別の角度から案件に大きな影響を持っています。すると営業の頭の中で、こうした混乱が起きます。
「検討を仕切っている人事企画の課長がチャンピオンだろう」「いや、現場オペレーションの人たちが"使えない"と言ったら通らない」「でも最終的に止めるのは情シスではないか」
ここで起きているのは、人物理解の失敗ではありません。重要人物が複数いる世界を、単数のラベルで説明しようとしていること自体に無理があるのです。
複雑なB2B購買では、複数部門の関係者が意思決定に関わるのが一般的です。調査系のレポートでも、複雑な購買では6〜10人以上が関与し、部門横断で検討が進むとされています [出典:Buying Committeeに関する調査整理] つまり、案件停滞を「チャンピオンが弱い」で片づけるのは、構造を単純化しすぎなのです。
先ほどの人事管理システムの例に戻ると、こういうことが起きます。人事企画の課長は「タレントマネジメントまで見据えて入れ替えたい」と前のめりです。ところが、人事オペレーションの現場は「今の給与計算フローが崩れたら月次処理が回らない」と考えている。情シスは「既存のERPとのデータ連携が仕様として担保されない限り、検討テーブルに載せられない」と見ている。推進者は前向き。でも、運用担当と情シスの論点が未解決のまま放置されている。この状態で「チャンピオンをグリップできている」と報告しても、案件は動きません。各人が違う観点で"賛成"と"反対"を持っていて、そのズレが埋まっていないからです。考えてみれば当たり前ですがチャンピオンという言葉に踊らされるとこの当たり前を見落としがちです。
エンプラ案件で本当に強いのは、営業が同席していない場でも、営業が提示したレールにある程度沿いながら、顧客内で論点共有と次アクションが進む案件です。逆に、毎回営業が入らないと会議が閉じない案件は危うい。会議体が自走していないからです。
ここで見るべきは、会議の回数ではありません。
この3つが回ると、案件はRFIの情報収集段階から、RFPに近い比較評価段階へ寄っていきます。RFIとRFPは本来、情報収集と提案依頼で役割が異なります。だからこそ、顧客側で論点が定義されていない状態では、いくら提案しても前に進みにくいわけです。[出典:RFIとRFPの違いに関する解説]
人事管理システムの例で言えば、営業がいなくても人事企画の課長が「情シスから出た連携条件の一覧」を元に、運用担当と「移行期間中の並行運用をどうするか」を話し合えている状態。これが"回っている案件"です。逆に、営業が毎回呼ばれて「次は何をすればいいですか」と聞かれる案件は、顧客の中で検討の段取りが組まれていないことが多い。
推進者は、検討会議を立ち上げ、論点を集め、関係者を呼び、議論を前に進める人です。権限は中程度でも、行動量は高いことが多い。要件整理が崩れたとき、最も火をかぶりやすいのもこの人です。
人事管理システムの例で言えば、人事企画の課長がこの役割に当たります。経営層からの指示を受けて検討を立ち上げ、情シスや現場を巻き込みながら会議体を運営する。ただし、この人自身が予算決裁権を持っているとは限りません。
営業としては、この人に期待をかけすぎるとリスクがあります。推進者は前向きでも、現場運用と情シスの条件まで背負いきれないことがあるからです。推進者を"唯一のチャンピオン"扱いすると、案件の見立てが甘くなります。
運用当事者は、形式上の決裁権は弱くても、実態では非常に強い影響力を持ちます。理由は単純で、導入後の二重運用、問い合わせ、例外処理、現場教育の負荷を最もかぶるのが彼らだからです。
人事管理システムの場合、人事オペレーション部門の担当者がこれに当たります。月次の給与計算、入退社処理、異動に伴うデータ更新。これらを日々回している人たちです。仮にシステムが入れ替わった場合、移行期間中は新旧両方のシステムで処理を走らせることになるかもしれない。問い合わせの一次対応も増える。「慣れた業務フローが壊れるリスク」を最も強く感じるのは、この人たちです。
ここが大事なポイントで、運用当事者の反応は"性格"ではなく"リスク負担"で読むべきです。慎重に見えるのは、保守的だからではありません。失敗したときのコストを自分が払うと分かっているからです。この層を雑に扱うと、「表では反対しないが、実務の場で協力が得られない」という形で案件が止まります。会議では特に異論が出ないのに、なぜか要件定義が進まない。こういう案件は、運用当事者が実質的に"静かな拒否"をしている可能性があります。
情シスは、セキュリティ、連携、ID管理、運用保守の観点で通過条件を提示する立場です。自ら手を動かす量は限定的でも、「この条件を満たさない限り、検討に載せない」と言える力を持っています。推進者や運用当事者がどれだけ前向きでも、情シスが「No」と言えばそこで止まる。拒否権としては、3者の中で最も強力です。
人事管理システムの例なら、こうした場面がよくあります。
「既存のERPとリアルタイム連携できるのか」「SAML認証に対応しているか」「監査ログはどこまで取れるか」「障害時のデータ復旧手順は」
これらの条件は、営業が提案書で「対応可能です」と一行書いたくらいでは通りません。仕様書レベルの根拠が求められます。
よくある失敗が、情シスを後工程のレビュー担当だと思うことです。実際には、要件定義の前半から巻き込まないと、「その要件では通らない」が終盤で出ます。そうなると、推進者も運用当事者も一気に消耗します。情シスは"最後に確認する人"ではなく、"先に通過条件を聞く相手"として扱うべきです。
――――――――
【パワーチャート作成キット】
この記事で触れた「推進者は前向きなのに、運用当事者と情シスのところで止まる」という状態は、属人的に対処しても再現しません。役割マップの作り方、会議体で確認すべき論点、"静かな拒否"の見抜き方を、ホワイトペーパーに整理しています。案件レビューにそのまま使える形です。
――――――――
最初にやるべきは、人物名の整理ではありません。
推進者・運用当事者・情シスごとに、
権限・行動・リスク負担を書くことです。これだけで見える景色が変わります。
人事管理システムの例で言えば、こうなります。推進者(人事企画課長)は会議設定と論点整理を回している。運用当事者(人事オペレーション)は給与計算や入退社処理の移行リスクを気にしている。情シスはERPとのデータ連携とSAML認証の対応可否を気にしている。
この粒度で書き出せれば、案件が進まない理由を「推進者の熱量不足」ではなく「未解決の論点がどこに残っているか」として扱えます。
顧客内の会議が機能しているかは、次の3つで見ます。論点が共有されている、必要材料がそろっている、次アクションが決まっている。逆に言えば、会議後にこの3つが残らないなら、その会議は前進していません。
現場の営業担当が明日からできることはシンプルです。会議後のメールや議事メモで、「未解決論点」「追加資料」「次回までの担当と期限」を3列で返すこと。営業資料を増やすより、顧客内で転送しやすい形に整えるほうが効く場面は多いです。
たとえば、人事管理システムの検討会議のあとに、こういうメモを残す。「未解決:移行期間中の給与計算の並行運用フロー」「追加資料:ERP連携の仕様書(営業から◯日までに提出)」「次回:情シス含めた3者で連携要件の確認、◯月◯日」。こうした材料が顧客内で回ると、営業が次の会議に呼ばれなくても、検討は進みます。
運用当事者は、感情で説得する相手ではありません。見るべきは、「導入後に自分の負担がどう変わるか」です。ここが曖昧だと、前向きな返事はもらえても実務では進みません。有効なのは、以下のような質問です。
「現行運用で例外が出るのは、どの場面ですか」「導入後に二重運用が発生しそうなのは、どのタイミングですか」「問い合わせが増えるとしたら、最初の1カ月で何が起きそうですか」
人事管理システムの場合なら、「月末の給与計算の締め処理で、新旧システムの数字が合わなかったらどう突合するか」「4月の大量入社のタイミングで移行が重なるとどうなるか」。こうした問いを営業から先に出せると、運用当事者は「この人は現場の負担を分かっている」と感じます。逆に、こうした話をせず「便利になりますよ」で押すと、表面上は前向きでも実務で協力を得られなくなります。
情シス向けの説明でやりがちなのが、製品紹介の延長で話してしまうことです。でも、相手が欲しいのは魅力の説明ではありません。通す条件を満たすかどうかの判断材料です。
人事管理システムなら、求められるのはこうした情報です。認証方式(SAML対応の有無・実装パターン)、権限管理の粒度、監査ログの取得範囲、データ保管場所とバックアップ方針、既存ERPとの連携方式(API仕様・バッチ頻度)、障害時の切り戻し手順。ここを整理せず「必要になったら回答します」で済ませると、情シスは安全側に倒します。「情報が足りないものは、通せない」。それだけのことです。
「通す条件」を先に聞き、その条件に対して不足なく返す。これが一番速い進め方です。製品が良ければ通る、というのはベンダー側の思い込みです。評価可能な形で条件が整ってはじめて、検討テーブルに載るります。この順序を間違えると、どれだけ推進者が前向きでも、案件は情シスの手前で止まります。
チャンピオンは不要ではありません。むしろ重要です。ただし、チャンピオンを"1人の英雄"として扱うと、エンタープライズ営業の実態を見誤ります。
本当に見るべきは、顧客社内で役割分担が成立しているかです。推進者が検討を回し、運用当事者が現場運用の論点を出し、情シスが通過条件を明確にする。この3者の間で、論点と材料と次アクションが循環し始めたとき、案件は自然にRFIからRFPへ寄っていきます。
だから、案件が止まったときの問いも変わります。「チャンピオンは誰か」ではありません。「誰が何を背負っていて、どの論点が未解決で、顧客内の会議体は自走しているか」です。
人事管理システムの例で振り返ると、こうなります。人事企画の課長は会議を回せているか。人事オペレーションは移行リスクの論点を出せているか。情シスは連携条件を明示しているか。そして、この3者が営業抜きでも次のアクションを決められる状態になっているか。
この問いに切り替わると、営業の動きも変わります。推進者への依存ではなく、合意形成の支援に軸が移ります。それが、エンタープライズ営業で停滞案件を前へ動かす、最も再現性の高いやり方です。
出展リスト: