リスクの高いビッグバン書き換えなしにレガシーシステムを近代化する方法
どのCTOも、いつかそれを引き継ぐことになります。10年前に構築されたシステムで、今もビジネスを支えているにもかかわらず、新しいアイデアが生まれるたびに進行を鈍らせる存在です。当初のベンダーはすでに姿を消し、それを構築した開発者たちも他社に移り、リリースのたびに祈るような気持ちになります。やがて、ある取締役会メンバーが当然の疑問を投げかけます。「いっそのこと書き直したらどうか？」この一つの質問が、どんな不正アクセスやシステム障害よりも多くのIT予算を焼き尽くしてきました。Standish GroupやMcKinseyによる調査は、大規模な全面書き換えプロジェクトが失敗するか、あるいは劇的に予算を超過する確率が3分の2を超えることを、繰り返し示してきました。失敗の形はいつも同じです。18ヶ月が経過し、数百万ドルを費やし、本番環境には何一つ届けられず、それでも売上を稼ぎ続けているのは古いシステムのままです。
クリーンスレート書き換えという神話
ビッグバン書き換えが魅力的なのは、きれいな決別を約束するからです。混乱を捨て、新しいチームを雇い、モダンなツールを使い、1年後には美しい新システムとともに再登場する。しかし現実には、その1年間が計画通りに終わることはほとんどありません。古いシステムは単なるコードではありませんでした。それは10年分のビジネスルール、エッジケース、規制対応パッチ、そして誰もドキュメントに残さなかった静かな回避策の集積です。書き換えは、ビジネス側がソフトウェアが何をしていると考えているかを記述した仕様書から始まりますが、実際に何をしているかは書かれていません。移行中に見つかる忘れられたルールが一つ増えるたびに、数週間が追加されます。その間も古いシステムは進化を続けます。ビジネスは止まれないからです。そして新システムは、機能を一つもリリースする前から、さらに遅れをとっていきます。
より良い思考モデルがあります。レガシーシステムを、取り壊す家として扱うのではなく、車が渡っている間に1車線ずつ置き換えていく橋として捉えるのです。目標は、より速く最終状態に到達することではありません。旅の間、毎週ビジネスを動かし続けることです。
近代化は一つの決断ではなく、四つの決断
計画を選ぶ前に、通常はまとめて一度に決められがちな意思決定を切り分けて考えましょう。
1. コードを近代化するのか、それともアーキテクチャを近代化するのか？ 同じモノリスを新しい言語で書き直しても、得られるものはほとんどありません。責任範囲を独立してデプロイ・スケール可能なサービスに分割することこそ、真のビジネスレバレッジが生まれる場所ですが、これはドメインが十分に理解されている場合に限られます。コード作業の前にアーキテクチャ作業を行ってください。
2. リホスト、リファクタリング、それとも置き換えか？ すべてのモジュールが同じ扱いに値するわけではありません。中には安定していて退屈で、単にモダンなインフラに移すべきもの（「リホスト」）があります。他には、その場で保存しつつクリーンアップすべきビジネスロジックを含むもの（「リファクタリング」）があります。また、過去と密結合しすぎていて、新規実装しか選択肢がないものもわずかにあります（「置き換え」）。システム単位ではなくモジュール単位で選ぶことこそ、18ヶ月の賭けを、2ヶ月ごとの小さな勝利の連続に変える鍵です。
3. データ優先か、機能優先か？ ほとんどのレガシーシステムでは、真のレガシーはその上に乗っているコードではなく、データベーススキーマそのものです。近代化計画に明確なデータ戦略（新しいスキーマ、移行パス、移行期間中のデュアルライトまたはイベントベース同期）がなければ、2つのシステムが真実の源について意見を異にした瞬間に崩壊します。
4. 移行を誰が所有するのか？ 単一の説明責任を負うプロダクトオーナーがいない近代化プロジェクトは漂流します。レガシーシステムの新機能追加にノーと言い、ロードマップを守り、「古いシステムを生かし続けたい」と「新システムに投資したい」という日々の緊張を仲裁できる人物が必要です。
ストラングラーパターン、わかりやすく
実世界の近代化で最も信頼できるパターンは、Martin Fowlerが「ストラングラーフィグ（絞め殺しイチジク）アプローチ」と名付けたものです。考え方はシンプルです。レガシーシステムの前段に、通常はAPIゲートウェイまたは軽量なオーケストレーターというルーティング層を設置します。新しい機能はすべて新アーキテクチャで構築され、そのルーター経由で提供されます。既存機能は、意図的に境界のあるスライスを一度に一つずつ移行するまで、レガシーバックエンドで動き続けます。数ヶ月から数四半期にわたって、新システムは古いシステムの周りにゆっくりと成長し、劇的な切り替えの週末を一度も経験することなく、最終的にそれを置き換えていきます。
このパターンのビジネス上の効果こそが重要です。本番環境には常に動作するシステムが存在します。移行された各スライスは、それがより速いページであれ、よりクリーンなレポートであれ、新しい統合であれ、それ自体で価値を提供します。1年間リリースされないブランチに蓄積されるのではありません。何かが壊れたら、会社全体ではなく、1つのスライスをロールバックします。そしてチームはレガシーシステムの実際の挙動を段階的に学びます。これがレガシーシステムを本当に学べる唯一の誠実な方法です。
現場からのストーリー
私たちがお手伝いしたある地方小売業者は、注文と在庫のワークフロー全体を15年前のERPで運用していました。ピークシーズンごとにシステムは動きが鈍くなり、eコマースチャネルを追加しようとする試みはすべて、ERPが追いつけないために失敗していました。過去2社のベンダーが全面置き換えを提案していました。期間12ヶ月、予算7桁ドル、9ヶ月目まで目に見える進捗はゼロ。両プロジェクトとも中止となりました。
別のアプローチは大きく異なるものでした。最初の6週間で、チームはERPの前段に薄いAPI層を配置し、商品カタログの読み取りパスだけを、適切な検索インデックスに支えられたモダンなサービスに移しました。ストアフロントのページ読み込み時間は3秒から0.5秒未満に低下しました。この単一のスライスはERPの書き込みパスに一切触れなかったため、リスクはほぼゼロで、3ヶ月分のコンバージョンリフトが次のフェーズの費用を賄いました。続いて注文受付、次に在庫予約、そしてレポート機能が続きました。18ヶ月後、ERPは以前の4分の1未満の仕事しかしなくなり、モジュールごとに静かに退役していきました。1日たりともダウンタイムはありませんでした。
実践的なロードマップ
もしあなたが今、自社のレガシーシステムを前にしているなら、リスクを低く保ちつつ勢いを維持する順序は次のようになります。
- 推測せず、地図を描く。 モジュール、統合、データフロー、そしてそれぞれに依存するビジネスプロセスの正直なインベントリを作成するのに、2〜4週間費やしてください。記述できないものは近代化できません。
- 価値が高くリスクの低いスライスを1つ選ぶ。 ビジネスを日々苦しめているものの、王冠の宝石である書き込みパスには触れないもの。読み取りモデル、レポート、顧客向けビューなどです。それを四半期以内に、ルーティング層の背後で本番環境にリリースしてください。
- すべてを計測する。 ログ、メトリクス、エラーバジェット。あなたはこれから2つのシステムを並行運用することになるため、それぞれが何をしているかを可視化する必要があります。
- 読み取り側が「退屈」になってから、書き込みパスを移行する。 新アーキテクチャが安全にトラフィックを処理できることが証明されたら、両システムを移行期間中も整合させるために、デュアルライトやイベントリプレイで書き込みの移行を始めてください。
- 意図的に退役させる。 レガシーモジュールは、電源が切られるまで完了ではありません。各スライスに明示的な停止日を設定し、それを守ってください。
率直な結論
近代化はコードプロジェクトではなく、ビジネス上の規律です。成功するチームはこれを、単一の英雄的なリリースではなく、四半期ごとにリターンをもたらす複数年の投資として扱います。彼らはクリーンスレート書き換えを約束せよという政治的圧力に抵抗し、最初の四半期から小さくても目に見える勝利を届けることで信頼を勝ち取ります。
あなたの組織がこの旅の最初にいる場合、あるいはすでに停滞した書き換えと共に生きている場合、リセットする最速の方法は、経験のあるチームを迎え入れることです。MercTechsでは、中堅・大企業のクライアントがレガシープラットフォームを段階的に近代化し、移行期間中もビジネスを守り、あらゆる段階で測定可能な価値を届けるお手伝いをしています。それが「もう一つの12ヶ月の約束」よりもあなたのニーズに近いと感じられるのであれば、ぜひご相談ください。