データ移行のマッピング表でZoho CRMへの移行漏れを防ぐ｜「要検討」項目を潰す検証手順

データ移行のマッピングとは、移行元の項目と移行先の項目を1つずつ対応づけることです。その対応づけに漏れがないかを確かめる移行漏れチェックは、移行元の項目一つひとつについて「移すか」「どこへ移すか」「移さないならなぜか」を決めきったかどうかを、移行の前に確かめる作業です。データ移行のトラブルは取り込みの操作そのものより、この「決めきれていない項目」から起きることがほとんどです。

この記事では、中小の人材紹介会社のZoho CRM導入で、複数の管理表（CSV）を移す準備をした際の検証レポートをもとに、要検討の項目を潰す手順と、マッピング（移行元の項目と移行先の項目の対応づけ）を検証する方法を紹介します。項目名は一般的な名前に置き換えています。

データ移行の漏れはなぜ起きるのか：「要検討」と空欄

この支援では、移行元が複数の管理表に分かれていました。企業との契約の管理表、営業リスト、求職者の管理表、問い合わせ・申込のデータ、案件の管理表などです。

最初に、各表の項目ごとに「必要／要検討／不要」の分類と、データ型、選択肢、確認事項を書いた項目一覧を作りました。ところが見直してみると、次のような状態でした。

項目のおよそ2割が「要検討」のまま残っていた
分類そのものが空欄の項目が、およそ1割あった
表によって「要検討」と「要議論」が混ざっていた（分類の表記ゆれ）

この状態で移行先の項目を作り始めると、要検討の項目は誰も決めないまま、移行先に受け皿がない状態になります。気付くのは、移行が終わって現場が「あの情報はどこ？」と探したときです。

手順1：分類を3つに固定し、空欄と表記ゆれをなくす

最初にやるのは、分類の言葉をそろえることです。

分類は「必要／要検討／不要」の3つに固定する。「要議論」などの別の言葉は「要検討」に寄せる
分類が空欄の項目を一覧で抜き出し、すべてに分類を付ける
「不要」にした項目も消さずに残す。後で「なぜ移さなかったか」を説明するためです

空欄の項目は、作成した人が判断を保留したものか、単に書き忘れたものです。どちらにしても、ここで決めないと後で必ず漏れます。

手順2：「要検討」を○△×→で決めきる

次に、要検討の項目に判定を付けます。この支援の検証レポートでは、要検討の項目ごとに「対応済み／部分対応／未対応」を付けて洗い出しました。そこで分かったことも踏まえ、次の4つの判定をおすすめします。

判定	意味	この支援での例
○	そのまま移す	電話番号の重複フラグ、居住地（都道府県で管理）
△	一部だけ移す	希望職種の第1・第2のうち、第1だけ移す
×	移さない	同じ電話番号の人を連番で管理する番号、「電話番号＋連番」の検索用の数式
→	別の項目・別の場所へ移した	「不要」としていた語学や職務経験の項目を、別の名前の項目として作り直した。会社紹介の資料を商談から取引先へ移した

ポイントは2つあります。

1つめは、△と×には必ず理由を書くことです。 たとえば「第2希望は今回は備考に残す」のように理由があれば、後から判断を見直せます。理由のない×は、決めたのではなく放置したのと同じです。

2つめは、「→」を独立した判定にすることです。 検証レポートでは、会社紹介の資料などを「未対応」としながら、備考に「取引先に移動済み」と書いていた項目がありました。移したのに未対応と書くと、漏れの一覧に紛れて、本当の漏れが見えにくくなります。逆に「不要」とした項目の中にも、実は別の名前で作り直していたものがありました。移した先が分かるよう、→の行には移行先の項目名を書きます。

判定を付けたら、×と△の項目を優先度で分けます。この支援では、重複の管理、求職者の詳しい希望条件（希望勤務地・希望業種・現在の年収）、過去の求職者への再アプローチの開始日を「高」、職種・希望職種の第2や数式の項目を「中」とし、推奨対応を「すぐ追加する項目」と「議論が必要な項目」に分けて整理しました。

手順3：マッピング表はどう作るか：移行先の項目から逆引きする

移行元から順に見るだけでは見つからない、どこからも値が来ない移行先の必須項目を、移行先の項目から逆にたどって見つける考え方を示した図

移行元から見た一覧だけでは、見つからない漏れがあります。移行先で必須にしている項目に、どの移行元からも値が来ないケースです。

そこで、Zoho CRMの項目を起点にした表も作ります。この支援では、モジュールごとに次の列を持つ表を作りました。

列	内容
セクション・項目名・API名・データ型・必須	Zoho CRM側の項目の情報
備考	どの元から、どう変換して入れるか
移行元ごとの列番号と項目名	契約の管理表の何列目、求職者の管理表の何列目、のように元ごとに1組
空値	どの元からも値が来ない場合の扱い

この形にすると、1つの項目に複数の元から値が入ることや、1行の元データから複数のレコードを作ることも表せます。たとえば契約の管理表の1行からは、取引先、採用の担当者、請求の担当者、商談の最大4レコードを作る設計でした。

手順4：マッピングの何を検証するか──修正が必要になる5つの型

マッピング表ができたら、1項目ずつ「本当にこの対応でよいか」を検証します。この支援の検証レポートで修正が必要と判断した項目は、次の5つの型に分けられます。

型	何が起きるか	この支援での例	直し方
意味のずれ	名前や型が似ているだけで、意味の違う項目に入れてしまう	取引の開始日を、取引先の「設立日」に入れようとしていた	対応を外し、意味の合う項目を作るか、移さない判定にする
型のずれ	入れ物の型と中身が合わない	会社紹介の資料（ファイルのURL）を、事業内容の複数行テキストに入れようとしていた	URL型の項目を作る、または添付として扱う
必須の欠落	移行先の必須項目に、元の値がない	法人番号、連絡先の作成日	補完方法を決める（一律の値・移行後に手入力など）
複数値の受け皿	元に同じ種類の値が複数ある	担当者のメールアドレスが2つある。1つのセルに改行区切りで複数の氏名が入っている	2つめの受け皿を作るか、備考へ。改行区切りは複数のレコードに分ける
値・所在の未確認	選択肢の値や、元データのどこにあるかが確かめられていない	連絡先の種別の選択肢、元データに経験職種がない場合がある、希望勤務地を住所から作れるか	実データで確かめ、選択肢の対応表を作る

このうち「意味のずれ」は、項目名やデータ型を機械的に比べても見つかりません。日付型どうしなので、形式の上では正しく見えるからです。各項目の「その値は何を表しているか」を、業務を知っている人と一緒に確かめる時間を取ってください。

手順5：複数の元が重なる項目は、優先順位を決めておく

同じ人のデータが複数の表にあるときは、項目ごとにどちらを使うかを決めます。この支援では、申込データと案件の管理表を突き合わせて、1件の案件として登録する設計にしました。ルールは次のとおりです。

更新が続いている案件の管理表を主にし、申込データは主の表が空のときの補完にだけ使う
担当者とステータスは、案件の管理表の値だけを使う（最新の状態を表しているため）
日付の項目は使う順番を決める。たとえば初回の面談日時は「面談日」、なければ「面談設定日」、どちらもなければ空にする
同じ人かどうかは「電話番号＋登録日」で突き合わせる。比べる前に、電話番号のハイフンの有無と日付の形式をそろえる
条件に合う人が複数いたら、最新の求職者のレコードを使う
理由を書く欄が複数ある項目（不採用の理由など）は、改行でつないで1つの項目に入れる
判断できない値は空にする。間違った値を入れるより、空のほうが後で直しやすいからです

形式のチェックはスクリプトに任せる

項目が数百あると、修正のたびに目で確かめ直すのは大変です。そこで、判定表と移行先の項目一覧をCSVで持ち、形式の上の漏れを機械的に洗い出すスクリプトを用意しておくと便利です。次の例は、Pythonの標準機能だけで動きます。

判定表（判定表.csv）の列は「元シート, 元項目, 元データ型, 分類, 判定, 移行先API名, 理由」、移行先の項目一覧（移行先項目.csv）の列は「モジュール, API名, データ型, 必須, 補完方法」です。

#!/usr/bin/env python3
"""移行判定表のチェック
使い方: python3 check_mapping.py 判定表.csv 移行先項目.csv
"""
import csv
import sys

VALID_CLASS = {"必要", "要検討", "不要"}
VALID_DECISION = {"○", "△", "×", "→"}  # →＝別の項目・別のモジュールへ移した

def load(path):
    with open(path, encoding="utf-8-sig", newline="") as f:
        return list(csv.DictReader(f))

def main(decision_path, target_path):
    rows = load(decision_path)
    targets = {t["API名"].strip(): t for t in load(target_path)}
    problems = []
    used = set()

    for i, r in enumerate(rows, start=2):  # 1行目は見出し
        where = f'{i}行目 {r["元シート"]}／{r["元項目"]}'
        cls = r["分類"].strip()
        dec = r["判定"].strip()
        dest = r["移行先API名"].strip()

        if cls not in VALID_CLASS:
            problems.append(f"{where}: 分類が「{cls or '空欄'}」です（必要／要検討／不要のどれかにする）")
        if dec not in VALID_DECISION:
            problems.append(f"{where}: 判定が「{dec or '空欄'}」です（○／△／×／→のどれかにする）")
            continue

        if dec in {"○", "△", "→"}:
            if not dest:
                problems.append(f"{where}: 判定が{dec}なのに移行先がありません")
            elif dest not in targets:
                problems.append(f"{where}: 移行先「{dest}」が移行先の項目一覧にありません")
            else:
                used.add(dest)
                src_type = r["元データ型"].strip()
                dest_type = targets[dest]["データ型"].strip()
                if src_type and src_type != dest_type:
                    problems.append(f"{where}: 型が違います（{src_type} → {dest_type}）。変換ルールを決めてください")

        if dec in {"△", "×"} and not r["理由"].strip():
            problems.append(f"{where}: 判定が{dec}なのに理由が空欄です")

    for api, t in targets.items():
        if t["必須"].strip() == "○" and api not in used and not t["補完方法"].strip():
            problems.append(f"移行先の必須項目「{api}」に、移行元も補完方法もありません")

    for p in problems:
        print(p)
    print(f"確認 {len(rows)} 行／要対応 {len(problems)} 件")
    return 1 if problems else 0

if __name__ == "__main__":
    if len(sys.argv) != 3:
        sys.exit(__doc__)
    sys.exit(main(sys.argv[1], sys.argv[2]))

このスクリプトが見つけるのは、判定の空欄、理由のない△と×、存在しない移行先、型の違い、補完方法のない必須項目です。たとえば「会社紹介の資料（ファイルURL）を複数行テキストへ→」という行があれば型の違いとして、「連絡先の作成日」が必須なのにどの元からも来ず補完方法も空なら必須の欠落として表示されます。

一方で、前の章の「意味のずれ」は見つけられません。取引の開始日を設立日に入れる対応は、どちらも日付型なので、このチェックを通ってしまいます。スクリプトで形式の漏れをゼロにしてから、人が意味を確かめる。この順番にすると、人が見るべき項目に時間を使えます。

移行先の項目一覧は、Zoho CRMの項目の情報を取得するAPI（settings/fields。公式ドキュメント「Field Metadata API」）の結果からも作れます。手で写すと、そこで新しい漏れが生まれるため、取れるものは取得したものを使うのがおすすめです。

移行前のチェックリスト

Salesforceから移る場合に確認したい項目は「SalesforceからZoho CRMへ移行する前に確認すべきデータ項目」、基幹システムのCSVを取り込むときのキーの決め方は「Zoho CRMで複合ユニークキーを作る方法」、移行したあとで項目の補完漏れに気付いたときの直し方は「Zoho CRMの商談から過去の受注明細を別モジュールへ移行する手順」で紹介しています。

まとめ

データ移行の漏れは、取り込みの失敗よりも、「要検討」のまま誰も決めなかった項目から生まれます。全項目に○△×→の判定と理由を付け、移行先から逆引きした表で必須項目の欠落を探し、5つの型で意味と型のずれを確かめる。形式の確認は機械に任せ、意味の確認に人の時間を使う。この順番で進めれば、移行後に「あの情報はどこへ行ったのか」と探し回ることは減らせます。

Salesforceから移る場合の移行全体の進め方はSalesforceからZoho CRMへの移行・乗り換え支援、移行事例はCRM移行事例の資料をご覧ください。

よくある質問

データ移行のマッピング表には、どんな列を用意すればよいですか？

移行先（Zoho CRM）の項目名・API名・データ型・必須の列に、移行元ごとの列番号と項目名、変換の方法、どの元からも値が来ないときの扱い（補完方法）を加えます。移行先の項目を起点に作ると、必須項目に値が来ない漏れを見つけられます。移行元から見た判定表と、2つそろえて使います。

「要検討」の項目は、移行のあとで決めてもよいですか？

おすすめしません。移行後に項目を足すと、過去のデータをもう一度取り込み直す必要が出ます。少なくとも「今回は移さない」と判定し、理由を残してから移行してください。移さないと決めた項目も、元データのバックアップを残しておけば後から補えます。

移行元のどの項目にも当たらない必須項目は、どうすればいいですか？

3つの選択肢があります。取り込み日などの決まった値を一律で入れる、別の項目から作る、移行後に手で入力する前提で必須を一時的に外す、のいずれかです。どれにするかを、マッピング表の「補完方法」の欄に書いておきます。当社が支援した移行準備では、連絡先の作成日は取り込み日で一律に入れる、法人番号は移行後に調べて入力する、という案を検証レポートにまとめました。

複数の管理表に同じ人のデータがある場合、どちらを使えばいいですか？

項目ごとに優先する元を決めます。当社が支援した移行準備では、更新が続いている案件管理の表を主にし、申込データは主の表が空のときの補完にだけ使うルールにしました。同じ人かどうかは「電話番号＋登録日」で突き合わせ、比べる前に電話番号のハイフンと日付の形式をそろえました。

Excelやスプレッドシートだけでも、このチェックはできますか？

できます。判定表と移行先の項目一覧を表計算で作り、フィルターで「判定が空欄」「理由が空欄」の行を探すだけでも効果があります。項目が数百あるなら、記事で紹介するスクリプトのように、毎回同じ条件で機械的に確認できる形にしておくと、修正のたびの見落としを防げます。

データ移行の漏れはなぜ起きるのか：「要検討」と空欄

手順1：分類を3つに固定し、空欄と表記ゆれをなくす

手順2：「要検討」を○△×→で決めきる

手順3：マッピング表はどう作るか：移行先の項目から逆引きする

手順4：マッピングの何を検証するか──修正が必要になる5つの型

手順5：複数の元が重なる項目は、優先順位を決めておく

形式のチェックはスクリプトに任せる

移行前のチェックリスト

まとめ

よくある質問

関連記事

SalesforceからZoho CRMへ移行する前に確認すべきデータ項目

Zoho CRMで複合ユニークキーを作る方法｜基幹CSV取込で得意先コードが重複したときの設計

Zoho CRMの商談から過去の受注明細を別モジュールへ移行する手順｜項目の補完漏れから復旧した記録

データ移行・乗り換えの進め方をご相談ください。

データ移行・乗り換えの進め方を
ご相談ください。