3.6 レガシーのモダナイゼーション

概要と動機

レガシーシステムは、世界を動かすシステムです。社会が依存する中核の銀行の元帳、税と給付のエンジン、航空管制と防衛のシステム、保険契約の管理、政府の登録簿は、しばしば何十年も古いものです。その多くはCOBOL(共通事務処理指向言語)やその他の古い技術で書かれ、今も重要なトランザクションの大半を処理しています。「レガシー」は侮辱ではありません。システムが生き延びるに足る価値があり、失敗が壊滅的なほど重要で、安全に変更するのが難しいほど古いということです。レガシーのモダナイゼーションとは、これらのシステムが提供する不可欠なサービスを壊さずに、改善し、移行し、置き換える規律です。

これは企業と政府に不釣り合いに多い問題であり、最大で最も公的なITの失敗が起こる場所です。世界の主要なトランザクションの大きな割合が、今もメインフレームのシステムに触れています。大きな機関の本番コードの大きな割合は、高齢化し縮小する専門家のプールによって保守される古い言語で書かれています。政府は最も重い負担を負います。何十年もかけて符号化された法定の義務、政権より長く続く調達と予算のサイクル、中断できない市民サービス。支配的なリスクは、これらのシステムが古いことではありません。多くは見事に動いています。リスクは、それを保守する知識が退職しつつあること、プラットフォームがますますコストがかかり制約されていること、そして「ただ書き直せばいい」という誘惑が、この分野の歴史で最も高価な失敗のいくつかにつながることです。

本章は、実際にうまくいく漸進的なモダナイゼーションのパターン(ストラングラーフィグと抽象化によるブランチ)、レガシーのリスクをどう評価し優先順位を付けるか、メインフレームとCOBOLの資産の管理、データ移行と並行稼働の規律、そして何よりも、大きな書き直しの誘惑にどう抵抗するかを扱います。中心的な信念は、成功するモダナイゼーションはほぼ常に、漸進的で、証拠に基づき、継続的に価値を届けるものだということです。それが、数年にわたる一括の切り替えであることは決してありません。

主要原則

レガシーとは、単に古いのではなく、価値があり基礎的だということ。 触れる前にシステムが何をするかを尊重してください。それは何十年もの苦労して得たビジネスルールを符号化しています。
漸進的は、ほぼ常に一括に勝る。 安定したインターフェースの背後で一片ずつ置き換え、継続的に価値を届け、リスクを小さく保ちます。
大きな書き直しは、既定の失敗モードである。 完全な書き直しは日常的に超過し、期待を下回り、中止されます。その衝動を深い疑いをもって扱います。
理解していないものはモダナイズできない。 置き換える前に、振る舞い(文書化されていないルールを含む)をリバースエンジニアリングし、文書化します。
データ移行はプロジェクトが死ぬ場所である。 データは誰もが予想するより古く、汚れ、絡み合っています。第一級の労力として計画します。
古いものと新しいものを並行して動かして信頼を築く。 並行稼働と比較は、切り替えの前に不一致を捉えます。
古さではなく、リスクと価値で優先順位を付ける。 単に最も古いものではなく、最もリスクが高く最も価値のあるものを最初にモダナイズします。
エンジンを変えている間、明かりをつけ続ける。 サービスは全体を通じて動き続けなければなりません。重要な市民や金融のシステムに許容できるダウンタイムはありません。

推奨事項

ストラングラーフィグパターンで漸進的にモダナイズする

ストラングラーフィグ(木の周りに育って次第にそれを置き換える蔓にちなんで名付けられた)は、安全なモダナイゼーションの主力です。レガシーシステムの前にルーティング層(APIゲートウェイ、ファサード、プロキシ)を置きます。それから機能ごとに、現代的なシステムで置き換えを築き、その一片のトラフィックをそこにリダイレクトし、残りはレガシーシステムに残します。時間とともに、新しいシステムは育ち、古いものは縮み、退役させられるようになります。これは継続的に価値を届け、各変更を小さく元に戻せるものに保ち、危険な切り替えを避け、どの時点でも止めたり優先順位を付け直したりできるようにします。一括の切り替えの正反対です。レガシーシステムは、その周りで置き換えている間も動き続け、その役目を果たし続けます。

内部の継ぎ目には、抽象化によるブランチを使う

システムの多くの部分が依存するコンポーネントを置き換える必要がある所では、抽象化によるブランチを使います。既存の実装の上に抽象化の層(インターフェース)を導入し、呼び出し元がその抽象化に依存するよう移行し、同じ抽象化の背後に新しい実装を築き、切り替え(しばしばフィーチャーフラグの背後で、段階的に)、最後に古い実装を取り除きます。これにより、長寿命のブランチなしに、開発のメインラインで大きなコンポーネントを漸進的に置き換えられ、システムを全体を通じてリリース可能に保てます。それはストラングラーフィグと自然に組み合わさります。ファサードが外部の継ぎ目を扱い、抽象化によるブランチが内部のものを扱います。

レガシーのリスクを意図して評価し、優先順位を付ける

モダナイズする前に、資産の冷静な一覧とリスク評価を築きます。各システムを、ビジネスの重要度、技術的リスク(陳腐化、サポートされないプラットフォーム、セキュリティの露出)、変更の頻度、そして決定的に、知識のリスク(まだ保守できる人が何人いて、退職にどれだけ近いか)で採点します。システムをリスク対価値のグリッドにプロットします。リスクが高く価値も高いものを優先してモダナイズします。安定していて、変更が少なく、よく理解されたシステムは、古くてもそのままにすることを検討してください。誰も変更する必要のない動くシステムは、緊急事態ではないからです。この評価は、「すべてが古くて怖い」を、擁護できる順序付けられたロードマップに変えます。

メインフレームとCOBOLの資産を、置き換えるだけでなく管理する

すべてのメインフレームやCOBOLのシステムが、すぐに置き換えられるべきでも、安全に置き換えられるわけでもありません。当面の優先事項はしばしば管理(スチュワードシップ)です。退職する前に知識を捉える。コードが符号化するビジネスルール(多くは文書化されておらず、代替不能)を文書化し、現在の振る舞いを固定して将来の変更を安全にする自動テストに投資し、保守担当者を採用して相互訓練し、中核がそのままの間も、周囲のデリバリーの実践(ソース管理、継続的インテグレーション(CI)、自動テスト)をモダナイズします。モダナイズする所では、最初の一歩として、現代的なAPIを通じてレガシーの機能を公開すること(カプセル化)を好みます。COBOLから現代的な言語への自動翻訳は、慎重に扱ってください。動くコードを生みますが、しばしば理解できないロジックを忠実に再現するからです。最も乏しい資源は、計算ではなく理解です。

データ移行と並行稼働を、プロジェクトの中核として扱う

ほとんどのモダナイゼーションの取り組みで、最も難しくリスクの高い部分はデータです。それは大量で、品質が低く一貫せず、何十年にもわたって積み重なった文書化されていない意味に満ちています。プロファイルして浄化し、古いスキーマから新しいスキーマへ明示的に対応づけ、何も失われたり変えられたりしていないことを証明できるよう、完全な照合(数、チェックサム、ビジネス上の合計)を伴う、繰り返し可能で自動化された移行を築きます。並行稼働で切り替えのリスクを下げます。古いシステムと新しいシステムを同じ入力で並べて動かし、新しいシステムが信頼の閾値まで古いものと一致するまで出力を比較します。それからようやく切り替え、元に戻す能力を保ちます。本当に重要なシステムでは、一度にではなく、スライスごとに移行して切り替えます。

大きな書き直しの誘惑を管理する

散らかった古いシステムを捨てて、ゼロからきれいな新しいものを作りたい本能は強く、大きく重要なシステムでは、ほぼ常に間違っています。完全な書き直しは、「醜い」コードに隠れた価値(エッジケース、規制のルール、実際のユーザーが依存するバグ互換の振る舞い)を過小評価し、予測よりはるかに長くかかり、最後まで価値を届けず、莫大な支出の後にしばしば中止されます。漸進的なモダナイゼーションを既定とします。書き直しは、プラットフォームが本当に持続不能で、漸進的な道が尽きた場合のために取っておきます。それでも、書き直しを、単一の一括のリリースではなく、ストラングラーパターンを通じて独立して届けられる部分に分解します。リーダーシップが全面的な書き直しを迫るとき、問いを主張してください。最初の三か月でどんな価値が出荷され、プログラムが途中で止められたら何が起こるか。

トレードオフ: 長所と短所

アプローチ	長所	短所
ストラングラーフィグ(漸進的)	継続的な価値、低リスク、元に戻せる、サービスを稼働させ続ける	全体のタイムラインが長い。二つのシステムを並行して動かさなければならない。統合のオーバーヘッド
一括の書き直し	まっさらな状態。新しいコードにレガシーの制約がない	非常に高い失敗率、最後まで価値がない、莫大なコスト、ビジネスルールの喪失
カプセル化(APIで包む)	速く低リスク。中核に触れずにアクセスをモダナイズする	中核はレガシーのまま。根底のリスクを解決せず先送りする
そのままにする(管理する)	プロジェクトのリスクなし。短期的に最も安い	知識とプラットフォームのリスクが積み上がり続ける。最終的に強いられる行動

根本的なトレードオフは、変革の速度と失敗のリスクであり、レガシーのモダナイゼーションは、その取引が最も偏った領域です。「速くきれいな」一括の書き直しは、繰り返し最も遅く最も高価な結果を生む蜃気楼です。中止されたプログラムと、まだモダナイズされていないシステム。漸進的なアプローチは、より遅く感じられ、二つのシステムを並行して動かすことを要しますが、全体を通じて価値を届け、リスクを小さく元に戻せるものに保ち、経験的に信頼できる道です。本物の判断は、安定したレガシーシステムをもう少し管理することと、今漸進的な置き換えを始めることの間にあります。古い技術への居心地の悪さではなく、リスクの軌跡、特に知識のリスクでその判断を導かせてください。

チームで議論すべき問い

レガシーシステムの前にルーティング層を置く場所がありますか。なければ、作るには何が必要ですか。 ストラングラーフィグは継ぎ目に依存します。一度に一つの機能を新しい実装にリダイレクトできる、APIゲートウェイ、ファサード、プロキシです。多くの古いシステムにはそのような継ぎ目がなく、最初のモダナイゼーションの増分は、しばしば単に傍受点を築くことで、その仕事は過小評価しやすいものです。現在の統合マップを持ち込み、一括の切り替えなしに、機能ごとにトラフィックを傍受できる場所がどこかを問ってください。どこにもなければ、内部の継ぎ目での抽象化によるブランチが、代わりの出発点かもしれません。ルーティング層がなければ、漸進的な道はなく、それがまさに、組織が通常失敗する書き直しへと押し戻される道です。
資産をリスク対価値のグリッドに実際にプロットしましたか。それとも、ロードマップは、どのシステムが最も古く感じられるかで駆動されていますか。本章は、高リスクで高価値のものを最初にモダナイズし、安定していて、変更が少なく、よく理解されたシステムは、たとえ古くても意図してそのままにするよう主張します。明示的なグリッドがなければ、注意は最も声の大きい不満や最も流行遅れの技術に流れ、本物の時限爆弾(退職間近の保守担当者が二人しかいない重要なシステム)が待たされます。各システムをビジネスの重要度、技術的リスク、変更の頻度、知識のリスクで採点し、右上の隅から順序付けてください。そのグリッドを共有の地図として会議に持ち込みます。知識のリスクに最も重い重みを与える価値があります。それは悪化するだけで、人々が去ったら買い戻せない唯一の入力だからです。
切り替えのとき、レコードが一つも失われたり変えられたりしていないことをどう証明し、その証拠を誰が承認しますか。 データ移行はこれらのプロジェクトが死ぬ場所であり、信頼は照合から来ます。古いものと新しいものの間で一致する行数、チェックサム、ビジネス上の管理合計、そして同じ入力で出力を比較する並行稼働が、高い閾値で一致するまで。給付や元帳のシステムでは、不一致は過少に支払われた市民や失われた1セントなので、証拠は、エンジニアだけでなく監査人を満足させなければなりません。どの合計を照合し、どの信頼の閾値が切り替えを引き起こし、古いものと新しいものをどれだけ並行して動かすかを、今決めてください。全体を通じてロールバックを利用可能にし、一度にではなくスライスごとに切り替えます。並行稼働中に見つかる不一致は、通常、保持しなければならない文書化されていないレガシーのルールなので、それぞれを単なる欠陥ではなく発見として扱ってください。
レガシーシステムのうち、どれを管理していて、どれを積極的に置き換えていて、どちらかを決めたのは誰ですか。 本章は、その場で安定させる価値のあるシステム(ルールの文書化、特性化テストの追加、保守担当者の相互訓練)と、漸進的に置き換える価値のあるシステムの間に意図した線を引き、両者は非常に異なる資金と人員配置を要求します。大きな組織にとって、危険はずれです。「今は管理する」とラベル付けされたシステムが、最後の保守担当者が退職し、選択が危機のもとで代わりに決められるまで、静かに「永遠に管理する」になります。相反する考慮は、一方に管理のコストとプラットフォームの陳腐化、もう一方に置き換えのリスクと混乱があり、知識のリスクは悪化するだけなので、天秤を傾けるべきです。リスク対価値のグリッド、各システムの保守担当者の人数と退職の見通し、管理するか置き換えるかの決定の明示的な所有者を持ち込んでください。企業や政府の資産では、各システムにレビューの周期と責任ある職員を名指ししてください。誰も見直さない分類は、誰も下していない決定だからです。
リーダーシップが全面的な書き直しを求めたとき、あなたの定まった答えは何で、漸進的な道が最初の三か月で何を出荷するかを示せますか。 一括の書き直しは既定の失敗モードですが、まっさらな状態は売りやすく、ストラングラーフィグは売りにくいので、資金を得続けます。大きなチームは、議論が最も上位の人ではなく証拠で勝たれるよう、リハーサルされた応答を必要とします。本物の緊張は、一部のプラットフォームは本当に持続不能で、書き直しが正当化されることなので、答えは全面的な拒否ではありえません。漸進的な継ぎ目がまだ存在するかを、古いプラットフォームを生かし続ける本当のコストと量らなければなりません。漸進的な最初の増分が届ける価値、同等の書き直しの過去の失敗率、提案された書き直しの、独立して出荷可能な部分への分解を持ち込んでください。中止された数年にわたるプログラムが、公衆の目の前で公的資金を燃やす政府では、どんな書き直しも早期に価値を届け、途中で止められても全損にならないようにするよう主張してください。
最古のコードに閉じ込められたビジネスルールを、それを理解する人々が去る前に、どう捉えますか。 レガシーシステムの価値の多くは、何十年ものエッジケース、規制、バグ互換の修正が積み重なった、文書化されていない振る舞いで、それは書かれた記録ではなく、縮小する退職間近の専門家のプールに住んでいます。大きな組織にとって、これは人々が去ったら買い戻せない唯一のリスクなので、より目に見えるプラットフォームの仕事より先に資金を出す価値があります。相反する引力は、知識の捕捉(ドキュメント、特性化テスト、リバースエンジニアリング、相互訓練)は何も出荷しないオーバーヘッドに感じられ、それがまさに先送りされる理由です。誰が重要な知識を持ち、退職にどれだけ近く、現在どんなテストカバレッジが現在の振る舞いを固定しているかの一覧を持ち込んでください。規制された公共の設定では、古いコードに符号化された法定のルールをコンプライアンスの資産として扱ってください。それを黙って失うことは、技術的負債ではなく、法的リスクです。

セクター別の視点

スタートアップ。 あなたのレガシーはメインフレームではなく、自分の急いだMVPです。今では収益を担い、誰もが触れるのを恐れるプロトタイプ。書き直してはいけません。最も怖いモジュールをきれいなインターフェースの背後に包み、その振る舞いを固定する特性化テストを加え、機能を漸進的に切り出します。各小さなリリースが価値を出荷し、リスクを縮めます。ゼロからの再構築のランウェイはないので、優雅さよりも選択肢の価値が重要です。

小規模事業者。 モダナイゼーションのチームはおらず予算も厳しいので、実用的な動きは通常、動いているシステムを動かし続けることです。それを理解している一人が知っていることを捉え、ソース管理にいくつかの自動テストとともに入れ、特注の再構築ではなく、ベンダーやパッケージ製品に頼ります。決定を買うか作るかとして枠づけ、機能が汎用品のときは買うことを好みます。限られた労力を、単に最も古く見えるものではなく、失敗すると事業が止まる唯一のシステムに使います。

大企業。 問題はポートフォリオの規模です。数十のシステム、多くのチーム、資産全体の知識のリスク。共有のリスク対価値の評価を実施し、漸進的なパターン(ストラングラーフィグと抽象化によるブランチ)を標準化し、データ移行と並行稼働を、皆が信頼する照合を伴う第一級の規律として扱います。モダナイゼーションを、英雄的なプロジェクトの寄せ集めではなく、リスクの軌跡に対する継続的なポートフォリオとして統治し、管理と知識の捕捉を明示的に予算化して、どの重要なシステムも、退職間近の単一の保守担当者に依存しないようにします。

政府。 何十年もかけて符号化された法定の義務、調達規則、中断できない市民サービスは、一括の置き換えを特に危険にします。スライスごとの切り替えを伴う漸進的なストラングラーフィグの移行を好み、照合と長い並行稼働を通じて、市民のレコードが一つも失われたり誤計算されたりしていないことを証明し、全体を通じてロールバックを利用可能に保ちます。調達では、不透明な翻訳ではなく、データの可搬性とビジネスルールの開示を求めるべきで、数年にわたるプログラムは、監査可能な価値を早期に届け、途中で止められても公衆の精査に耐えなければなりません。

事例

スタートアップ。 創業3年のスタートアップの最初のMVPは、それ自体が一種のレガシーになりました。今では本物の収益を扱い、皆が触れるのを恐れる、急いで作ったプロトタイプです。書き直す代わりに、チームは最悪のモジュールをきれいなインターフェースの背後に包み、現在の振る舞いを固定する特性化テストを加え、数か月かけて機能を一片ずつそこから移します。各小さなリリースが価値を出荷し、怖い部分を縮めるので、スタートアップは、負担できないゼロからの再構築に会社を賭けることなく、保守可能なシステムを得ます。

大企業。 大手保険会社は、信頼できるが変更が高価で、退職間近の少数のエンジニアが保守するメインフレームのCOBOLシステムで、契約管理を運用しています。書き直す代わりに、保険会社はメインフレームを現代的なAPIで包み、ストラングラーフィグを適用します。新しい見積もりと購入、セルフサービスの機能が現代的なプラットフォームで築かれてファサードを通じてルーティングされ、中核の契約レコードはメインフレームに残ります。並行して、チームはビジネスルールを文書化し、COBOLの周りに特性化テストを加えます。数年かけて、機能ごとにメインフレームから離れ、各リリースが価値を届け、残りの中核が、危機のもとではなく保険会社の条件で退役できるようになります。

政府。 社会保障の機関は、何百万人もの市民に支払い、中断も誤った支払いもできない、何十年も古い給付計算システムをモダナイズしなければなりません。同等の失敗したプログラムを研究した後、一括の置き換えを退けます。代わりに、データをプロファイルして浄化し、管理合計に対する完全な照合を伴う自動の移行を築き、新しい給付エンジンを何か月も古いものと並行して動かし、両方に同じ申請を与えてあらゆる計算を比較し、各不一致を調査します(しばしば、保持しなければならない文書化されていないレガシーのルールが見つかります)。新しいシステムが非常に高い信頼度で古いものと一致して初めて、給付の種類ごとに切り替え、全体を通じてロールバックを保ちます。ストラングラーのファサードにより、市民は移行を通じて一つの連続したサービスを目にします。

ビジネスケース: 動機、ROI、TCO

レガシーのモダナイゼーションには珍しいビジネスケースがあります。最大のコストはしばしば何もしないコストであり、最大のリスクはモダナイゼーションのプロジェクト自体だからです。モダナイズしないことの増え続けるコストは具体的です。陳腐化するプラットフォームでの保守とライセンスの上昇、ますます希少で高価になる専門家の労働力、新しい規制やサービスの需要に素早く応えられないこと、システムを理解する人が誰も残っていない壊滅的な失敗への露出の増加。それに対して、モダナイゼーションのコストは高く、一括でやれば本当に高い確率で失敗します。まさにそれが、漸進的なアプローチがROIにとって重要な理由です。それは、一つの大きな賭けを、それぞれが価値を返し、止められる一連の小さな賭けに変えます。

選択を言い換えて、リーダーシップに論拠を示してください。問いは「モダナイズするかしないか」ではありません。「今、漸進的にモダナイズするか、エスカレートする管理コストを払い、後に危機のもとで強いられる、よりリスクの高いモダナイゼーションに直面するか」です。現状のTCO(プラットフォームとライセンスのコスト、希少なスキルへの割増、回復不能な障害のリスク加重コスト)を定量化し、サービスを動かし続けながら増分ごとにリスクとコストを下げる段階的なプログラムと比べてください。決定的に、提案された書き直しは、早期に頻繁に価値を届けるよう構造化することを主張してください。三年間何も届けず、全損で中止されうるプログラムは、投資ではなく賭けです。ストラングラーのアプローチへの最も強いROIの論拠は、選択肢の価値です。価値が継続的に出荷され、組織はどの時点でも進路を調整できます。

アンチパターンと落とし穴

一括の書き直し。 最後まで価値を届けず、莫大なコストで頻繁に中止される、数年にわたる全か無かの置き換え。
理解せずに書き直す。 ビジネスルールが文書化されなかったコードを置き換え、実際のユーザーと法律が依存するエッジケースを黙って落とすこと。
データの過小評価。 データ移行を、プロジェクトで最も難しくリスクの高い部分であるのに、後回しとして扱うこと。
並行稼働の省略。 並行比較なしに新しいシステムへ切り替え、実際の人々に影響してから不一致を発見すること。
解決策としての自動翻訳。 COBOLを現代的な言語に機械翻訳して仕事が終わったと信じ、古いロジックをそのまま再現する、理解できないコードを生むこと。
リスクではなく古さによるモダナイゼーション。 高リスクで変更の多いシステムが待たされる間に、古いが安定したシステムに労力を使うこと。
知識の喪失。 ビジネスルールを捉え特性化テストを加える前に、最後の保守担当者を退職させること。
ロールバックがない。 新しいシステムが実際の負荷と実際のデータのもとで誤動作したとき、戻る道がないまま切り替えること。

成熟度モデル

レベル1: 開始。 レガシーシステムは恐れられ凍結され、変更は避けられます。一覧もリスク評価もありません。モダナイゼーションは、試みられるとしても、苛立ちに駆られた場当たり的な全か無かの書き直しです。知識は少数の退職間近の頭の中にあり、何も書き留められていません。
レベル2: 発展。 一部のチームは一覧とリスクのおおまかな感覚を持ち、いくつかのレガシーシステムはアクセスのためにAPIで包まれています。漸進的なパターンは知られていますが不均一に適用され、考え方はまだ一括の書き直しへと流れます。データ移行は試みられますが過小評価され、実践はチームごとに大きく異なります。
レベル3: 標準化。 システムは、文書化された組織全体の方法に従って、リスクと価値で優先順位付けされています。漸進的なパターン(ストラングラーフィグ、抽象化によるブランチ)は徹底される既定で、あらゆるモダナイゼーションは標準のプレイブックに従います。データ移行は、切り替えの前に並行稼働を伴う、計画され照合された取り組みで、知識の捕捉と特性化テストは任意ではなく必須の実践です。
レベル4: 管理。 モダナイゼーションがデータで測定され、制御されます。資産はベースラインを持ちます。システムごとの保守担当者の人数と退職の見通し、特性化テストのカバレッジ、移行の照合の合格率、並行稼働の不一致の数、増分ごとに出荷された価値が、目標に対して追跡されます。管理か置き換えかの決定と切り替えの継続・中止の判断はこの証拠に基づいて行われ、知識のリスクの閾値を超えそうなシステムは、危機を待たずに行動を引き起こします。
レベル5: オーケストレーション。 モダナイゼーションは継続的で、ビジネスとリスクの計画と統合され、適応的です。ポートフォリオは、リスクの軌跡(特に知識のリスク)の変化に応じて再均衡され、漸進的な置き換えは日常的で騒ぎが少なく、あらゆる増分は価値を届けて元に戻せ、組織は意図してペースを舵取りします。各移行からの教訓が共有のプレイブックにフィードバックされるので、資産全体が時間とともに改善します。

議論のためのアイデア

最も重要なレガシーシステムを、まだ保守できる人は何人いて、彼らは退職にどれだけ近いですか。
一括の書き直しに誘われるのはどこで、代わりに漸進的なアプローチは最初の三か月でどんな価値を出荷できますか。
最古のシステムのビジネスルールはどれだけよく文書化されていて、コードが置き換えられたらそれらはどうなりますか。
移行が必要なデータをプロファイルしましたか。そして実際にどれだけ汚れて絡み合っているかを知っていますか。
安全にそのままにしておけるのに、モダナイゼーションの労力を使っている、古いが安定したシステムはどれですか。
新しいシステムを古いものと並行して動かし、切り替える前に両者が一致することを証明できますか。

要点

レガシーとは価値があり基礎的だということです。変更する前に、システムを尊重し理解します。
ストラングラーフィグと抽象化によるブランチで漸進的にモダナイズし、継続的に価値を届け、あらゆる変更を小さく元に戻せるものに保ちます。
一括の書き直しを既定の失敗モードとして扱います。本当に持続不能なプラットフォームのために取っておき、それでも分解します。
古さではなく、リスクと価値(特に知識のリスク)で優先順位を付けます。一部の古いシステムは、置き換えるより管理するのが最良です。
データ移行と並行稼働が取り組みの核心です。プロファイルし、照合し、並行して動かし、ロールバックを保ちます。
最も強いビジネスケースは選択肢の価値です。漸進的なモダナイゼーションは、一つの大きなリスクの高い賭けを、価値を返す多くの小さな賭けに変えます。

参考文献とさらなる読み物

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, “StranglerFigApplication” and “BranchByAbstraction”
Sam Newman, Monolith to Microservices
Nicholas Carr / industry studies on mainframe and COBOL dependency (context on the scale of legacy estates)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (anti-corruption layer)
Gregor Hohpe, Enterprise Integration Patterns and The Software Architect Elevator
Standish Group CHAOS Report (evidence on large project and rewrite failure rates)