BLOGIT基礎
移行データの入力規則｜厳しくしすぎず品質を守る設計
新システムの入力規則を過去データへ一律適用すると、当時は正しかった記録まで取り込めないことがあります。新規入力と移行を分けて考えます。
先に結論止めるエラー、確認する警告、記録だけ残す情報を、業務責任者と決めます。
技術的な不正と業務上の例外を分ける
存在しない日付、壊れた参照、数値列の文字は技術的な問題です。一方、古い住所、廃止コード、通常範囲外の金額は正当な過去記録かもしれません。
形式違いを理由に元値を消さず、変換前・変換後・理由を残します。自動補正できない値は判断待ち一覧へ出します。
必須・形式・範囲を列ごとに決める
新規入力では必須でも、過去データに存在しない項目があります。仮の値を勝手に入れず、未設定を明示できる設計を検討します。
金額、数量、率、日付範囲は業務上あり得る境界を確認します。0や負数を一律禁止せず、取消・返品・調整の扱いを責任者へ確認します。
参照関係と重複を確認する
顧客のない案件、案件のない明細、退職者が更新者となる履歴などを検出します。履歴の作成者を現行ユーザーへ置き換えず、元情報として保持します。
一意キーは見た目の名称でなく安定したIDを使います。既存IDと新規採番が衝突しない範囲を決め、再取込にも耐える識別子を用意します。
検査結果を直せる形で返す
ファイル名、行番号、項目、元値、理由、推奨対応を一覧にします。エラーコードだけで終わらせず、担当者が元資料へ戻れるようにします。
警告を大量に無視する運用になっていないか確認します。規則変更は件数と影響を再集計し、同じテストデータで再現できるよう版を管理します。
相談前にそろえるもの
- 技術エラー・業務例外
- 新規入力・過去データ
- 必須・範囲・0・負数
- 参照関係・一意キー
- 行番号付き結果表
全部そろっていなくても構いません。分かる範囲を確認し、業務ルールや金額に関わる部分は担当者と一緒に決めます。