移行計画書の作り方｜失敗を防ぐ6項目

新システムの画面が完成し、受け入れテストも終わった。あとは本番へ切り替えるだけ。そんな終盤で、現行データに想定外のコード値が見つかる。

移行日は迫っている。ところが、誰が補正を判断するのか、何件まで不一致を許すのか、切り戻す場合にどの時点へ戻すのかが決まっていない。移行プロジェクトで怖いのは、変換プログラムの不具合だけではない。判断条件が文書になっていないことだ。

移行計画書は作業予定表ではない。「何を、どのルールで移し、何をもって成功とするか」を関係者で合意する仕様書である。実務では、次の中核6項目を一つの流れとして設計すると抜けが減る。

1. 移行対象と対象外
2. データの対応・変換ルール
3. 検証方法と合格条件
4. 停止時間と差分取り込み
5. 切り戻し条件と復旧手順
6. 役割分担と承認者

作成順序もこの並びでよい。現行調査から対象表を作り、項目マッピングに変換ルールを足す。次に検証条件と移行タイムラインを決め、切り戻しと体制を重ねる。最後にリハーサルの実測値と例外を反映し、承認版へ更新する。

6項目とは別に、移行環境、アクセス権限、バックアップ、セキュリティ、利用者への周知、全体リスクも前提条件として確認する。案件によって独立章にするべき内容は変わる。

移行計画書は「移せる」より「判定できる」を目指す

よくある移行文書には、対象テーブル、実施日、担当者、作業手順が並ぶ。もちろん必要だ。だが、その一覧だけでは当日の判断に使えない。

たとえば、顧客マスタ1万件を移行するとする。処理が完了して1万件が新環境へ入れば成功なのだろうか。重複顧客が統合されるなら、移行後の件数は減る。退会済み顧客を除外するなら、さらに変わる。件数一致だけを合格条件にすると、正しい変換を失敗と判定しかねない。

反対に、件数が一致していても安心できない。請求先コードと契約情報の対応が崩れていれば、業務は止まる。氏名の文字化け、金額の丸め、タイムゾーンの変換、参照先のない外部キーも確認が必要だ。

JICAのシステム要件定義書では、移行概要、移行対象、移行中の影響、移行テスト、スケジュール、体制を移行計画の記述項目として挙げ、対象ごとの移行方法と検証方法を求めている。重要なのは、作業内容と完了判定が対になっている点だ。

移行計画書の完成度は、ページ数では測れない。障害や不一致が起きたとき、担当者が同じ結論を出せるかで測る。

1. 移行対象と対象外を業務単位で決める

最初に作るのは、テーブル一覧ではなく「業務で残す情報」の一覧だ。現行データベースの物理構造から始めると、使われていない列や一時テーブルまで対象に入りやすい。一方で、ファイルサーバー上の添付資料や担当者が管理する補助台帳を落としやすい。

対象を整理するときは、次の単位で確認する。

• 顧客、契約、注文、請求などの業務オブジェクト
• 現在値だけでなく、履歴や証跡を残す必要がある情報
• 画像、PDF、CSVなどデータベース外の関連ファイル
• 他システムが参照するID、コード、連携キー
• 法令、契約、社内規程で保持期間が決まる情報
• 廃棄、匿名化、アーカイブの対象

対象外も明記する。「移さない」だけでは弱い。なぜ対象外なのか、どこで閲覧できるのか、いつまで保持するのかまで決める。移行後に現行環境を止めるなら、参照手段のない対象外データが発生しないかを確認したい。

デジタル庁の政府相互運用性フレームワークは、システム間の相互運用性を高めるための参照データモデルを公開している。移行先の項目名を決めるだけでなく、意味、形式、識別子をそろえる視点が欠かせない。

業務オブジェクトと関係を先に整理する方法は、ER図を業務ルールから作る5ステップでも扱っている。移行対象表とER図を対応づけると、親だけ移して子を落とす事故を見つけやすい。

2. データの対応・変換ルールを一行ずつ定義する

次に、移行元と移行先の対応表を作る。単純な項目名の対応だけでは足りない。一つの移行先項目に対し、少なくとも次を持たせる。

PMDAの調達仕様例では、この案件の受託者に対し、空白、欠損、ID・番号・コードの付番方式、データ型の違いなどの加工方法を事前に協議するよう求めている。一般のプロジェクトでも、こうしたルールは遅くとも移行設計に入る前までに合意したい。

変換ルールには「自動変換できない例外」も含める。自由記述から担当部署を推定する、古い住所を現行の行政区分へ直す、といった処理は誤判定を含みうる。AIを使って候補を出すことはできるが、信頼度が低い行の扱い、人が承認する範囲、元データを保持する方法を先に定める必要がある。

実務では、移行ツールの実装以上に、この対応表の合意に時間を要することも多い。だからこそ、発注者は業務上の意味と例外を決め、SIerは変換可能性、処理方式、検証方法へ落とす。片方だけでは完成しない。

対応表を構造化しておけば、AIに変換処理のたたき台やテストケースを作らせる際にも使える。ただし、AIが生成した変換式をそのまま本番へ流さない。対応表のルールIDとテスト結果を結び、どのルールから処理と検証が作られたかを追跡できる状態にする。

3. 検証方法と合格条件を数値で決める

「移行後に確認する」では、受け入れ条件にならない。何を、誰が、どの母数で確認し、どの状態なら合格かを決める。

検証は四層に分けると扱いやすい。

件数・総量

移行元件数、除外件数、統合件数、移行先件数の関係を確認する。金額、数量、ファイル容量など、件数以外の総量も照合する。

項目・形式

必須項目の欠損、文字コード、日付、桁数、列挙値、丸めを確認する。変換前後の値を追跡できるよう、移行バッチIDや対応ログを残す。

関係・業務ルール

契約のない請求、顧客のない注文、無効な担当者など、参照関係と業務制約を確認する。単体データが正しくても、関係が壊れていれば利用できない。

画面・業務シナリオ

代表顧客を検索できる、過去の契約を参照できる、請求書を再発行できるなど、実際の操作で確認する。重要業務はサンプル件数と選定条件を事前に決める。

AWSのデータ移行解説も、移行の要件と宛先を定義し、計画、実行、検証をつなぐ必要性を示している。検証スクリプトは本番移行だけでなく、リハーサルでも同じものを使える状態にしたい。

合格条件は「エラー0件」が常に正解とは限らない。既知の不整合を例外リストとして承認する場合もある。ただし、許容するエラー種別、上限、業務影響、解消期限は明示する。判断を曖昧にしたまま数字だけ緩めてはいけない。

4. 停止時間と差分取り込みを時系列で描く

本番移行では、現行システムのデータが動き続ける。最初の抽出から切り替えまでの間に追加・更新されたデータをどう扱うかが重要だ。

時系列には次の時点を入れる。

• 利用者への事前告知
• 現行データの事前抽出
• 現行システムの更新停止
• 最終差分の抽出
• 変換と投入
• 自動検証と業務確認
• 移行可否の判定
• 新システムの開放
• 旧システムの参照期間

停止できない業務なら、二重入力、差分同期、段階移行など別の方式が必要になる。方式名だけを決めず、どのデータをどちらで更新できるのか、競合した場合に何を正とするのかまで書く。

移行リハーサルでは、処理結果だけでなく所要時間を測る。抽出に60分、変換に90分、投入に120分、検証に60分かかるなら、停止枠に余裕があるか。再実行時間を含めても間に合うか。机上の工程表を、計測済みの工程表へ変えるのがリハーサルの役割だ。

5. 切り戻し条件と復旧手順をセットにする

切り戻しは「重大障害があれば実施」と書くだけでは動けない。重大かどうかを誰が判断するのか、何時までなら戻せるのか、戻した後の差分をどう扱うのかが必要だ。

切り戻し条件の例は次の通りだ。

• 必須データの欠損が許容上限を超えた
• 主要業務シナリオが完了しない
• 処理時間が判定期限を超過した
• 参照整合性エラーが解消できない
• セキュリティや権限の重大な不整合が見つかった

切り戻し手順には、新環境へのアクセス停止、旧環境の再開、移行中に発生した取引の復元、利用者への連絡、障害記録を含める。新環境で更新を許した後は、単純に旧環境へ戻せない。切り戻し可能な最終時刻を決める理由はここにある。

本番化の判定を整理する考え方は、生成AI PoCの成功基準は本番化の前に決めるにも通じる。成功条件だけでなく、停止条件と戻し方を先に合意しておく。

6. 役割分担と承認者を成果物ごとに置く

「移行はベンダー担当」と一括りにすると、業務判断が宙に浮く。データの意味、変換方式、実行、検証、承認では責任者が違う。

承認者には代理者も置く。本番移行が休日や夜間なら、平日の会議体を前提にした承認フローは使えない。連絡手段、応答期限、判断材料の保存場所まで決めておく。

IPAの相互運用性ガイドが扱うように、データは移行後も他のシステムや利用者から参照される。移行担当チームだけで閉じず、連携先、運用担当、監査・セキュリティ担当も関係者に含めたい。

移行計画書をレビューするチェックリスト

レビューでは、次の問いに「文書のどこに答えがあるか」を確認する。

• 業務上、残すべきデータと捨てるデータが分かれているか
• 移行元と移行先の項目対応、変換、欠損、重複のルールがあるか
• 件数、総量、項目、関係、業務シナリオの合格条件があるか
• 最終差分の取得から新環境開放までが時系列になっているか
• リハーサルで所要時間と再実行時間を測るか
• 移行中止、切り戻し、復旧の条件と期限があるか
• 発注者、SIer、運用担当の責任と承認者が決まっているか
• 変換前後の対応と判断履歴を追跡できるか

この8問に答えられれば、移行計画書は当日の台本として機能する。答えが会議の記憶にしかないなら、まだ仕様になっていない。

移行は開発の最後に見えるが、準備は要件定義から始まっている。対象、例外、合格、停止、切り戻し、責任を早めに構造化すれば、移行直前の「聞いていない」を減らせる。

株式会社Atsumellでは、業務ルールや既存資料から要件を整理し、開発・テスト・移行へ渡せる仕様づくりを支援している。移行計画を作業表から判断可能な仕様へ変えたい場合は、お問い合わせフォームから相談してほしい。

関連記事

• ER図の書き方｜業務ルールから作る5ステップ
• プロセスマイニングをAI要件に変える方法
• 生成AI PoCの成功基準は本番化の前に決める