フレームワーク活用ガイドひとことで言うと#
レガシーシステムを一気に置き換えるのではなく、新しいシステムで徐々に機能を巻き取りながら、古いシステムを自然に消滅させる移行パターン。熱帯の絞め殺しの木（Strangler Fig）が宿主の木を徐々に覆い尽くす様子に由来する。
押さえておきたい用語#
- ファサード（Facade）
- リクエストを新旧システムに振り分けるルーティング層のこと。APIゲートウェイやリバースプロキシで実装し、クライアントからは1つのエンドポイントに見える。
- ビッグバンリプレース
- レガシーシステムを一括で新システムに置き換える移行方式を指す。リスクが極めて高く、失敗事例が多い。ストラングラーフィグはこの対極にある。
- 並行稼働（Parallel Run）
- 新旧システムを同時に動かして結果を比較検証する期間のこと。データの整合性を確認してから本切り替えを行う。
- モダナイゼーション
- レガシーシステムを最新の技術・設計に刷新する取り組みである。ストラングラーフィグパターンはモダナイゼーションの代表的な手法。
ストラングラーフィグパターンの全体像#
こんな悩みに効く#
- レガシーシステムを刷新したいが、ビッグバンリリースは怖すぎる
- 古いシステムを動かしたまま、少しずつモダンな技術に移行したい
- 過去に全面リプレースに失敗した経験があり、安全な方法を探している
基本の使い方#
レガシーシステムの中から移行しやすく、かつ効果の大きい機能を選ぶ。
- ビジネスへの影響が小さく、独立性の高い機能から始める
- 依存関係を洗い出し、切り出しやすさを評価する
- 最初の成功体験を作ることが重要
ポイント: 最も複雑な機能から手を付けるのではなく、「勝てる戦い」から始める。
リクエストを新旧システムに振り分けるルーティング層を作る。
- APIゲートウェイやリバースプロキシを活用する
- 特定のURLやリクエストパターンで新旧を切り替える
- クライアントからは1つのエンドポイントに見える
ポイント: ファサードがあれば、いつでも旧システムにフォールバックできる安心感がある。
選定した機能を新しい技術スタックで実装し、ファサード経由で公開する。
- 旧システムと並行稼働させ、動作を検証する
- データの整合性を確認する仕組みを用意する
- 問題があればファサードで即座に旧システムへ戻す
ポイント: 「新しい方が動いている」ことを確認してから切り替える。
新システムの動作が安定したら、旧システムの該当機能を廃止する。
- モニタリングで問題がないことを一定期間確認する
- 旧コードを削除し、次の移行対象に進む
- これを繰り返し、最終的にレガシーシステム全体を置き換える
ポイント: 焦らず1機能ずつ。完了のたびにチームの自信と知見が積み上がる。
具体例#
状況: 従業員120名のEC企業。10年物のPHP製モノリスECサイト（コード行数48万行）。商品管理・注文・在庫・決済がすべて1つのコードベースに密結合。デプロイに50分、月間障害4.8回。
ステップ1: 比較的独立している「商品検索機能」を最初の移行対象に選定。依存関係が少なく、移行効果（検索速度改善）が大きい。
ステップ2: Nginx をリバースプロキシとして設置。/api/search/* へのリクエストだけ新サービスに転送し、それ以外は旧PHPアプリへ。
ステップ3: Elasticsearch + Go で新しい商品検索APIを構築。旧システムと同じDBを参照しつつ、レスポンスの整合性をダブルチェック。
ステップ4: 2週間の並行稼働で問題なしを確認。旧PHPの検索ロジックを削除。次は「商品管理機能」の移行に着手。
| 指標 | Before | After（1.5年後・全移行完了） |
|---|---|---|
| デプロイ時間 | 50分 | 平均3分/サービス |
| 月間障害件数 | 4.8回 | 0.9回 |
| 検索レスポンス | 1.2秒 | 0.15秒（8倍高速化） |
| サービス停止 | — | 移行期間中ゼロ |
デプロイ50分→3分、検索レスポンス1.2秒→0.15秒。1.5年でPHPモノリスを完全に退役させ、サービス停止はゼロ。「いつでも旧システムに戻せる」安心感がチームの推進力になった。
状況: 地方銀行のコア勘定系システム。COBOL製で30年間稼働。COBOLエンジニアの平均年齢が62歳で、5年以内に保守不能になるリスク。しかし一括リプレースは過去に他行で3件の失敗事例（業務停止・数十億円の損失）がある。
移行計画（5年）:
- Year 1: 為替計算モジュールを切り出し（最も独立性が高い）
- Year 2: 口座照会・残高計算を移行
- Year 3: 入出金処理を移行
- Year 4: 融資管理を移行
- Year 5: 旧COBOL完全退役
ファサード設計: ESB（Enterprise Service Bus）を中間層に配置。COBOLとJavaの両方にリクエストを送り、結果を比較する「シャドーモード」を3ヶ月間実施してからJavaに切り替え。
| 指標 | Year 0 | Year 2（中間報告） |
|---|---|---|
| COBOL依存度 | 100% | 45%（為替+口座照会を移行済み） |
| 処理速度（為替計算） | 8秒 | 0.4秒（20倍高速化） |
| 業務停止インシデント | — | ゼロ |
| 保守可能エンジニア数 | 3名（COBOL） | 12名（Java + COBOL） |
COBOL依存度100%→45%、保守可能エンジニア3名→12名。業務停止インシデントはゼロ。シャドーモードで新旧の結果を比較してから切り替えたことが、リスクをほぼゼロに抑えた要因。
状況: 人口18万人の自治体。オンプレミスで稼働する住民情報システム（2008年構築）。サーバー老朽化でハードウェア障害が年間6回発生。クラウド移行したいが、住民票発行・転入転出・税務が密結合しており、一括移行は不可能。
移行順序:
- 証明書発行（PDF生成）→ AWS Lambda + S3に移行（3ヶ月）
- 住民情報照会API → ECS + RDS に移行（4ヶ月）
- 転入転出処理 → ECS + Step Functions に移行（6ヶ月）
- 税務計算 → 最後に移行（8ヶ月）
ファサード: AWS ALB でURLパスベースの振り分け。移行済みパスはECSへ、未移行パスはVPN経由でオンプレミスへ。
| 指標 | Before | After（全移行完了後） |
|---|---|---|
| ハードウェア障害 | 年間6回 | 年間0回 |
| 証明書発行速度 | 平均45秒 | 平均8秒 |
| 月間運用コスト | 380万円 | 210万円（45%削減） |
| 災害時の復旧時間 | 推定72時間 | 15分（マルチAZ） |
ハードウェア障害年6回→0回、運用コスト45%削減、災害復旧72時間→15分。住民サービスを1日も止めずにクラウド化を完了。最も影響の小さい機能から始めたことが、庁内の信頼醸成につながった。
やりがちな失敗パターン#
- ファサード層を作らず直接切り替える — ルーティング層がないとロールバックが困難になり、結局ビッグバンと同じリスクを負う。必ず振り分け層を挟むこと
- 旧システムの廃止を先延ばしにする — 新旧並行稼働の期間が長くなると、二重メンテのコストが膨れ上がる。移行完了したら速やかに旧機能を削除する
- データの整合性を軽視する — 新旧システムで同じデータを扱う場合、同期の仕組みが不十分だとデータ不整合が発生する。移行期間中のデータ戦略を事前に設計する
- 最も複雑な機能から着手する — 最初に最難関に挑むとチームが疲弊し、プロジェクト全体が頓挫する。独立性が高く効果の大きい「勝てる戦い」から始めることで成功体験を積む
まとめ#
ストラングラーフィグパターンは 「大きなリスクを取らずにレガシーシステムを刷新する」 ための実践的な移行戦略。ファサード層を設けて新旧を振り分け、1機能ずつ確実に移行していく。全面リプレースの誘惑に負けず、小さく始めて確実に前進しよう。