2025.06.23

「2025年の崖」とレガシーシステム

地に足の着いたレガシーモダナイゼーションをするために

中村 公也 

2018年に経済産業省が発表したDXレポートでは、「2025年の崖」という表現で、企業が抱えるレガシーシステムの問題に対して強い警鐘が鳴らされた。これを受けて、多くの企業がレガシーシステムへの対応に取り組んできた。2025年になった現在、すでにレガシーシステムから脱却した企業もある一方で、依然として多くの企業が課題を抱えており、対応が求められる状況が続いている。本稿では、レガシーモダナイゼーションの計画におけるポイントと今後どのようにこの課題に向きあっていくべきかについて論じる。

「2025年の崖」とは何だったのか

2018年に経済産業省が発表した「DXレポート」では、企業の競争力を高めるうえで、老朽化したレガシーシステムの存在が大きな障壁であると指摘された。さらに、これを放置した場合、2025年以降には最大で年間12兆円規模の経済損失が発生する可能性があるとされ、「2025年の崖」という強い警鐘が鳴らされた[1]。その後、経済産業省は、初版のDXレポートが「DX=レガシー刷新」という誤解を一部に生んだことを踏まえ、DXの本質的意義を再定義する姿勢を示した。2020年に公表された「DXレポート2」では、デジタル技術を活用したビジネスモデル変革や新たな価値創出こそがDXの本質であり、レガシー刷新はあくまでその手段の一つであることが明確にされた[2]。
DXレポートの影響により、レガシーシステムへの取り組みは多くの企業で実施されてきている。しかし、2025年現在においてもレガシーシステムは多く残っており、課題として認識している企業は依然として多い状況である。

レガシーモダナイゼーションを計画する上でのポイント

多くの企業がレガシーモダナイゼーションの検討を進めているが、期待通りに進まないケースも多く見られる。その原因の1つとして、「計画段階で実現性や費用対効果が十分に考慮されていない」ことが挙げられる。
レガシーモダナイゼーションの計画では、現状の課題やニーズを明確にし、将来の目指すべき姿(To-Be)を定めた上で、ロードマップとして計画を立てていく。その際、対象となるレガシーシステムは100万STEPを超える大規模なものが多く、膨大なコストやリソース、期間が必要となる。それによって、膨大な投資やリスクに対するリターンが見合わず、経営の承認が得られずにリプランもしくはプロジェクト自体が頓挫することもある。重要なのは、実現性と費用対効果のバランスを踏まえた“現実解(Can-Be)”を描き、投資効果のあるモダナイゼーション計画を立てることである。
そのためには、レガシーモダナイゼーションによって得たい”効果”(モダナイゼーションの目的)を明確にしていくことを最優先で実施すべきだと考える。目的を達成するための手段を整理し、予算やコスト、リスク、効果などに鑑みてCan-Beを描いていくべきである。

図1:モダナイゼーション計画の進め方とポイント

 

また、Can-Beを描く際には、システム領域ごとの特性や課題、ニーズを整理していくとよい。例えば、各システム領域における変更頻度や保守費用などを整理し、変更頻度が高く保守費用の高い領域は、新しく作り直し(リビルド)をし、そうでない領域は現状のまま維持することで、少ない投資で効果を得ることも可能である。その際、システム間の依存関係をチェックすることも重要である。図2の例で説明する。領域①のみをモダナイゼーションして、領域②をそのまま残す計画を策定したとする。その際、領域①と②が密結合になっている場合、別システムとして切り離すことが困難になり、開発工数にも大きく影響してしまう。そのため、そのような手法をとる場合は、事前に依存関係を整理して、密結合であれば疎結合化するなどの対策を事前に検討しておく必要がある。

図2:領域特性・ニーズに応じたモダナイズ方針の例

 

今後のレガシーシステムとの向き合い方

成果につながるレガシーモダナイゼーションを進めるには、以下のような視点とアプローチが重要である。

1. 「レガシー=悪」という発想からの脱却

「レガシー=悪」という発想になると、レガシーシステムを脱却することが目的になってしまうことがある。これは、手段の目的化であり、本来重要なのは、レガシーシステムを脱却して「何を実現したいか?」である。例えば、COBOL開発人材の減少に対応するために、COBOLをJavaなどの言語に変換する際、機械的に変換するツールを利用することがある。そうすることで、言語はJavaになるが、プログラムの構造はCOBOLのままJavaで書かれた、いわゆる“Jabol化”されたコードとなり、かえって保守性が低下することがある。また、結果的にはCOBOLとJavaの両方の知識を有する人材が必要になって、却って人材調達リスクを高めてしまう結果にもなりかねない。そのため、レガシーモダナイゼーションはあくまで手段であることを念頭に置き、モダナイゼーションの目的や現状に応じた適切な手段を見極めることが重要になる。場合によっては、レガシーシステムをそのまま維持・継続することも有効な選択肢となることもある。

2. 現実的かつ丁度よいCan-Beを策定する

To-Be像を描くことは重要であり必須だが、過剰なものになってしまうと、投資やリスクが増大する。費用対効果や実現可能性を踏まえた「現実的かつ適切なCan-Be像」を描くことが重要である。例えば、モダンなシステムの代表例として挙げられるマイクロサービスは、開発の柔軟性やスケーラビリティ向上など多くのメリットがある一方で、開発や運用・監視の難易度が高く、ランニングコストが増大することがある。そのため、必ずしもマイクロサービス化を目指す必要はなく、モノシリックなシステムのままでも、アプリケーションの改善や開発プロセスの変革などの施策を打つことでモダナイゼーションの目的を達成できることもある。

3. 段階的なモダナイゼーションの検討

一度にすべてを刷新するのではなく、リスクを軽減しながら段階的にモダナイゼーションを進めることも検討すべきである。モダナイゼーションの実現に多くの費用や長い期間をかけてしまうと、開発そのもののリスクが大きくなり、実現性が下がってしまう。また、当初の計画時点から市場環境や技術のトレンドなどが変わり、開発が終了したタイミングで既にレガシーなシステムとして扱われるリスクもある。NTTデータグループでは、「モダナイズジャーニー」としてレガシーからマイクロサービスまでのシステムのステータスとルートを定義している。モダナイズジャーニーでは、必要な投資額と各ステータスで得られる効果に勘案し、段階的な開発ロードマップの策定に活用されることを想定している。

図3:モダナイズジャーニー

 

おわりに

レガシーシステム脱却を目的とせず、レガシーシステムとうまく付き合いながら必要な部分だけ変革していくことも必要になる。そのためには、現状のシステムの課題や今後求められるニーズを明確にし、地に足の着いた計画を策定していくことが重要であると考える。本稿が、皆様のレガシーモダナイゼーション成功の一助となれば幸甚である。

中村 公也

ITマネジメント担当

マネージャー

※担当領域および役職は、公開日現在の情報です。

  • facebook
  • はてなブックマーク
QUNIE