要点
- 全面的な作り直しの失敗は、技術よりもスコープとタイミングに起因することが多い。
- 背後を置き換える前に、まず旧システムの前に安定したインターフェースを置く。
- 業務機能をひとつずつ置き換え、本番で検証してから次に進む。
- 新旧を並行稼働させて出力を比較してから、トラフィックを切り替える。
全面的な作り直しは白紙からの出発を約束しますが、多くの場合は長くリスクの高いプロジェクトになります。レガシーシステムを段階的に置き換えれば、ビジネスを動かしたまま各ステップを検証できます。
全面的な作り直しが行き詰まる理由
レガシーシステムが古いのには理由があります。動いていて、ビジネスがそれに依存しているからです。長年のルール、例外、修正が組み込まれ、その多くは文書化されていません。作り直しでは、旧システムが変わり続ける中でそれらをすべて再発見する必要があります。
結果はおなじみのパターンです。新システムは予定より長引き、その間に旧システムには緊急の変更が必要になり、切り替え日がずれていきます。その間、ビジネスは2つのシステムの費用を払いながら、どちらの恩恵も受けられません。
まず安定したインターフェースから
最初のステップは、中核部分の新しいコードを書くことではありません。既存システムの前にインターフェース（通常はAPIレイヤー）を置き、他のアプリケーションがレガシーのデータベースや画面ではなく、そのインターフェースとやり取りするようにすることです。
利用側が実装ではなくインターフェースに依存するようになれば、その背後をひとつずつ変えられます。これはストラングラーパターンと呼ばれ、新システムが旧システムの周りで少しずつ成長し、最後に旧システムを停止できるようにする手法です。
業務機能ごとに順序を決める
最初に置き換える機能は、現在どれだけ問題を生んでいるか、どれだけ独立しているかの2つの基準で選びます。入力と出力が明確で依存が少ないものが良い候補です。例えば見積書の生成、通知、レポートなどです。
最も中心的で、最も多くとつながっている部分から始めるのは避けます。初期の段階では、プロジェクト全体を賭けるのではなく、自信と共通理解を築くべきです。
- 業務機能と、それぞれが持つデータを整理する。
- 各機能を業務上の痛みと結合度で評価する。
- 痛みが大きく結合度が低いところから始める。
- 中核の取引処理は、チームがドメインを十分に理解するまで残しておく。
並行稼働で各ステップを検証する
機能を切り替える前に、新旧の実装を同じ入力で並行して動かし、結果を比較します。違いからは、どんな要件定義のワークショップよりも早く、文書化されていないルールが見つかります。
トラフィックは支店、顧客グループ、割合などで段階的に切り替え、切り戻しの手順を文書にしておきます。元に戻せない移行ステップは、まだ準備が足りないステップです。
データ移行はひとつのプロジェクトとして扱う
データはコードより長く生き残ります。レガシーのデータには重複、形式のばらつき、本来の用途と異なる使い方をされた項目が含まれていることがよくあります。クレンジング、マッピング、検証を明示的に計画し、何も失われていないことを件数とチェックサムで証明します。
最後の機能を移したとき、旧システムの停止は形式的な作業になっているべきです。すべての利用側が新しいインターフェースを使い、すべてのデータが検証され、ビジネスは何週間も新システムで動いている状態です。
参考になりましたか？次の記事をメールで受け取れます。