データ移行の要件定義とは｜切り替え前に決める5つの条件

はじめに

新しい顧客管理システムへ、旧システムのデータを取り込んだ。件数は合っているのに、請求先が一部違う。添付書類が開けない。更新を続けていた旧システムには、新環境にない受注が残っている。これは説明用の例だが、データをコピーできたことと、業務を引き継げたことの違いがよく表れている。

データ移行の要件定義は、何を移し、何を変換し、どの状態なら業務を再開できるかを合意する工程だ。移行ツールや作業日程を決める前に、業務担当者と開発担当者が同じ基準で結果を判断できるようにする。

本記事は、移行計画全体の作り方ではなく、計画の前提となる5つの条件に絞って解説する。工程表や役割分担まで含む計画は、移行計画書の作り方も参照してほしい。

要件と手順を分けて考える

「顧客と請求情報の対応が崩れない」は、移行後に満たすべき条件だ。「顧客テーブルを先に投入する」は、その条件を満たすための手順である。両者を分けると、手段を変更しても守るべき条件が残る。

AWSのデータ移行の解説でも、移行の計画や検証が扱われている。個別の製品を選ぶ前に、移行元と移行先、業務上の制約、結果の確認方法を整理したい。

要件には、条件だけでなく、判断者と確認する証拠も付ける。「正常に移行する」では判定できない。「対象の請求について顧客との対応を全件照合し、未解決の不一致がないことを業務責任者が確認する」なら、確認作業へ落とせる。

切り替え前に決める5つの条件

1. 移す対象と、移さない情報の扱いを決める

顧客、契約、受注などの業務単位で、対象期間と状態を決める。テーブル一覧だけを見ると、添付ファイルや別の台帳で管理する情報を落としやすい。履歴、連携先で使うID、データに付いた閲覧権限も対象か確認する。

対象外には理由と移行後の参照先を付ける。過去の契約を新システムへ移さない場合、旧環境を停止した後も必要な期間だけ閲覧できるのかを確認する。保持期間は法令、契約、社内規程に従い、一律の年数で決めない。

対象表には、情報の種類、抽出条件、除外条件、件数の算出方法、業務上の責任者を記録する。未確定の情報は、対象外と決めつけず「要確認」として残す。

2. 項目の意味と変換できない例外を決める

同じ「顧客コード」でも、旧環境と新環境では識別する単位が違うことがある。項目名だけで結び付けず、意味、型、桁数、単位、日付のタイムゾーンを確認する。

欠損、重複、廃止済みのコード、文字化けを見つけたときの扱いも必要だ。自動補正するのか、業務担当者へ確認するのか、移行を止めるのかを決める。空欄を便宜的に埋めるだけでは、元の意味を変えてしまう可能性がある。

たとえば顧客の統合では、同じ社名だけを理由に同一と判定しない。採用する識別子、統合後に残す値、契約や請求への参照の付け替え方を明記する。元のIDと移行先IDの対応を残すと、後から問い合わせを受けても追跡しやすい。

3. データ品質と業務上の合格条件を決める

件数の一致は確認の一つであり、合格のすべてではない。統合や除外がある場合には、移行前後の件数が違うこともある。除外した件数、統合による減少分、変換できなかった件数を説明できるようにする。

金額の合計、必須項目の欠損、参照先の有無、添付ファイルの閲覧なども確認する。加えて「対象の顧客を検索し、契約を開き、請求先を確認できる」といった業務操作を受け入れ条件に含める。

全件を自動照合する項目と、人がサンプルを確認する項目は分ける。サンプル確認では、対象の選び方と確認件数を事前に合意する。許容する例外がある場合は、種類、件数、業務影響、解消期限、承認者を記録し、エラーの総数だけで合否を決めない。

4. 切り替え時の更新と停止時間を決める

事前にデータを取り込んでも、切り替えまで旧システムの更新が続けば差分が生まれる。どの時点までのデータを正とするか、いつ更新を止めるか、最後の差分をどう取り込むかを決める。

停止できない業務では、段階移行や差分同期を検討する。ただし方式名だけでは要件にならない。どちらの環境で更新を許すか、同じ情報が両方で変わったらどう扱うか、未反映をどう検出するかまで必要だ。

停止時間には投入処理だけでなく、検証、業務確認、判断、必要な復旧の時間を含める。リハーサルの実測値で停止枠に収まるか確認し、当日まで未計測の時間を確定値として扱わない。

5. 中止・切り戻しの条件と判断期限を決める

「重大な問題があれば戻す」では、担当者ごとに判断が変わる。必須データの欠損、主要業務の実行不可、最終差分の未反映、検証の時間超過など、戻す判断に使う条件を具体化する。

切り戻し可能な期限と、判断者・代理者を決める。新環境で更新を受け付けた後は、旧環境を再開するだけでは新しい取引が失われる。新環境で発生した更新を回収・反映する方法まで確認する。

バックアップがあることと、期限内に復旧できることも別だ。復元手順、所要時間、復元後の確認、関係者への連絡までリハーサルの対象にする。

受け入れ条件の記入例

以下は説明用の例であり、実際の数値や対象はプロジェクトで合意する。

条件ごとにIDを付け、変換仕様やテストへ対応付けておくと、変更時に確認先を追いやすい。要件トレーサビリティの考え方も活用できる。

まとめ

データ移行の要件定義では、移行対象、項目変換、データ品質、切り替え、切り戻しの5条件を、判断者と証拠まで含めて合意する。ツールの処理成功ではなく、業務を引き継げるかで結果を判断したい。

Kakusillなどの仕様書づくりの道具を選ぶ際にも、まず業務側が判断する条件と開発側が検証する条件を分けて整理しておく。その合意があれば、移行計画やテストのレビューで何を確認すべきかが明確になる。