データ移行のリハーサルは、予定としては1回ですが、失敗すればデータを流し直して、一発で通るまで繰り返します。データは本番と同じものを使い、メール送信のようにリハーサルで実行してはいけない処理だけをリハーサル用のアカウントで代替します。リハーサルは移行が成功するかの確認だけでなく、手順そのもののレビューにもなります。
データ移行の手順や費用はデータ移行ガイドに、移行全体のスケジュールはシステム移行のスケジュール目安にまとめています。この記事では、その中でも実際にやってみないと分からない部分、リハーサルで何をどこまでやっているかを書きます。
リハーサルは「1回」ではなく「通るまで」
リハーサルの回数は、予定としては1回です。ただし、リハーサルで失敗した場合はデータを流し直して、もう一度実施します。つまり実際の回数は、一発で通るまで何回でもという形になります。
これは慎重を期しているというより、通らないまま本番に進む選択肢がないからです。移行が途中で止まると、旧システムと新システムのどちらを正とするかが決まらない状態になり、その日の業務をどちらで回すかという判断から迷うことになります。
「通るまで繰り返す」というのは、失敗した状態から続きをやり直すという意味ではありません。データを入れ直して、最初の手順から通し直します。途中から再開すると、その回で何が起きたのかが分からなくなり、本番当日に同じ手順を再現できなくなるためです。
データは本番と同じものを使う
リハーサルで使うデータは、本番と同じものです。件数を絞ったサンプルや、テスト用に作ったデータでは、実際に起きる問題の多くが出てきません。
リハーサルで実行してはいけない処理は、代替する
一方で、本番と同じデータで動かすと困る処理もあります。分かりやすいのはメール送信です。移行の途中で実際の顧客宛にメールが飛ぶと、それだけで事故になります。
こうした処理は、リハーサル用のアカウントを発行するなどして、本番に近い設定のまま送り先だけを変える形で代替します。処理そのものを飛ばしてしまうと、その部分が本番で初めて動くことになり、リハーサルの意味が薄れます。
リハーサルで実際に見つかるもの
リハーサルは、移行が成功するかどうかの確認としてだけでなく、二つの意味で機能します。
データの変換は、やってみないと分からない
旧システムと新システムでデータの持ち方が違う場合、変換の処理が必要になります。この部分は、仕様を読んで設計した段階では想定できていても、実際のデータを通すと予想外の値が出てきます。データ変換を伴う作業は、リハーサルでやってみて初めて分かる部分が大きいと考えています。
手順そのもののレビューになる
もう一つは、作業手順のレビューとしての価値です。手順を順番に実施していくと、バックアップを取る手順が抜けているといった不足が見つかります。頭の中では分かっているつもりでも、書き出した手順どおりに動かすと足りない工程が浮かび上がります。
本番の移行当日は、判断に使える時間が限られます。手順の抜けをその場で見つけるのと、リハーサルの段階で見つけるのとでは、負担がまったく違います。
本番の移行とリハーサルの決定的な違いは、やり直せるかどうかです。リハーサルは失敗しても流し直せますが、本番は稼働中のシステムを止めて行うため、戻す判断にも時間の制約がつきます。リハーサルで通しておく価値は、成功を確認することよりも、失敗する余地をリハーサル側に寄せておくことにあります。
リハーサルなしで本番を迎えることはあるか
あります。理由は予算と短納期です。リハーサルは本番と同じ作業をもう一度行うものなので、その分の工数が必要になります。予算が限られていて、かつ納期も短い場合、リハーサルの枠を取れないまま進むことがあります。
これは望ましい形ではありません。発注側から見れば、リハーサルを削ることは移行当日の不確実性を引き受けることと同じです。調査を省いた場合と同じ構造で、削って消えるのは費用の項目であって、リスクそのものではありません。
発注側がリハーサルのために用意できること
リハーサルを有効にするために、発注側から出せるものがあります。
- 本番と同じデータを使うことへの合意(取り扱いの範囲を先に決めておく)
- メール送信のように、実行されると困る処理の洗い出し
- 移行後のデータを業務目線で確認できる担当者の時間
三つ目は特に重要です。データが移っていることは開発側で確認できますが、その値が業務として正しいかどうかは、普段その画面を使っている人でないと判断できません。並行運用に入ったあとの進め方は新旧システムの並行運用は何が大変かに書いています。
移行の進め方についてのご相談はお問い合わせからお受けしています。
この記事をシェア