Strangler Fig Applicationについて理解する

Strangler Fig Applicationについて理解する
ソフトウェアアーキテクチャレガシーモダナイゼーションシステム移行Strangler Fig
2026年08月22日読了目安 約6分

古いシステムを新しいシステムへ置き換えたいとき、すべてを一括で作り直して置き換える方法を思いつくことがあります。

これを一括で行う方法は、個人の小規模なプロジェクトや、まだ利用者がいないシステムでは有効な場合もあります。 しかし、規模が大きく、現在も利用されているシステムは簡単には止められません。 一度に切り替える変更範囲が広いほど、失敗したときの影響も大きくなります。

このような一括置換を避け、既存システムを動かしながら段階的に移行する考え方の1つに、Strangler Fig Application（ストラングラー・フィグ・アプリケーション）というものがあります。

Strangler Fig Applicationが扱うのは、移行後のシステム構成そのものではなく、稼働中のシステムが担う責務を、どのように新しいシステムへ移していくかです。

Strangler Fig Applicationとは

Strangler Fig Applicationは、稼働中の既存システムが担う機能や振る舞いを小さな単位で新しいシステムへ移し、旧システムの役割を徐々に減らしていく、レガシーモダナイゼーションの漸進的な移行アプローチです。

文脈によって、アーキテクチャパターン、移行パターン、デザインパターンなどと呼ばれます。

ただし、StrategyやObserverのように、クラスやオブジェクトの関係を扱うGoFのデザインパターン1とは、扱う範囲が異なります。 Strangler Fig Applicationは、システム全体をどのような手順で移行するかを扱う概念です。

この概念がソフトウェアの文脈に導入されたのは、Martin Fowler（マーティン・ファウラー）氏です。 Fowlerは2004年に「Strangler Application」を公開し、2019年に「Strangler Fig Application」へ改題しました。 さらに2024年には、この考え方をレガシーモダナイゼーションの文脈から整理した「Strangler Fig」を公開しています。

名前の由来は、Fowlerがオーストラリアのクイーンズランドで見たStrangler Figというイチジクです。 この植物は別の木を支えにして成長し、根を地面まで伸ばしながら宿主を覆います。 やがて自立し、場合によっては宿主の木が枯れたあとも、その場所に残ります。

Fowlerはこの成長過程を、既存システムの周囲で新しいシステムを育て、振る舞いを少しずつ移していく方法に重ねました。

移行では「責務」と「接点」を分けて考える

Strangler Fig Applicationを使うときは、「新しい技術を使うこと」ではなく、移行によって得たい成果を最初に決めます。 たとえば、新機能を届けるまでの時間を短くすること、サポートが終了した技術を廃止すること、特定のシステムへの依存を減らすことなどです。

Fowlerが2024年に整理した説明では、漸進的なモダナイゼーションに必要な活動として、成果の理解、問題の分割、分けた部分の提供、それを継続するための組織の変化が挙げられています。 成果が判断基準になることで、「何をどの順番で移すか」を決めやすくなります。

移行単位を考える

移行単位とは、既存システムから新しいシステムへ移す責務のまとまりです。 機能、ビジネス能力、ドメイン、URLや画面、データの一部などを単位にできます。

単位が大きすぎると一括置換に近づき、失敗したときの影響も広がります。 逆に小さすぎると、新旧のシステムをまたぐ呼び出しやデータ同期が増え、移行の効果を独立して確かめにくくなります。

最初の単位は、利用者や運用にとって意味があり、動作を個別に検証でき、問題があれば元に戻せる大きさから選びます。

どのSeam（境界）で切り替えるか

Seamとは、既存システムと新しいシステムを分離し、呼び出し先を分岐または差し替えられる接点です。 代表的なSeamは、URLルーティング、APIの境界、イベント、抽象化レイヤー、データアクセス層などです。 機能やドメインは「何を移すか」であり、URLルーターやAPIは「どこで切り替えるか」です。 両者を分けて考えると、移したい責務を小さく切り出せる接点がどこにあるのかを検討できます。

1つの機能や画面を移す例

たとえば、稼働中のWebサイトにある「会員情報の表示と変更」を、/account/profileというURLごと新しいシステムへ移すとします。 この場合、表示と変更という機能が移行単位であり、URLルーターがSeamになります。

移行は次のように進められます。

  1. 新しいシステムに、会員情報の表示と変更を実装する
  2. データはどちらが正しい持ち主なのかを決め、新しいページから必要なデータへアクセスできるようにする
  3. /account/profileの呼び出し先を、URLルーターで新しいシステムへ切り替える
  4. 表示エラー、更新の成功率、応答時間などを確認し、問題があればルーティングを元に戻す
  5. 旧ページへの呼び出しがなくなったことを確認し、旧ページと不要になった移行用の設定を削除する

新しいページが旧システムのAPIを使うなら、画面の責務は移っていても、データの責務はまだ旧システムに残っています。 「ページを移した」だけで完了と判断せず、どの責務がどちらに残っているかを確認する必要があります。

新旧が共存する期間を管理する

WebサイトやWebアプリケーションでは、利用者から届くリクエストを既存システムと新しいシステムへ振り分ける、FacadeやProxy2を置く方法がよく使われます。

利用者
  ↓
Facade / Proxy
  ├─ 未移行の責務 → 既存システム
  └─ 移行済みの責務 → 新しいシステム

ただし、FacadeやProxyは代表的な実装方法であり、Strangler Fig Applicationの必須構成ではありません。 システムの構造に合わせて、APIの抽象層、イベントルーター、データアクセス境界などもSeamとして利用できます。

移行中だけ必要になるルーティング、互換層、データ同期処理などの構造は、Transitional Architectureと呼ばれます。 建物の改修における足場と同じように、完成後には不要でも、移行中の安全性を確保するためには必要です。

この共存期間には、次の内容を決めます。

  • 新旧のどちらが、各データと責務の正しい持ち主なのか
  • 新旧で共有するデータや呼び出しを、どのように同期するのか
  • 何を観測し、どの状態なら旧システムへ戻すのか
  • 誰が移行用の仕組みを管理し、どの状態になれば削除するのか

段階的な移行では、1回あたりの変更範囲と切り戻し範囲を小さくできます。 一方で、共存期間が長くなるほど、新旧2つのシステムと移行用の仕組みを保守する負担は増えます。

処理を途中で分岐できない場合や、新旧を共存させる費用が一括置換のリスクを上回る場合には、Strangler Fig Applicationが適さないこともあります。 段階的であること自体を目的にせず、得たい成果と共存コストを比べて選ぶ必要があります。

スムーズに移行するための7つの問い

Strangler Fig Applicationを実際のシステムへ当てはめるときは、次の問いから考えられます。

  1. この移行によって、どのような成果を得たいか
  2. 何を単位として移行するか
  3. どこにSeamを作るか
  4. 新旧システムのデータと責務をどう管理するか
  5. どう検証し、問題が起きたらどう切り戻すか
  6. 誰が移行を所有し、継続的に進めるか
  7. 何を削除できたら移行完了とするか

Strangler Fig Applicationは、単に古いシステムと新しいシステムを共存させる方法ではありません。 達成したい成果を明確にし、小さく移せる責務とSeamを見つけ、価値を提供しながら新しい側へ責務を移すアプローチです。

最終的に、役割を失った旧機能と不要になったTransitional Architectureを撤去できて、移行の1単位が完了します。

参考

Footnotes

  1. Strategyは処理方法を差し替える仕組み、Observerは状態の変化を関係する相手へ通知する仕組みで、どちらも「Gang of Four」と呼ばれる4人の著者が整理した代表的なデザインパターンです。

  2. Facadeは複数の処理を1つの窓口にまとめる仕組み、Proxyは利用者と実際の処理先の間に入り、呼び出しを転送または制御する仕組みです。この例では、どちらも新旧のシステムを利用者から隠す入り口として使えます。ただし、両者の役割は異なります。

記事を共有する