ミッドマーケット企業におけるソフトウェアスプロールの本当のコスト

著者: Victor Hoang · 更新日: 2026年1月30日

平均的なミッドマーケット企業は、130以上の SaaS アプリケーションを運用しています。IT 部門が把握しているのは、そのうち60程度でしょう。財務部門は、そのすべてに支払っています。Productiv の SaaS Intelligence レポートによると、大企業は全社で平均300以上のアプリを抱えており、その支出の3分の1は、利用率の低さから事実上無駄になっています。

目に見えるコストは簡単に見つかります。法人クレジットカードの明細を開いて、足し上げていけばよいのです。しかし、スプロールをライセンス統合の作業として捉える CFO は、的外れな問題を解いています。ライセンス費用は、多くの場合、全体のごく一部にすぎません。本当のコストは、その130のツールが、組織の注意力、セキュリティ態勢、業務効率に何をもたらしているかです。こうした数字は、予算の項目には現れません。

ほとんどのスプロール分析が見落とす3つのコスト

標準的なソフトウェア監査は、ライセンス料、利用率、重複を調べます。それらは重要です。しかし、ほぼ必ず帳簿から漏れてしまうコストが3つあります。

連携の保守コスト。 別のツールに接続するツールは、すべて、保守される連携を必要とします。API は変わり、認証は壊れ、データ形式はずれていきます。130のアプリケーションを運用する企業では、ツール同士の接続の仕方にもよりますが、稼働中の連携は40〜80にのぼることが多くあります。こうした連携の1つ1つに保守の負担があります。誰かが監視し、壊れたら誰かが直し、30日前の通知で API が変わるときには、誰かがベンダーとの関係を調整しなければなりません。

Rework によるミッドマーケットの IT チームの分析では、ツールスタックを積極的に管理してこなかった企業では、連携の保守が IT の対応能力の20〜30%を消費していることがうかがえます。これは明細の項目ではありません。プロダクトのインフラ、セキュリティの改善、あるいは事業を前に進めるほかのことに使われていない、失われた能力です。統合を検討するチームは、手持ちの対象範囲を把握するために、移行前のデータ準備から始めることがよくあります。

重複するデータ入力と突き合わせ。 CRM、請求、プロジェクト管理、カスタマーサクセスで別々のツールを使い、きれいな連携がないと、誰か（たいていは複数人）が、システム間で手作業でデータを移しています。CRM で案件が成約します。誰かが手作業で、プロジェクト管理ツールにプロジェクトを作成します。誰かが手作業で、請求システムに請求書を作成します。誰かが手作業で、カスタマーサクセスのプラットフォームを更新します。

ここでの人件費は現実のものです。従業員500人の会社で、50人が手作業のデータ突き合わせに週平均2時間を費やしていれば、年間で5,200労働時間になります。ミッドマーケットのナレッジワーカーの、フルロード（諸経費込み）の平均コストを時給75ドルとすると、手作業の突き合わせ労働として年間39万ドルです。このコストは各チームに目に見えない形で分散しているため、ほとんどの企業はその存在に気づいていません。

ツール切り替えによる集中力のコスト。 認知的な切り替えは高くつきます。従業員がツールからツールへ移るたび（Slack でメッセージを確認し、Asana でタスクを更新し、Salesforce で通話を記録し、Notion でタイムラインを更新する）、コンテキストスイッチのペナルティが生じます。米国心理学会（APA）の認知科学の研究は、複雑なナレッジワークにおいて、切り替えのたびに必要となる回復時間を含め、無視できないコストが生じると推定しています。従業員が1回の午前中に6〜8つのアプリケーションをまたいで作業するのが日常の企業では、生産性の損失の合計は大きく、しかも測定されていません。

これは、すべてを1つのツールで運用すべきだという主張ではありません。従業員に吸収させるコンテキストスイッチの数について、意図的であるべきだという主張です。スタックに加えるツールにはすべて、それを使う全員が毎日支払う認知的な税金がついてまわります。

スプロールはどう加速するか

スプロールのコストを理解するには、それを生み出す仕組みを理解する必要があります。ソフトウェアスプロールは、IT がガバナンスをやめたから起こるのではありません。組織の購買行動が構造的に分散していて、個別に見れば合理的な購入判断が、全体で見ると不合理になるから起こるのです。

典型的なパターンはこうです。営業チームがより良いプロスペクティングツールを必要とします。営業リーダーは年間3,000ドルのツールを見つけ、5,000ドルまでの権限を持つ上司の承認を得ます。ツールは導入されます。1年後、カスタマーサクセスチームがヘルススコアリングのツールを必要とします。同じプロセスで、年間4,000ドル、マネージャーレベルで承認されます。マーケティングが新しい SEO ツールを必要とします。承認されます。RevOps がエンリッチメントツールを必要とします。承認されます。

こうした決定は、どれも単独では間違っていません。しかし、全体を見渡せる意思決定者は誰もいません。CFO は予算を承認しました。各チームはその予算の範囲内で支出しています。スタック全体を完全に把握している人はおらず、経営層が後押しするイニシアチブなしに、チームの垣根を越えて統合する権限を持つ人もいません。

IT はこのパターンを止められません。購入は IT の目に触れる前に、多くの場合は事業部門のクレジットカードで行われるからです。財務部門も、はっきりとは把握できません。コストが数十のコストセンターに分散しているからです。その結果、四半期ごとに積み上がっていく、自然発生的なスプロールが生まれます。

シャドーIT の力学

シャドーIT、つまり従業員が IT に知らせずに購入するツールは、このパターンを加速させます。ただし、シャドーIT への典型的な対応は、問題を見誤っています。

従業員が IT を迂回してツールを購入するとき、そこには通常、満たされていないニーズが表れています。デザインチームが、IT の知らない有料の Figma プラグインを使っているのは、承認されたデザインツールが、必要なワークフローに対応していないからです。営業チームが個人契約の AI ライティングツールを使っているのは、承認された営業スタックにその機能がないからです。シャドーIT は、勝手な振る舞いではありません。サインなのです。

正しい対応は、無許可の購入を取り締まることではありません。シャドーIT を監査して、承認済みスタックの不足を示すパターンを探すことです。15人が個別に同じカテゴリーのツールにお金を払っているなら、それは、正式なスタックが満たしていない正当なニーズです。

シャドーIT には、実験という重要な役割もあります。全社展開の前に小さなチームが新しいツールを試すのは、健全なことです。問題は、そうした実験が整理されないまま放置されるときです。正式な評価、ガバナンス、連携の計画がないまま実験が恒久化すれば、短期的な柔軟性と引き換えに、長期的な技術的負債を抱え込むことになります。これは、のちに CRM プラットフォームを乗り換えることが、本来より高くつく原因と同じ失敗パターンです。ガバナンスされていない実験が積み重ねた技術的負債です。

ソフトウェアスプロール監査マトリクス

どのツールを残し、統合し、廃止するかを優先順位づけするには、各アプリケーションを4つの観点で評価します。

利用の深さ： このツールは日常のワークフローにどれだけ深く組み込まれているか。ユーザーの80%が毎日開くツールは、20%が月に一度開くツールとは違います。アクティブユーザー数、頻度、そしてそのツールがなくなるとワークフローが止まるかどうかに基づいて、1〜5でスコアをつけます。

連携価値： このツールは、データフローにどれだけ貢献しているか。コアシステム（CRM、ERP、データウェアハウス）との間にきれいな双方向の連携を持つツールは、直接の機能を超えた構造的な価値を持っています。実質的に孤島となっているスタンドアロンのツールは、いずれ接続が必要になったときに、連携負債を増やします。連携の品質と重要度に基づいて、1〜5でスコアをつけます。

重複リスク： すでに保有している別のツールが、同じユースケースの80%以上をカバーしているか。そうなら、統合の候補です。スコアは反転させて1〜5をつけます。5は既存のツールとの重複が大きいこと、1は本当に固有の機能を果たしていることを意味します。

ベンダーの安定性： このベンダーは3年後も存在しているか。スタックの中のシードステージのスタートアップはリスクです。18か月で3回のレイオフを経験したツールもリスクです。資金調達の状況、売上規模、ベンダー自身のロードマップにおける戦略的な重要性に基づいて、1〜5でスコアをつけます。

出力は1つのグリッドになります。利用の深さと連携価値のスコアが低く、重複リスクが高いツールは、廃止の候補です。利用の深さのスコアが高いものの、重複リスクも高いツールは、統合の判断が必要です。誰かが気に入っているツールを使えなくなるため、そこで変更管理が重要になります。

反発を招かない統合

ソフトウェアの合理化の取り組みは、ほとんどの場合、監査の段階ではなく、展開の段階で失敗します。削減されるのは、人々が実際に使っているツールです。アクセスを失うチームは、統合のイニシアチブを推進した側ではないことがほとんどです。さらに、ミッドマーケット企業の内部の政治的な力学により、CFO の部門が削減を後押ししていても、機能部門のリーダーは、お気に入りのツールを守ることができる場合が少なくありません。CRM の展開と定着のガイドは、最も一般的な統合のカテゴリーである営業・売上関連ツールについて、同じステークホルダーの力学を扱っています。

繰り返し起こる統合の失敗には、パターンがあります。IT または財務が重複するツールを特定し、何が削減されるかのリストを提示して、チームに統合先への移行を求めます。チームは反発します。スケジュールは遅れます。3か月後、「廃止された」ツールの半分は、誰かのワークフローがそれに依存していて、移行が完全には終わらなかったために、まだ稼働しています。

代わりに機能するのは、次の方法です。

決定ではなく、データから始める。 どのツールも廃止対象として名指しする前に、監査マトリクスを実施します。提言の前に、分析を示します。基準を理解しているチームは、結果を恣意的なものと受け取る可能性が低くなります。

統合先にも競わせる。 4つのプロジェクト管理ツールを1つに統合するなら、置き換えられる各チームの実際のユーザーを交えて、30日間の評価を行います。現在のツールが対応していて、統合先が対応していないユースケースを提出してもらいます。統合先のベンダーに、回答する機会を与えます。これはセールスプロセスではありません。正当性を確保するためのプロセスです。評価に参加したチームは、決定を一方的に押し付けられたチームより、結果を受け入れやすくなります。

切るのではなく、移行する。 失敗のパターンは、新しいワークフローが安定する前に、古いツールを廃止してしまうことです。両方のツールを並行して運用する60日間の併用期間を設け、積極的な移行支援をつけます。そのうえで、利用データからチームが実際に移行したことが確認できたときにだけ、古いツールを切ります。

IT チケットだけでなく、移行オーナーを任命する。 移行は、IT のプロジェクトとして扱われると失敗します。影響を受ける各チームの事業部門側のオーナーが、自分のチームの移行完了に責任を負うときに成功します。その人は、IT チケットにはできない形で、同僚を変化の中で導くだけの組織内の信頼を持っています。

30日間のスプロール監査

COO や IT リーダーが、外部のコンサルタントなしで実行できる、実践的な出発点を紹介します。

第1週：ディスカバリー。 過去12か月分の、法人クレジットカードと経費精算からすべての SaaS の請求を抽出します。IT が把握している既存のアプリケーション一覧と照合します。この2つのリストの差が、シャドーIT のマップです。

第2週：分類。 各ツールを、4つのカテゴリーのいずれかに割り当てます。Core（日常業務に不可欠）、Departmental（1つのチームにとって重要で、部門横断ではない）、Experimental（トライアル中または限定的な利用）、Orphaned（誰も所有しておらず、積極的に使われていない）です。

第3週：マトリクスのスコアリング。 すべての Core と Departmental のツールに、ソフトウェアスプロール監査マトリクスを適用します。重複リスクの高いツールは、統合の検討対象としてフラグを立てます。Orphaned のツールは、すべて解約を予定します。

第4週：優先順位をつけた提言。 統合または廃止の上位10候補を、推定のコスト削減額、推定の移行の複雑さ、決定の推奨オーナーとともに、順位づけしたリストにまとめます。結論だけでなく、基準が見える形で、経営陣に提示します。

このプロセスでは、SaaS 支出の15〜25%が、重複または放置されたものとして一貫して特定されます。ソフトウェアに年間200万ドルを費やしている従業員500人のミッドマーケット企業なら、30万〜50万ドルの回収可能な支出です。Gartner のソフトウェア資産管理に関するガイダンスは、組織が事後対応のライセンスレビューではなく、構造化された監査を行った場合、エンタープライズの SaaS 最適化の機会は、現在の支出の平均20〜30%になるとしています。しかし、本当の価値は、解消された連携負債と、取り戻された IT の対応能力にあります。

正しく実行できたとき、何が変わるか

構造化されたスプロール監査を12〜18か月ごとに実施している企業は、ライセンスの節約を超えた、組織としての規律を身につけます。つながっていないツールが減れば、連携の継ぎ目も減るため、よりすっきりしたデータアーキテクチャを築けます。スタックの中のツールはすべて、攻撃対象になり得るため、セキュリティ上のリスクも減らせます。そして、分散したツール群が生む、組織の注意力という税金も減らせます。

調達モデルも成熟します。可視性のない部門単位の購入ではなく、CFO と CIO が、しきい値（通常は年間5,000〜1万ドル）を超える新規 SaaS について、共同の承認プロセスを整えます。このしきい値は、意味のある購入のほとんどを捉えられる低さでありながら、チームが小さな実験を行う柔軟性も残せます。CAC ペイバックと SaaS のユニットエコノミクスを理解することも、この成熟の一部です。調達の意思決定が、投資判断により近いものになっていくのです。

目標は、会社全体を5つのツールで運用することではありません。加えるツールのすべてについて意図的であること、スタック全体の総コストを理解すること、そして、その複雑さに見合う価値を生んでいないツールを退役させることです。

関連記事

• 新しい B2B 購買委員会：会議室に本当にいるのは誰か：購入の時点でスプロールを防ぐ、ガバナンスの構造
• シートベース価格は終わりつつある。その後継となるモデルとは：価格モデルの変化が、ソフトウェア統合に実際にかかるコストにどう影響するか