レガシーシステムを稼働させたまま機能を最新化できる ストラングラーフィグパターンとは？：メリット、デメリット、実装方法、実践例、代替手法が分かる

　パフォーマンスを向上させるため、システムに手を入れる方法は幾つかある。システムの利用を止め、一気に全てを作り直す方法もあれば、システムを利用しながら部分的に改修する方法もある。

　ストラングラーフィグパターンのように部分的に改修する方法には3つの利点がある。1つ目は、段階的に改修するのでシステム全体を止めなくてもよいこと。2つ目は、改修によって不具合が出ても、原因の特定が容易なこと。3つ目は、システムを使いながら改修ができることだ。

　ストラングラーフィグパターンの目的は、個々の機能を完全に停止させずに、少しずつリファクタリングし、最終的にレガシーシステムを廃止することだ。レガシーシステムを全面的に作り直す場合、移行プロセスは複雑なものになるが、ストラングラーフィグパターンであれば、管理しやすい順番で改修作業を進められる。

　別の視点では、開発者の負担軽減にも有効だ。一括置換をする場合、開発チームは（一時的ではあるものの）既存のシステムと新しいシステムの両方の面倒を見なければならない。ストラングラーフィグパターンなら、開発チームは一つのサービスや機能のリファクタリングに集中できる。

ストラングラーフィグパターンはいつ使う？

　ストラングラーフィグパターンは、システム移行において「どの機能をどのタイミングで新システムに置き換えるか」という段階的な計画（ロードマップ）が立てやすいという特徴がある。一方で、このパターンが全ての移行プロジェクトに適しているわけではない。

　一般的にストラングラーフィグパターンは、レガシーアプリケーションの更新、アーキテクチャの変更（モノリスからマイクロサービスへの移行）などで使われる。このパターンが適しているかどうかの判断には以下の点を考慮に入れる必要がある。

継続的な開発が困難

　レガシーシステムの開発を続けるのが現実的ではないケースだ。例えば、技術的負債がコードベースに蓄積しており、小さな変更でさえ多大なコストを伴う状態になっている。または、ある部分のコードを少し変更するだけで、別の部分に予期しない不具合が生じるような状況もストラングラーフィグパターンに適している。

予想外の成長への対応が必要

　システムの一部が機能要件を満たしていたとしても、増加する負荷にアーキテクチャが耐えられないことがある。需要が急増した際、業務を継続しながら迅速に移行を進める必要がある場合には、ストラングラーフィグパターンが有効だ。

並行開発の必要性が高い

　複数チームによる同時開発が必要なのに、システムに明確なインタフェースや分離構造が存在しないために、それができないことがある。このような状況では、段階的なリファクタリングによって構造を整備することが有効だ。

技術が陳腐化している

　企業として特定の技術を廃止したいと考えているが、それが業務の中核を担っており、何年もかけて全面的に書き直すことが現実的でない場合はストラングラーフィグパターンが有効だ。稼働中のシステムを維持しながら、段階的に新しい技術スタックへの移行が可能となる。

ストラングラーフィグパターンのメリットとデメリット

　ストラングラーフィグパターンを採用する際は、そのメリットとリスクを慎重に評価することが、移行プロセスの重要なステップとなる。

ストラングラーフィグパターンのメリット

業務の継続性

　システムの移行中も業務を継続させられるため、サービスを停止することなく、既存の機能を稼働させたまま刷新が可能だ。

ユーザー体験の維持

　サービス中断を最小限に抑えることで、これまでの操作性やインタフェースを保ちながら（ユーザー体験を維持しながら）、機能を更新できる。

リスクの管理

　新しい機能に不具合が発生しても、段階的な導入であれば変更部分を素早く元に戻すことが可能だ。これによって、重大な障害のリスクを低減できる。

初期コストの削減

　全面的な刷新では、機能ごとに旧システムと新システムの両方に対応するコードが必要になる。ストラングラーフィグパターンではその必要がないため、リグレッションテスト（既存機能の再テスト）の負荷も軽減できる。

長期的なコスト管理

　システム全体を停止せずに済むため、企業の予算や開発リソースに応じて、移行の優先順位や作業ペースを柔軟に調整できる。

市場投入までの時間短縮

　ストラングラーフィグパターンは機能単位で開発するため、システム全体を作り直す場合と比べて、新機能を市場に投入する時間が短くて済む。

ストラングラーフィグパターンのデメリット

技術的な負債

　移行対象のシステム（旧システム）の技術的負債が、移行中に適切に対処されなければ、新システムにもそのまま引き継がれる可能性がある。移行を急ぐあまりに実施した暫定的な対応が、新システム側に新たな技術的負債を積み重ねることにもなり得る。

データの整合性

　新旧のシステム間でデータを同期、変換する際、慎重に管理しなければ、データの重複や不整合、エラーを引き起こす恐れがある。特に旧システムと新システムが同時に稼働している期間は、整合性の維持が課題となる。

システムの複雑化

　ストラングラーフィグパターンは、旧システムと新システムが共存する構成となるため、一時的にアーキテクチャが複雑になる。これによって、パフォーマンスが低下したり、障害発生時のデバッグ作業が困難になったりする可能性がある。

レガシー技術に対するスキルの必要性

　旧システムを理解しており、機能の分析やデータの抽出ができる開発者が必要になる。それができなければ、コードの読み取りや変換作業に時間がかかり、移行作業がスムーズに進まなくなる可能性がある。

移行期間の長期化

　システムの段階的移行には時間がかかる。明確な廃止計画がないと、旧システムと新システムが長期間にわたって共存し、保守コストや運用コストが増大する結果となる。

ストラングラーフィグパターンの実装方法

　ストラングラーフィグパターンは、複雑に思えるかもしれないが、正しい手順に従えば比較的簡単に実装できる。このパターンを導入する際は、以下の図に示されるように段階的に進めるのが基本だ。

ファサードを通じてリクエストを振り分けながら、段階的にレガシーシステムから新システムへ移行することが可能

　ストラングラーフィグパターンの実装で重要な手順に「ファサードインタフェース」（Facade Interface）がある。これは、レガシーシステムと、そのレガシーシステムを呼び出す外部のアプリケーションやシステムがやりとりする仲介役として機能する。

　例えば、複数のサービスが単一のモジュール内で密結合している場合、外部システムは、各機能がどのコードブロックに結び付いているかを特定できない。このような構造では、レスポンスが遅くなるだけでなく、個別のサービス単位での正確なテストができなくなる。

　ファサードインタフェースは、外部のアプリケーションやシステムが特定の機能に関連するコードを識別できるようにし、同時に基盤となるレガシーコードを隠蔽（いんぺい）するのに役立つ。この問題に対応するため、ストラングラーフィグパターンは、モノリスから個別のサービスや機能を切り出す際に、それらを明示的に外部へ公開できるよう、ファサードインタフェースを構築する。

　開発者が新しいコードを書き、テストし、デプロイしていくことで、時間の経過とともに、ファサードインタフェースの背後にあるレガシーコードは徐々に小さくなる。

ストラングラーフィグパターンの実践例

例1：オブジェクト指向プログラミングの場合

　1つのクラスに数千行から数万行のコードが収容される場合がある。こうしたクラスは「ゴッドクラス」（god class）とも呼ばれる。こうしたゴッドクラスには関係のないメソッドも多数含まれているため、プロジェクトのアップデートではゴッドクラスの変更が最も面倒な作業になることが多い。どのメソッドも意図しない変数にアクセスしたり変更する可能性がある。つまり、ある箇所への変更が他の箇所に意図しない結果をもたらす可能性がある。

　このようなオブジェクト指向システムにストラングラーフィグパターンを適用するには、まず大きなクラスの中から関連する変数を特定し、それらをより小さなクラスに切り出す。この新しいクラスは、対象の変数をカプセル化し、定義されたインタフェースを通じてのみ変更を許すことで、無関係な影響を防ぐ役割を果たす。

　特定の機能に関係するコードを修正する際には、そのコードを専用の新しいクラスに移動させる。こうして、開発者がコードを変更、追加していくたびに、構造化された新しいコードユニットが増える。それに伴ってゴッドクラスは徐々に解体され、最終的には完全に除去できる可能性がある。

例2：データベースの場合

　エンタープライズ向けデータベースの多くは、トリガーに基づくメカニズムを採用しており、イベントに応じてコードを実行し、発生した変更を自動的に記録できるようになっている。これによって、発生するイベントを追跡、処理できる別のシステムを並行して運用できる。

　レガシーシステム側で何らかの変更が発生した際、それを新しいシステム（イベント追跡システム）が取得し、レポートを提供できるように構成する。この仕組みをベースに、トリガー処理やデータフローを段階的に新システム側へ移行すれば、旧データベースを完全に退役させることも可能だ。

ストラングラーフィグパターンの代替手法

　ストラングラーフィグパターンを本格的に採用する前に、代替手法についても検討し、それぞれのトレードオフを慎重に比較する必要がある。代表的な選択肢には、以下のようなものがある。

全面的なリライト

　費用がかかる上、場合によっては新機能のリリースが完全に停止するリスクもある。リソースや期間に大きな制約が発生しやすい手法だ。

ベンダーが提供する代替システムへの移行

　移行はスムーズかもしれないが、商用ライセンス費用、従業員へのトレーニングコスト、ベンダーロックイン（特定ベンダーに依存した状態）といった課題が発生する可能性がある。

レガシーシステムへの保守パッチの適用を継続する

　一時的な解決にはなるが、リソースを圧迫し、技術的負債をさらに増やす結果になりかねない。

　ストラングラーフィグパターンが最適だと判断した場合も、どこから実装を始めるかを決めるのは難しいことがある。シンプルなアプローチとしては、既に開発中の機能から着手することだ。手を加えているコードに新しい構造を導入すれば、移行を自然に進めやすい。

　ソフトウェアエンジニアリングにおける「ボーイスカウトルール」、つまり「触ったコードは、必ず少しでも良くしてから戻す」は、ストラングラーフィグの考え方に通じている。このアプローチによって、チームは開発速度を向上させ、リグレッションの問題を減らしながら、新機能の追加も継続的に実施できるようになる。