「IT部門がOKを出した」では足りない──エンタープライズ商談を止める"見えないチーム"の正体
「IT部門には話を通した。承認ももらった。なのに、なぜか商談が進まない」。こんな経験、一度や二度はあるのではないだろうか。その理由はほとんどの場合、「IT部門」という言葉が持つ"ひとくくり感"に引っ張られて、内部にある複数の機能・チームが視界に入っていないことにある。エンタープライズ営業で受注するためには、部署という単位ではなく、その部署の中にある機能・チームのレベルまで降りて初めて、有効な作戦が立てられる。この記事では、その構造と、具体的な把握の仕方を整理していく。
「IT部門に承認をもらった」——その認識は正しいか？
エンタープライズの商談は、複数のステークホルダーが絡み合う複雑なプロセスだ。それ自体は多くの営業パーソンが理解している。「部長クラスを動かさないといけない」「IT部門の確認が必要だ」といった意識は、ある程度の経験を積んだ人なら持っているだろう。
ところが、ここに一つの落とし穴がある。
「IT部門の承認を得た」という言葉を使う時、そこにはIT部門が単一の判断主体であるという前提が、無意識のうちに滑り込んでいる。現実はそうではない。IT部門という括りの中には、それぞれ異なる判断軸を持つ複数のチームや機能が存在する。そして、その各機能が独自の視点で案件を評価している。
「IT部門のAさんが前向きだった」という事実が、IT部門全体の合意を意味しない。それは、あくまでAさんが所属する機能のスタンスを示しているに過ぎない。この区別ができていないと、思わぬところで商談が止まる。
30年以上、外資系のIT企業でエンタープライズ商談を担当してきた経験からいうと、失注の原因を後からひもといていくと、「見えていなかったチーム」にぶつかることが少なくない。商談が突然止まる時、その手前には必ずと言っていいほど、誰も話を通していなかった機能が存在する。
IT部門の中にある複数の機能と、それぞれの関心ごと
では、IT部門の中には具体的にどんな機能が存在するのか。業種・企業規模によって名称や分け方は異なるが、大企業のITに関わる投資の場合、おおむね以下のような機能が関与してくることが多い。
IT企画 全社のIT戦略や投資計画を管理する機能。「このシステムが全社の方向性に合っているか」「ロードマップに沿っているか」という視点で案件を見る。
インフラ担当 サーバー・ネットワーク・クラウド環境などを管理する機能。「自社の環境と技術的に統合できるか」「運用負荷はどうか」という観点が主な関心事になる。
ガバナンス IT投資の承認プロセス・コンプライアンス・内部統制を担当する機能。「正規の意思決定プロセスを経ているか」「稟議の要件を満たしているか」を確認する立場だ。
セキュリティ 情報セキュリティポリシーへの適合を審査する機能。近年、この審査が長期化・厳格化している企業は増えており、「セキュリティがOKを出さない」という理由で案件が止まるケースは決して珍しくない。
IT購買 契約条件・調達プロセス・ベンダー評価を担う機能。技術的な検討とは別軸で動いており、「調達のプロセスに正しく乗っているか」「承認済みベンダーか」が関心の中心になる。
これらはすべて「IT部門」という括りの中にある。しかし、それぞれが気にしていることはまったく異なる。IT企画の担当者が「戦略的に面白い」と評価していても、セキュリティが「ポリシーに合わない」と判断すれば止まる。インフラが「技術的に問題ない」と言っていても、購買が「調達フローに乗っていない」と言えば止まる。
「IT部門のOK」とは、正確には「IT部門内の各機能がすべてOKを出した状態」を指す。この認識の違いが、商談の終盤で大きな差を生む。
IT以外の部署でも同じ構造が存在する
ここまでITを例に取って説明してきたが、この構造はIT部門に限った話ではない。どの部署にも、内部に複数の機能・チームが存在する。
たとえば、人事系のソリューションを扱う場合。「人事部門の担当者と話をした」では足りない。人事部門の中には、人事企画・労務・採用・研修・人事システムなど、それぞれ異なる機能がある。
採用支援のサービスなら採用チームが主な関係者になるかもしれないが、システム化が絡む話になれば人事システム担当やIT部門が関与してくる。給与や勤怠に影響するなら労務が動く。会社全体の人事施策として位置づけるなら人事企画の関与が必要になる。
財務・経理に関わるソリューションであれば、経理・財務・内部監査・コーポレートファイナンスと、それぞれ別の機能が関与してくる。
つまり、「担当部署を特定した」の次のステップは、「その部署の中にどんな機能・チームがあるか」を把握することだ。扱うソリューションの性質によって、どの機能が関与するかは変わってくる。そこを踏まえた上でなければ、関係者マップは半分しか描けていない。
この「部署の内部構造を理解した上で仮説を立てる」という視点は、BECQAフレームワークでいうB（Business）の考え方に当たる。顧客組織の構造を事前に仮説として描いておくことで、商談の"穴"が見える。逆に言えば、この仮説がなければ、後工程でブロックされるまでその穴に気づけない。BECQAフレームワークの詳細はこちら
機能・チーム単位のステークホルダーマップの作り方
では、部署の内部構造をどうやって把握するか。大きく二つのアプローチがある。
① 商談前に仮説として描く
顧客と会う前に、自分で「このソリューションが関係しそうな機能」を書き出してみる習慣を持つことが出発点になる。完璧な情報は最初からない。だからこそ「仮説として描く」という姿勢が重要だ。
やり方はシンプルだ。白紙に部署名を書き、その下にその部署の中で想定される機能・チームを列挙する。次に、自社のソリューションが各機能の仕事にどう影響するかを考える。「このシステムを入れたら、セキュリティ担当は何を気にするか」「購買はどんなプロセスを踏むか」——そこまで想像できれば、商談の準備の質は変わる。
業界経験を積むほど、この仮説の精度は上がっていく。ただし、同じ業種でも企業によって組織構造は異なる。あくまで「仮説」として描き、顧客との会話で検証していくというサイクルを回すことが大切だ。
② 顧客の担当者との会話の中で確認する
実際に顧客と話せる機会が生まれたら、「社内ではどんなチームが関わりそうですか？」という問いかけを自然に入れてみてほしい。
ポイントは、この問いを「関係者を洗い出すための審問」ではなく、「一緒に作戦を立てるための対話」として位置づけることだ。「この案件をうまく進めるために、どんな方々と話しておく必要がありますか？」という言い方でも良い。
顧客の担当者自身も、社内で誰を巻き込む必要があるか、常に明確に把握しているわけではない。むしろ、この問いかけを通じて一緒に整理していくプロセス自体が、関係構築につながる。「社内の調整を一緒に考えてくれる営業」という印象を与えることは、エンタープライズ商談においてプラスに働く。
また、「現在のIT環境では、こういったシステムを入れる場合、セキュリティ審査のプロセスはどのように進むことが多いですか？」のように、機能名を出して具体的に聞くと、顧客側の担当者が「そうか、セキュリティにも確認が必要だったな」と気づくきっかけになることもある。顧客の社内整理を助けることが、結果として商談をスムーズに前進させる。
明日から実践できるアクション
ここまで話してきたことを、次の商談で試せる形に落とし込むと、以下の三つになる。
アクション1：担当部署の「内部機能リスト」を仮説で作る 次の商談の準備として、顧客の担当部署の中にどんな機能・チームがあるかを書き出してみる。完璧でなくていい。「こんなチームがあるかもしれない」という仮説を持った上で商談に臨むだけで、気づく情報の量が変わる。
アクション2：「グリーンフラグが必要な機能」を確認する問いを入れる
商談の中で、「この案件を社内で進めるにあたって、どんなチームや機能の確認が必要になりますか？」という問いかけを一つ入れてみる。顧客の担当者にとっても、社内整理のきっかけになる問いだ。
アクション3：関係者マップを「部署名」ではなく「機能名」で描き直す 既存の商談案件を一度見直してみてほしい。「IT部門」「人事部門」という部署名ではなく、「IT企画」「セキュリティ」「IT購買」のように機能名まで落とし込んで関係者マップを描いてみる。そこで空欄になっている機能が、リスクの所在を示している。
関連記事
部署の名前だけ見ていると、地図の半分しか見えていない
「IT部門がOKを出した」は、出発点に過ぎない。IT企画・インフラ・ガバナンス・セキュリティ・IT購買——それぞれが異なる判断軸を持って動いており、その全員の合意が揃って初めて「IT部門のOK」が成立する。
この構造はIT部門に限らない。扱うソリューションが影響する部署には必ず内部構造があり、機能・チーム単位で関係者を把握してこそ、有効な作戦が立てられる。
部署の中まで降りて初めて、商談の"穴"が見える。次の商談で、担当部署の内部に目を向けてみてほしい。それだけで見える景色は変わる。
著者紹介
酒井秀樹｜Sales Trek株式会社 代表取締役。SAP、Adobe、QlikTech、Sitecore、Tealiumなど、30年以上にわたる外資系B2B営業の経験を持つ。アカウントエグゼクティブ、セールスディレクター、カントリーマネージャーなど様々なロールを歴任。現在は独自フレームワーク「BECQA」（ベクア）をベースにしたトレーニングビジネスを展開している。
