段階を分けて置き換えようとすると、最初に出る問いは「どこで切るか」です。画面ごとに切るのか、機能ごとに切るのか、データベースのテーブルごとに切るのか。ここを決めないまま着手すると、途中で新旧両方のコードが同じテーブルを更新する状態になり、身動きが取れなくなります。
切り口は書き込みの向きで決める
切る場所を選ぶときの基準は、そこで何を読んでいるかではなく、どこに書き込んでいるかです。あるテーブルに新システムと旧システムの両方が書き込む状態になると、どちらが正しい値を持っているか誰にも分からなくなります。読み取りだけなら両方から読んでも大きな問題は起きません。
切り口の候補が複数あるときは、書き込み先のテーブルが完全に分かれる場所を選びます。取引先ごとに管理しているデータや、月次で締めて終わるデータは、書き込みの単位がはっきりしているので切りやすい部類に入ります。逆に、複数の画面から同じ在庫数を更新しているような箇所は、最初に切ってはいけない場所です。
戻せる状態を先に作る
切った直後に問題が出ることは前提にします。新システム側で不具合が見つかったとき、旧システムに戻せるかどうかが、この段階の設計で一番重要な点です。
戻すためには、新システムに切り替えた後も、旧システムが読める形でデータを残しておく必要があります。新システムの内部だけで完結する形式に変換してしまうと、戻すときにもう一段の変換作業が発生し、切り戻しに数日かかることになります。切り替えた当日に戻せないなら、それは段階を分けたことになっていません。
切り方を間違えた例
ある案件では、注文受付の画面だけを新システムに切り替え、注文データの保存先は旧システムのテーブルのままにしました。画面だけを切り離せば影響が小さいという判断でしたが、旧システムの夜間バッチがそのテーブルの形式に依存していて、新システムからの書き込みで一部の列が空のまま登録され、翌朝のバッチが止まりました。
見た目の切り口である画面と、実際に影響が及ぶ範囲であるバッチが読むテーブルの形式が一致していなかったことが原因です。切る前に、そのデータを他に誰が読んでいるかを確認していれば防げた失敗です。
並行稼働の期間をあらかじめ決める
新旧を並行して動かす期間は、切り替えた瞬間ではなく、切り替える前に決めておきます。期間を決めずに始めると、新システムに小さな不具合が見つかるたびに並行期間が延び、いつまでも旧システムを消せない状態になります。
期間の目安は、その業務の締めのサイクルが最低でも1回は入る長さです。月次処理があるなら1か月、四半期で締めるものが絡むなら3か月は見ておきます。この期間中は旧システムのログを消さないことも、あわせて決めておきます。
この段階で決めなくていいこと
最初の切り分けの時点で、最終的に何本に分けるかまで決める必要はありません。1つ切ってみて、想定より苦労が大きければ、次の切り方は小さくします。逆に楽に進んだなら、次はまとめて切っても構いません。
分からないのは当然だと考えていいのは、切った後にどれだけ不具合が出るかです。これは実際に切ってみないと分かりません。事前に見積もれるのは切り口の選び方までで、その先は動かしながら調整することになります。
