データマッピングのテンプレート：移行元と移行先の対応例

データマッピングのテンプレートには、元の各フィールドを移行先のフィールドへどう変換するかを記録します。値の取得元、認める変換、値を使えない場合の処理を定めます。「顧客ID」と「ID」を線で結ぶだけでは、取り込み処理の実装やテストに必要な情報が足りません。

ここでは、小さな顧客CSVを新しい顧客テーブルへ取り込む例を扱います。フィールドごとのルール、受け入れ可能なレコード、保留する入力、再利用できるマッピングカードを示します。登場する組織とレコードは、説明用に作った架空のものです。

移行元と移行先のマッピングに必要な情報

列見出しのスクリーンショットだけではなく、移行元と移行先の定義から始めます。各フィールドについて、データ型、必須か任意か、変換方法、許容値、不正な値の扱いを記録します。Boardmixの共有ダイアグラム用キャンバスに取得元、ルール、移行先を並べると、データを渡す側と受け取る側が同じ対応表を見ながら話し合えます。

図は、データをどう移すかについての合意を表します。図自体が移行処理を実行するわけではありません。取り込みスクリプトや連携ツールでルールを実装し、受け入れるレコードと保留するレコードを出力します。

関連する三種類の資料を区別しておきましょう。

• ER図：データモデルのエンティティ、属性、関係を表します。
• データフロー図：処理、保存先、外部の関係者やシステムの間でデータがどう移動するかを表します。
• 移行元・移行先のマッピング：データを移す際に、個々のフィールドをどう扱うかを表します。

並べて使うことはできますが、CustomerとOrderの関係だけでは、古いステータスコードを新しい値へどう変換するかは分かりません。

具体例：顧客データの五つのフィールドを取り込む

旧システムから顧客一件につき一行を出力し、新システムには五つのフィールドが必要だとします。空の移行先への一回限りの取り込みであり、既存レコードの更新やマージではありません。

この例では、移行先の五つのフィールドをすべて必須とします。国コードはGB、JP、ES、ステータスはactive、inactiveだけを受け入れます。説明を分かりやすくするためにリストを小さくしており、実際の顧客システムを三か国に制限する提案ではありません。

識別子は、数字だけで構成されていてもテキストです。「0017」を数値の17に変えると、識別子が変わってしまいます。データ型は見た目の書式だけでなく、値の意味に関わります。

各フィールドの変換と、失敗した場合のルールを書く

この例では、未知の値を黙って修正しません。移行元の仕様は大文字のAとIだけを許すため、小文字の「a」は保留します。大文字と小文字を区別しない運用にしたい場合は、マッピングを明示的に変更し、小文字のテストケースも加えます。取り込みツールの便利な初期設定に、この方針を決めさせないようにしましょう。

同様に「03/09/26」を、取り込み担当者の地域設定から推測してはいけません。異なる日付を意味する可能性があります。合意した形式で出力してもらうか、移行元の既知の形式を記録してから変換します。

フィールド名の対応付けとデータ型の変換は、別の作業です。Microsoftのスキーマ・データ型マッピングの説明でも、具体的な連携ツールの中で両者を分けています。設定方法は製品ごとに異なりますが、ツールを設定する前に、求める結果をフィールドの取り決めとして定めます。

一件のレコードを入力から出力まで追う

次が元のレコードです。引用符は前後の空白を見えるようにするためのもので、保存される値には含まれません。

• source_ref: “ 0017 ”
• company_label: “Orion Studio ”
• country: “United Kingdom”
• joined: “2026-09-03”
• state: “A”

前後の空白を除去した識別子0017が、他の入力行と重複していなければ、次のレコードを受け入れます。

• customer_id: “0017”
• display_name: “Orion Studio”
• country_code: “GB”
• joined_date: 2026-09-03
• account_status: “active”

この変換では、組織名を分割したり、英語表記に直したり、識別子を数値にしたりしません。それらを行うなら、単なる整形ではなく追加のルールになります。入力から結果をたどれるよう、移行の記録には元の行も残します。

保留するレコードの扱いも設計する

成功する行だけを示したマッピングでは、重要な処理が未定義のままです。この例では、一つのフィールドでも条件を満たさなければ行全体を保留し、一部だけの顧客レコードは書き込みません。

理由ラベルに加え、保留レコードの出力には元の行を識別する情報と、問題のフィールドも必要です。エラーメッセージに不要な個人情報を載せないようにします。実際の移行では、制限のないボードに顧客レコードをコピーするのではなく、承認済みのサンプルと組織のアクセス管理を使います。

重複の扱いは、フィールド変換とは別に定めます。「最後の行を残す」は簡単ですが、ファイルの行順で結果が変わってしまいます。確認済みの更新時刻など、正しいレコードを選ぶ業務ルールがあるなら、同値だった場合の扱いも含めて記録します。決められない場合は、任意に選ばず競合するレコードを保留します。

フィールドごとに使えるマッピングカード

多くのフィールドを一覧するには表が便利ですが、複雑な変換について話すときは小さなカードが扱いやすくなります。次のカードには、同じ基本情報をまとめています。

• マッピングID：M-03
• 移行元：customer_export.country、テキスト
• 移行先：customer.country_code、必須のテキスト
• 意味：移行先で使う国の分類
• ルール：前後の空白を除去し、承認済みのUnited Kingdom/GB、Japan/JP、Spain/ES対応表を使う
• 欠落・未知の値：元の行全体を保留する
• 例：“ Japan ”は“JP”に変換し、“JPN”は保留する
• 問い合わせ先：移行元の国の値を管理する担当者

複数のフィールドを使う変換では、すべての入力を同じカードに書きます。given_nameとfamily_nameからfull_nameを作る処理は、独立した二つの直接対応ではありません。順番、区切り文字、一部が欠けた場合の扱いをまとめて定めます。別テーブルを参照する場合は、照合キーと、該当がゼロ件または複数件だったときの処理を記録します。

受け入れるデータと保留するデータをチームで追う

Boardmixのキャンバスでは、左に移行元、右に移行先のスキーマを置き、その間にマッピングカードを並べます。変換が必要なフィールドをラベル付きの線で結びます。受け入れるレコード例は主な流れの下に、保留経路は別の領域に置くと、意見の違いがフィールド名、業務上の意味、不正な値のどこにあるかを見つけやすくなります。

移行元の担当者には元の値の意味を、移行先の担当者には受け取り側の要件を説明してもらいます。その後、サンプルレコードを各ルールに当てはめます。一方が「UKは受け入れる」、もう一方が「UKは保留する」と考えているなら、取り込み前に対応リストをそろえます。

最初の実装テストでは、入力行数と、受け入れた行数・保留した行数の合計を照合します。この例では、元の各行は必ずどちらか一方に入ります。識別子とフィールド値も比較してください。件数が一致するだけでは、別の顧客に誤ったステータスを割り当てた問題は分かりません。

Boardmixを開いて移行元・移行先の対応図を作り、チームで確認しましょう。合意したルールとサンプルの結果を、移行処理の実装担当者へ渡します。図は取り決めを記録し、取り込みテストは実装がその取り決めに従っているかを確かめます。