Data Migration Guide
レガシーシステムと新システム間のフィールドマッピング
フィールドマッピングはCRM移行の中で、やってみると問題が出るまで簡単に見える部分です。「First NameはFirst Nameにマッピング」は問題ありません。しかし、ソースシステムにFull Nameフィールドがひとつしかなく、移行先がFirst NameとLast Nameを別々に要求している場合はどうでしょう？Salesforceのリードステータスに8つの値があって移行先が5つしかサポートしない場合は？Annual Revenueが通貨フィールドではなくテキストフィールドとしてインポートされ、初日からすべての収益レポートが壊れる場合は？
最後のシナリオは仮の話ではありません。よく起こります。そして防げます。最初のインポート実行中ではなく、その前にフィールドマッピング文書を作成すれば。
このガイドでは、完全なフィールドマッピングプロセスを説明します。まずオブジェクトレベルのマッピング、次に標準フィールド、そして難しいケース（カスタムフィールド、ピックリスト値、リレーションシップフィールド、タイプの不一致）。移行先CRMに触れる前に、これらの手順を順番に実行してください。
ステップ1：まずオブジェクトレベルのマッピング
フィールドをひとつもマッピングする前に、オブジェクトをマッピングしてください。CRMは同じ概念に対して微妙に異なる用語を使います。オブジェクトのマッピングがずれていると、大規模なリレーションシップデータが破壊されます。
標準オブジェクトマッピング
| ソースシステム | ソースオブジェクト | 移行先概念 | 備考 |
|---|---|---|---|
| Salesforce | Lead | コンタクト（変換前） | Salesforceのリードは コンタクト＋アカウント＋商談に変換される |
| Salesforce | Contact | コンタクト | 直接マッピング |
| Salesforce | Account | 会社 | |
| Salesforce | Opportunity | 取引 | |
| Salesforce | Activity (Task/Event) | 活動 | |
| HubSpot | Contact | コンタクト | 直接マッピング |
| HubSpot | Company | 会社 | 直接マッピング |
| HubSpot | Deal | 取引 | 直接マッピング |
| HubSpot | Ticket | チケット/サポートケース | 移行先による |
| Pipedrive | Person | コンタクト | |
| Pipedrive | Organization | 会社 | |
| Pipedrive | Deal | 取引 | 直接マッピング |
| Pipedrive | Activity | 活動 | |
| Zoho CRM | Lead | コンタクト（変換前） | SalesforceのLeadモデルと類似 |
| Zoho CRM | Contact | コンタクト | |
| Zoho CRM | Account | 会社 |
Salesforceのリード変換の問題：Salesforceにはリードとコンタクトがあります。リードは変換前、コンタクトは変換後です。他のほとんどのCRMにはコンタクトのみです（ライフサイクルステージ付き）。マッピングを始める前に決めてください：Salesforceのリードを「Lead」ライフサイクルステージのコンタクトとして移行するのか、変換済みのコンタクトのみを移行するのか。この判断は何千件ものレコードに影響します。SalesforceからReworkへの移行では、このリードからコンタクトへの変換がReworkのデータモデルで具体的にどう機能するかが解説されています。
オブジェクトモデルが一致しない場合：ソースに移行先に対応するものがないカスタムオブジェクトがある場合、明示的に文書化してください。カスタムオブジェクトデータを標準オブジェクトに無理やり当てはめないでください。移行先にカスタムオブジェクトとして移行するか、移行する価値がないと判断するかのどちらかです。
ステップ2：標準フィールドのマッピング
標準フィールドは単純に見えます。しかし、そうでないことがよくあります。
名/姓 vs フルネーム：Salesforceは名前と苗字を別々に保存します。フルネームのみのシステムもあります。フルネームしかないソースから名前と苗字を別々に必要とする移行先に移行する場合、分割変換が必要です。これは完璧ではありません（「Dr. María José García-López」はどうするのか？）。
電話フィールドの複数性：SalesforceのコンタクトにはPhone、MobilePhone、OtherPhone、HomePhone、AssistantPhone という5つの別々の電話フィールドがあります。ほとんどのCRMは1つのプライマリと1つのセカンダリ電話フィールドです。どのソースフィールドがどの移行先フィールドにマッピングされるかをインポート前に決めてください。電話番号を廃棄する場合はその判断を文書化してください。
メールの複数性：同じ問題です。SalesforceにはメールとContact methodsによるセカンダリメールがあります。HubSpotはコンタクトごとに複数のメールをサポートします。移行先がプライマリメール1件のみサポートする場合、どちらが優先されるかのルールが必要です。
ウェブサイトフィールド：URLの形式が不整合だと検証エラーが発生します。一部のレコードには「example.com」、他には「https://www.example.com」、さらに「www.example.com/products/page」があります。目標形式を決めて変換ルールとして追加してください。
ステップ3：カスタムフィールドの棚卸し
ここでほとんどの移行が行き詰まります。成熟したCRMには何年もかけて積み重ねられた数十のカスタムフィールドがあります。そのほとんどは移行する価値がありません。
ソースからすべてのカスタムフィールドをエクスポートする：
- Salesforce：設定 > オブジェクトマネージャー > オブジェクトを選択 > フィールドとリレーション。リストとしてエクスポート。Salesforce Data Loaderドキュメントでは、レコードデータと並行してフィールドスキーマをエクスポートする方法が説明されています。
- HubSpot：設定 > プロパティ。「作成者」でチームでフィルタリングしてカスタムプロパティを確認。HubSpotインポートドキュメントではインポート時に必要なプロパティが記載されています。
- Pipedrive：設定 > データフィールド。カスタムフィールドはオブジェクトごとに一覧表示されます。
- Zoho CRM：設定 > カスタマイズ > フィールド。
各カスタムフィールドに3つの質問を適用してください。カスタムフィールドガイドでは、命名規則、フィールドタイプの選択、移行先でのカスタムフィールド作成のガバナンスプロセスについて詳しく解説しています：
- レポートで使用しているか？ このフィールドを使用するレポートがなければ、おそらくビジネス価値を提供していません。
- セグメンテーションに使用しているか？ このフィールドを参照するワークフロー、シーケンス、リストフィルターがなければ、休眠している可能性があります。
- 自動化のトリガーとして使用しているか？ このフィールドを使用する自動化トリガーがなければ、移行する必要があるかを検討してください。
3つすべての答えが「いいえ」なら、ソースシステムにアーカイブしてください。移行先にフィールドを作成しないでください。
すべてのカスタムフィールドについて残す/スキップの判断を文書化してください。 担当者が3週間後に「Partner Typeフィールドがなぜなくなったの？」と尋ねてきたとき、書面での記録がある方が良いです。
カスタムフィールド棚卸しテンプレート
| フィールド名 | オブジェクト | タイプ | レポートでの使用 | セグメント利用 | 自動化利用 | 判断 | 備考 |
|---|---|---|---|---|---|---|---|
| Partner Type | コンタクト | ピックリスト | あり（1件） | あり（1リスト） | なし | 移行 | パートナーレポートで使用 |
| Legacy Territory | アカウント | テキスト | なし | なし | なし | アーカイブ | 新しい担当エリアモデルに置き換え |
| MQL Score (手動) | コンタクト | 数値 | なし | なし | なし | スキップ | 自動スコアリングに置き換え |
| Referral Source Detail | コンタクト | テキスト | あり（2件） | なし | なし | 移行 |
ステップ4：ピックリスト値の変換
ピックリストフィールドは移行における最もリスクの高いフィールドタイプです。シンプルに見えますが複雑さを隠しています。ソース値が移行先値と一致しないことが多く、一致しない値は空白でインポートされるかエラーになります。
プロセス：
- ソースからピックリストフィールドごとのすべての異なる値をエクスポートする
- 移行先の対応フィールドで許可されているすべての値をエクスポートする
- 値から値への明示的なマッピングを作成する
- 移行先に対応する値がないソース値の扱いを決定する
ピックリストマッピングテンプレート
例：リードステータス / ライフサイクルステージ
| ソース値 | 件数 | 移行先値 | 処理方法 |
|---|---|---|---|
| New | 1,450 | Lead | 直接マッピング |
| Working | 680 | Lead | Leadにマッピング |
| Nurturing | 320 | Lead | Leadにマッピング |
| Marketing Qualified | 290 | MQL | 直接マッピング |
| Sales Accepted | 175 | SQL | 直接マッピング |
| Sales Qualified | 210 | SQL | 上と統合 |
| Demo Scheduled | 88 | SQL | SQLにマッピング＋活動メモ追加 |
| Proposal Sent | 62 | SQL | SQLにマッピング |
| Customer | 2,400 | Customer | 直接マッピング |
| At Risk | 155 | Customer | Customerにマッピング、「at-risk」タグ追加 |
| Churned | 310 | Customer | Customer（非アクティブ）にマッピング |
| Dead | 890 | Disqualified | Disqualifiedにマッピング |
| Not Interested | 430 | Disqualified | Disqualifiedにマッピング |
移行先に対応する値がない場合：空白のままにしないでください。最も近い移行先値にマッピングするか（変換文書にメモを付けて）、移行先にカスタムフィールドを作成して区別を保持してください。ライフサイクルステージが空白だと、ライフサイクルステージでフィルタリングする自動化にそのレコードが拾われません。
ステップ5：リレーションシップフィールドのマッピング
リレーションシップは最も頻繁に壊れ、事後に修正が最も難しいフィールドマッピングの部分です。
アカウント→コンタクトの関連付け（Salesforce）：Salesforceのすべてのコンタクトは、AccountIdルックアップを通じてアカウントにリンクされています。ほとんどの移行先CRMでは、これがコンタクト→会社の関連付けになります。インポートツールはコンタクトレコードの会社名を既存の会社レコードと照合して、その関係を解決する必要があります。
操作の順序が重要です：まず会社をインポートし、次にコンタクトをインポートします。会社より先にコンタクトをインポートすると、関係を確立できません。
取引→コンタクトの関連付け：SalesforceのOpportunityにはプライマリコンタクトがあり、Opportunity Contact Roleを通じて追加のコンタクトがある場合があります。移行先CRMが1取引に複数のコンタクトの関連付けをサポートするかどうかを確認し、どのコンタクトを移行するかを決めてください。
複数リレーションシップのレコード：一部のコンタクトは複数の会社に関連付けられています（コンサルタント、取締役会メンバーなど）。ほとんどのCRMはこれをSalesforceとは異なる方法で扱います。シャドーインポートでこれらのレコードをいくつか具体的にテストしてください。
親子アカウント階層：Salesforceのアカウントには親アカウントを持つことができます（子会社関係のため）。すべての移行先CRMがこれをネイティブにサポートしているわけではありません。親子階層が移行を生き残るかどうかをマッピング前に把握してください。
ステップ6：フィールドタイプの不一致
フィールドタイプの不一致は最も危険なマッピング問題です。エラーなしにインポートされることが多く、間違ったタイプがデータをサイレントに破壊するからです。
タイプ変換リファレンステーブル
| ソースタイプ | 移行先タイプ | 安全か？ | 必要な変換 |
|---|---|---|---|
| テキスト | テキスト | はい | なし |
| テキスト | ピックリスト | リスクあり | 値がピックリストと一致する必要あり。不一致は失敗 |
| ピックリスト | テキスト | はい | 値はそのままインポート |
| 数値 | テキスト | はい | なし |
| テキスト | 数値 | リスクあり | 数字以外の文字でインポートエラー |
| 通貨 | 数値 | リスクあり | 通貨記号とカンマ区切りを除去 |
| 数値 | 通貨 | はい | なし |
| 日付 | 日時 | はい | T00:00:00Zを追加 |
| 日時 | 日付 | はい | 時間部分を除去 |
| テキスト（日付形式） | 日付 | リスクあり | 先にISO 8601に変換が必要 |
| チェックボックス（真偽値） | テキスト | はい | True/Falseを文字列として |
| テキスト | チェックボックス | リスクあり | True/Falseに正確に標準化が必要 |
| ルックアップ（ID） | 関連付け | リスクあり | 解決ロジックが必要。ほとんどのインポートツールは自動処理しない |
Annual Revenueの問題：これは常に発生します。SalesforceはAnnual Revenueを通貨フィールドとして保存します。一部の移行先CRMは単純な数値として保存します。「$1,250,000.00」のような書式付きの通貨文字列を数値フィールドにインポートすると、インポートエラーになります。インポート前にドル記号とカンマを除去してください：$1,250,000.00を1250000に変換します。プラットフォーム間のCRMデータモデルの違い（フィールドタイプ処理を含む）については、タイプ変換ルールを確定する前にRework対HubSpot CRMが参考になります。
チェックボックスフィールド：システムによって真偽値の表現が異なります。SalesforceはTrue/Falseをエクスポートします。一部のCRMは1/0をインポートします。「Yes」/「No」を要求するものもあります。インポートツールが期待するものを把握して適切に変換してください。
ステップ7：変換ルール文書
直接マッピングでないすべてのフィールドについて、変換ルールを明示的に書き留めてください。この文書がインポートガイドになります。インポートを実行する担当者はその場で判断することなく、この文書に従います。
変換の記法
すべての変換ルールに一貫した形式を使用します：
IF [ソースフィールド] = "[ソース値]"
THEN [移行先フィールド] = "[移行先値]"
ELSE [デフォルトの動作]
例：
IF lead_status = "Dead" OR "Not Interested"
THEN lifecycle_stage = "Disqualified"
IF annual_revenue = テキスト形式 "$N,NNN,NNN.NN"
THEN annual_revenue = REPLACE("$","") + REPLACE(",","") [数値のみ]
IF phone = 任意の形式
THEN phone = E.164形式 (+CC + 加入者番号、区切りなし)
IF close_date = NULL
THEN close_date = [空白のまま、デフォルト日付を設定しない]
IF contact.account_id IS NOT NULL
THEN [移行先の会社名マッチでAccountIdを会社に解決]
ELSE [会社の関連付けなしでスタンドアロンのコンタクトを作成]
単純でないマッピングすべてにルールを記述してください。ルールを書けない場合、まだ判断が下されていません。それが回避しようとしている問題そのものです。
ステップ8：100件のテストレコードでフィールドマップを検証する
フルインポートを実行する前に、100件のテストサンプルに対してすべてのマッピング判断を検証してください。
実際のツールを使用してテストインポートを実行してください。 カットオーバー当日とは異なるインポート方法でテストしないでください。目標はマッピング文書のエラーを表面化させることであり、インポートツールのエラーではありません。
アウトプットのすべてのマッピングフィールドを確認してください：
- テキストフィールドは正しい値を持っているか？
- ピックリストフィールドは移行先の値を表示しているか（ソース値ではなく）？
- 日付フィールドは正しい形式で表示されているか？
- 通貨/数値フィールドはテキストではなく数値としてインポートされているか？
- リレーションシップフィールドは正しい会社/取引レコードに解決されているか？
サイレントエラーを探してください： エラーなしで完了したインポートは、正しいインポートとは異なります。10件のレコードを手動で開いて、ソースと1フィールドずつ比較してください。自動化されたQAはサイレントなタイプ変換エラーを見逃します。これはインポートログではクリーンに見えます。
テストインポートでエラーを見つけた場合、まずマッピング文書を修正してください。移行先のレコードを手動で修正しないでください。それは症状を修正しますが、マッピングファイルに根本原因を残したままにします。次の10,000件のレコードで同じエラーが発生します。
よくある落とし穴
まだ必要かどうかを決めずにカスタムフィールドをマッピングする。 カスタムフィールドの棚卸しステップには理由があります。誰も使わないフィールドを移行すると、担当者が見慣れないフィールドを見て混乱するノイズが移行先CRMに追加されます。
フィールドタイプの不一致を無視する。 「おそらく大丈夫だろう」は、Annual Revenueが初日から収益ダッシュボードを壊すテキストフィールドになる方法です。すべてのタイプの不一致を明示的にチェックしてください。
変換ルールを文書化せず、後で忘れる。 ライフサイクルステージの値マッピングを考え出すのに90分かかります。3週間後に誰かが「Leadsが 'Unknown'とレポートに表示されるのはなぜか」と尋ねたとき、その文書が欲しくなります。新鮮なうちに書き留めてください。このマッピング作業の基準となるライフサイクルステージの定義については、リードライフサイクルステージで標準的な進行とほとんどのチームが逸脱する箇所が解説されています。
ルックアップ/関連付けフィールドを通常のフィールドと同じように扱う。 リレーションシップフィールドには、関連付けられたレコードが移行先に既に存在している必要があります。コンタクトより先に会社をインポートすると、すべての会社の関連付けがサイレントに失敗します。インポートの順序はフィールドマッピングの判断の一部です。
クリーンなレコードのみでテストする。 テストサンプルにはエッジケースが含まれている必要があります：NULL値のレコード、最大フィールド長のレコード、特殊文字のあるレコード。クリーンなデータで機能するマッピングは、乱雑なケースをスキップすると実際のデータで失敗します。
次のステップ
今週、ソースのオブジェクトスキーマをエクスポートしてください。ほとんどのCRMにはタイプ情報付きのフィールドリストをダウンロードする方法があります：
- Salesforce：スキーマビルダー（視覚的）またはSalesforce Workbench経由の
describe()呼び出し。WorkbenchはAPIネームとタイプを含む完全なフィールドリストを1回のエクスポートで提供します - HubSpot：設定 > プロパティ > エクスポート
- Pipedrive：設定 > データフィールド
- Zoho：設定 > カスタマイズ > フィールド。ZohoのCRM移行リソースではフィールドタイプ参照の完全なオブジェクトスキーマが記載されています
各ソースフィールドを含むスプレッドシートを作成し、移行先フィールド列を埋め始めてください。この段階では、大まかな最初のパスでも価値があります。難しいケース（ピックリストの不一致、タイプの競合、対応する移行先がないフィールド）を発見し、カットオーバー当日の危機になる前に判断を始められます。フィールドマッピングが完成してテストが済んだら、CRMのロールアウトと採用でチームを初日に向けて準備する方法が解説されています。
