NICHICOMA
データ移行のリハーサルを終えたものの、「エラーは直したが、本番へ進めてよいのか」「一部の問題が残っているが、延期すべきか」と迷うことがあります。
本番へ進むには、必要なデータが正しく移り、業務開始までに確認を終えられることが前提です。問題が残る場合は、業務への影響と対応方法まで確認して判断します。
この記事では、開発会社からリハーサル結果の報告を受ける発注・導入担当者に向けて、本番移行を判断する5つの基準を整理します。
データ移行リハーサルは、本番の手順と結果を確かめる予行演習
データ移行リハーサルでは、本番を想定した手順でデータを移し、作業時間や移行後の状態を確かめます。データを取り込めたかだけでなく、新システムで検索、更新、帳票出力などの業務を行えるかも確認する作業です。
本番へ進める条件は、リハーサル前に発注側と開発会社で決めておく必要があります。結果を見てから条件を決めると、予定日を守るために問題を軽く扱ってしまうことがあるためです。
結果の報告には、移行対象と成功・エラー件数、重要な数値の照合結果、作業ごとの所要時間、手順書から変更した箇所、未解決問題、切り戻しの確認結果を残します。
エラーを修正した場合も、原因、直した手順、再確認の結果まで記録しておきましょう。本番当日の担当者が変わっても、同じ手順で作業できる状態にするためです。
判断基準1：必要なデータが正しく移っているか
データの正しさは、件数だけでは判断できません。件数が一致していても、請求額が違っていたり、受注と明細の紐づきが失われていたりすれば、業務に支障が出ます。
次のように、件数、数値、データ同士の関係、実際の業務結果を分けて確認します。
| 確認する項目 | 確認例 |
|---|---|
| 件数 | 全体だけでなく、拠点別・状態別でも移行対象の件数が合うか |
| 重要な数値 | 売上、請求額、残高、在庫などの集計が合うか |
| データ同士の関係 | 顧客と契約、受注と明細などの紐づきが保たれているか |
| 業務での利用 | 検索、更新、帳票出力、承認、後続処理を実行できるか |
| 移行できなかったデータ | 理由、件数、対応方法が分かっているか |
許容できる差異は、データの種類ごとに決めます。請求金額やアクセス権限など、業務や安全性に直接影響する差異は、未解決のまま進めない扱いにするなど、重要度に応じた基準が必要です。
また、移行できないデータを除く場合は、除外する理由と業務への影響を確認し、発注側と開発会社で扱いを合意しておきましょう。
判断基準2：業務開始までに確認を終えられるか
正しく移行できても、業務開始までに終わらなければ予定どおりには使えません。データの抽出、変換、取り込み、照合、利用部門の確認にかかった時間を分けて記録します。
本番では、承認待ちや担当者間の連絡、エラー調査と再実行、バックアップの取得・確認、利用者への案内にも時間がかかります。データを取り込む時間だけで予定を組まないようにしましょう。
リハーサルのデータ量が本番より少なければ、実測した時間をそのまま本番の所要時間には使えません。本番相当のデータ量と環境で確かめるか、条件の違いを考慮して見積もる必要があります。
本番の計画には、完了予定時刻とあわせて、切り戻しへ切り替える最終判断時刻を入れます。切り戻しにも時間がかかるため、業務開始時刻まで作業を続けてから判断すると、旧システムの再開が間に合わない場合があります。
移行だけでなく、開発全体の日程を確認したい場合は、こちらの記事も参考にしてください。
システム開発の期間はどれくらい？希望日に間に合わせる準備とスケジュール
判断基準3：残る問題が業務に与える影響を許容できるか
未解決問題は、件数よりも業務への影響を見て判断します。画面の表示位置のずれと、請求額の誤りを、同じ「一件の問題」として扱うことはできません。
問題ごとに、誰のどの業務に影響するか、発生する条件、代替手段、他の機能やデータへの影響を整理します。移行後に修正する場合は、担当者と期限に加えて、代替運用を何日続けられるかも確認が必要です。
条件付きで本番へ進む場合は、「対象拠点を一部に限定する」「過去履歴は本番後に追加する」「特定の帳票は旧環境で一時的に出力する」など、進める条件を具体的に記録します。
「運用で対応する」という説明だけでは、利用部門が対応できるか判断できません。誰が、どの方法で、いつまで対応するのかを明確にしましょう。
移行対象を減らして進められるか
問題のあるデータや拠点を対象から外し、範囲を絞って開始できる場合もあります。
ただし、対象を減らした結果、業務が成立しないなら進められません。新旧システムをまたぐ作業、二重入力、集計への影響を確認し、利用部門が対応できる範囲かを判断します。
判断基準4：当日の担当者と判断する責任者が決まっているか
移行当日は、開発会社だけでは判断できない場面があります。データの意味や業務結果を確かめられる利用部門の担当者も必要です。
| 役割 | 主な対応 |
|---|---|
| 全体の責任者 | 本番移行の続行・中止を判断する |
| 移行作業の担当者 | 手順書に沿って移行を実施する |
| データ照合の担当者 | 件数や重要な数値、データの関係を確認する |
| 利用部門の担当者 | 新システムで業務を行えるか確認する |
| 連絡・案内の担当者 | 問題を集約し、関係者や利用者へ状況を伝える |
担当者は部署名だけでなく、氏名、連絡方法、待機時間、代理担当まで決めておきましょう。「営業部に確認する」という手順だけでは、当日に誰へ連絡すべきか分からなくなります。
責任者が判断する時刻に、必要な確認結果がそろうかも確認しておく必要があります。
判断基準5：問題が起きたときに旧システムへ戻せるか
切り戻しとは、移行を中止して旧システムで業務を再開することです。バックアップを取得しただけでは、切り戻せるとは判断できません。
旧システムをどの状態に戻すか、復旧と確認に何時間かかるか、誰が作業するかを手順書に記載し、リハーサルで確かめます。切り戻し後は、データと業務の状態を確認し、利用者へ再開を案内する必要もあります。
特に、新システムで入力・更新が始まった後は、そのデータをどう扱うかが問題になります。旧システムへ戻すだけで、新システムに登録した情報まで引き継がれるわけではありません。
移行中や利用開始後の入力をどう扱うかも含めて、切り戻し手順を確認しておきましょう。本番当日は、事前に決めた中止基準と最終判断時刻に沿って、続行するか戻すかを判断します。
本番へ進む・条件付きで進む・延期する場合の判断表
5つの確認結果をそろえたうえで、責任者が本番移行を判断します。次の表は判断の整理例です。実際の基準は、自社の業務と移行方法に合わせて決めてください。
| 判定 | 判断の目安 | 次に行うこと |
|---|---|---|
| 本番へ進む（Go） | 必須データと主要業務の確認が完了し、時間・体制・切り戻しの条件も満たしている | 計画どおり本番へ進む |
| 条件付きで進む（条件付きGo） | 残る問題の影響を限定でき、代替手段・対応期限・担当者・対象範囲が合意されている。必須条件は満たしている | 合意した範囲と条件で本番へ進む |
| 延期する（No-Go） | 重要データの差異や業務を止める問題が残る、時間内に終わらない、必要な体制がない、切り戻しの条件を満たせない | 原因と対応範囲を整理し、再リハーサルと次回判定の日程を決める |
条件付きで進める判断は、必須条件を満たしていない状態で予定日を優先するためのものではありません。代替運用でも業務が成立しない場合は、延期を検討します。
判定会議では、結論と当日の対応まで決める
判定会議では、リハーサル結果を共有し、次の内容を決めます。
- 本番へ進む、条件付きで進む、延期するのいずれか
- 未解決問題の扱い、対応する責任者、期限
- 本番当日の中止基準と最終判断時刻
- 利用部門への案内内容と送信時刻
- 条件付きで進む場合の対象範囲
- 延期する場合の再リハーサルと次回判定の日程
判断結果と根拠、参加者を記録しておけば、本番当日も同じ条件で判断できます。開発会社の説明だけで決めず、利用部門による確認結果もそろえて判断しましょう。
まとめ
データ移行リハーサルでは、必要なデータが正しく移り、決めた時間内に業務確認まで終えられるかを確かめます。残る問題の扱い、当日の体制、切り戻しの手順も、本番へ進むための判断材料です。
発注側と開発会社でリハーサル前に基準を合意し、結果に照らして責任者が本番移行の可否を決めます。条件を満たせない場合は、対象を絞る方法や延期も含めて検討してください。
参考情報
以下は、移行前のリハーサル、担当体制、切り戻し手順を検討する際の参考資料です。AWSへの移行を対象とした資料のため、自社システムへ適用する際は、移行方法や業務条件に合わせた確認が必要です。本記事の5分類と判断表は、担当者が確認しやすいように整理したもので、各資料が定める統一基準ではありません。
AWS Prescriptive Guidance：Pre-cutover stage 移行計画、リハーサル、切り戻し手順の準備について。
AWS Prescriptive Guidance：Cutover stage 移行時の担当体制、事前テスト、切り戻しの判断条件、変更されたデータの扱いについて。
システム開発について相談したい方へ
ニチコマでは、Webシステムや業務システムの開発についてご相談を承ります。