「2025年の崖」という言葉が経済産業省のDXレポートで示されてから、すでに数年が経ちました。2025年を過ぎた今、レガシーシステムを刷新し終えた企業と、いまだ手つかずの企業との差は、静かに、しかし確実に広がっています。COBOLやVB6、古いAS/400を扱えるエンジニアの高齢化はいよいよ深刻になり、担当者の退職とともに保守コストが跳ね上がるという話も珍しくなくなりました。皆さんの会社では、基幹システムの刷新は計画通りに進んでいるでしょうか。本稿では、2026年時点で見えてきた業界ごとのDX進捗の差と、システム刷新の現場で問われる勘所を、ITストラテジストの視点から整理します。
業界によって進捗に差が出る理由
DXの進捗は、業界横断で一様には進んでいません。例えば製造業では、政府が建築・交通と並んで重点分野に掲げていることもあり、テコ入れが進む一方で、人手不足と業務の属人化という構造的な課題が刷新の足かせになっています。生産現場のノウハウが特定の熟練者に偏っている場合、システムを刷新する以前に、業務そのものを標準化し言語化する作業が必要になり、ここで多くのプロジェクトが停滞します。一方、金融業界のように早くから規制対応やセキュリティ要件への投資を重ねてきた業界では、基幹系の刷新は着実に進む反面、投資額が大きくなりやすく、経営層への説明責任がより重くのしかかります。また、小売や流通業界では、ECサイトやポイントシステムなど顧客接点のデジタル化は比較的早く進んだものの、その裏側にある在庫管理や物流の基幹システムは旧来のまま残されているケースが目立ちます。顧客体験の刷新が先行し、バックオフィスの刷新が後回しになった結果、フロントとバックエンドの間でデータ連携の歪みが生じ、結局は二重入力や手作業での帳尻合わせが常態化してしまう。こうした「見た目は先進的だが中身は旧態依然」という状態は、外からは進捗が見えにくいだけに、経営層が実態を正しく把握できていないことも少なくありません。業界ごとの「進みやすさ」の違いや、フロントとバックエンドの刷新の非対称性を理解せずに横並びの計画を立てると、現場との温度差から計画倒れになりかねません。
刷新方式の選択とシステム開発現場での勘所
レガシーシステムの刷新方式は、大きく分けて既存の業務ロジックをそのままクラウド基盤に移す「クラウドマイグレーション」と、現行業務を見直しながら最新の技術スタックで組み直す「再構築」の二つがあります。前者は移行期間を短縮できる一方、レガシーな業務プロセスの非効率までそのまま持ち越してしまうリスクがあります。後者は本質的な改善につながりやすいものの、要件定義の負荷が大きく、現場のヒアリングに想定以上の時間がかかることが少なくありません。ここで重要なのは、生成AIやAIエージェントの活用を前提にシステムを設計するのであれば、仕様を完全に固めてから開発に入る従来型のウォーターフォール的な発想だけでは対応しきれないという点です。稼働後もエージェントの挙動を継続的に監視し、チューニングしていくことを前提とした体制と予算を、要件定義の段階からあらかじめ組み込んでおく必要があります。皆さんのプロジェクトでは、刷新後の運用体制まで見据えた予算組みができているでしょうか。
ガバナンスと人材育成という長期戦
システムを刷新して終わり、ではありません。刷新後も継続的に手を入れられる体制を維持できなければ、数年後には再びレガシー化してしまいます。そのためには、特定のベンダーや個人に依存しない内製化の推進と、若手エンジニアが基幹システムの知識を継承できる仕組みづくりが欠かせません。情報処理試験の世界でも、IPAは2026年度からITストラテジスト試験を含む高度試験をCBT（Computer Based Testing）方式で実施すると発表しており、試験時期も従来の春期・秋期から変更される見込みです。試験制度の変化そのものは形式面の話にとどまりますが、それは裏を返せば、資格取得後も学び続ける姿勢を持つ人材が、これまで以上に重宝される時代になったということでもあります。
まとめ
「2025年の崖」という号砲から時間が経った今だからこそ見えてきたのは、レガシーシステム刷新は一度きりのプロジェクトではなく、業界特性を踏まえた継続的な取り組みだという事実です。刷新方式の選定、生成AI時代を見据えた開発体制の設計、そして刷新後を担う人材の育成まで、ITストラテジストが目を配るべき範囲は年々広がっています。まずは自社の基幹システムがどの刷新方式に適しているか、そして刷新後の運用体制まで見据えた計画になっているかを、あらためて棚卸ししてみてはいかがでしょうか。
