古いシステムを前にして「いっそ全部作り直したい」と思ったことのある人は多いはずです。
ところが全面刷新の提案は、たいてい稟議の段階で止まります。
止まる理由は予算だけではなく、止めた瞬間に事業が止まるという性質にありました。
テックリードに求められるのは、この板挟みの中で現実に動く進め方を選ぶことです。
私はまだテックリードの立場に立った経験がないので、公開されている一次情報を手がかりに、判断の型を整理しておきました。
レガシーシステムは「古い」ではなく「触れない」
レガシーシステムという言葉は、単に年数が経ったシステムを指すわけではありません。
経済産業省が2018年に公表した DX レポートでは、老朽化・複雑化・ブラックボックス化という3語で問題が説明されました。
技術が古いこと自体より、仕様が誰にも分からず変更が怖い状態が本体の問題です。
この状態を放置すると事業側の要望に追従できなくなり、競争力を失うという警告が「2025年の崖」でした。
その後、経済産業省はデジタル庁と IPA を事務局とする「レガシーシステムモダン化委員会」を設置し、2025年5月に総括レポートを公表しています。
レポートでは、IT 資産の可視化と内製化、現行踏襲の見直し、上流人材の育成が企業側の対策として挙げられました。
つまり最初にやることは書き換えではなく、いま何が動いているかを見えるようにすることだと整理されています。
一括刷新（ビッグバン移行）が失敗しやすい理由
全部を新しく作って、ある日いっせいに切り替える進め方がビッグバン移行です。
この方式は分かりやすい一方で、いくつもの不利を同時に抱え込むことになりました。
まず、リリースまで価値がゼロのまま投資だけが積み上がります。
次に、開発中も旧システムの改修要望は止まらないため、新旧の二重メンテナンスが発生するのです。
さらに、切り替え当日に問題が出たときの戻し方が「旧システムに戻す」しかなく、戻すほど傷が深くなります。
仕様が文書化されていないシステムでは、そもそも「同じ動きになったか」を判定する基準すら作れません。
失敗したときの被害が一度に来るという点が、この方式の最大の弱さでした。
ストラングラーフィグパターンとは
Martin Fowler が2004年に書き、2024年に書き直した StranglerFigApplication は、この一括刷新への対案として広く参照されています。
名前の由来は、彼が2001年にクイーンズランドの熱帯雨林で見た「絞め殺しの木」でした。
イチジクの一種が宿主の木の上で発芽し、根を地面まで伸ばして自立し、やがて宿主が枯れて外形だけが残るという生態を指します。
この比喩が示すのは、新システムを旧システムの外側に少しずつ育てるという進め方です。
具体的には、旧システムの前面にリクエストを振り分ける層を置き、機能単位で新しい実装に流す先を切り替えていきます。
切り替えた機能が安定したら、旧システム側の該当コードを止めます。
これを繰り返すと、投資と回収が時間に分散され、失敗の単位が1機能まで小さくなるわけです。
Fowler の記事は、旧新が同時に動くための「移行期のアーキテクチャ」が一見むだに見える点にも触れています。
それでもリスク低減と早期の価値提供に見合うという評価が、記事の結論でした。
切り分けの足場をどこに置くか
パターンを知っていても、実際には「どこで切るか」で詰まります。
Fowler の記事では、目指す成果の理解・問題を小さな単位に分ける方法の決定（継ぎ目〈seam〉を見つける工程）・各単位の完遂・それを続けられる組織への変革という4つの活動が挙げられました。
エンジニアリング側の勘所は、2つ目の継ぎ目の発見にあります。
外部との境界がはっきりしている部分ほど、継ぎ目として使いやすいのが実情です。
たとえば HTTP エンドポイント・バッチの入出力ファイル・メッセージキューは、外から差し替えやすい候補になります。
逆に、コードの内部で密に絡んだ処理を切り離すには、先に抽象の層を挟む必要がありました。
コードの内側を段階的に入れ替える手法としては、Branch by Abstraction が対になる考え方です。
クラウドベンダーの実装ガイドも公開されており、AWS の Prescriptive Guidance にはストラングラーフィグを使った段階移行の手順が載っていました。
テックリードが最初に決める3つのこと
技術的にどう切るかの前に、決めておくと後戻りが減る論点があります。
1つ目は終わりの定義です。
「全部移し終える」を目標にすると、費用対効果の悪い末端機能まで移す羽目になり、途中で息切れします。
移さずに凍結する範囲を先に決めておくほうが、計画は現実に近づくのです。
2つ目は、移行中の二重メンテナンスをどちらの都合で吸収するかという分担でした。
旧システムへの改修を止める期間を設けるのか、両方に入れるのかは、事業側と合意しておく論点になります。
3つ目は進捗の見せ方です。
移行率をコード量で測ると実感と合わないので、機能数やトラフィック比率のように外から見える単位を選びます。
この種の説明は、技術的負債をビジネス側に伝える話と地続きになりました。
既存コードに手を入れる合意の作り方については、別の記事で整理しています。
最後に
レガシーシステムの問題は古さではなく、中身が見えず変更が怖い状態そのものでした。
一括刷新は失敗の被害が一度に来るので、機能単位で外側に新システムを育てるストラングラーフィグパターンが対案になります。
継ぎ目を外部との境界に求め、終わりの定義と二重メンテナンスの分担を先に決めておくと、計画が現実側に寄りました。
全部を移し切ることではなく、止まらずに移し続けられる形を作ることが目的地になります。
以上です。
コメントを残す