
便利なSaaSを増やしたのに、なぜ仕事は複雑になるのか|権力のアルゴリズム
本レポートで得られるSaaS市場の判断軸
① 各ツールの効率と、ツール間の画面切り替え・二重入力にかかる負担を分けて見る。
② 製品の機能だけでなく、顧客が日々の業務を始める画面を誰が持つかを見る。
③ 他社のハブに接続する製品は、APIやデータ持ち出しの条件変更で利用がどう変わるかを見る。
1. 導入:現場の違和感
分散最適化が招いた「新たなサイロ化」を通じた構造検証
企業の現場では、SaaS導入による効率化の期待とは逆の現象が進行している。しかし、この現象はSaaS市場だけに固有の問題ではない。情報の民主化が進み、機能そのものが差別化要因ではなくなった市場では、権力の源泉は顧客接点へ移動した。本稿では、SaaS市場をその典型例として、この構造変化を検証する。
部門ごとに最適なツールが導入された結果、業務プロセスにおいて複数アプリの画面切り替えや通知過多、データ入力の二度手間が常態化した。この「SaaS疲れ」と呼ばれる現象は、生産性を高めるはずのクラウドシフトが、かえって新たな業務負荷を生み出しているという明確な違和感である。
この事象に対する一般的な説明は、組織のITリテラシー不足や、現場主導の導入によるITガバナンスの欠如に求められてきた。全体アーキテクチャの設計を欠いた個別最適が原因であり、情報システム部門による利用権限の一元管理によって解決可能であると解釈されている。
しかし、この既存解釈には説明不能な矛盾が存在する。高度なリテラシーを持つIT先進企業においてすら複雑化は進行しており、各SaaSに分散・サイロ化したデータを全社統合するために、結局は巨大なデータ連携システムを独自開発するという形で、多大な工数とコストが再生産されている事実がある。
ここで判断前提を反転させるのが、市場で観測された情報流通の変化である。従来のように情報そのものを独占する構造は崩れ、単一ツールの機能的優位性だけでは競争優位を維持できなくなった。この構造転換が、どのような要因によって生じたのかは、第4章で検証する。
これらの事実から導かれるのは、権力の源泉が「クローズドな情報を独占する構造」から、顧客の業務プロセスを束ねて滞在時間を支配する「顧客接点構造」へ移行したという仮説である。機能ではなく接点を握る者が資源と意思決定を独占するこの構造変化に直面する中、かつて市場を支配していた旧勝者は、どのような力学によって権力を維持していたのだろうか。
2. 旧重力:旧勝者アルゴリズム
「情報の非対称性」と「初期投資」によるロックイン構造の因果関係分析
かつてのソフトウェア産業において、市場を支配していた評価基準は「システムの絶対的な安定稼働」と「顧客が提示する要件定義(RFP)に対する網羅的な機能提供」であった。オンプレミス環境を前提とする時代においては、自社の特異な業務プロセスにどれだけシステムを適合させられるかが至上命題として君臨していた。この基準を満たすためには数年単位の巨大な開発が不可避であり、機能の独自性がそのまま勝者の条件として機能していた。
この構造を成立させていた前提は、市場における希少資源が「情報」と「資本」に集中していたことである。ベンダーが独占するクローズドな仕様情報と、顧客企業が計上する莫大な資本的支出(Capex)は、市場参加者が容易に代替できない資源として機能していた。ソースコードは完全に隠蔽され、ハードウェア調達から構築まで数千万〜数億円規模の予算が動く環境下では、容易に切り替えが効かない巨大なサンクコストが形成されていた。
結果として、権力配分構造は情報システム部門を頂点とするトップダウン型の意思決定メカニズムへ極端に集中した。巨大な資本投下と全社アーキテクチャの統一が求められる以上、現場部門の個別要件は排除され、予算と権限は中央集権的な単一窓口へ収束する。ここでは人物ではなく、「巨額の一括投資と長期運用を前提とする仕組み」そのものが、権力を情報システム部門へ強制的に吸い寄せていた。
この強固なロックイン構造が成立していた理由は、三つの絶対的な制約が存在したためである。第一に、インフラ調達に数か月を要する「技術制約」である。第二に、長期の減価償却と一括請負を前提とする「制度制約」である。そして第三に、最も支配的だったのが、ベンダーと顧客間に横たわる決定的な「情報の非対称性」である。価格や機能は営業担当者を経由しなければ開示されず、顧客は代替手段を容易に比較検討できなかった。
巨大な初期投資や独自仕様によって顧客を囲い込む従来の構造は、クラウドやSaaSの普及によって変わり始めました。では、導入しやすい製品が増えた市場で、企業は何によって競争上の優位を維持するのでしょうか。
ここからは、顧客が日々の業務を始める画面、複数ツールを結ぶ接続点、APIやデータ利用の条件を検証します。製品の機能と、市場の意思決定を左右する力を分けて評価する判断軸を導きます。