社内ITスリム化の本丸は業務アプリだ――3層構造の詰まりをEAはどう打破するか

システムを減らしたいなら、まず業務を減らせという現実

「システムを減らせ」と言われても、減らせるわけがない――現場でスリム化を推進しようとしたことがある人なら、この感覚はわかると思います。業務アプリケーションのスリム化、コスト削減、システム統廃合。どの会社でも経営課題として挙がりますが、いざ動こうとすると必ず同じ壁にぶつかります。「業務がある限り、システムは落とせない」という、至極まっとうな反論です。

EA（エンタープライズアーキテクチャ）の視点から言わせてもらえば、この問題の本質は技術的なものではありません。構造的・組織的な問題です。そしてその構造を可視化することこそが、EAの仕事だと思っています。

なぜ業務アプリが「本丸」なのか

スリム化を考えるとき、多くの人がまずインフラやミドルウェアに目を向けます。確かにコストインパクトが大きいのはそこです。データセンター、クラウド基盤、認証基盤、API連携基盤、データ連携基盤――こういった共通インフラ・共通アプリ基盤の維持費は馬鹿になりません。

しかし、ここに落とし穴があります。

インフラ・共通基盤は、その上に乗っている業務アプリがなくならない限り、落とせません。

人事システム、総務システム、経理・購買システム――これらの業務アプリが稼働している限り、それを支える基盤は延命し続けます。コストの塊に見えるインフラ層に手をつけたければ、その上の業務アプリ層を先に整理しなければならない。業務アプリを整理するには、業務部門が「この業務をやめる・変える」という判断をしなければならない。

この連鎖を整理すると、こうなります。

業務部門：業務をやめる・変える判断をする
業務アプリ層：業務部門の判断を受けてシステムを退役・統合する
インフラ・共通基盤層：業務アプリがなくなって初めて落とせる

この3層の連鎖が断ち切れないことが、スリム化が進まない最大の理由です。

業務部門が動かない理由は「悪意」ではない

業務部門はシステム統合に興味がありません。これは批判ではなく、構造上の話です。

業務部門にとっての最優先事項は「業務を回すこと」です。システムが変わることは業務が変わることを意味します。そのリスクを取るインセンティブが、業務部門側にはそもそもありません。「今のシステムで業務が回っているなら、それでいい」というのは至極合理的な判断です。

IT部門から「システムをまとめましょう」と言っても動かないのは当然です。相手にとってそれは自分ごとではないからです。IT部門側のアプローチや説明の仕方の問題ではなく、そもそも業務部門がシステム統合に動くインセンティブ設計になっていないという、構造上の設計問題です。

経営マターの大型プロジェクトが立ち上がれば話は別です。ERP一本化のような経営判断が下りれば、業務オーナーも巻き込まれる形で動き始めます。しかし、グローバルERPや標準SaaSに自社業務を合わせるかカスタマイズするかというFit&Gap議論で沼にはまる展開はよくある話で、結局またスリム化は進まない。

チキンレースを制するのは「廃止計画とITロードマップの整合性」だ

スリム化推進で必ず発生するのが、こんなやり取りです。

インフラ側：「このシステムが終わるまで基盤は延命できない」
業務側：「移行先が決まるまで退役時期は言えない」

完全なチキンレースです。誰も先に動きたくない。誰も期限を言いたくない。この状態を放置すると、何も変わらないまま時間だけが過ぎていきます。

ここでEAがやるべきことは、システム廃止計画とITロードマップの整合性を強制的に取る構造を作ることです。

このインフラはいつ終わるのか
その上に乗っている業務アプリはいつ移行するのか
移行先はいつ稼働するのか
システムが落ちたとき、依存関係の末端に残る「最終ランナー」は何か

最終ランナーとは、他のすべてのシステムが移行・廃止された後も、依存関係の末端に残り続けるシステムのことです。これが特定できていないとITロードマップ上の退役順序が設計できません。どのシステムを先に落とせばどのインフラが落とせるのか、その連鎖を把握することがシステム廃止計画の出発点になります。

なお、EAには退役期限を一方的に決める権限はありません。しかし、「期限が決まらないことのコスト」を可視化して経営に判断を求めることはできます。それがEAの役割です。

EAの打ち手：システム依存関係の可視化でデータが3層をつなぐ

では具体的に何をするのか。私の答えは「データで3層をつなげて見せる」です。

業務体系・業務アプリ・インフラ基盤の3層を、データとして一元管理し、システム依存関係を可視化する。

具体的には以下のことが見えるようにします。

どの業務にどのシステムが対応しているか（業務とシステムの紐付け）
どのシステムとどのシステムが連携しているか（システム間依存関係）
どのシステムがどの共通基盤・インフラを利用しているか（インフラへの依存）
それぞれの廃止・移行予定時期（ITロードマップとの整合性）

これをExcelで管理しようとするのは現実的ではありません。Excelはリレーションシップの管理が苦手です。業務とシステムを紐付け、システム間の連携を管理し、さらにインフラへの依存まで一元的に持とうとすると、シートをまたいだ参照が爆発的に増えます。更新も属人化します。これは構造的な限界です。

IT資産管理とレイヤー間の紐付け、システム依存関係の可視化、ITロードマップ管理まで一気通貫でできるツールが必要です。機能要件さえ満たせばツールは何でも構いません。ただし導入・維持コストと、可視化によって得られる意思決定加速の効果は天秤にかける必要があります。私が知る限りServiceNowのCSDMは有力な選択肢の一つで、業務機能からサービス、システム、インフラ環境まで構造的に管理できる設計になっています。