
「2025年の崖」は経済産業省が2018年に公開したデジタルトランスフォーメーション(DX)に関する報告書で取り上げた言葉だ。2025年頃に老朽化した企業システムが増え、運用や更新を担うエンジニアの不足感が強まることを指摘した。この課題が解消しない場合はDXが進まず、大きな経済損失が生まれると警鐘を鳴らした。2025年が目前に迫った現在でも、この「崖」はそそり立ったままだ。これまでの流れを改めて確認しながら、企業が取るべき対策や進むべき方向について考えてみる。
経産省が報告書「DXレポート」の中で指摘した課題は複数あり、それらが複雑に絡み合っている。問題の根幹と言えるのが、企業が運用する基幹系システムの老朽化と、それにともなうブラックボックス化だ。
従来の日本企業の基幹系システムは多くの場合、各事業部門が個別に構築したものが連なった形になっている。全社最適を考えて作られたものでないため、DXで必要とされる全社横断的なデータ活用が難しい。
DXレポートでは、2025年時点で21年以上稼働する基幹系システムが6割を超える、と想定している。それはシステムの老朽化と同時に、企業内にシステム構築当時を知る人材が少なくなっていることを意味する。
部分最適による複雑化や、システム構築当時を知る人材がいなくなっていることなどにより、基幹系システムはブラックボックス化する。ブラックボックス化したシステムは運用や保守の難易度が高まり、DXを進めるためのカスタマイズなどにも多くの手間とコストがかかってしまう。
DXという言葉は、デジタルを使って経営改革を進めることを指す。基幹系システムがブラックボックス化し、デジタルがうまく活用できない状況ではDXが進まない。レポートはそうしたことを想定し「2025年から2030年の間に、年間で最大12兆円の経済損失が生じる可能性がある」としている。
これを回避するために必要なこととして挙げているのが、2025年までに基幹系システムを集中的に刷新することだ。しかし、これを難しくする複数の問題も同時に指摘している。
1つはIT人材の不足だ。2015年時点で既に約17万人不足していたとする国内のIT人材が、2025年時点では約43万人不足すると予想した。日本ではIT人材の多くがITベンダーに所属している。システムを所有・利用する企業だけでなく、その構築や運用をサポートするITベンダーでも多くの人材が不足するのだ。
中でも特に不足するとされたのが、「レガシーシステム」を扱う人材だ。大型コンピューターの「メインフレーム」や、その上で動くアプリケーション開発で多く用いられるプログラミング言語「COBOL」などで構築したシステムを、レガシーシステムと呼ぶ。レガシーシステムは旧式の技術で構築されているため、これに精通した技術者は不足が著しい。
それでは現在広く普及している現行のサービスやソフトウエアを使えばよいのではないか、となるが、ここに別の問題が重なる。大企業の多くが基幹系システムに採用するERP(統合基幹業務システム)パッケージのサポート終了が、2025年に予定されていたのだ。サポートが切れたソフトは、セキュリティの問題が見つかった際に対応パッチが配布されないなどの問題があるため、継続利用が難しい。
システムがブラックボックス化し、DX推進のために手を打たなくてはならないにもかかわらず、システムを改修できない。手助けを頼みたいITベンダーでもIT人材が不足する。レガシーシステムの専門家は特に枯渇が著しく、有力なERP製品のサポートも終わってしまう。このように複数の問題が大挙して押し寄せるとされたのが、2025年の崖なのだ。
経産省が最初にDXレポートを発表したのは2018年だ。不足するIT人材の数や経済損失などについての予測は、「指摘した課題を克服できなかった場合」として挙げたものだ。
ではレポートが発表されてから状況はどう変わったのか。レポ—トが大きな話題となったことで、意識を変えた企業はシステム更新の前倒しや、DX人材の確保などを進めてきた。
その動きは実際に数字として表れている。電子情報技術産業協会(JEITA)によると、企業や官公庁向け業務システム構築のサービスについて、日本企業の2023年度の売上高は前年度比5.4%増の8兆3732億円だった。2025年の崖を見据え、システム更新を前倒しする企業が相次いだためと見られている。
ITベンダー各社も対応を進めてきた。例えば欧州SAPは、大企業に高いシェアを持つERPパッケージ「SAP ERP 6.0」の保守期限を、当初の2025年から2年延長し、2027年にした。
企業からのシステム更新やDXの要望に応えるため、M&AによってIT人材の拡大を図るITベンダーも増えている。国内最大手のNTTデータは2024年4月、独立系システム開発のジャステックを約340億円で完全子会社化すると発表した。IT人材を増やし、開発体制を強化することが目的だ。他にも多くのITベンダーが人材獲得を目的としたM&Aを実施している。
政府も対応を進めている。企業が抱える老朽化したシステムの問題解消を目指す省庁横断の「レガシーシステム脱却・システムモダン化協議会(仮称)」を、早ければ2024年度中に新設する予定だ。
民間企業が共同で課題解決に取り組む動きもある。三菱UFJ銀行は2024年10月、地方銀行向けに基幹系システムを所有し、運用を一括受託する取り組みをスタートした。「金融ハイブリッドクラウド・プラットフォーム」の名称でサービスを提供する。
三菱UFJ銀行が日本IBMからメインフレームなどのIT機器を調達し、機器やソフトの保守は日本IBMが担当する。サービスを利用する地銀はシステムの利用料を支払う。地銀はサービスを利用することで、自行で基幹系システムを運用する場合などと比較して、コストが減らせる見込みだ。
産官学で様々な対応が取られてきたものの、2025年が目前に迫った現在、2025年の崖として予想された問題は解消に至っていない。
経産省は2022年7月に発表した「DXレポート2.2」において、DXの推進の取り組みに対する意識は高まっているものの、「既存ビジネスの維持・運営をデジタル投資の約8割が占めており、DX推進に経営資源が投入されていない」とした。「2025年の崖問題の克服状況は順調ではないとの指摘がある」とも言及している。
2023年度にシステム更新を前倒しした企業が多くあったことを先に紹介したが、一方で取材をしていてよく耳にするのが、「ITベンダーにシステム再構築やDX支援を依頼したが、ベンダー側が引く手あまたで忙しく、断られてしまった」といった声だ。ITベンダー側の人手不足により、企業のシステム更新やDX推進のニーズに応えられていないことが分かる。
2025年の崖には様々な問題がある中で、特に大きな課題として指摘されることが多いのがレガシーシステムだ。先の通り、政府も企業のレガシーシステムからの脱却を支援するための取り組みを進めている。
レガシーシステムからの脱却法として代表的なのは、ERPなどの汎用的な現行製品を採用したシステム・サービスへ移行することだ。アプリケーションのプログラミング言語を、COBOLから現在でもメジャーなJavaなどのプログラミング言語に移行することも考えられる。
これらによってレガシーシステムから脱却することは可能であるものの、企業のデジタル化にとってこれが正解とは言い切れないのが難しいところだ。例えば、SAPのERPを扱える技術者はレガシーシステムの技術者よりもずっと多いが、SAPのERPを使っている企業も多く、最近はシステム更新が相次いでいる。「技術者が不足しており、簡単には集められない」という点では、レガシーシステムもERPパッケージも状況は同じなのだ。
レガシーシステムからの移行作業自体も簡単ではない。象徴的なのが、2024年4月に表面化した江崎グリコのシステム障害だ。同社はそれまで使っていた旧システムを、SAPのERP「SAP S/4HANA」に移行したところ、大規模なシステム障害が発生した。これにより、多くの商品の出荷が止まるなどの影響があった。
グリコの問題は詳しい原因が公開されていない。2025年に近い時期に起きたため、2025年の崖と関連付けたくなるが、それは早計かもしれない。なぜならグリコは事実関係だけで見れば、2025年よりもかなり早い段階でSAPのERPの導入に必要な人員をそろえ、2024年4月にシステム更新を終えていたことになる。この動きだけを見ると、2025年の崖に正面から向き合い、取り組んできた、とも言える。グリコの問題から学べるとしたら、「レガシーシステムからの脱却は簡単ではない」ということや、「大規模な基幹系システムの更新は非常に難しい」といったことだろう。
レガシーシステムを持ち続けることの最大の問題とされるのは、技術者が高齢化し、それに代わる若手の技術者が育っていないことだ。これから発展が見込める技術ではないため、今後若手技術者が増える見込みは少ない。
しかし最近は、多くの若手IT技術者を抱えるベトナムのITベンダーが、日本企業からのサービス受託のためにCOBOL技術者を育成する、といった動きがある。これが日本企業全体のニーズを満たすほどの規模になるかは難しいところだが、急いでレガシーシステムから脱却することが必須、とは言い切れない状況だ。
「COBOLのような古いプログラミング言語を使っているのが良くない」と言われることもあるが、その批判は言葉足らずだ。問題なのはアプリケーションが老朽化して中身がブラックボックス化していることであり、言語の問題ではない。強いて言えば、COBOLを扱える技術者が少ないため、ブラックボックス化したアプリケーションを後からひもといて理解するのは難しいかもしれない。しかし、繰り返すがCOBOLを使ったからブラックボックス化した訳ではないのだ。
仮にJavaを使っていたとしても、ブラックボックス化する恐れは十分にある。一方でCOBOLで作ったアプリケーションであっても、必要な要員を確保し、しっかりメンテナンスを続ければ老朽化やブラックボックス化は防げる。
基幹系システムのかじ取りは、様々な要因が関係するため、多くの企業に当てはまる最適な道筋を示すのが難しい。はっきりと言えるのは、企業は自社の基幹系システムをベンダー任せにせず、常に発注者としての責任を果たせるようにしておくことが重要だということだ。レガシーシステムとERPのいずれでも、ベンダーに頼りきり、自分たちにとってシステムの中身がブラックボックス化してしまうと、他ベンダーへの作業移管や他システムへの切り替えの難易度が格段に上がってしまう。
自社に適したシステムのロードマップを描くには、自社システムについてしっかりと理解することが最も重要だ。その上で自社に合ったシステム基盤は何か、選択したシステム基盤に関する技術者を長期にわたって確保できるか、といったことを一つひとつ、地道に考えていくしかないだろう。