2022年に富士通がメインフレーム事業の終了方向を示して以降、国内企業のモダナイゼーションのスピードは明らかに加速した。さらに日立製作所もメインフレーム事業からの完全撤退を発表したことで、国産メインフレームを利用する企業にとって、移行は「いつか検討する課題」ではなく「期限のある経営課題」になった。
ただし、レガシーシステムはメインフレームだけではない。古いバージョンのJavaや.NETで構成され、長年にわたって機能追加を繰り返してきたシステムもレガシー化が進んでいる。技術的にはオープンな環境であっても、利用しているフレームワークやミドルウェアが古く、仕様を理解する人員がいなくなれば、簡単には変更できない。
レガシーシステムへの危機感、84％の企業が認識
ITR（アイ・ティ・アール）の調査によると、レガシーシステムの存在に危機感を持っている企業は84％に上る。そのうちの21％が非常に強い危機感を持っている。多くの企業が問題を認識しながらも、対応を先送りしてきた実態が浮き彫りになった。
経済産業省が「2025年の崖」という言葉でこの問題を提起したのは、2025年になってからモダナイゼーションに取り組むためではなかったはずだ。本来であれば、それまでにレガシーシステムを解消し、デジタル時代に対応できる基盤を整える必要があった。しかし実際には、崖の手前に立ち、足元が崩れ始めてから、ようやく企業は重い腰を上げたと言える。
移行の最初の壁は技術ではなく人と予算
筆者がモダナイゼーションプロジェクトを支援する機会はここ数年で明らかに増えた。しかし現場で最初に直面するのは、移行技術やアーキテクチャの問題ではない。極めて現実的な問題、すなわち人と予算の確保である。
社内では、現行システムの仕様や設計思想を理解する担当者が退職したり、別の部署に異動したりしている。設計書が十分に残されておらず、プログラムを解析しなければ実際の処理が分からないケースも珍しくない。ベンダー側も深刻だ。メインフレームや古いプログラミング言語に対応できる技術者は減少している。企業がRFP（提案依頼書）を発行しても、必要な技術者を確保できない、プロジェクトのリスクが高いといった理由から、提案を辞退するベンダーもいる。
提案を受けられたとしても、提示された費用がユーザー企業の想定予算を大きく上回ることもよく目にするようになった。ハードウェアやソフトウェアだけでなく、クラウドサービスの価格も上昇、さらに人件費も高騰している。つまり、モダナイゼーションを先送りしたことで、移行はさらに難しくなっている。時間が経過するほど、システムを理解する人材と、移行を担うベンダーの両方が減少し、コストとリスクが上昇しているのだ。
リホスト選択が63％、その意外な落とし穴
人と予算を確保した後にも、大きな「壁」がある。どの移行方式を選択するかという問題だ。
経営陣は、業務停止やプロジェクト失敗のリスクを避けたいと考える。そのため、アプリケーションを大きく変更せず、新しい基盤に移すリホストを支持しやすくなる。一方、業務部門は、せっかく大規模に投資するのであれば、現在の使いにくさを解消し、効率性を大きく向上させたいと考える。その要求を満たそうとすれば、アプリケーションを再設計するリアーキテクチャや、ゼロから作り直すリビルドが必要になる。
その間に立つIT部門は、リスクと効果の接点として、既存の仕様を維持しながら新しい言語や環境に書き換えるリライトを選びたくなる。現行業務への影響を最小限に抑えつつ、保守性や拡張性を高められると考えるからだ。
経営陣、業務部門、IT部門のいずれの主張にも合理性がある。誰かが明らかに間違っているわけではないからこそ、移行方式がなかなか決まらない。そして議論を重ねるほど、最もリスクが低いと見えるリホストへと引っ張られていく。
ITRの調査でも、レガシーシステムの移行方式としてリホストを選ぶ企業は63％に上る。こうして、「モダナイゼーション」と看板を掲げて始まったプロジェクトが、現行システムを安全に移すことを優先するマイグレーションプロジェクトへと変わっていくのである。
「第一歩」のはずのリホストが終着点になる
筆者は、リホスト自体が悪いとは考えていない。保守期限が迫り、人材も限られている状況では、まず安定した基盤に移すことは合理的な判断である。最終的に目指す姿があり、そこへ向かうジャーニーの第一歩として位置付けられているのであれば、リホストも立派なモダナイゼーションだ。
問題は、リホストが事実上の終着点になってしまうケースが多いことだ。その最大の理由は、リホストが完了すると、経営陣からは問題が解決したように見えることにある。製品の保守終了やメインフレーム撤退といった差し迫った危機を回避できれば、次の段階に向けた投資の優先度は下がる。また、第一段階の移行で、当初想定していた以上の予算と人材を使い果たしてしまうこともある。プロジェクト体制は移行完了とともに解散し、その後の変革を継続して担う責任者も不在（あいまい）になる。
さらに、プロジェクトの評価指標は「期限内に、問題なく移行すること」に偏りがちだ。開発生産性や変更容易性、データ活用、業務改革といった将来的な価値よりも、障害を起こさないことが優先される。結果として、インフラは新しくなっても、複雑なプログラムや密結合したシステム構造、属人的な運用は残る。さらに、古い設計や脆弱性を引きずることで、セキュリティリスクが解消されない可能性もある。「新しい環境で動くレガシーシステム」になりかねない。
リホストは、技術的負債を解消するものではなく、「返済期限」を先延ばしする手段である。そこで得られた猶予期間をどう使うのかが決まっていなければ、技術的負債が再び積み上がる。
AIによって「あるべき姿」が決めにくくなった
現在のモダナイゼーションをさらに難しくしているのが、AIの急速な進化だ。少し前まで、モダナイゼーションの目指す姿は比較的明確だった。クラウドに移行し、アプリケーションをマイクロサービス化し、コンテナやAPIを活用する。DevOpsやCI/CDを導入し、俊敏に変更できるクラウドネイティブなシステムを構築することが、代表的な目的地と考えられていた。
もちろん、こうした取り組みの重要性が失われたわけではない。しかし、生成AIやAIエージェントの急速な進化によって、クラウドネイティブ化だけをモダナイゼーションの完成形として描くことは難しくなりつつある。今後、人間が詳細な要件を定義し、設計し、プログラムを実装するという開発の進め方そのものが変わる可能性がある。人間は実現したい目的や制約条件を示し、AIが設計、実装、テストの多くを担うようになれば、求められる開発基盤やアプリケーションの構造も変わる。
業務システムの利用方法も変わるだろう。従業員が個々のシステムを直接操作するのではなく、AIエージェントが複数のシステムを横断し、必要なデータを参照しながら業務を実行する形が広がる可能性がある。そうなれば、既存システムを全面的に作り直すことよりも、APIなどを通じてAIエージェントから安全に利用できる状態にすることが優先されるケースも出てくる。
つまり、AIによって変わるのは、開発を効率化する方法だけではない。システムを誰が開発し、誰が操作し、どのように業務を実行するのかという、エンタープライズシステムの前提そのものである。AIが今後どこまで進化するかを正確に予測できない以上、数年後に求められるアプリケーション構造や開発基盤を、現時点で一つの完成形として定めることは困難だ。
だからといって、AIの進化を見極めるまで何もしないという判断も適切ではない。AIの進化を待っている間にもシステムは古くなり、対応できる人材は減少する。必要なのは、将来のあるべき姿を一つに決めることではなく、今後どのような変化が起きても対応できる体制をつくることではないかと考えている。
今求められているのは、進むべき道を決めることではない
これからのモダナイゼーションで重要なのは、将来の技術構成を正確に予測し、一つの完成形を描くことではない。技術や事業環境が変化したときに、最適な選択をし直せる体制をつくることである。
その第一歩は、現在のシステムを理解できる状態に戻すことだ。どの機能がどの業務を支え、どのデータやシステムに依存し、どこに固有の業務ルールが埋め込まれているのかを明らかにする。現状を理解できなければ、リホスト、リライト、再構築、SaaSへの置き換えのいずれが適切かを判断することもできない。AIはコード解析や仕様の復元、依存関係の整理など、ブラックボックス化したシステムを解明する手段として活用できる。
次に必要なのは、将来の選択肢を過度に絞らないことだ。特定の製品やクラウド、開発方式を唯一の正解として固執するのではなく、データを取り出せるか、他のサービスと連携できるか、別の基盤に移行できるかといった観点を設計や契約に組み込む。将来変更する可能性が高い領域と、安定稼働を優先する領域を見極め、それぞれに必要な柔軟性を持たせることが重要である。
さらに、モダナイゼーションを一度限りの大規模プロジェクトにしないことも必要だ。システムの状態や技術的負債を継続的に評価し、事業環境や技術の変化に応じて、対象範囲や優先順位、移行方式を見直せる仕組みが必要である。
目的地が見えにくい今、企業に求められるのは、進むべき道を最初から一つに決めることではない。環境の変化に応じて進路を選び直せる余地を残すことこそが重要だと筆者は考える。
