2025年の崖とは？2026年に見直すレガシーシステムと対応の優先順位
「2025年の崖」は、2025年を過ぎれば自動的に解消する問題でも、すべての企業が同じ年にシステムを入れ替える期限でもありません。2026年に必要なのは、過去の警告を実測値として扱わず、自社で止められない業務、変更できない仕組み、引き継げない知識を把握して、対応の順番を決めることです。
2025年の崖は2018年の条件付き警告
経済産業省の2018年のDXレポートは、既存システムの課題を克服できない場合、2025年以降に最大12兆円／年の経済損失が生じる可能性を警告しました。これは条件を置いた将来の予測であり、2026年に12兆円の損失が実際に確認されたという意味ではありません。
レガシーシステムの問題は、稼働年数だけでは読み取れません。業務やデータの仕組みが分からず、変更や復旧の判断が難しい状態かを確認します。古くても目的と運用が明らかな仕組みと、新しくても依存関係が見えない仕組みでは、必要な対応が異なります。
過去の予測・公表資料・自社の事実を分ける
資料の年と、調査対象の時期を確認しましょう。2025年の経済産業省のレガシーシステムモダン化委員会総括レポート公表ページは、経営・業務とIT資産の可視化などの対応を扱っています。過去に行われた調査を2026年の調査と読み替えたり、関連がある結果から原因を断定したりしないことが大切です。
情報の種類 | 読み方 | 自社での使い方 |
|---|---|---|
2018年の最大12兆円／年 | 課題を克服できない場合の予測 | 問題意識の背景として扱う |
2025年公表の資料 | 公表日、調査期間、対象、提案を確認 | 可視化や体制を見直す観点にする |
自社の保守記録 | 対象期間、範囲、費用の定義をそろえる | どの作業に資源が必要かを調べる |
自社の復旧試験 | 実施日、対象、成功条件、未確認を残す | 止まった際の業務影響を判断する |
2025年のデジタル庁の公式解説も、警告とレガシー脱却の文脈を確認する材料になります。公表資料は考える手がかりであり、自社の停止リスクや移行費用の見積もりそのものではありません。社内説明には「公表された事実」「自社で確認した事実」「まだ置いている仮定」を分けて記載します。
業務・データ・依存関係から棚卸しする
システム名だけの一覧から始めると、同じ業務を支える表計算や手作業、周辺の連携を見落とします。「受注から出荷まで」「月次請求を確定するまで」など、業務の入口と完了からたどり、入力、出力、データ保管先、連携先、判断する担当者を記録します。
架空の対象業務 | 依存関係・担当 | 確認できた課題 | 次の判断 |
|---|---|---|---|
受注から出荷 | 在庫連携と出荷担当 | 復旧手順の試験が未実施 | 代替手順と復旧試験を先に整える |
使われなくなった集計 | 担当部署と定期出力 | 利用先を確認できない | 利用有無と保存条件を確かめ廃止を検討 |
月次の請求 | 経理担当と取引先データ | 手修正が多く理由が属人化 | 例外業務を整理し標準化の範囲を検討 |
広告アプリの計測連携 | アプリ担当と複数SDK | 識別子の扱いを説明できない | 仕様・送信先・目的を棚卸しする |
表は架空の記入例です。実際の台帳には、業務責任者、保守担当、契約上のサポート期限、データの所有者、復旧試験日、代替手段、判断期限も加えます。期限は製品名だけで推測せず、対象の版と契約について確認します。識別子やSDKを含む場合はAndroid広告IDの確認事項のように、個々の仕様を確かめる必要があります。
廃止・標準化・刷新・延命をリスクで選ぶ
利用者も出力の利用先もない処理は、保存義務や連携への影響を確認して廃止を検討します。業務の例外が多い場合は、先に例外を減らして標準化できるかを見ます。変更が必要で既存方式では実現しにくい部分は刷新を、すぐ移せない重要業務は期限と対策を決めた延命を検討します。
架空の同じ年数の二つの仕組みでも、出荷を止める仕組みに代替手段がない場合と、利用されない集計を出すだけの場合では優先度が違います。「一番古いから最初」ではなく、停止の影響、変更の必要性、復旧可能性、保守期限、依存関係を並べて判断します。
延命を選ぶ場合も、何もしないことと同じではありません。担当の引き継ぎ、復旧手順、必要な保守、次の判断日を残します。刷新ではデータ移行や業務変更も費用に含め、標準機能に合わせるだけで必ず短期間に終わると見込まないようにします。
小さな移行で検証・復旧・引継ぎを確かめる
最初の移行対象は、業務の境界と依存関係を説明できる範囲に絞ります。例えば一つの帳票や、特定部門の入力手順から確認し、データの件数だけでなく意味と集計結果が合うかを照合します。試す目的と判断条件を絞る考え方はMVPによる小さな検証とも接続できます。
- 対象業務、対象データ、除外する範囲を決める。
- 移行前後で照合する結果と、許容できない差を決める。
- 移行を中止・切り戻しする条件と責任者を決める。
- 代替手順と復旧を試し、現場の担当者が実行できるか確認する。
- 通常運用、例外処理、問い合わせ先を引き継いで次の範囲を判断する。
「データを移せた」と「業務を継続できる」は別の完了条件です。試験できなかった項目は合格扱いにせず、未確認として責任者と期限を残します。
経営と現場で実行シートをレビューする
実行シートは「解消したい業務上の問題／対象／対応案／責任者／費用と時間／判断日／成功条件／復旧条件」で作れます。架空の記入例なら「請求の手修正理由を説明できるようにする／月次請求／例外の整理と一部標準化／経理責任者／工数を別途見積もる／試行後に判断」とします。
測る指標は、変更リードタイム、手修正件数、復旧試験で確認できた範囲など、目的と対応させます。比較条件の決め方はKPIの基本と設定手順を参照できます。移行の完了だけで事業成果を保証せず、空いた資源を何に使うかまで経営と現場で決め、次のレビューにつなげましょう。
