レガシー刷新が、現場に嫌われる理由

基幹システムの刷新プロジェクトを、現場が喜んで迎えた場面を私はあまり見たことがありません。二年かけて、予算を使い切って、切り替えた翌週に言われるのが「前のほうが速かった」です。

技術的には成功しています。動いています。それでも誰も良くなったと思っていない。

前提の確認

2018年9月、経済産業省が DX レポートを公表しました。既存システムの問題を放置して経営改革が遅れれば、2025年以降に最大で年間 12 兆円の経済損失が生じうるという内容で、これが「2025年の崖」として広まりました。当時、企業の IT システムのおよそ 8 割がレガシー化しているとされていました。

その後も動きは続いています。デジタル社会の実現に向けた重点計画（2024年6月21日閣議決定）に基づき、経産省・デジタル庁・IPA を事務局とするレガシーシステム刷新検討会が設置され、2024年7月から2025年3月の議論をまとめた総合報告書が 2025年5月28日に公表されました。

つまり、七年経っても終わっていません。

データを読むと、話が少し違う

IPA のDX動向2025にレガシーシステムの状況を聞いた設問があり、日米独で比較されています。日本の結果は少し変わっています。

「レガシーシステムはない」と答えた割合は 3 か国で日本が最も高い。ところが「ほとんどがレガシーシステムである」と「わからない」の割合も、日本が最も高い。刷新が終わった企業と、まったく進んでいない企業の両方が多い、二極化した状態です。

そして 2023年度と 2024年度でほとんど傾向が変わっておらず、IPA は刷新が頭打ちになっていると書いています。

もう一つ、あまり知られていない結果があります。残っているレガシーシステムが DX の足かせになっているかを聞いた設問では、「DX 推進に対する大きな足かせとなっている」と答えた企業は 3 か国とも 2 割以下でした。

レガシーが問題でないという意味ではありません。ただ、企業自身は、それを一番の障害だとは答えていない。にもかかわらず刷新プロジェクトは動いていて、そして現場では歓迎されていません。この二つが同時に起きている理由のほうが、私には興味があります。

画面が仕様書として扱われている

刷新プロジェクトの最初の作業は、たいてい現行システムの棚卸しです。画面を全部数える。帳票を全部数える。機能を全部並べる。

そこまでは正しい作業です。問題は、その一覧がそのまま要件になることです。

現行の画面は、要件ではありません。過去の判断の堆積物です。中身を分解すると、だいたい次のものが混ざっています。

いまも必要な業務。何年も前の法改正に対応するために足されたもので、その後の改正で不要になったもの。一度だけ発生した事故の再発防止として足された確認画面。もう退職した特定の担当者のための項目。そして、当時のシステムの制約を回避するために現場が編み出した手順が、いつのまにか正式な業務として画面化されたもの。

最後のものが一番厄介です。制約への回避策が業務として固まっている。そして新しいシステムにはその制約がないのに、回避策のほうは移植されます。

こうして現場は、制約が消えた後も回避策を続ける画面を渡されます。速くならないのは当然で、工程は一つも減っていないからです。

「前のほうが速かった」の中身

この感想は、たいていの場合、正確です。

旧システムを十年使ってきた人は、そのシステムの遅さを前提にした最適化を体に入れています。どこでタブを押すか、どの順番で入力すれば再計算が走らないか、どの画面から入れば二つ手順を飛ばせるか。それが全部無効になります。

新しいシステムが同じ工程数で、しかも慣れがゼロなら、体感が遅くなるのは当たり前です。工程数を減らしていなければ、この感想は永久に正しいままです。

だから刷新の成否は、切り替え直後の混乱の量ではなく、工程数を減らしたかどうかで決まります。減らしていれば、慣れとともに評価は反転します。減らしていなければ、二年経っても反転しません。

順番を変える

技術構成から決めるのをやめて、業務の形から決めます。

移さないものを先に決める。 一覧を「移す」「移さない」「あとで決める」の三つに分けます。「あとで決める」は必ず「移す」になるので、期限を切ります。この作業をやると、たいていの会社で全体の 2 割から 3 割が「移さない」に落ちます。落ちない場合は、まだ真面目にやっていません。

画面ではなく、業務の流れを書く。 誰が何を、どういう順番でやるのか。誰が誰を待っているのか。画面は最後です。先に画面を見ると、現行の構造から離れられなくなります。

残す工程については、なぜ残すのかを一行で書く。 書けないものは残す必要がありません。「昔からこうなっている」は理由ではありませんが、少なくとも正直な回答なので、そう書いてもらったほうが議論が進みます。

状態を数える。 エラー、空、読み込み中、権限なし、通信断。画面数ではなく状態数がプロジェクトの実際の規模です。20 画面は珍しくなく 60 から 80 の状態を意味します。ここを数えずに立てた計画は、実装の途中で必ず崩れます。

現場の人を最初の週に入れる。 受け入れテストではありません。何を移さないかを決める会議にです。一番危ない工程を知っているのはその人たちで、そして刷新後に運用するのもその人たちです。

一番効く問い

刷新の会議で私が必ず聞くのは、これです。

この作業は、いまのシステムがこうだから、こうやっているのですか。

この質問に対して部屋が静かになる工程が、毎回いくつか出てきます。そこが削れるところです。そして削れる工程を見つけずに新システムに移すと、その制約はシステムからなくなった後も、業務の中に生き残ります。

十年後、次の刷新をする人が同じ画面を見て、なぜこの手順があるのか誰にもわからない状態になります。今回の刷新で、あなたがその状態を作ったことになります。

システムの入れ替えは、仕事の入れ替えではありません。前者だけをやると、費用だけが新しくなります。

参考

• 経済産業省 DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～（2018年9月7日）。既存システムを放置した場合に 2025年以降で最大年間 12 兆円の経済損失が生じうるとの試算
• 経済産業省 レガシーシステム刷新検討会 総合報告書（2025年5月28日）。経産省・デジタル庁・IPA が事務局、2024年7月から2025年3月の議論をとりまとめ
• IPA DX動向2025、本文 PDF（2.5 節、図表 2-17、2-18）