システム刷新の成否は、いつ判定されるのか

レガシー刷新の成功例が語られるとき、公開される事例には強い選択バイアスがかかっている。失敗したプロジェクトは事例発表されない。結果として「Strangler パターンを使えば安全に移行できる」という理解が広く共有されているが、実際の失敗率を公表事例から推定することはできない。複数の失敗事例に共通する構造を、対策とセットで見ていく。

失われるのはコードではなく理由

レガシーシステムの多くには、コード上では説明されない背景知識が埋め込まれている。この計算式は1998年の税法改正に対応したもの。この分岐は特定の大口顧客の契約上の要求。このバッチジョブは月末の会計処理と依存関係がある。こうした知識は、設計した当事者が退職すると消える。

刷新プロジェクトの初期段階で、コード解析ツールは処理フローを可視化できる。フローの意図までは復元できない。新システムで同じ振る舞いを再現すること自体は技術的に可能だが、なぜその振る舞いが必要なのかを理解しないまま再現すると、次の要件変更で身動きが取れなくなる。Fred Brooks が1975年に conceptual integrity として指摘した問題と、本質的には同じものだ。

知識の引き継ぎは数年前に始まる

対策として挙がるのは、退職前のインタビュー、ペアプログラミングでの引き継ぎ、ビジネスルールの体系的な文書化あたりになる。どれも退職者が去った後では実行できない。

つまりこれは、刷新プロジェクトの3年から5年前に始める必要がある種類の投資である。プラットフォーム化の議論と同じく、成果が見えるのは投資から数年後で、その時間差が予算獲得を難しくしている。

並行運用が終わらない理由

Strangler パターンでは旧システムと新システムを並行運用しながら段階的に機能を移す。理論的には安全な設計だが、並行運用期間のコストが計画を大きく超過して膨れる失敗が多い。推計であり案件により幅があるものの、傾向としては一貫している。

主要因は意思決定の遅延にある。この機能は新システムで動くと確認できたか。旧システムを止めていいか。こうした判断は事業側から見て新機能開発ほど優先度が高くない。結果として並行運用期間は終わりを決められない状態が続き、旧システムのライセンスコスト、運用要員、監視体制がそのまま維持されたまま、新システムのコストが上乗せされる。

意思決定の遅延という別の問題と直結している。並行運用の終了判断を事業側の意思決定プロセスに委ねる限り、技術チームがコストを制御することはできない。契約上、明示的な移行期限を設定するアプローチが実務的だが、その期限を強制する権限が組織内で誰にあるのかは自明ではない。クラウド撤退の判断と同じく、期限設定は技術判断ではなく契約と組織構造の問題になる。

要件を凍結できるという前提

刷新プロジェクトの設計時に「移行期間中は要件を凍結する」という前提が置かれることがある。事業側から見て、この前提は非現実的だ。規制、競合、市場といった事業環境は移行期間中も変化し続けるため、対応する要件変更を数年凍結することは事業リスクに直結する。

実際に起きるのは、凍結された前提の上で実際には変更されている要件を追いかける状態である。これが移行スコープの継続的な拡大につながる。GAO や OMB が連邦システムの近代化プロジェクトについて繰り返し報告してきた予算超過と期間延長の主要因は、この構造にある。

アジャイルで吸収できるか

要件変更に対応できないのは古い設計手法の問題であって、反復開発で吸収できるという反論はもっともに聞こえる。原理的には正しい。レガシー刷新という文脈では実装が難しい、というだけだ。

難しさの正体は、レガシーシステムの機能単位が小さなスプリントに分解できないことにある。月末バッチ処理、税務申告連携、顧客残高計算。こうした機能は数十年にわたって蓄積された特殊ケースを含んでおり、2週間で完結する単位に切ると特殊ケースが取りこぼされる。アジャイル手法の効用とレガシー機能の分割可能性は、独立した問題として扱ったほうがいい。

成功確率を上げたいなら、技術選定より先に組織的な準備を進めることになる。ドメイン知識の体系化を数年前から始める。並行運用の終了権限を組織構造で明確にする。要件変更の吸収経路を設計する。この三つを持たないまま技術検討に入ると、「Strangler パターンを採用したのに刷新が終わらない」という、よく見る失敗の形に落ち着く。