LASSIC Media らしくメディア
2025年の崖とレガシー刷新の経営判断
LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託
この記事のポイント
- 経済産業省が示した「2025年の崖」は、老朽化・ブラックボックス化した基幹システムを放置した場合の経済損失に関する警鐘であり、単なる期限ではありません。
- レガシー刷新が進まない背景には、現行踏襲の要求、ベンダーへの丸投げ、全面刷新のリスクに対する懸念という複数の要因が重なっています。
- 経営が着手すべきは、現行システムの棚卸しによる仕分けと、優先度に基づく段階的な移行計画、そして内製と外部パートナーの役割分担の設計です。
目次
2025年の崖とは何か、経産省DXレポートの警鐘
2025年の崖とは、経済産業省が2018年9月に公表した「DXレポート~ITシステム『2025年の崖』の克服とDXの本格的な展開~」*1で示した問題提起で、老朽化・複雑化・ブラックボックス化した既存システムを放置した場合に生じる経済的な悪影響を指します。
同レポートは、複雑化・老朽化・ブラックボックス化した既存システムが残存し克服できない場合、2025年以降、12兆円/年規模(現在の約3倍)の経済損失が生じる可能性があると指摘しました*1。この12兆円という数値は、同レポートが示した試算上の上限シナリオであり、断定的な予測ではなく回避すべきリスクの規模を示す警鐘として提示された点に留意が必要です。
レポートが問題視したのは、単に古いシステムを使っていること自体ではありません。技術的負債(短期的な視点で開発・改修を重ねた結果、長期的に保守・運用コストが積み上がった状態)を解消しないままデータ活用だけを進めようとすると、保守運用コストがIT予算の9割以上に達するおそれがあるという構造そのものです*1。国内企業のIT関連費用は、約8割が既存システムの維持・運用(ラン・ザ・ビジネス)に充てられているとも指摘されており*1、新たなデジタル投資に振り向けられる余力が乏しい状態が問題の根にあります。
加えて、レポートは基幹系システムを保守できる人材の引退・退職やサポート終了が2025年前後に集中する見通しを踏まえ、IT人材不足がシステムのブラックボックス化と保守困難をさらに深刻化させると整理しました*1。老朽化・ブラックボックス化・人材枯渇という3つの要因が重なることで、保守費が高騰し、結果として経済損失につながるという因果関係が「2025年の崖」の骨子です。
2025年から現在まで、崖はどう推移したか
2025年の崖という言葉は2018年に提起されましたが、経済産業省はその後も継続してDXレポートの続編を公表し、論点を更新してきました。2020年12月には「DXレポート2(中間取りまとめ)」*2を公表し、DX推進指標による自己診断結果(2020年10月時点、約500社が回答)を分析した結果、9割以上の企業がDXに全く着手できていない、または散発的な取り組みにとどまる段階にあることを示しました*2。
2021年8月には「DXレポート2.1」*3が公表され、論点はシステム刷新そのものから、ユーザー企業とベンダー企業の関係性へと広がりました。同レポートは、ユーザー企業がIT対応をベンダーに委ねる一方、ベンダーも労働量に応じた価格設定でリスクを回避するという相互依存の構図を「低位安定」と呼び、これがデジタル産業への変革を妨げる要因になっていると指摘しました*3。丸投げの関係を続ける限り、刷新の意思決定そのものが先送りされやすいという課題が、ここで明確に言語化されたことになります。
2022年7月には「DXレポート2.2(概要)」*4が公表され、デジタル技術を守りのコスト削減だけでなく収益向上の手段として使う視点への転換が論点として示されました。一連のレポートを通じて、経済産業省の問題提起は「老朽システムの技術的リスク」から「経営としての意思決定・企業間関係の見直し」へと重心を移してきたと整理できます。
現行踏襲・丸投げ・全面刷新の恐怖 — 刷新を止める3要因
2025年の崖という警鐘から数年が経過してもなお、多くの企業でレガシー刷新の着手が遅れている背景には、経営判断を止める複数の要因が重なっています。第一に、現行システムをそのまま踏襲したいという要求があります。既存業務フローに合わせて作り込まれた個別機能は、担当部門にとって使い慣れた仕様であり、刷新によって業務が変わることへの抵抗感が意思決定を鈍らせます。
第二に、システムの設計・保守を外部ベンダーに丸投げしてきた結果、発注側の企業内にシステムの全体像を把握する人材が育っていないという問題があります。DXレポート2.1*3が指摘した「低位安定」の関係は、発注側の要件定義力・システム理解を弱め、刷新の是非を自社で判断すること自体を難しくする一因になっています。
第三に、全面的な刷新に伴うリスクへの懸念です。基幹システムを一括で置き換える場合、移行時のデータ不整合や業務停止のリスクは避けられません。過去に大規模な刷新プロジェクトが遅延・頓挫した事例が業界内で語られてきたことも、経営層が全面刷新に踏み切れない心理的な要因になっています。
これら3つの要因はいずれも、レガシー刷新を「情報システム部門の技術課題」としてではなく「経営としての意思決定課題」として扱う必要があることを示しています。現行踏襲の是非、丸投げからの脱却、全面刷新か段階移行かの選択は、いずれも経営が判断すべき事項であり、現場任せにできる範囲を超えています。
経営判断の起点は現行システムの棚卸しと仕分け
レガシー刷新を先送りしないための経営判断とは、いきなり刷新プロジェクトを発注することではありません。最初に着手すべきは、自社が保有する現行システムの全数を棚卸しし、それぞれを刷新・塩漬け・廃止のいずれに仕分けるかを決める作業です。
棚卸しでは、各システムについて稼働年数・保守担当者の在籍状況・ドキュメントの有無・関連する業務範囲を確認します。特に、仕様を把握している担当者が退職・異動した場合に保守が継続できるかどうかは、ブラックボックス化の進行度を測る実務的な指標になります。ドキュメントが整備されておらず、特定の個人しか改修できない状態にあるシステムは、優先的に扱いを検討すべき対象です。
仕分けの基準は、事業への影響度と技術的なリスクの2軸で整理するとよいでしょう。基幹業務に直結し、かつ保守リスクが高いシステムは刷新の優先候補になります。一方、利用頻度が低く事業影響が限定的なシステムについては、無理に刷新せず現状維持(塩漬け)とする、あるいは役目を終えたシステムとして廃止するという選択も、経営判断としては合理的です。すべてを刷新することが目的ではなく、経営資源を事業影響の大きい領域に集中させることが仕分けの目的です。
全面刷新ではなく優先度で進める段階的移行
棚卸しと仕分けが終わった後、経営が次に判断すべきは移行の順序です。基幹システムを一度にすべて置き換える全面刷新は、移行リスクが大きく、業務への影響も広範囲に及びます。DXレポート2.2*4が示すように、DXの本質はシステム刷新そのものではなく、事業や組織の変革を段階的に進めることにあります。刷新の進め方についても、この考え方に沿って優先度に基づく段階移行を軸にすることが現実的です。
優先度は、前段の仕分けで刷新対象と判定したシステムの中から、事業影響度・技術的リスク・改修の難易度を踏まえて決めます。影響範囲が限定的で技術的にも切り出しやすい周辺システムから着手し、知見を蓄積してから基幹領域に着手するという順序は、移行リスクを抑える現実的な選択肢になります。
段階移行を進める過程では、旧システムと新システムを一定期間並行稼働させる設計や、データ移行時の検証手順の整備が欠かせません。これらの工程を軽視すると、移行時のデータ不整合や業務停止という、全面刷新で懸念されるリスクと同種の問題が部分的にでも発生し得ます。段階移行は全面刷新よりリスクを抑えやすい進め方ではありますが、リスクがゼロになるわけではない点は経営として認識しておく必要があります。
内製と外部パートナー、役割分担の設計
DXレポート2.1*3が指摘した「低位安定」の関係を繰り返さないためには、内製と外部パートナーの役割分担をあらかじめ設計しておくことが重要になります。すべてを外部に委ねる丸投げでも、すべてを自社で抱える完全内製でもなく、どの判断を自社が持ち、どの実装を外部に委ねるかを切り分ける発想が求められます。
具体的には、事業要件の定義・優先度の決定・移行後の運用ルール策定といった意思決定に関わる部分は自社側の役割として残し、設計・開発・移行作業の実務は、専門知見と実績を持つ外部パートナーに委ねるという分担が一つの型になります。この分担であれば、自社にシステムの全体像を把握する人材が育たないまま丸投げが固定化する事態を避けつつ、実装工数を確保できます。
レガシーシステムの刷新には、対象システムの仕様解読、移行先アーキテクチャの設計、データ移行時の検証といった専門知識が必要であり、社内の情報システム部門だけで完結させるには相応の人員と期間を要します。必要な知見を自社で一から育成するか、外部パートナーの実績を活用するかも、経営が判断すべき事項の一つです。
外部委託先を選ぶときの判断材料
内製と外部委託の役割分担を決めた後、経営が判断すべきは委託先の選定基準です。レガシーシステムの刷新は、システムを新しくするだけでなく、業務を止めずに移行を完了させることが求められる特殊な案件であり、通常の開発案件とは異なる判断材料が必要になります。
第一の判断材料は、対象領域に類似した刷新・移行の実績があるかどうかです。基幹システムの刷新は業種・業務ごとに固有の事情が多く、類似領域での経験の有無が移行リスクの見積もり精度に直結します。第二に、現行システムの仕様解読やドキュメント整備を担える体制があるかどうかです。ブラックボックス化したシステムを扱う以上、要件定義の前段階で仕様を可視化する工程を担えるかは重要な判断軸になります。
第三に、移行完了後の保守・運用まで一貫して対応できる体制があるかどうかです。刷新プロジェクトを実装で終わらせず、その後の保守運用まで見据えた体制を持つパートナーであれば、刷新後に再びブラックボックス化が進行する事態を防ぎやすくなります。委託先の評価は、目先の開発費用だけでなく、これら実績・体制・保守継続性を総合して行うことが、レガシー刷新を一過性で終わらせないための判断材料になります。
まとめ:レガシー刷新を進める3つの経営判断軸
本稿では、経済産業省のDXレポート*1が示した「2025年の崖」の問題提起と、その後のDXレポート2・2.1・2.2*2*3*4で更新されてきた論点を踏まえ、レガシーシステム刷新を先送りしないための経営判断の進め方を整理しました。要点を3つに集約すると次の通りです。第一に、2025年の崖は特定の期限ではなく、老朽化・ブラックボックス化・保守費高騰という構造的な問題への警鐘として理解する必要があります。第二に、刷新の起点は現行システムの棚卸しと仕分けであり、全面刷新ではなく優先度に基づく段階移行を選択肢の中心に据えることが現実的です。第三に、内製と外部パートナーの役割をあらかじめ切り分け、実績・体制・保守継続性を基準に委託先を選ぶことが、丸投げの再発を防ぎます。これら3つの判断は、いずれも情報システム部門任せにできるものではなく、経営がリードして進めるべき事項です。
よくある質問
2025年の崖という言葉は今も使われていますか。
経済産業省が2018年のDXレポートで示した警鐘としての用語は現在も広く参照されています。ただし同省はその後もDXレポート2・2.1・2.2*2*3*4で論点を更新しており、単なる期限の話ではなく、老朽化したシステムへの対応や企業間の関係性の見直しを含む継続的な課題として扱われています。
12兆円という経済損失の数値はどのように理解すればよいですか。
経済産業省のDXレポート*1が示した12兆円/年規模(現在の約3倍)という数値は、既存システムの課題を克服できなかった場合の試算上の上限シナリオです。将来を断定的に予測した数値ではなく、放置した場合に生じ得るリスクの規模を示す警鐘として理解するのが適切です。
全面刷新と段階移行はどちらを選ぶべきですか。
事業影響度や技術的リスクは対象システムごとに異なるため、一律の正解はありません。多くの企業にとっては、現行システムを棚卸しして仕分けたうえで、事業影響が限定的な領域から着手する段階移行の方が、移行時のリスクを抑えやすい進め方になります。
刷新を外部パートナーに委託する場合、自社は何をすればよいですか。
事業要件の定義、刷新対象の優先度決定、移行後の運用ルール策定といった意思決定は自社側の役割として残すことが重要です。設計・開発・移行作業の実務を外部パートナーに委ねる場合も、判断の主体を自社に置くことで、丸投げの関係を避けられます。
委託先を選ぶ際、費用以外に何を確認すべきですか。
類似領域での刷新・移行実績、ブラックボックス化した現行仕様を解読・可視化できる体制、移行完了後の保守運用まで一貫して対応できる体制の3点を確認することが判断材料になります。費用だけで選定すると、移行後に再びブラックボックス化が進む懸念があります。
著者:テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典:経済産業省「DXレポート~ITシステム『2025年の崖』の克服とDXの本格的な展開~」(2018年9月7日公表)https://www.meti.go.jp/policy/it_policy/dx/20180907_02.pdf
- *2 出典:経済産業省「DXレポート2(中間取りまとめ)」(2020年12月28日公表)https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation_kasoku/pdf/20201228_3.pdf
- *3 出典:経済産業省「DXレポート2.1(DXレポート2追補版)」(2021年8月31日公表)https://www.meti.go.jp/press/2021/08/20210831005/20210831005-2.pdf
- *4 出典:経済産業省「DXレポート2.2(概要)」(2022年7月公表)https://www.meti.go.jp/policy/it_policy/dx/002_05_00.pdf