レガシーシステムのモダナイゼーション・プロジェクトは、決まって同じ魅力的な発想から始まります——機能開発を凍結し、今度こそきちんとシステムを書き直し、完成したら一気に切り替える、というものです。しかし、この種のプロジェクトのほとんどは、スケジュールを大幅に超過するか、リリース前に中止になるか、あるいはリリースの時点ですでに時代遅れになっている書き直し版を届けることになります。代替策である漸進的なモダナイゼーションは、計画段階では地味に見えますが、実際にリリースされる可能性ははるかに高くなります。
なぜビッグバン型の書き直しは失敗するのか
レガシーシステムには、誰も文書化していないエッジケース、ビジネスルール、そして静かな修正の積み重ねが何年分も刻み込まれています。書き直しは、多くの場合、元のコンテキストなしにそれらすべてをゼロから再発見しなければならず、その一方でビジネス自体もその下で変化し続けます。新システムが18か月前の旧システムの要件に対して機能的に追いついた頃には、旧システムはすでに先へ進んでおり、ビジネス自体もまた先へ進んでいるのです。
ストラングラーフィグ・パターン
システム全体を一度に置き換えるのではなく、一度に一つの機能単位のトラフィックだけを新しい実装にルーティングし、レガシーシステムはそれ以外のすべてを引き続き処理します。時間が経つにつれて、新システムは旧システムを取り囲むように成長していき、やがてレガシーコードに依存するものが何もなくなった段階で、安全に廃止できるようになります——これは、ストラングラーフィグ（絞め殺しの木）が宿主となる木を取り囲むように成長していく様子と同じです。各ステップは、独立してテスト・リリース・ロールバックできる程度に十分小さく保ちます。
「簡単さ」ではなく「リスクと価値」で順序を決める
勢いをつけるために、まず一番簡単なモジュールから着手したくなるものです。しかし通常は、たとえそれが最も難しい部分であっても、レガシーシステムが最も痛みを引き起こしている場所——最も頻繁に壊れるモジュール、あるいは最も多くのロードマップ項目をブロックしているモジュール——から順序立てるほうが良い結果につながります。そここそが、モダナイゼーションが実際に予算に見合う成果を生み出す場所であり、ステークホルダーがプロジェクトを支持し続けられるだけの十分早い段階で価値を実感できる場所です。
ダウンタイムゼロの切り替えは、願いではなく実践である
各移行ステップは、トラフィックを段階的にルーティングし、問題があれば即座にロールバックできる仕組みの背後でリリースするべきです——フィーチャーフラグ、カナリアリリース、あるいは新旧の実装間でトラフィックの割合を切り替えられるプロキシ層などです。これに加えて、完全な切り替えの前に新旧間で徹底したパリティテストを行えば、ダウンタイムは「起きないことを願うもの」ではなく「計画的に排除するもの」になります。
モダナイゼーションの間もビジネスは前進し続ける
漸進的なモダナイゼーションの最大の実践的な利点は、機能開発の凍結を必要としないことです。システムのうち一部分だけが一度に変化するため、残りのチームは並行してプロダクト開発を進め続けることができます。そしてこれこそが、プロジェクトを完遂できるだけの期間、資金的な支持を得続けられる理由でもあります。
技術的負債はビッグバン的に積み上がったわけではなく、ビッグバン的に返済する必要があることもめったにありません。レガシーシステムの廃止に成功するチームとは、モダナイゼーションを一度限りの英雄的プロジェクトとしてではなく、継続的なエンジニアリングの規律として扱ってきたチームなのです。