データ移行の進め方

データ移行は、見積りで軽く見られがちな作業です。「既存のデータを新しい箱に移すだけ」と思われるからです。

実際には、移行で工数の大半を占めるのは、移す作業ではなく「確かめる作業」です。ここを見誤ると、終盤で一気に苦しくなります。

■ まず、現行データを調べる

設計を始める前に、実際のデータを見ます。仕様書ではなく、本物のデータです。

とくに「備考欄の使われ方」は要注意です。長く使われたシステムほど、正式な項目がない情報が備考欄に押し込まれています。ここを見落とすと、移行後に「あの情報はどこに行った」となります。

■ 移行ルールを決める

項目ごとに、どうするかを決めます。決めることは3つです。

• 移すか、移さないか

• どう変換するか（コード体系の読み替え、桁の切り詰め、日付形式）

• 値がないときどうするか（初期値を入れる／移行対象から外す／エラーにする）

ここで重要なのが「移さないデータ」を決めることです。

「念のため全部移す」は、業務側に確認せずに決めてはいけません。移行しないと決めたデータを、後から「必要だった」と言われるのがいちばん困ります。

■ リハーサルは複数回やる

ここが、成否を分けるいちばんのポイントです。

• 1回目：必ず問題が出る。エラーで止まる、桁あふれ、想定外の文字

• 2回目：問題を直して、手順が固まる

• 3回目：所要時間が読めるようになる

本番移行の作業時間は、リハーサルで実測した時間をもとに決めます。机上の見積りで「たぶん3時間」と置くのは危険です。

リハーサルは、必ず本番相当のデータ量で行います。テスト用の1000件では、本番の100万件で何が起きるかは分かりません。

■ 突合は4つの数字で見る

移行が終わったら、正しく移ったかを確認します。全件を目で見るのは不可能なので、次の4つで判断します。

件数と合計値が合えば、大きな取りこぼしはありません。あとは抜き取りで、変換ルールが意図どおりかを見ます。

■ 確認には業務側の人を入れる

開発側だけで突合すると、「数字は合っているが、業務的におかしい」を見逃します。

業務側の人に見てもらうときは、具体的な依頼の形にします。

• 「移行結果を見てください」ではなく

• 「よく使う取引先10社の情報が正しく移っているか、画面で確認してください」

漠然と渡すと、見てもらえません。確認する対象と手順を、こちらから用意します。

■ 本番当日は、リハーサルと同じ手順で

本番で手順を変えると、リハーサルの意味がなくなります。当日は、リハーサルで固めた手順書をそのまま実行します。

差分だけを流す方式（リハーサル後に発生したデータだけを移す）を取る場合は、その差分取得の手順もリハーサルに含めておきます。

■ 移行後、現行システムをいつ止めるか

移行が終わっても、現行システムはすぐに止めません。

• 移行しなかった過去データを参照する必要がある

• 移行結果に疑問が出たときの突合元になる

「いつまで、誰が参照できる状態で残すか」を決めておきます。止める判断も、事前に期限と条件を決めておくのが確実です。

■ まとめ

データ移行でうまくいく案件は、共通して次の3つをやっています。

• 設計前に、本物のデータを見ている

• リハーサルを複数回、本番相当のデータ量でやっている

• 突合に業務側の人を入れている

いま移行を抱えている案件があれば、リハーサルの回数が計画に入っているかを確認してみてください。1回しか入っていなければ、そこが最初のリスクです。