2018年に経済産業省がDXレポートで「2025年の崖」について警鐘を鳴らして以降、多くの企業がレガシーモダナイゼーションに注力してきました。しかし、2025年が到来した現在も、依然として多くの企業でレガシーシステムが残存している状況です。

出所：IPA 2024年度ソフトウェア動向調査 調査結果

なぜレガシーモダナイゼーションがうまく進んでいないのでしょうか。それは、いざ進めてみると、当初想定していなかったさまざまな課題に直面するからです。例えば、ある製造業では、長年運用してきたグローバル基幹システムの老朽化が進み、保守人材の確保が困難になったことや、システムのブラックボックス化といったリスクから、基幹システム刷新プロジェクトが立ち上がりました。しかし、関係者間の合意形成が難航し、プロジェクトの見直しが行われたため、数年経っても現状調査や構想の段階で足踏みをしている状況です。企業によっては、プロジェクトが途中で頓挫してしまうケースも少なくありません。

このような課題に直面している企業は多いと考えられます。レガシーモダナイゼーションを阻む壁は主に、「関係者との活動の合意の壁」「現行解析の壁」「プロジェクトマネジメントの壁」という3つの「壁」が存在します。それぞれの壁がどのようなもので、どう対処すればよいのかについて、次の章で解説します。

①関係者との活動の合意の壁

レガシーモダナイゼーションは、IT部門が危機を感じて活動を開始するケースが多くあります。一方で、経営層や業務部門はレガシーシステムへの危機意識が低く、刷新にかかるコストや労力に対して効果がないと感じ、協力を得られずにプロジェクトが止まってしまうケースがあります。

IT投資は一般的に、費用対効果に見合うかどうかで判断されることが多いですが、レガシーモダナイゼーションに関しては、リスク回避が主な目的となります。効果だけでシステム投資額や、それにかかる労力を回収することは難しく、特に会計や人事といったバックオフィスの仕組みでは利用者も限られるため、定量効果での説明が難しくなります。

そのため、費用対リスク回避としての投資であることを経営層や業務部門と合意し、さらにプラスアルファの効果があることを納得してもらうことが重要です。

リスク要因としては、以下のようなものが挙げられます。

• 保守人材の不足
• ソフトウエアやハードウエアの保守切れ
• ランニングコストの増大
• 障害発生の頻発や長期化
• 新事業立ち上げやM&A時の対応の遅れ

一方で、効果としては以下が期待できます。

• 業務効率化や生産性向上
• 収益向上
• データ利活用やデータドリブン経営への貢献
• パッケージやSaaSのバージョンアップによる法改正対応や機能拡充
• 対象システムに関わる人員調達の容易性

老朽化したシステムの知識の習熟はキャリアとしての将来性が見込めないため、IT部門や業務部門ともに避けたがる傾向が見られます。

実際の事例でも、リスク回避を理由にレガシーモダナイゼーションに踏み出すケースが多くみられます。冒頭の製造業の例では、老朽化と担い手不足といったリスク回避を、レガシーシステムの刷新を意義の中心に据えていました。また、同じ製造業の事例ですが、当初のベンダー見積もりが非常に高額であったため、アーキテクチャーの見直しを行い、中堅パッケージを組み合わせることで費用を抑え、社内の合意形成を図りました。

このように、レガシー刷新の意義を整理するとともに、費用を抑えることも重要となります。近年では有力かつ安価なパッケージやSaaS製品も増えてきているため、そうした製品の活用により費用を抑制することも検討されています。

②現行解析の壁

レガシーモダナイゼーションにおいて新システムへの要求を整理する際、現行機能要求が置き去りになってしまうことがあります。これは、業務部門にもIT部門にも、過去にどういう要求からそのような仕様になったのか、仕様の中身だけでなくその必要性までも把握できていないことが原因と言えます。

そのため、現行の業務やシステムの実態を十分に把握しないまま、理想像（ToBe）だけをもとに新システムを設計し、構築フェーズで現行仕様の抜け漏れや必要性が明らかになり、大幅に開発規模が膨らんで、コストやスケジュールの超過といった事態を招くことがあります。
このため、序盤から現行解析を進めておくことは重要なプロセスとなります。システムの規模がそれほど大きくなく、設計書が最新化されており、現行システムの仕様に関する有識者が十分にいる場合には、設計書の解読や有識者へのヒアリングを基に、現行解析を進めることができます。
一方で、古いレガシーシステムの場合は、設計書などのドキュメントが存在しない、または最新化されていない、有識者が社内にもベンダー側にもいないといった状況が見られます。また、開発規模があまりにも大きく、設計書があっても読み解くのが困難な場合もあります。これは、パッケージであっても大量の追加開発で構築されているケースでは、同様の問題が起きることがあります。
こうした問題に対して、昨今発展が目覚ましいAI技術が活躍するケースが増えています。設計書不足などの事情により現行解析に問題が生じる場合、AIを活用した現行解析ツールによるソースコードの解読や、設計書のリドキュメント化が有効な手立てとなりつつあります。対応可能なドキュメントや解読対象の言語なども拡大しています。
また、現行システムの可視化の後にはToBeのシステム構成を検討していくことになりますが、ここにもAIツールの活用余地があります。現行のシステム間・機能間の結びつきやプログラムの複雑性を基に、AIにどこでシステムを切り離すべきかの分割案を提示させるといった活用方法も出てきています。

一方で、現行可視化やシステム分割において、AIにすべてを任せればよいというわけではなく、業務とシステムへの理解をもつ人間による判断も重要となるため、AIと人のエンジニア力をかけ合わせることが重要です。

③プロジェクトマネジメントの壁

レガシーモダナイゼーションは、規模が巨大で関係者が多いため、プロジェクトマネジメントの難易度が高くなる傾向にあります。また、構築規模が大きいことからプロジェクトが長期化し、構築期間中のビジネス環境の変化が要件にも影響を与え、要件のコントロールが難しくなるという問題も生じます。こうした問題を抑え込み、マネジメントをしっかりと機能させるためには、プロジェクトマネージャーが管理しやすい規模にプロジェクトのサイズを適切な単位に設定することが求められます。

過去の事例を踏まえると、プロジェクトマネージャーが管理できる範囲は、業務単位、サブシステム単位、一定の開発規模といった観点で妥当な規模に設定することで、品質面や進捗面でプロジェクトマネージャーが全体を把握し、適切な管理を行うことが可能となります。また、分割した複数領域を同時並行で進めることで、前述のプロジェクト長期化リスクの回避や、効果の早期刈り取りにもつながります。
しかし、複数プロジェクトを同時並行で進めることは、上記のようなメリットがある一方で、難易度が高まる要因にもなるため、対策も必要となります。大規模プロジェクトを複数領域にまたがって推進する場合、領域間のインターフェースや仕様の不整合により、大きなトラブルに見舞われることもあります。ある大手製造業では、大規模な基幹システムの刷新を行った際に、領域間の不整合により稼働後に大きな障害が発生し、事業にも多大な影響をもたらしました。

それでは複数領域を同時並行で進めるためのポイントは何か、ご紹介していきます。

まず体制面では、プロジェクト全体のQCD管理や領域間横断の意思決定を行う機能として、統括プロジェクトマネージャーを設定します。統括プロジェクトマネージャーは、プロジェクトの全体管理に責任を持つ必要がありますが、各領域に直接入り込むことはできないため、体制と合わせて、外側から個別プロジェクトの状況を把握する仕組み（統一のプロジェクト管理ツールや各種報告ルールなど）の構築が不可欠となります。
また、タスクやスケジュールの設定として、各領域がどこで合流し、どこで分散・独立して推進可能かを整理し、全体スケジュールとして整合性を図っておく必要があります。さらに、全体の業務やシステムの成立性を担保するタスク（要件定義後のウォークスルー、全体移行方針や計画、全体テスト方針や計画など）を設定し、領域間で中身の整合性を図っていくことが重要になります。
これら対策を取ることで、複数領域を同時並行で推進するプロジェクトが現実的なものとなっていきます。

レガシーモダナイゼーションは、古いシステムであるがために中身がわからない、規模が大きく関係者も多くなってしまうといった特有の難しさがあり、一筋縄では行かないテーマです。

一方で、依然として多くの企業がレガシーシステムを抱えており、保守人材の不足などのリスクが顕在化する中で、レガシーモダナイゼーションへ向かう必要性は、今後さらに高まってくると考えられます。

そうした企業の皆様が刷新に行き詰った際に、今回ご紹介した3つの壁と乗り越え方が参考になりますと幸いです。