2025年の崖問題とリーン/アジャイルアプローチ

経済産業省の「D X レポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～」で指摘された問題です。DXレポートでは、既存システム（いわゆるレガシーシステム）が足かせとなり、 DXが実現できないのみならず、2025年以降、最大１２兆円／年（現在の約３倍）の経済損失が生じる可能性を指摘しています。

では具体的にレガシーシステムの何が問題なのかというと、DXレポートでは

１．データ活用ができない

２．市場の変化に応じて、ビジネスモデルを柔軟・迅速に変更できない

３．システムの維持管理費が高額化し、IT予算の9割以上に（技術的負債）

４．運用保守の担い手が不足し、セキュリティ事故や障害、データ消失、といったリスクの高まり

の4点が指摘されています。

もっともこれらの問題は今に始まった話ではなく、1990年代にダウンサイジングが流行ったときにも同じことが指摘され、多くのメインフレームがUNIXサーバやWindowsサーバに置き換わりましたが、当時の最新技術で作られたオープンシステムも今では立派なレガシーシステム（オープンレガシー）になっています。

ところで、この2025年問題、日本以外の国ではあまり聞きませんよね？

欧米では比較的短いサイクルでシステムの全面更改をする傾向にあり、その際過去のアプリケーション資産を流用することはせず、全てパッケージに置き換えるか、全てゼロベースで作り直す、という選択をするケースがほとんどだと思います。

そのため、何十年も前に作られて誰も触れないアプリケーションが今でも現役で動いて技術的負債になっているという事例は日本に比べて少ないのではと考えられます。

また技術者の高齢化も日本特有の問題です。政府統計データの「賃金構造基本統計調査」（H30 年度調査）によれば、従業員1000人以上の企業に所属するシステムエンジニアの平均年齢は男性39.5歳、女性34.1歳とのことですが、レガシーシステムの運用保守に携わっているエンジニアに限って言えばこれよりも平均年齢は高いでしょうから、2025年ごろにはエンジニアの高齢化により運用保守の担い手が確保できなくなることが予想されます。

さて、以前からこうした問題が指摘されていたにも関わらず、日本でレガシーシステム更改がなかなか進まない原因はいくつかありますが、そのうち最大の原因はレガシーシステム更改のROI（Return Of Investment)にあると考えられます。

新規にシステムを構築する場合は、これまでなかったビジネス価値を生むシステムを構築するので、比較的ROIは正当化し易いのですが、既存システム更改の場合、システムが提供するビジネス価値は（多少の向上は見込まれるにしろ）基本的にはあまり変わらないので、　ビジネス価値だけではシステム更改に伴う多額のIT投資の正当化は困難です。そのため、製品保守期限切れにより障害リスクやセキュリティリスクが高まることを理由にシステム更改を正当化することになるわけですが、経営者からしてみれば起こるか起こらないか分からない将来リスクのために、今多額の費用をかけるという意志決定は気の進まないものであり、高度にクリティカルなシステム以外の更改がなかなか進まない原因となっています。

DXレポートにより「2025年の崖問題」が多くの経営者の認知するところとなり、今後レガシーシステム更改が進むきっかけとなることは間違いありませんが、そのためにはレガシーシステムを維持し続けることによるリスクを定量化し、ROIを正当化するためのフレームワークが欠かせません。

次に考えられる原因はレガシーシステム更改の失敗リスクが非常に高いことが挙げられます。レガシーシステム更改プロジェクトが途中で頓挫した、あるいは何とか完成させたが、当初計画よりスケジュールは大幅に遅れ、更改費用が数倍にも膨れ上がった、等の事例は枚挙にいとまがありません。

ではなぜレガシーシステム更改プロジェクトは失敗するリスクが高いのでしょうか？

その原因は日本特有の「現行仕様踏襲」というシステム更改アプローチに依るところが大きいと考えられます。

欧米ではシステム更改の際、業務の仕方も新システムに合わせて大きく変更することが前提となることが多いので、このことが問題となるケースは比較的少ないですが、日本の場合は現行業務を変えないことが前提となることが圧倒的に多いので、これがシステム更改リスクを高める大きな原因の一つとなっています。

ほとんどのレガシーシステムでは、長年改修を重ねてきたシステムの全容が分かる仕様書などというものは存在しないか、存在したとしても改定を重ねてきた結果解読不能な状態にあることがほとんどです。そのため「新システムの仕様は現行システムの仕様を踏襲」と言われたITベンダーはソースコードやUIから現行システムの仕様を解析しようとするわけですが、解析ツール等で自動化できる範囲は限られており、分析に膨大な労力がかかる割にそこから現行システムの完全な仕様を導出することは困難を極めます。そしてここでの仕様の漏れや誤りがプロジェクト終盤のシステムテストで明らかになって大きなトラブルになります。

なお、「現行仕様踏襲」のために、言語コンバージョンツールを使ってJava等のオープン系言語に変換するアプローチが採用されるケースも良く見かけますが、このやり方では現行アプリケーションの冗長さや複雑さもそのまま移植されてしまいます。ハードやOS・ミドルウェア製品の保守期限切れには対応できるかもしれませんが、レガシー問題の根本的な解決手段とはなりえません。

では、レガシーシステム更改の失敗リスクを低減するにはどうしたらよいでしょうか？

一つは、「現行仕様踏襲」をやめ、従来の業務オペレーションの変更を厭わずに、業務とシステムを新たにデザインし直すことです。アメリカの調査会社スタンディッシュグループによる調査では、ソフトウェアの機能の内45%は「全く使われていない」という結果が出ていますが、長年改修が重ねられてきたレガシーシステムには（過去には使われていたかもしれませんが）現在は使われていない機能が多く含まれてます。

新たに業務とシステムをデザインし直すことで、使われない無駄な機能の作りこみを避け、新たに開発するシステムの規模を小さくシンプルにすることが可能となり、結果としてプロジェクト失敗リスク低減につながります。

もう一つのアイデアは、レガシーシステム更改にリーン/アジャイルのアプローチを取り入れることです。つまり、一度に全システムを更改する（ビッグバンアプローチ）のではなく、レガシーシステムからマイクロサービス化した機能を少しずつ切り出していき、並行稼働しつつ最終的にレガシーシステムを廃止する、というアプローチです。

レガシーシステム更改プロジェクトにリーン/アジャイルアプローチを採用するためには、まず既存のモノリシックなシステムをアジャイルチームが扱えるサイズのサービスに切り分ける必要があります。サービスの切り分け方には何通りかの考え方があって、対象システムのドメインナレッジが不可欠なこともあり、切り分けはなかなか難しいのですが、対象システムがいわゆるSOR（System Of Record）の場合はデータに着目して、データのエンティティとそれに紐づくビジネスロジックをサービスとして切り出す方法が適しているのではないかと思います。

なお、サービス分割の際は、サービスをまたがるトランザクションが発生しないよう気をつける必要があります（＝疎結合）。サービスをまたがるトランザクションが必要そうに見える場合は、非同期トランザクションにして結果整合性がとれれば良い設計に出来ないか検討し、どうしても同期トランザクションでの整合性が必要な場合はサービスを統合する必要があります。

またいきなり全体をサービス分割するのではなく、いくつかプロトタイプ的にサービスを切り出して実装してみることをお勧めします（リーンアプローチ）。これにより机上では分からなかった課題が明らかになり、その後のサービス分割・実装作業の効率と品質の向上が期待できます。

以上、2025年の崖問題として指摘されているレガシーシステムの更改について、そのリスクと対応のアイデアについて考察してみました。読者の皆様のレガシーシステム更改プロジェクトの企画計画にあたって一助となれば幸いです。

レガシーシステム更改には多額の費用とリスクが伴います。株式会社シーエーシーでは、日本で最初の独立系SIベンダーとしての長年の経験に基づき、レガシーシステム更改プロジェクトの企画計画から実行まで、幅広いご支援を提供しております。

既存システムの単なる焼き直しではなく、再レガシー化しにくく、DXにともなう変更要求に柔軟なシステムに生まれ変わらせたいとお考えの方は、ぜひご相談ください。