Spreadsheetからの脱出: CRMへの5ステップ移行

著者: Calvin D. · 更新日: 2026年4月18日

12人の営業チームが、spreadsheetを新しいCRMに直接インポートしました。整理されたデータではなく、実際に使っていたファイル、つまり11種類の日付フォーマット、地域別に3つのタブ、誰も作成した覚えがない「maybe」列が混在したファイルを、そのままです。インポートは4分で完了しました。

3ヶ月後も、まだその後片付けをしていました。重複した連絡先レコードが4,000件。3種類の異なるスペルで登録された会社に紐付いた案件。「メール」列に入った電話番号。列ヘッダーがインポートテンプレートと一致しなかったために、間違ったフィールドに入ってしまったメモ。

データ移行自体は難しくありませんでした。省いた準備作業が問題だったのです。

このガイドでは、spreadsheetの移行を「つまらなく」する、つまり計画通りに進む5ステップのプロセスを説明します。開始前にデータ移行前の準備をご確認ください。何を含め、何を除外するかという判断が、以下のすべてのステップを左右します。

Spreadsheet移行が特に複雑な理由

CRMは構造を強制します。Spreadsheetはそうではありません。これが根本的な問題です。

営業チームのspreadsheetは数ヶ月、数年にわたって次のような問題を蓄積します。

Gartnerの営業テクノロジー調査によれば、営業担当者が実際に営業活動に費やす時間は37%未満であり、残りの大部分はデータ入力とCRM管理タスクに費やされています。レガシーなspreadsheetシステムはこれをさらに遅くし、エラーを増やします。

• 複数の日付フォーマット: 「Jan 12, 2024」「2024-01-12」「1/12/24」「先週」がすべて同じ列に混在
• 表記の不統一: 「Acme Corp」「Acme Corporation」「ACME」「Acme」が4社として別々に登録
• 構造的な不整合: 案件と連絡先が同じ行に混在、または連絡先と案件が別ファイルで紐付けフィールドがない
• 履歴が置き換わっている: 案件の「メモ」列にあるメモ、メールスレッドにあるメモ、誰も管理していない別の「履歴」タブにあるメモ
• 複数のソースファイル: メインのspreadsheet、Sarah個人の管理ファイル、メールツールのCSVエクスポート、昨年のカンファレンスで収集したリスト

これらの問題は個別では大したことありませんが、重なると「1回のインポート」が実際にはデータ再構成プロジェクトになります。成功するチームは最初からそう捉えているチームです。

ステップ1: すべてのSpreadsheetを1つのマスターファイルに集約する

何かを整理する前に、まずすべてを見つけます。ほとんどのチームはspreadsheetファイルの数を過小評価しています。

探す場所:

• 共有ドライブ（Google Drive、SharePoint、Dropbox）
• 現在および元の営業担当者の個人ドライブ
• メールの添付ファイル: 「連絡先リスト」「leads」「見込み客」「Pipeline」で検索
• CRMやツールのエクスポート: 別のCRMの無料トライアルを以前使っていた場合はエクスポートしておく
• マーケティングツール: メールプラットフォームの購読者リスト、フォーム送信のエクスポート
• カンファレンスやイベントのリスト: 一度インポートして放置されがちなもの

インベントリの作成:

統合の方法:

すべてのファイルを1つのマスターspreadsheetに結合します。各行の出所を記録する「source_file」列を追加します。これが後でレコードを遡る際の監査証跡になります。まだ重複は削除しないでください。まずすべてを1か所に集めます。

重複候補を特定するための共通キーを使います。連絡先の場合はメールアドレスが最適なキーです。会社名は正規化後（ステップ3参照）のアカウントに使えます。Wikipediaのデータ重複排除の解説は、連絡先レコードの統合に直接適用できるマッチングと統合の手法を説明しています。完全な重複排除の手法（ファジーマッチの処理を含む）はデータクレンジング: 重複排除、正規化、エンリッチメントで解説しています。

ステップ2: CRMのデータモデルを先に定義する

Spreadsheet移行のミスのほとんどは、データがどのような形で届くべきかを決める前に整理を始めてしまうことで発生します。

CRMには固有の構造があります。1行も整理する前に、その構造を理解します。

CRMの標準オブジェクト:

• Contact: 個人（姓、名、メール、電話、役職）
• Account: 会社または組織（名前、ウェブサイト、業種、規模）
• Deal/Opportunity: 営業プロセス（案件名、金額、ステージ、クローズ予定日）
• Activity: 記録されたインタラクション（電話、メール、ミーティング、メモ）

Spreadsheetの列をCRMフィールドにマッピングする:

マスターspreadsheetを開き、列マッピングを作成します。各列について次を決定します。

• どのCRMオブジェクトに属するか（Contact、Account、Deal、Activity）？
• どのフィールドにマッピングされるか？
• 既存のフィールドにマッピングできない場合、カスタムフィールドにすべきか？

CRMフィールドにきれいにマッピングできないものは判断が必要です: カスタムフィールドを作成する、メモフィールドに入れる、または削除する。これらの判断は整理の前に行います。整理しながら決めるのではありません。旧システムと新システム間のフィールドマッピングでは、このようなエッジケースを体系的に処理するフレームワークを提供しています。

ステップ3: マスターファイルを整理する

列マッピングが定義されたら、マスターファイルを整理します。各問題カテゴリを体系的に処理します。

重複排除:

メールアドレスを主要なマッチキーとして重複を特定します。メールがない場合は、姓名と会社名の組み合わせを使います。重複を削除するのではなく、統合します。統合されたレコードは各フィールドで最も完全な情報を保持します。

整理チェックリスト

• 日付フォーマットをYYYY-MM-DDに統一（またはCRMが受け付けるフォーマットに）
• 電話番号を一貫したフォーマットに統一（+81XXXXXXXXXX または(XX)XXXX-XXXXなど）
• 会社名を統一（1社につき1つの表記を決め、一貫して適用）
• すべてのテキストフィールドから前後の空白を削除
• テキストを一貫した大文字・小文字ルールに変換（名前はタイトルケース等）
• メール形式を確認: @マークの欠落、「.cmo」→「.com」などよくある誤りを確認
• 重複を削除（最も完全なレコードを残す）
• 「案件金額」列を整理: 数値のみ、通貨記号と,なし
• ステージの値を新CRMの正確なステージ名にマッピング
• すべてのDealレコードにContactが紐付いているか確認（メールで）
• 「migration_source」列を追加し、値を「spreadsheet_migration_2024」と設定

最後の項目は重要です。移行元フィールドでインポートされたレコードにタグを付けることで、後で移行データのみをフィルタリングし、必要に応じてバッチクリーンアップを実行し、移行前のレコードとgo-live後にチームが追加したレコードを区別できます。

空白の扱い:

CRMで必須のフィールド（通常はContactのメールとAccountの名前）を事前に決定します。必須フィールドが欠けているレコードはインポートに失敗します。欠落した値を探すか、それらのレコードを「要確認」タブに移すか、このパスではインポートしないことを受け入れます。

ステップ4: 50件でテストインポートを実施する

すべてを一度にインポートしないでください。データの複雑さを代表する50件でテストインポートを実施します（エッジケースを含む）。

50件の選び方:

• きれいでシンプルな10件
• 名前に特殊文字が含まれる10件（アクセント記号、アポストロフィ、ハイフン）
• 会社が紐付いていない10件
• ContactとDealがセットになった10件
• 最も問題のあるソースファイルからの10件

テストインポート後の確認事項:

1. 50件すべてがエラーなくインポートされたか？
2. 連絡先の名前が正しく表示されているか（文字化けなし）？
3. ContactとAccountが正しく紐付いているか？
4. Dealレコードが存在し、正しいステージと金額が表示されているか？
5. ActivityレコードM（メモ、最終連絡日）が正しいContactに表示されているか？
6. 「migration_source」フィールドがすべてのレコードに正しく表示されているか？

いずれかのチェックに失敗した場合は、原因を調査し、フルインポートを実行する前にマスターファイルを修正します。よくある原因:

• Spreadsheetの日付フォーマットとCRMが期待するフォーマットの不一致
• SpreadsheetのステージがCRMのステージオプションと完全に一致しない
• 特殊文字を含むExcelファイルの文字エンコードの問題
• フィールドの文字数制限: 一部のCRMフィールドには文字数上限がある

修正し、50件のテストを再実行し、クリーンになるまで繰り返します。このステップには1〜3回の反復が必要です。各反復は15〜30分かかります。無駄な時間ではありません。フルインポートを「つまらなく」するための時間です。より重要な移行の場合は、シャドーインポートによる移行テストでこの概念をcutover前の本番環境に近い環境での検証に拡張できます。

ステップ5: フルインポートとその後の検証

50件のテストがクリーンに完了したら、フルインポートを実行します。

実行前に確認するインポート設定:

• 重複処理: 「新規作成」ではなく「スキップ」または「統合」に設定（既に重複排除済み）
• フィールドマッピング: テストで機能した設定と列からフィールドへのマッピングが一致していることを確認
• 担当者の割り当て: インポートされたレコードをすべて1人の担当者にするか、spreadsheetの列を割り当てに使うかを決定
• エラー処理: CRMのエラーログオプションを使用し、失敗した行がサイレントにスキップされず報告されるようにする

インポート後の検証:

インポートが完了したら、すぐに以下を確認します:

インポートエラーへの対応:

CRMは失敗した行を報告します（通常、失敗したレコードのCSVファイルとエラー理由の列）。それらの行を修正し、失敗したレコードのみで追加インポートを実行します。無視しないでください。

5ステップのまとめ

ほとんどの時間はステップ3にかかります。それが正しいです。インポート自体は数分で終わるはずです。準備こそが本当の作業です。

よくある失敗パターン

**元のSpreadsheetを直接インポートする。**元のファイルは標準化されていません。予測可能な形で失敗します。必ずコピーで作業し、必ず先に整理します。

**1つのファイルにContactとLeadを混在させる。**CRMがContactとLead（またはContactとProspect）を分けている場合、混在したファイルをインポートすると孤立したレコードが生まれます。インポート前に分けてください。

**インポートしたレコードにタグを付けない。**移行から6ヶ月後、インポートしたレコードだけをデータ品質チェックしたくなります。「migration_source」タグがなければ、新しく追加されたレコードと区別できません。Harvard Business Reviewのデータガバナンス調査では、データの出所追跡、つまりどのレコードがどこから来たかを把握することが、長期的なCRMデータ品質を維持するための基礎的なプラクティスであると強調しています。

**検証する前に成功を宣言する。**インポートの完了はインポートの成功を意味しません。行数とサンプルの抽出チェックは30分で完了し、営業チームが問題に遭遇する前にそれを発見できます。

次に取るべき行動

インポートの検証が完了したら、2つのことをすぐに行います。

まず、チームがレコードの追加を始める前に、新しいCRMで重複検出ルールを設定します。Spreadsheetの移行では、重複排除パスで見逃した重複が必ず多少残ります。組み込みの重複検出機能で、新しい重複が蓄積される前に検出できます。

次に、メールスレッドからの案件履歴やメモも移行する場合は、そのデータを同じCRMに追加する前に過去の活動履歴、メモ、メールの取り扱いを確認してください。McKinseyの営業におけるデジタル変革に関する調査によれば、spreadsheetベースからCRMベースへの営業移行に成功した企業は、Pipeline の可視性と予測精度が最大40%向上するとされています。

また、フルインポートを実施する前にテストインポートを実行したい場合は、シャドーインポートによる移行テストでより重要な移行のための構造化された検証プロセスを説明しています。

データに関する根本的な判断、つまり何を移行し、何を残すか、プロジェクト全体のスコープをどう設定するかについては、データ移行前の準備で扱っています。これ以降のすべての判断はここで決まります。

関連ガイド

• データ移行前の準備
• データクレンジング: 重複排除、正規化、エンリッチメント
• シャドーインポートによる移行テスト
• 過去の活動履歴、メモ、メールの取り扱い
• CRMデータモデル設計: カスタムフィールド、オブジェクト、リレーションシップ
• 新入社員のday oneツールセットアップ