株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。
あなたの会社に、こんな状況はありませんか？
- コンサルから出てきた提案書を、中身を十分に精査できないまま稟議に回してしまった
- プラットフォーマーの営業に「フルパッケージ」を勧められ、高いとは思いつつもそのまま契約した
- SIer（System Integrator）の見積もりが膨らんだが、「現場が必要と言っています」と言われて突っぱねられなかった
- システム導入後に「こんなはずじゃなかった…」と感じたことがある
一つでも心当たりがあれば、今日の話はきっと刺さると思います。
「振り回されている」と感じている方もいれば、振り回されていること自体に気づいていない方もいるかもしれません。
実は、これは個人の能力不足の問題ではないんです。
ベンダーとお客様の間には、構造的な利益の相反がある。
この構造を知らないまま、どれだけ頑張っても、振り回される状態からは抜け出せません。
私自身、コンサル業界やSI業界に身を置いていた経験があります。 そして正直に言えば、事業会社側で責任者をしていた時にも、振り回された経験があります。
「この提案で本当に大丈夫なのか？」と思いながらも、稟議の期限に追われて通してしまったこと…ゼロではありません。
だからこそ、あの時の自分に伝えたいという気持ちで、今回はベンダーに振り回される「構造」と、そこから抜け出すための具体的な打ち手についてお話しします。
目次
- ベンダーには3つの顔がある ― コンサル・SIer・プラットフォーマーの利益構造
- なぜ見抜けないのか ― 情報の非対称性という壁
- カスタマービジットの裏側 ― 一次情報はこうやって取りに行く
- 振り回されないための3つの武器
- 知った上で判断する ― それでも「この案で行く」と言えるか
1. ベンダーには3つの顔がある ― コンサル・SIer・プラットフォーマーの利益構造
振り回されないためには、まず相手のビジネスモデルを知ることが出発点です。
業務改善や業務改革のITプロジェクトを立ち上げようとした時、関わるベンダーは大きく3種類に分かれます。
- コンサルティングファーム：構想策定や計画、ときには実行を担う
- SIer（システムインテグレーター）：システムの提案・設計・構築を担う
- プラットフォーマー：SaaSのライセンスを提供する
それぞれのビジネスモデルを理解することが、振り回されないための第一歩です。
コンサルティングファームの構造
コンサルは基本的に人月商売です。
提案の場には熟練のパートナーやディレクターが出てきます。説明がうまくて、ロジカルで、なるほどと思わせる力がある。
ところが、実際にプロジェクトが始まると、現場に送り込まれるのは20代〜30代のマネージャ/シニアコンサルタント/コンサルタント/ビジネスアナリストが中心です。
そして、あの提案の場で輝いていたパートナーやディレクターの関与度はどれくらいか。
よくて20%。下手すると5%です。
5%というのは、月に1日。 押し並べれば、30分〜1時間の社内レビューで終わりということもあります。パートナーやディレクターのKPIは実案件の稼働率が低く(10%～50％)程度。他は営業活動に充てられています。つまりは案件を獲得する人たちという位置づけ。コンサルティングの営業ですね。
なので実案件を獲得したら、手を動かさず、実務を担うメンバーが作った成果物を短時間でレビューしてお客様に出す。
正直、これはこの人にお願いしたい！と思っていたお客様からしてみると、期待していた内容なのでしょうか？また非効率ではないでしょうか？
なぜなら、そのパートナー自身も正解を持っているわけではないからです。
お客様の業務の実態に入り込んでいないのに、正しい判断ができるはずがない。
本来はお客様と一緒に汗をかいて、ああでもない、こうでもないと導き出していくべきものなんです。
さらに大手コンサルティングファーム、いわゆるBig4と呼ばれるような企業では、構想策定の段階からすでに出口戦略が描かれているということです。
具体的には…
- 業務提携により合弁子会社を設立し、運用・オペレーションから継続的に収益を得る
- コンサルティングフィーやシステム導入のPMやPMOを実施し、アンダーにシステム会社を入れることでマージンを稼ぐ
- 自社がシステムの代理店販売を実施しており、ライセンスマージンを取る
- 保守・運用フェーズでさらに継続的に収益を得る
- 運用のオペレーションを含めるとBPOを提案し、継続的に収益を得る
この5段階のパッケージが、社内にナレッジとして蓄積されている。(どこまで提案するかどうかは規模や内容による)
つまり、「御社のためです」と言いながら提案される内容は、すでにパッケージ化されたバリューセットであることが少なくないのです。
もちろん、善悪の話をしたいわけではありません。ビジネスとして当然の構造です。
ただ、この構造を知らないまま提案を受け入れるのは、目隠しをして総合格闘技のリングに上がるようなものです。 しかも相手は百戦錬磨の肉食型のファイターです。
SIerの構造
SIerも本質は同じく人月商売です。
大量に人を送り込むモデルである以上、複雑性を増すインセンティブが働きます。
なぜなら見積根拠として「この機能を作るためにこれだけの人数(工数)が必要です」と説明する必要があるからです。
お客様側からすれば、シンプルで明確な仕組みが理想のはず。 運用が回って、効果が出ればそれでいい。
最初から作り込むという選択肢は、本来は一番最後のはずなんです。
ところが「この機能は絶対必要です」と説明され、業務のオペレーションレベルまでは把握しきれていない担当者は「そうなのかな…」と受け入れてしまう。
そして見積もりはどんどん膨らんでいく。
「予算を超えました。でも現場が必須と言っています。どうしましょう？」
この問いに対して、「この機能はいらない」と突っぱねられる人がどれだけいるでしょうか。
経営陣も含めて、です。そういう場合「担当のXXさんは何と言っている？」と確認する組織が大半ではないでしょうか？担当からすると「あれば嬉しい」となります。そうすると回答としては「必要」となります。
それでもこの機能はいらない！と主張できる人はどのくらいいるでしょうか？
プラットフォーマーの構造
プラットフォーマーの営業担当者には、当然ながらインセンティブ（売上目標）があります。
毎月、あるいは四半期ごとの売上に近づけるために、提案はフルパッケージに寄りがちです。
例えばSalesforce/HubSpotのようなサービスでは、エディションやプランがマトリックス状に存在します。 スターター/スタンダード/エンタープライズ、SFA/Service/Marketing…
もし100人が使うシステムだとして、「20人はこのプラン、80人はこのプラン」と自分たちで分けられますか？
要件定義もまだやっていない段階で、それは極めて難しい。
だからプラットフォーマーはフルパッケージを提案してくる。
そして、お客様側は「高い」としか言えない。
「じゃあいくらなら適正ですか？」と聞かれても、適正感の尺度も、安くするための具体的な戦術も持っていない。
結果として、稟議の期限に追われ、「フルパッケージならとりあえず現場から文句は出ないだろう」と、そのまま通してしまう。
これが振り回される構造です。
忘れてはいけないのは、システムを導入すること自体は目的ではないということ。 使ってもらい、事業成長に寄与して初めて価値がある。
なのに、導入の時点でこれだけの力学が働いている。 ベンダーの構造を理解しないまま進めれば、振り回されるのは構造上の必然なんです。
経営者の方へ： コンサル・SIer・プラットフォーマーのビジネス構造と、自社のメリットが一致する領域は、実はベン図でいうと非常に狭い範囲です。この構造を自社の担当者が理解しているか、一度確認してみてください。担当者任せにしていると、気づかないうちにPL・BSが痛んでいきます。
2. なぜ見抜けないのか ― 情報の非対称性という壁
ロジックは合っている。資料も綺麗。でも、それが自社に合っているかは別の話です。
プロジェクトの最初、構想策定のフェーズを思い出してください。
経営陣から「コスト削減」「売上拡大」「業務改革」といったお題が降りてくる。 でも、具体的な実現像なんてほとんどの場合イメージできていません。
「コスト何%削減します」という数値目標は立てられても、そのために何をどう変えて、ビフォーアフターがどうなるのかは描けていないことがほとんどです。
だから、コンサルに頼む。
コンサルは他社事例を豊富に持っているから、それを当てはめて「御社にはこの方向性が最適です」と、綺麗なパワーポイントで見せてくれる。
ロジカルシンキングの基礎が叩き込まれた人たちが作る資料だから、ロジック的には合っているんです。
「なるほど、そうだよな」と納得してしまう材料になっている。
でも、ここで立ち止まって考えてほしいんです。
本当にそれ、自社に合っていますか？
あくまで他社事例の当てはめであり、コンサル会社もお客様の実務に入っているわけではない。 現場の本音も、業務の細かいオペレーションも知らないまま提案しているんです。
NOと言えない構造
さらに厄介なのが、構想策定が終わった後の力学です。
稟議のスケジュールは決まっている。 周りの部署は「何かやってくれるんだ」と期待している。 経営陣も構想策定のコストを出しているから「そろそろ結果が出るだろう」と思っている。
この力学の中で、「やっぱり無理でした。うちには合いません」と言えるかどうか。
相当な勇気が必要です。
だから9割以上は、ちょっとした不安を抱えながらも「まあいいか」と稟議書を書いてしまう。
しかも、その稟議書に書かれている金額はコンサルから出てきた金額です。 これが現実です。
もっと厄介なケース ― トップセリングで降りてくる
さらに厄介なのが、プラットフォーマーの営業がトップセリング（経営層への直接営業）を仕掛けるケースです。
社長が「いいね、やろう」と言ってしまい、その状態で現場に降りてくる。
部長は「社長がOKしたの？じゃあやるしかないか」となり、担当者Aさんに振られる。
Aさんは「え？入れるの？」という状態。
導入の背景も、目的も、何も説明されていない。
「どう嬉しくなるんでしょう？」と聞いても、「資料にはこう書いてあるけど、具体的にはわからない」としか返ってこない。
設計ができるはずがありません。
でも、プラットフォーマーの営業にとっては受注した時点でゴール達成です。 その後のことは、正直なところ、彼らの評価指標には入っていない。
こうした構造の中で、担当者が振り回されるのは、もはや避けようがない状況と言えます。
振り回される人と振り回されない人の違い
では、振り回される人と振り回されない人の差はどこにあるのか。
例えば、ベンダーとの打ち合わせの場面を想像してください。
＜共通の場面設定＞
ベンダーから提案資料が届き、定例ミーティングの場で内容を説明されます。 アジェンダはベンダー側が用意。提案内容、スケジュール、見積もりが並んでいます。
【パターンA：受け身の担当者】
ベンダー「今回の提案はこちらになります。まず構成としては…」 担当者「はい…なるほど…ふむふむ…」 ベンダー「こちらの機能も必須で、現場からもご要望がありましたので含めています。」 担当者「あ、はい。そうなんですね。ちなみにこの部分って、具体的にはどういう…？」 ベンダー「はい、こちらは他社でも多くの実績がありまして…」 担当者「なるほど…わかりました。一旦持ち帰って検討します。」
【パターンB：対案を持つ担当者】
担当者「今日のアジェンダはこちらで用意しました。まず提案内容の3点について確認させてください。」 ベンダー「あ、はい。承知しました。」 担当者「この機能ですが、うちの業務フローだとここまでの作り込みは不要だと考えています。この部分を外した場合の見積もりを出してもらえますか？」 ベンダー「ただ、他社事例では…」 担当者「他社事例は承知しています。ただ、うちのオペレーションレベルで考えると、ここは運用でカバーできる範囲です。加えて、ライセンスのプラン構成ですが、全員エンタープライズではなく、20名はスタンダードで十分だと判断しています。この構成での再見積もりをお願いします。」
違いは明確です。
自分の案を持っているかどうか。
来た提案をベースに「ちょっと修正してください」レベルだと、それは振り回されている延長線上にあります。
「六割は自分の案で、いろいろ言ってくれてありがとう、一部取り入れたけどこの案で行く」と言えるかどうか。
これが分水嶺です。
この姿勢によりコンサル/SIer及びライセンスのコストがグッと下がります。下手すると数千万、億という金額で変わってきます。
では自分の案を持つために何をしなければいけないのか？それは一次情報を自分の力で取りに行き、アイデアをもらい、自社に落とし込む(仮説を作る)ことを実施する必要があります。
そのためには他社と繋がる必要があるのですが、注意点があります。それはカスタマービジットです。
3. カスタマービジットの裏側 ― 一次情報はこうやって取りに行く
紹介された先で本音が聞けると思ったら、大間違いです。
プラットフォーマーやコンサルに「同業他社で使っているところを紹介してください」と相談すると、「ありますよ！引き合わせましょう」と快く応じてくれることがあります。
いわゆるカスタマービジットと呼ばれる仕組みです。
私も以前、これを利用したことがあります。
最初は「いい仕組みだな」と思いました。
でも、一回で見抜きました。
その場にはプラットフォーマーのAE(アカウントエグゼクティブ)やCS（カスタマーサクセス）担当者がニコニコしながら同席しているんです。
私のヒアリングシートには「一番このシステムでダメだったところを教えてください」という項目がありました。
でも、その人の前でそんなこと言えるわけがない。
「課題だと思います」くらいは言えても、「ここは本当にダメで使い物にならない」とは口が裂けても言えません。
人間ですから、悪く思われたくないのは当然です。
目的を切り替えた
だから私は、2回目以降のカスタマービジットでは目的を変えました。
目的は「情報を得ること」ではなく、「名刺を獲得すること」に切り替えたんです。
そして後日、直接連絡を取って、ベンダー抜きで話を聞く場を作る。
これを4〜5回繰り返しました。
もう出るわ出るわ、ですよ。
ベンダーが同席していた時には絶対に出てこなかった本音が、堰を切ったように出てくる。
「この機能、全然使えなくてね…」 「営業がいろんな部署に勝手に電話かけまくって大炎上した」 「やる前はそこまで必要だと思ってなかったけど、やってみたらそこが一番のヒットだった」
逆に、「ここが地雷でした」「事前にこういうことをやっておくべきでした」という、プロジェクトの成否を分ける一次情報が手に入る。
こうした具体的な話を聞くことで、「うちには合っている」「うちとは状況が違う」という判断ができるようになるんです。
情報はオープンにした方がオープンに返ってくるのが基本の方程式です。
でも、第三者の目が入っている構造では、この方程式は成り立たない。
だからこそ、一次情報を取りに行く「場の設計」が極めて重要なんです。
経営者の方へ： 自社の担当者が、ベンダー紹介の事例企業訪問だけで判断材料を集めていないか、確認してみてください。本音が聞ける場を自ら設計できる担当者かどうかは、プロジェクトの成否に直結します。
4. 振り回されないための3つの武器
対案を出せるかどうか。それが振り回されるか否かの分水嶺です。
では、具体的にどうすれば振り回されない側に回れるのか。
私が現場で見てきた経験から、3つの「武器」をお伝えします。
武器① 門番 ― 第三者チェックを置く
自社のメリットが100%の状態で相談できる相手を、一人でいいから確保してください。
なぜこれが必要か。
コンサルに相談すれば、コンサルのメリットに転換されます。 プラットフォーマーの営業に聞けば、自社製品を売る方向に誘導されます。
当然です。彼らにも予算目標があり、キャリアのインセンティブがある。
全員が自社にとって最適な提案を出してくるわけがないんです。
だから、出てきた提案内容が自社に合っているか、自分たちで見抜けないなら、見抜ける人を横に置く。
例えば、業界経験のあるアドバイザーに、その案件に限定して相談する。 その人が他のベンダーからお金をもらっていない状態であれば、嘘をつく理由がない。
経験者であればあるほど、その言葉の信頼性は高い。
「この提案書、フルパッケージになってますけど、こんなにいらないでしょう。」 「この構成だと運用フェーズで8割くらい無駄になりますよ。大丈夫ですか？」 「ライセンスの値引き、この範囲までなら相手の決裁で通せるはずです。もう少し交渉しましょう。」
こうしたアドバイスが一回の打ち合わせで得られるなら、その費用対効果は計り知れません。
仮にアドバイザリー費用で、数百万〜数千万円のコスト最適化ができるなら、それはやらない理由がないはずです。
ただし、注意点もあります。
アドバイザー自身の質の見極めは必要です。
肩書きだけで選ぶのではなく、実際にその領域で手を動かした経験があるか、顧客側の立場で仕事をした実績があるか。
ここを確認せずに「有名な人だから」で選ぶと、結局コンサルに頼むのと同じ構造に陥りかねません。
武器② 横連帯 ― 他社とのネットワークを持つ
BizOpsの業務内容は、実は企業間で大きな差がないのが実態です。
細かい部分は違いますが、業務のモデルや構造は似通っている。
つまり、BizOpsの領域は事業の差別化要因にはなりにくい。
だからこそ、他社と横で連帯を組んで情報交換することに大きな価値があります。
「うちにもこんな提案が来たんだけど、どう思う？」 「あ、うちにも同じ提案来たよ。」
こういうやり取りが非公式でもできる関係があれば、ベンダーの提案内容を客観視できるようになります。
「人脈がない」「そういう場がない」という方もいるかもしれません。
でも、BizOps協会のコミュニティのような場もありますし、自分から開拓しに行くことも可能です。
ここで大事なのは、「Giveの精神」です。
自分だけ情報をもらおうとしても、長続きしません。
「うちはこうやって失敗した」「この構成で進めたらこうなった」と、自分の経験を先に差し出す。
そうすると、相手も同じように返してくれる。
この循環が、メディアの二次情報とは比較にならない、生きた一次情報のネットワークを作ります。
自分の足で取りに行った情報こそが、本当の判断材料になるんです。
武器③ 対案力 ― 自分で対案を組み立てる
最終的には、自分自身で対案を組み立てられる力が最強の武器です。
とはいえ、業界にいたことがない人にとって、それは簡単ではないこともわかっています。
でも、今はAIという強力な味方がいます。
例えば、第三者から得た情報とコンサルの提案内容を両方AIに入力して、「この2つを融合させるとどういうストーリーになるか」と聞く。
それだけでも、かなり精度の高い対案のたたき台ができます。
大切なのは、「わからないことがわからない」状態を認識することです。
そこから、誰に何を聞いて、得た情報をどう使うかを設計していく。
この思考の習慣は、ITプロジェクトに限らず、あらゆる業務に応用が利きます。
打ち合わせでベンダーが用意したアジェンダに沿って「はい…なるほど…」と受け取り続ける限り、永遠に振り回されます。
自分からアジェンダを出す。質問をぶつける。指摘する。
この姿勢を持てるかどうかが、全てです。
5. 知った上で判断する ― それでも「この案で行く」と言えるか
全部を知った上での判断なら、それはもう振り回されていません。
ベンダーの構造を知ること。 情報の非対称性を認識すること。 一次情報を取りに行くこと。 対案を作ること。
ここまでやった上で「この提案で行く」と判断するなら、それは振り回されているのではなく、主体的な意思決定です。
問題は構想策定まで遡る
システム導入後に「こんなはずじゃなかった」となった時、原因を遡っていくと何が起きるか。
なぜテストで見つからなかった？ → なぜ製造（開発）段階で見つからなかった？ → なぜ設計でわからなかった？ → なぜ要件定義で見つけられなかった？ → なぜ構想策定の段階で気づけなかったのか？
工程を前に前に遡って問題を先に気づけることが大事なんです。
だからこそ、構想策定や計画を立てるタイミング、稟議書を書くタイミングで、知見を持った人間がそばにいるだけで結果は全く変わります。
「パフォーマンスでいい」なら、それもまた正解
一方で、正直に申し上げると、すべてのプロジェクトが全力で取り組むべきものとも限りません。
経営陣から「業務改革してくれ」というオーダーが降りてきても、現実的にはリソースの制約がある。
「今回はパフォーマンスでいい」と割り切れるなら、最小限のプロジェクトにすればいい。
それは決してネガティブな判断ではありません。
「知った上でやっている」のと「知らずに振り回されている」のでは、天と地の差があるからです。
大事なのは、本音を話せるパートナーがいるかどうか。
「今回はパフォーマンスでいいんだ」と言った時に、「じゃあ軽くいきましょう。こっちの方法で、やったことにしましょう」と柔軟に対応してくれる。
そういうパートナーの存在が、どれだけ心強いか。
私自身も責任者をしていた時に、そういう人が横にいてほしかった、と心から思います。
おわりに
今回は、ベンダーに振り回される構造とその抜け出し方についてお話ししました。
改めて整理すると…
- コンサル・SIer・プラットフォーマーには、それぞれのビジネスモデルに基づいた利益構造がある
- お客様側は情報の非対称性により、提案が自社に合っているか見抜くのが極めて難しい
- 一次情報を取りに行く「場の設計」が、正しい判断の土台になる
- 門番（第三者チェック）・横連帯（他社ネットワーク）・対案力、この3つの武器を持つ
- 全てを知った上での判断なら、それは「振り回されている」のではなく**「主体的な意思決定」**
そして、この「ベンダー構造を見抜き、対案を出せる力」こそ、BizOps担当者の中核スキルの一つです。経営と現場をつなぎ、事業成長を仕組みで支えるBizOpsにとって、ベンダーとの対峙は避けて通れない場面。ここで振り回されるか、主導権を握れるかで、事業に対する貢献度は大きく変わります。
ベンダーの構造を知ることは、相手を敵に回すことではありません。
対等なパートナーシップを築くための、最低限の前提条件です。
今はどちらかというと、ベンダーやコンサル側にメリットが偏りすぎているように見えます。 それをお互い半々くらいの、本当の意味でのWin-Winに持っていきたい。
そのためには、お客様側が知識を持ち、戦える武器を備えることが必要不可欠です。
受け身のままでは、刺される一方です。 しかも、刺されているのは自分ではなく、経営陣の懐 ― PLとBSという名の財布です。
少しでも「違和感がある」「振り回されているかもしれない」と感じたなら、それは変化の第一歩です。
事件は会議室で起きてるんじゃない。現場で起きてるんです。
提案書の中にある綺麗なロジックではなく、現場の本音と構造の理解から、本当のプロジェクトは始まります。
お問い合わせ
ベンダーとの関係性やプロジェクトの進め方について、壁打ち相手が欲しい方、提案内容のセカンドオピニオンが欲しい方は、お気軽にご相談ください。