レガシーシステムの近代化アプローチ：リフトアンドシフトからストラングルフィグまで

レガシーシステムを運用するあらゆる組織は、同じ根本的なジレンマに直面している。これらのシステムは、放棄するにはあまりにも価値が高く、現状維持するには費用がかかりすぎ、一括して置き換えるにはリスクが高すぎる。COBOLメインフレームは、世界中のATM取引の95%を処理している。米国連邦政府のIT予算の80%は、何年も前に近代化されるべきだったシステムの維持に費やされている。レガシーシステムは、失敗しているのではなく、成功しているのだ。まさにそれが、変更を非常に困難にしている理由なのである。

何もしないことの代償は、年々増大します。近代化を先延ばしにするほど、技術的負債は増え続けます。パッチが適用されなくなったコードベースには、セキュリティ上の脆弱性が蓄積されます。レガシーアーキテクチャとクラウドネイティブパターンとのギャップが広がるにつれ、最新システムとの統合は困難になります。そして、レガシー言語を開発した開発者が退職するにつれ、それらの言語を理解できる開発者の数は減少していきます。近代化に成功する組織は、プレッシャーが耐え難いほどになるまで待つ組織ではありません。計画を綿密に立て、各システムに最適なアプローチを選択し、プログラム全体を単一の大規模な移行に賭けるのではなく、段階的に実行していく組織です。

レガシーシステムの近代化とは？

レガシーシステムの近代化とは、多くの場合、モノリシックで保守が困難、かつ統合が難しい旧式のソフトウェアシステムを、最新のアジャイルでスケーラブルなアーキテクチャへと変革するプロセスです。必ずしもシステムを置き換える必要はありません。近代化には、既存コードを最小限の変更でクラウドインフラストラクチャに移行することから、段階的なリファクタリング、そして最新の代替システムによる完全な再設計や置き換えまで、幅広いアプローチが含まれます。

単純な保守との違い：保守はシステムを現状のまま稼働させ続けることを指します。近代化は、システムの基本的な機能、アーキテクチャ、または動作環境を変更することで、耐用年数を延ばしたり、運用コストを削減したり、最新システムとの統合を可能にしたり、AIワークロードを含む将来の機能開発に向けて組織を準備したりすることを指します。

レガシーシステムはいつまでも待てない理由

複数の要因が重なり、2026年の支払猶予コストは3年前よりも高くなっている。

AIへの対応準備。生成型AIワークロードは、パイロット導入後わずか数週間で、企業データ資産のあらゆる弱点、断片化されたソース、一貫性のないセマンティクス、管理されていないアクセスなどを露呈させます。組織は、サイロ化され、文書化されていないレガシーシステム上で、有意義なAIワークフローを実行することはできません。近代化は、AI時代の能力を実現するための前提条件です。

人材不足。COBOL、PL/I、そして15年前のJavaの開発者を見つけるのは、本当に難しくなってきている。COBOL開発者の平均年齢は現在50代半ばだ。近代化が遅れるたびに、組織の知識がそれを保持している人々とともに引退する前に、知識を継承できる機会が狭まっていく。

セキュリティリスク。ベンダーからのセキュリティパッチが提供されなくなった旧式システムでは、未対応のCVE（共通脆弱性識別子）が蓄積されます。システムがこの状態で稼働する期間が長くなるほど、既知の脆弱性のある領域は拡大します。

統合の複雑さ。最新のAPI駆動型アーキテクチャ、マイクロサービス、クラウドネイティブプラットフォームは、従来のモノリシックなシステムではネイティブにサポートされていない接続パターンを前提としています。新たな統合回避策を講じるたびに技術的負債が増大し、最終的な近代化がより困難になります。

7つのR：近代化決定のためのコアフレームワーク

ガートナーのオリジナルの5つのRを基盤とし、業界の実践を通じて拡張された7つのRフレームワークは、組織が自社のアプリケーション群に対してどのような対応を取るべきかを体系的に決定するための方法を提供する。重要な原則は、すべてのシステムに適した単一のアプローチは存在しないということである。ポートフォリオレベルのモダナイゼーションプログラムでは、システムの複雑さ、ビジネス上の重要度、戦略的価値に基づいて、システムごとに異なる戦略を適用する。

Strategy	その意味	いつ使用するか	典型的なタイムライン	リスクレベル
引退	廃止、システムはもはや不要です	冗長なシステム、未使用のシステム、または完全に廃止されたシステム	即時	ロー
保持する	現状維持、最小限の変更にとどめる	システムは機能しており、近代化のコストは利益を上回る。	継続	ロー
再ホスト	コード変更なしでクラウドへ移行	重要度の低いワークロード、短期的な成果、インフラコストの削減	1〜3月	ロー
リプラットフォーム	対象を絞ったプラットフォームの変更（例：マネージドデータベース）に合わせて移行する	適度な結合、特定の性能またはコストの最適化が必要	2〜6月	技法
リファクタリング	外部動作を変更せずにコードを再構築する	技術的負債の削減、保守性の向上、テストカバレッジ	3〜12月	技法
再設計	クラウドネイティブ、マイクロサービス、または新しいアーキテクチャに対応した再設計	大幅な拡張性要件、戦略的なプラットフォーム変更	12〜24月	ハイ
交換する	カスタムシステムを廃止し、SaaSまたは最新の代替システムを採用する	既存製品でより適切に提供される汎用的な機能	6〜18月	高いメディア

あらゆる近代化プログラムにおいて最も重要な決定は、すべてに同じ戦略を適用するのではなく、このフレームワークを厳密に適用することです。すべてにリフト＆シフトを適用する組織は、データセンターのコストよりも高いクラウド料金を支払うことになり、その費用に見合う柔軟性も得られません。すべてに再設計を適用する組織は、価値の提供が遅すぎてステークホルダーの支持を維持できない、複数年にわたるプログラムに陥ることになります。

8つの近代化アプローチを詳細に解説

1. リホスティング（リフトアンドシフト）

リホスティングとは、アプリケーションコードを変更することなく、アプリケーションをクラウドまたは最新のインフラストラクチャ環境に移行することです。アプリケーションは異なるプラットフォーム上で動作しますが、動作は以前と全く同じです。クラウドへの移行において、最も迅速でリスクが低く、変革も最小限に抑えられる方法です。

最適な用途：インフラコストの削減、データセンターの統合、または将来の近代化に向けた準備が主な目的である、重要度の低いアプリケーション。リホスティングは多くの場合、最初の段階として使用され、システムをクラウドインフラストラクチャに移行した後、段階的にリファクタリングを行います。

解決できない点：技術的負債、保守性の問題、統合の複雑さ、アーキテクチャ上の制約。システムはクラウド上で稼働しますが、アーキテクチャ自体は変更されません。オンプレミス環境で保守コストが高かったモノリシックなシステムは、クラウド移行後も保守コストが依然として高いままです。

2.プラットフォームの再構築

リプラットフォームとは、アプリケーションアーキテクチャを再構築することなく、クラウドサービスを活用するためにプラットフォームまたはランタイムに的を絞った調整を行うものです。自己管理型データベースからクラウド管理型データベースサービスへの移行、あるいは自己管理型アプリケーションサーバーからマネージドコンテナプラットフォームへの移行は、典型的なリプラットフォームの例です。

最適な用途：特定のコンポーネントに明確なクラウドネイティブな代替手段があり、運用上のオーバーヘッドを削減できるアプリケーション、および全面的な再設計に伴うコストとリスクがビジネス上のメリットに見合わないアプリケーション。

3. リファクタリング

リファクタリングとは、既存のコードを再構築して、外部の動作を変えることなく内部品質を向上させる手法です。技術的負債の解消、テスト容易性の向上、複雑性の軽減、コードの理解と拡張性の向上に貢献します。プラットフォームの移行とは異なり、システムはリファクタリング前後で同じ環境で動作します。

リファクタリングが最も適切なアプローチとなるのは、システムのコア機能が健全で依然として必要とされるものの、内部構造が複雑で変更に時間がかかりリスクも伴う場合です。数十年にわたって蓄積された条件ロジックを持つCOBOLプログラムは、重要な業務機能を正しく実行しているものの、変更を加える前に何日もかけて綿密な分析を行う必要があるため、リファクタリングの候補となります。

4. 再構築

アーキテクチャの再構築とは、アプリケーションの基本的な構造を再設計し、モノリシックなシステムをマイクロサービスに分解し、同期通信からイベント駆動型通信に移行し、CQRSやイベントソーシングパターンを実装することです。適切に実行すれば最も労力とリターンが得られる戦略ですが、不適切に実行すれば最もリスクの高い戦略となります。

最も注意すべき失敗パターンは「分散型モノリス・アンチパターン」です。これは、新しいサービスを実装する際にデータ層の分離を怠り、マイクロサービスの運用上の複雑さとモノリスの密結合を併せ持つ状態を生み出してしまうパターンです。このパターンは、サービスを抽出する前にデータ境界を明確に定義することで機能します。

最適な用途：既存の構造では拡張性、回復力、またはアーキテクチャの柔軟性に関する要件を満たすことができないシステム、および組織が分散システムを運用するためのエンジニアリング成熟度を備えている場合。

5. 絞め殺しイチジク模様

絞め殺しイチジクパターンとは、既存システムの機能を新しいアプリケーションやサービスで段階的に置き換えていき、最終的に新しいシステムが既存システムの古い部分や重要な部分をすべて置き換えるという、近代化のアプローチです。

既存システムを一度に置き換えるのではなく、新しい機能は既存システムと並行して構築され、最新のコンポーネントが引き継ぐにつれて徐々に置き換えられていきます。プロキシまたはファサード層がリクエストをルーティングし、最初はすべてを既存システムに送信しますが、検証が進むにつれて新しいコンポーネントへのルーティングを徐々に増やしていきます。既存システムは、安全に廃止できるまで段階的に「締め付けられ」ます。

最もリスクの高い方法は、ビッグバン方式による移行です。システムを個別に構築し、その後一気に切り替える方法は、企業規模では高い失敗率が報告されています。

ミッションクリティカルなシステムにおいて、ストランギュラーフィグが標準的な推奨手法となっている理由：レガシーシステムの近代化における最大の失敗要因である、一斉切り替えを排除できるからです。新しいコンポーネントは、次のコンポーネントが取り込まれる前に、本番環境で検証されます。レガシーシステムは稼働し続けるため、ロールバックは常に可能です。ビジネス継続性は、移行プロセス全体を通して維持されます。

実例：金融機関が基幹バンキングシステムを刷新する際、まず口座照会機能を新しいサービスとして抽出します。新しいサービスは照会トラフィックを処理し、既存システムはそれ以外のすべての処理を担当します。サービスが安定したら、次の機能である取引開始機能を抽出します。このプロセスは、既存基幹システムがダウンタイムゼロで、各段階で継続的な検証を行いながら完全に廃止されるまで続きます。

6. APIラッパー（カプセル化）

APIラッパーは、既存システムの内部コードを変更することなく、その周囲に最新のAPIレイヤーを構築します。外部の利用者は最新のAPIとやり取りし、APIはリクエストを既存システムのネイティブインターフェースに変換し、レスポンスを最新のフォーマットに変換します。既存システムは、クリーンなインターフェースの背後に隠された内部実装の詳細となります。

最適な用途：規制要件、コスト、または複雑さのために永続的に運用する必要があるが、最新の統合パターンに参加する必要があるシステム。APIラッピングは、多くの組織がCOBOLコードに手を加えることなく、COBOLプログラムを最新のWebアプリケーションやモバイルアプリケーションから利用できるようにするために用いる方法です。

制限事項：基盤となるシステムの制限事項（パフォーマンス、拡張性、保守性など）は考慮されていません。APIラッパーは統合性を向上させますが、ラッパーの対象となるシステム自体を改善するものではありません。

7. ゼロからの再構築

再構築とは、既存の実装を破棄し、最新のアーキテクチャ、言語、プラットフォームをターゲットとして、ゼロから新しいシステムを構築することです。既存システムが経済的に修復不可能なほど老朽化しており、かつビジネス要件が十分に理解されているため、自信を持って代替システムを特定できる場合に適しています。

リスク：重要なシステムの大規模な再構築を試みた組織は、既存システムに文書化されていない業務ロジックが含まれており、新しいシステムではそれを再現できなかったという問題に直面した。2018年の英国TSB銀行のIT移行では、190万人の顧客が数週間にわたってアカウントにアクセスできなくなった。FBIの仮想事件ファイルプロジェクトは、1億7000万ドルの開発費を投じた後、中止された。クイーンズランド州保健省の給与システム置き換えでは、3万5000人の病院職員が数か月にわたって給与の過少払いまたは過大払いとなった。いずれの場合も、既存システムの複雑さ、組み込まれた業務ルール、エッジケース、明示的に指定されていなかった条件下での運用挙動は、プロジェクト開始前に置き換えチームが理解していた範囲を超えていた。

8. AIを活用した近代化

AIを活用したモダナイゼーションは、大規模な言語モデルと専用のAIツールを使用して、レガシーシステムのモダナイゼーションにおいて最も労力を要する段階、すなわちコード理解、ドキュメント生成、コード変換、テスト生成を加速します。

COBOLからJavaへの変換ツールは、両言語に合わせて最適化されたLLM（言語レベルモデル）を使用してCOBOLプログラムの初期翻訳を作成し、その後、人間のエンジニアがそれをレビューして改良します。翻訳によって機械的な変換作業の大部分は削減されますが、翻訳されたコードが何をするべきかを人間が理解する必要性はなくなるわけではありません。

自動ドキュメント生成機能は、既存コードを分析し、各プログラムの動作、実装するビジネスルール、読み書きするデータ、分岐条件などを構造化したドキュメントとして生成します。このドキュメントは、人間のエンジニアが翻訳されたコードを検証し、COBOLのエキスパートが退職した後も組織が知識を保持するために不可欠です。

テスト生成では、AIを使用して既存プログラムの入出力動作の分析に基づき単体テストを作成し、元の開発時には作成されなかったテストカバレッジを確保します。これは、リファクタリングを安全に実行するために必要なものです。

AIを活用した近代化における重大な限界：AIツールはコードの変換を加速させるが、コードが実装するビジネスロジックを理解する必要性をなくすわけではない。翻訳自体は正しくても、ビジネスルールが誤解されていれば、正しく翻訳されたプログラムも失敗に終わる。AIツールは機械的な作業のコストを削減するが、理解作業のコストを削減するわけではない。

適切なアプローチの選択：意思決定フレームワーク

あらゆるシステムにとって最適な近代化アプローチは、ビジネス上の重要性、技術的な複雑さ、戦略的価値、そして利用可能な予算と期間という4つの要素を総合的に評価することによって決まります。

システムプロファイル	推奨されるアプローチ
ビジネス上の重要度が低く、複雑性も低い。	引退または再ホスト
ビジネス上の重要性が高く、複雑性が低く、インフラコストの要因となっている。	リホストまたはリプラットフォーム
高い重要度、中程度の複雑性、技術的負債が主な問題	段階的にリファクタリング
高い重要度、高い複雑性、ミッションクリティカル、ダウンタイムゼロの要件	絞め殺しのイチジクの模様
システムが非推奨プラットフォームに密接に結合している	プラットフォームの再構築またはアーキテクチャの再設計
SaaSとして利用可能な汎用機能	交換する
経済的な修復を超えて、十分に理解された要件	（細心の注意を払って）再建する
大規模なCOBOLまたはレガシー言語ポートフォリオ	AIによる翻訳＋人間による検証

最もよくある間違いは、関係者への説明が簡単だからといって、ポートフォリオ内のすべてのシステムに同じアプローチを適用することです。システムの特性に関係なくすべてをプラットフォーム変更する近代化プログラムは、適切な結果（一部のシステムの場合）から、不必要なコスト（廃止すべきシステムの場合）、危険なほどの過度の単純化（実際には再設計が必要だったシステムの場合）まで、さまざまな結果をもたらします。

既存システムの近代化における課題：プログラムを頓挫させる要因とは？

近代化プログラムが失敗する理由を理解することは、利用可能なアプローチを理解することと同じくらい重要です。失敗の理由は一貫しています。

文書化されていないビジネスロジック。レガシーシステムには、コードの動作以外にはどこにも存在しないビジネスルールが含まれています。30年以上にわたって12人の開発者によって修正されてきたCOBOLプログラムには、文書化されず、現存するチームメンバーの誰も完全に理解していない決定事項が組み込まれています。システムを変更する前にこのロジックを抽出して文書化しないモダナイゼーションアプローチは、ビジネス上の影響が発生したときに初めて明らかになる、旧システムとは異なる動作をする新システムを生み出すリスクがあります。

一括移行の試み。近代化において最も深刻な失敗を犯す組織は、特定の日付にシステム全体を一度に切り替えようとする組織です。TSB銀行、FBI VCF、クイーンズランド州保健局など、よく知られている大規模な近代化の失敗事例はすべて、このパターンを共有しています。段階的な近代化と各段階での継続的な検証こそが、成功するアプローチです。

実行段階におけるスコープの拡大と発見。近代化チームは、計画段階では見えなかった複雑さを発見する。境界が限定されたアプリケーションに見えたシステムが、文書化されていないファイルインターフェースを介して他の20ものシステムとデータを共有していることが判明する。単純に見えた機能が、確立に3ヶ月もの規制交渉を要し、どこにも文書化されていないビジネスルールを実装していることが判明する。解決策は、構造分析なしに計画を立てるのではなく、計画前に構造分析を行うことである。

知識集中リスク。既存システムを最もよく理解している人は、往々にして定年退職が近い人たちである。彼らが知識の継承と文書化が行われる前に退職してしまうと、近代化チームはシステムの機能について不完全な理解のまま作業を進めることになる。

間違ったものを測定している。モダナイゼーションの成功を、ビジネス成果、コスト削減、サービスの信頼性、機能実装までの時間ではなく、コード移行率やスケジュール遵守率で測定するチームは、結果よりも活動を最適化している。

あらゆるアプローチ決定に先立って行われるべき評価

組織が近代化のアプローチを選択する前に最も重要なことは、現状のシステムを理解することです。ドキュメントのレビューと開発者へのインタビューからなる評価は、2つの理由から不十分です。1つは、ドキュメントが不完全で古くなっていること、もう1つは、開発者の知識が分散していて一貫性がなく、しかも多くの場合、連絡が取れない人や定年退職間近の人に集中していることです。

構造評価では、対象となるすべてのアプリケーションの実際のソースコードを解析し、コードが実際に行っていることから依存関係モデルを構築することで、その後のすべての意思決定の根拠となる証拠が得られます。

プログラム一覧。実際に存在するプログラムの数（ドキュメントに記載されていないものも含む）。大規模なレガシー環境では、実際のプログラム数はドキュメントに記載されている数を20～30%上回るのが一般的です。

依存関係マッピング。どのプログラムがどのプログラムを呼び出すか、どのプログラムがファイルやデータベースを介してデータを共有するか、どのJCLジョブがどのプログラムをどの順序で呼び出すか。依存関係構造によって移行の順序が決まり、多くのコンポーネントが依存する高ファンインコンポーネントは最後に移行されます。

デッドコードの特定。本番環境で実行時に呼び出されることのないプログラムは、モダナイゼーションの対象から完全に除外できます。一般的なレガシーシステムでは、デッドコードは全体の10～25%を占めており、評価段階で大幅な対象範囲の削減が可能です。

複雑性の分類。循環的複雑度が最も高いプログラム、コピーブックへの依存関係が最も多いプログラム、呼び出し元が最も多いプログラム、データベースとのやり取りが最も多いプログラムはどれか。これらは最も多くの労力とリスクを伴うため、チームがより複雑でないコンポーネントで経験を積んだ後、最後に着手すべきである。

ビジネスロジックの抽出。各プログラムがどのような意思決定を行い、どのような条件で分岐し、どのような計算を実行するのか。このドキュメントは、近代化されたシステムを検証するための仕様書となる。

認定条件 SMART TS XL レガシーシステムの近代化をサポート

上述の構造評価はまさに SMART TS XL 自動化します。すべてのCOBOLプログラム、JCLジョブストリーム、コピーブック、PL/Iモジュール、RPGプログラム、SQLスキーマ、および関連コンポーネントを同時に解析することで、完全な依存関係モデルを構築し、近代化計画を仮定に基づくものではなく、証拠に基づくものにします。

レガシーシステムの近代化分析では、ドキュメントに記載されていないプログラムも含め、すべてのプログラムインベントリが作成され、各コンポーネントの予備的な複雑度スコアが算出されます。アプリケーション依存関係マッピングでは、言語間の依存関係グラフが構築され、移行の順序が決定されます。つまり、依存関係のないコンポーネントは早期に近代化でき、依存するコンポーネントの準備が整うまで待つ必要があるコンポーネントが特定されます。

影響分析機能により、提案されたすべての変更は実行前にリスクが認識されます。例えば、チームが300のプログラムで使用されているCOBOLコピーブックの最新化を提案した場合、影響分析機能はそれら300のプログラムすべてを列挙し、検証作業の範囲を定め、変更が行われる前に最もリスクの高い依存関係を明らかにします。

静的コード分析機能は、本番実行パスからの参照がないデッドコード、プログラム、および段落を特定し、変換作業を開始する前にモダナイゼーションの対象から除外することを可能にします。クラウドへの移行を検討している組織にとって、デッドコードを移行しないことは、評価フェーズで達成できる最も直接的なコスト削減策の一つです。

エンタープライズ検索機能により、構造モデルを複数年にわたる近代化プログラム全体を通してクエリ可能にします。特定のデータセットから読み込むすべてのプログラム、特定のフィールドを定義するすべてのコピーブック、特定のプログラムを呼び出すすべてのJCLジョブを、あらゆる言語の組み合わせで記述された数百万行のコードの中から、数秒で見つけることができます。

SMART TS XLさん コードの視覚化 依存関係図とプログラムフローチャートを作成することで、文書化されていないシステム構造を、COBOLを見たことがないエンジニアを含む、近代化チーム全体にとって理解しやすいものにします。これにより、置き換えようとしているプログラムが実際に何をしているのかを理解することができます。

段階的近代化：あらゆる成功プログラムの根底にある原則

成功した近代化プログラムと失敗した近代化プログラムの両方において、最も一貫して見られるのは、漸進主義の役割です。ベストプラクティス：漸進的な近代化では、ストランギュラーパターンまたはコンポーザブルロードマップを使用することで、ワークロードをドメインまたは機能ごとに段階的に移行し、リスクを軽減します。

漸進主義は臆病さを意味するものではありません。それは、複雑な既存システムの理解は近代化プロセス全体を通して深まっていくという認識であり、その理解の深まりを各段階で取り入れるように構成されたプログラムは、完全な理解に先立つ計画段階にすべての意思決定を集中させるプログラムよりも、より良い意思決定を可能にするという認識です。

予測された投資対効果（ROI）を実現する近代化プログラムは、プログラム全体ではなく、各波で検証済みの本番環境対応コンポーネントを提供する段階的なプロセスで成功を定義するものです。プログラム全体における成功の定義は、最終的な切り替え時のみに限定されます。各段階のプロセスは組織の信頼を築き、統合における複雑な問題を障害となる前に明らかにし、選択したアプローチが組織のシステムと制約という特定の状況下で有効であることを実証します。