既存プレイヤーは、なぜここで反撃してくるのでしょうか
企業が本気で変わろうとするとき、抵抗は社内だけから生まれるわけではありません。
むしろ、社外のプレイヤーの方が、変化の意味を早く嗅ぎ取ることがあります。
大手コンサル、SIer、SaaSベンダー。彼らは普段、「変革を支援する側」として登場します。実際、それは間違いではありません。これまで多くの企業変革は、彼らの知見や仕組みや製品に支えられてきました。
ですが、変革の質が変わる局面では、彼ら自身が変革の当事者にもなります。
なぜなら、顧客企業の変わり方によって、彼らの商売の前提そのものが揺らぐからです。
ここで起きていることを整理すると、既存プレイヤーはそれぞれ異なるものを売っています。
大手コンサルは、構想、プログラム、変革の大義、推進体制を売っています。
SIerは、個別開発、保守、複雑な接続、段階的改修を売っています。
SaaSベンダーは、ユーザーID、部門ごとの業務機能、追加オプションを売っています。
一見すると別々の商売に見えます。
ですが根っこでは、いずれも企業の中に存在する“断絶”や“手間”や“分業”を前提に成立しているという共通点があります。
たとえば大手コンサルは、会社の中に課題が多く、論点が広く、部門間調整が大きく、構想を束ねる役が必要なほど強くなります。
だからこそ彼らは、全社BPR、横断変革、全社PMO、チェンジマネジメントといった大きな言葉を使います。もちろん、それが必要な局面もあります。
ですが、危機のなかにある企業が短期で止血しながら構造を変えたいとき、その大きさはしばしば問題にもなります。
テーマが広がるほど、本当に触るべき痛点がぼやけます。
組織が巻き込まれるほど、会議が増えます。
構想が立派になるほど、現場は遠くなります。
つまり、大手コンサル型の変革は、企業の複雑さを束ねる力がある一方で、複雑さそのものが残っていることに価値を持ちやすいのです。
SIerも同じです。
多くのSIerは、企業ごとの個別要件、既存資産、例外運用、段階的な接続の上で商売しています。
これは現実的なようでいて、別の見方をすると、企業が複雑なままでいてくれるほど成立しやすいモデルでもあります。
部門ごとに違うマスタ。
システムごとに違うデータ定義。
例外だらけの業務。
それらが残れば残るほど、「安全に進めるための追加開発」「つなぎこみのための保守」「現場事情に合わせた個別対応」が増えます。
だから、企業がSaaS標準業務へ寄り、API連携で横断接続し、例外を切り、個別開発の余地を減らしていくと、SIerは困ります。
困るからこそ、彼らはたいてい「現場を壊さない」「既存資産を活かす」「段階的に進める」と言います。
それ自体は一理あります。
ですが、その一理が、しばしば複雑さの延命になっていないかは見なければいけません。
SaaSベンダーもまた、別の意味で同じ構造にいます。
SaaSは本来、業務を標準化し、スピードを高め、システム運用の負担を下げる力があります。多くの企業にとって、SaaSは現実的で強力な選択肢です。
ただし、SaaSベンダーの多くは、依然としてユーザー課金を成長の中心に置いています。
つまり、席数が増えるほど伸びる。
部門が増えるほど伸びる。
追加オプションが増えるほど伸びる。
この構造のままでは、企業の中に断絶が残り、人がその断絶を埋める限り、SaaSの席数は増えやすいです。
営業にも一席、経理にも一席、総務にも一席、管理にも一席。それぞれが自部門のSaaSを持ち、必要に応じてオプションも増やしていく。
ですが、企業が本気で標準化を進め、APIでつなぎ、生成AIで中間作業を減らし始めると、ここに変化が起きます。
必要なのは、単純な“席数”ではなくなります。
必要なのは、どれだけ少ない席数で、どれだけ広い流れを回せるかになります。
この瞬間、SaaSベンダーにとっては、成長の前提が変わります。
ここで重要なのは、既存プレイヤーが悪意だけで動いているわけではないことです。
彼らの提案が一見もっともらしく見えるのは、それぞれ本当に効く局面を知っているからです。
大手コンサルの全社構想が必要な局面はあります。
SIerの段階的移行が正しい局面もあります。
SaaSのスピード導入が有効な場合もあります。
だから彼らの提案は、完全な嘘には見えません。
むしろ一部は正しい。
そこが最も危険です。
部分的に正しい提案ほど、企業は自分に都合よく受け取りやすいからです。
たとえば、社内が割れている会社にとって「まずは大きな傘で包みましょう」という提案は魅力的です。
現場が疲れている会社にとって「いまの運用をあまり崩さずに改善しましょう」という提案も魅力的です。
早く成果を出したい会社にとって「まずは部門ごとにAIオプションを入れましょう」という提案も魅力的です。
どれも、いま困っている論点には触れています。
ですが、本当に問うべきは、その提案が会社の流れそのものを変えるのか、それとも今の流れの上に新しい課金を重ねるだけなのかです。
ここで、生成AIとAPI連携が持つ意味が見えてきます。
この二つが本格的に効き始めると、企業の中で長く前提だったものが崩れます。
部門の間を人がつなぐ。
システムの違いを人が吸収する。
資料作成と説明で意思決定を支える。
問い合わせの一次対応を人が担う。
データを集めて初めて状況が分かる。
こうした構造は、これまでホワイトカラーの仕事を支えてきました。
同時に、既存プレイヤーの商売も支えてきました。
だから、人がつなぎ役でなくなるとき、単に工数が減るだけではありません。
その工数の周辺で成立していた課金モデルもまた、揺らぎます。
ここでようやく、「SaaSの死」という言葉の輪郭が見え始めます。
死ぬのはSaaSそのものではありません。
死ぬのは、SaaSを部門ごとに増やし、人がそのあいだを埋め続けることで成立していた構造です。
死ぬのは、構想と会議の大きさで価値を作れたコンサルモデルです。
死ぬのは、例外を保存しながら個別開発で収益を上げられたSIerモデルです。
死ぬのは、ユーザー席数がそのまま成長の象徴だったSaaSモデルの一部です。
その代わりに生まれるのは、SaaSを部品化し、APIで流れをつなぎ、生成AIで横断処理し、ダッシュボードで全体を見えるようにする世界です。
そして、この構造変化は、企業側にも覚悟を求めます。
既存プレイヤーを批判するだけでは何も変わりません。
彼らの提案が魅力的に見えるのは、企業自身が「できるだけ今を壊さずに、でも変わったように見せたい」と思ってしまうからです。
だから囲い込みが起きたとき、本当に問われているのは外部プレイヤーの善悪ではありません。
問われているのは、企業がどこまで本気で現行を手放すつもりがあるかです。
次の章で描かれるのは、その問いに対する一つの答えです。
現行業務を精密に再現するのではなく、SaaS標準、API連携、生成AIを前提に新しい型を先に描く。
つまり、外部プレイヤーの提案の善し悪しを比較するのではなく、自分たちの会社の流れそのものを描き直す段階に入っていきます。
囲い込みが激しくなるのは、変革が間違っているからではありません。
むしろ逆です。
企業が本当に古い流れを手放そうとし始めたとき、そこで利益を得ていた側が、最も早くそれに気づくのです。
だから、既存プレイヤーの反撃は、変革が本物に近づいた兆候でもあります。