CRMデータ設計の教科書｜GTMエンジニアが最初に整えるべきデータ基盤

CRMデータ設計とは、営業組織が扱うデータの構造・品質・ガバナンスを体系的に設計することだ。CRM導入プロジェクトの多くは「どのツールを選ぶか」から始まるが、本来最初に取り組むべきはデータ設計である。オブジェクトの関係性、プロパティの定義、命名規則、バリデーション——これらが整っていなければ、どんなCRMを入れてもデータは汚れ、レポートは信頼できず、営業の意思決定を支えるデータ基盤にはならない。本記事では、GTMエンジニアが最初に整えるべきCRMデータ設計の全体像を、オブジェクト設計からデータガバナンスまで体系的に解説する。

CRMデータ設計はなぜ最初に取り組むべきか

結論から言えば、CRMのデータ設計は営業DXにおける最上流工程であり、ここが崩れると下流のすべて——レポート、スコアリング、自動化、AI活用——が機能しなくなる。

多くの企業がCRM導入時に犯す最大の間違いは、ツール選定を先に行い、デフォルト設定のまま運用を開始することだ。HubSpotやSalesforceにはテンプレートが用意されているが、それはあくまで汎用的な出発点であり、自社の営業プロセスに最適化されたものではない。

データ設計を後回しにすると何が起きるか。営業が独自の解釈でデータを入力し、同じ意味のフィールドが複数生まれ、命名規則がバラバラの状態でカスタムプロパティが増殖する。半年後に「ダッシュボードを作りたい」と思ったとき、必要なデータが構造化されておらず、集計も分析もできない。この時点で設計をやり直そうとすれば、既存データの移行・クレンジングに膨大な工数がかかる。

だからこそ、データ設計はCRM導入の最初のフェーズで行うべきだ。設計に1-2週間かけることで、その後の運用における数ヶ月分の手戻りを防げる。CRMのデータが汚いのは営業のせいじゃない、設計のせいだで述べた通り、データ品質の問題は設計品質の問題である。

CRMのオブジェクト設計——データの骨格を定義する

CRMデータ設計の出発点は、オブジェクト（データの入れ物）とその関係性の設計だ。BtoB営業のCRMでは、基本的に以下の4つの標準オブジェクトを中心にデータモデルを構築する。

コンタクト（Contact） — 個人の連絡先情報。営業がやり取りする「人」を管理する。氏名、メールアドレス、役職、電話番号などの属性を持つ。

会社（Company / Account） — 法人の情報。企業名、業界、従業員数、所在地などを管理する。1つの会社に複数のコンタクトが紐づくのが一般的だ。

取引（Deal / Opportunity） — 商談情報。金額、ステージ、受注予定日、担当者などを管理する。パイプラインの構成要素であり、売上予測の基盤になる。

チケット（Ticket / Case） — カスタマーサポートの問い合わせ。受注後の顧客対応を管理し、解約リスクの早期検知にも活用できる。

オブジェクト間のリレーション設計

オブジェクト設計で最も重要なのは、オブジェクト間の関係性（リレーション）を正しく定義することだ。基本的な構造は以下の通りである。

• 会社 → コンタクト: 1対多（1つの会社に複数の担当者がいる）
• コンタクト → 取引: 多対多（1人のコンタクトが複数の商談に関与し、1つの商談に複数のコンタクトが関わる）
• 会社 → 取引: 1対多（1つの会社との間に複数の商談がある）
• コンタクト → チケット: 1対多（1人のコンタクトが複数の問い合わせを持つ）

ここで見落としがちなのが「コンタクトと取引の多対多関係」だ。BtoB営業では、1つの商談に意思決定者・推進者・利用者・技術評価者など複数のステークホルダーが関与する。コンタクトと取引を1対1で管理してしまうと、「この商談に誰が関わっているか」が追えなくなり、ABM（Account-Based Marketing）やマルチスレッド営業の分析ができなくなる。

カスタムオブジェクトの判断基準

標準オブジェクトでカバーできないデータが出てきたとき、カスタムオブジェクトを作るかプロパティで対応するかの判断が必要になる。判断基準はシンプルだ。

• 独自のライフサイクルを持つ → カスタムオブジェクト（例: プロジェクト管理、契約管理）
• 既存オブジェクトの属性にすぎない → カスタムプロパティ（例: 顧客の利用製品名）
• 既存オブジェクトと1対多で紐づく繰り返しデータ → カスタムオブジェクト（例: 見積明細）

カスタムオブジェクトは便利だが、増やしすぎると管理コストが上がる。「本当にオブジェクトとして独立させる必要があるか」を常に問うべきだ。

プロパティ設計の原則——命名・型・必須項目

オブジェクト構造が決まったら、次はプロパティ（フィールド）の設計に入る。ここが最も実務に直結するパートであり、設計の良し悪しが日々の入力品質を左右する。

命名規則の標準化

命名規則を最初に決めず運用を始めると、以下のようなカオスが生まれる。

• industry、業界、Industry_c、company_industry が並立する
• 誰が何のために作ったかわからないフィールドが50個以上ある
• 同じ情報を指すフィールドが複数存在し、どれが正なのか不明

命名規則は以下のフォーマットで統一することを推奨する。

• 形式: オブジェクト略称_カテゴリ_項目名（例: deal_budget_range, contact_lead_source）
• 言語: 英語のスネークケースを基本とし、UIの表示ラベルは日本語で設定する
• 接頭辞: カスタムフィールドには必ず自社略称を接頭辞として付与する（例: hbt_deal_lost_reason）

接頭辞を付けることで、標準フィールドとカスタムフィールドの区別が一目でつき、ツール間のデータ連携時にも競合を防げる。

データ型の選択基準

プロパティのデータ型は「どう分析に使うか」から逆算して選ぶ。よくある間違いと正しい選択を示す。

• 業界: テキストではなく「単一選択」。テキストにすると「IT」「IT業界」「情報通信」が混在する
• 従業員数: 数値型ではなく「単一選択（レンジ）」。正確な数字を営業は知らないので「1-50名」「51-200名」のレンジで十分
• 予算: 数値型。集計・平均・合計の計算に使うため、選択式にすると分析幅が狭まる
• 失注理由: 単一選択＋連動する詳細選択の2階層構造が最適解

「とりあえずテキストで」は設計の放棄だ。テキスト型のフィールドは集計・フィルタ・レポートに使えない。構造化できるデータは必ず選択式にすべきである。

必須項目のステージ連動設計

必須項目は「多ければ安心」ではない。商談の初期段階で不明な情報を必須にしても、営業は「未定」と入力するだけだ。必須項目はステージの進行に合わせて段階的に増やす設計が正しい。

• 商談作成時（最大5項目）: 会社名、コンタクト名、リードソース、商談名、概算金額
• ヒアリング完了時に追加: 課題カテゴリ、予算レンジ、導入時期、決裁プロセス
• 提案時に追加: 競合情報、提案金額、提案日
• クロージング時に追加: 受注/失注理由、契約開始日

この設計はHubSpotのRequired PropertiesやSalesforceのValidation Ruleで実装できる。ポイントは、営業が「そのステージで自然に知っている情報」だけを求めることだ。

データクレンジングの実践——品質を仕組みで担保する

データクレンジングとは、CRM内の不正確・重複・不完全なデータを検出し、修正・統合するプロセスだ。導入時の初期クレンジングと、運用中の継続的クレンジングの2つのフェーズがある。

重複排除（デデュプリケーション）

重複データはCRMの品質を最も確実に破壊する。同じ企業が「株式会社ABC」「(株)ABC」「ABC株式会社」として3レコード存在すると、商談履歴が分散し、営業が過去の接点を把握できなくなる。

重複排除のアプローチは以下の通りだ。

1. マッチングキーの定義: メールアドレス（コンタクト）、法人番号またはドメイン名（会社）を一意キーとする
2. ファジーマッチング: 完全一致だけでなく、表記揺れ（株式会社 / (株) / KK）も検出対象にする
3. マージルール: 重複レコードの統合時に、どちらのデータを優先するかのルールを事前に決める（最終更新日が新しい方、入力項目が多い方、等）
4. 予防策: 新規レコード作成時に既存レコードとの重複チェックを自動で走らせる

HubSpotには重複管理機能が標準で搭載されており、Salesforceでは重複ルールとマッチングルールで同等の仕組みを構築できる。

正規化とバリデーションルール

正規化とは、データの表記・形式を統一することだ。電話番号、住所、会社名などが対象になる。

• 電話番号: 03-1234-5678、0312345678、+81312345678 → 統一形式に正規化
• 会社名: 法人格の位置（前株/後株）、全角/半角、スペースの有無を統一
• メールアドレス: 小文字に統一、不正形式の検出

バリデーションルールは、不正なデータの入力を入口で防ぐ仕組みだ。Salesforceでは数式ベースのValidation Ruleを設定でき、HubSpotではワークフローとプロパティの入力規則で同様の制御ができる。入力後にクレンジングするより、入力時点で品質を担保する方が圧倒的にコストが低い。

HubSpotとSalesforceのデータモデル比較

CRMデータ設計を語る上で、二大プラットフォームであるHubSpotとSalesforceのデータモデルの違いを理解しておく必要がある。

HubSpotのデータモデル

HubSpotの標準オブジェクトは、コンタクト・会社・取引・チケットの4種類。オブジェクト間の関連付けはGUIで直感的に操作でき、標準の関連付けタイプ（1対多、多対多）が事前に定義されている。カスタムオブジェクトはEnterprise以上のプランで利用可能であり、APIやインポートでの作成に対応する。

HubSpotの強みは「設定のシンプルさ」にある。プロパティの作成、パイプラインの設計、ワークフローの構築がすべてGUIで完結し、管理者の学習コストが低い。一方で、オブジェクト間のリレーションの柔軟性はSalesforceに劣る部分がある。複雑な参照関係や自己参照が必要なケースでは制約を感じることがある。

Salesforceのデータモデル

Salesforceはリード・取引先・取引先責任者・商談を標準オブジェクトとして持ち、カスタムオブジェクトの作成に制限が少ない。ルックアップ関係と主従関係の2種類のリレーションを柔軟に定義でき、複雑なデータ構造にも対応する。数式フィールド、ロールアップ集計、Validation Ruleなど、データ整合性を保つための機能が豊富だ。

Salesforceの強みは「拡張性」である。組織固有のビジネスロジックをデータモデルに組み込める自由度が高い。ただし、その自由度ゆえに設計が複雑化しやすく、専任のアドミニストレーターやコンサルタントが必要になるケースが多い。

選定の判断軸

観点	HubSpot	Salesforce
営業組織の規模	50名以下に最適	50名以上で真価を発揮
カスタマイズ性	標準で十分なら強い	複雑要件に強い
管理者の学習コスト	低い（GUI完結）	高い（設計知識が必要）
カスタムオブジェクト	Enterprise以上	全プランで利用可能
マーケティング連携	標準で統合	Pardot等の追加導入が必要
初期コスト	低い（無料CRMあり）	高い（ライセンス費用）

どちらのプラットフォームを選んでも、本記事で述べたデータ設計の原則は共通だ。ツール選定の前にデータ設計を行い、設計に基づいてツールを評価するのが正しい順序である。

データガバナンスの仕組み構築

データ設計は「作って終わり」ではない。組織が成長し、CRMの利用者が増えるにつれて、設計は劣化していく。これを防ぐのがデータガバナンスだ。

権限設計

「誰が何を編集できるか」を制御する権限設計は、データ品質の防波堤になる。基本的な設計方針は以下の通りだ。

• フィールドの作成・削除: CRM管理者（GTMエンジニアまたはRevOps担当）のみ
• レコードの作成・編集: 営業担当者は自分の担当レコードのみ。マネージャーはチーム全体
• レコードの削除: マネージャー以上、または管理者の承認制
• 一括インポート/エクスポート: 管理者のみ

特に重要なのは「フィールドの作成権限」の制限だ。営業マネージャーが独自にカスタムフィールドを追加し始めると、命名規則が崩壊し、重複フィールドが増殖する。フィールドの追加はリクエスト制にし、管理者が命名規則・データ型・使用目的を確認した上で作成する運用が望ましい。

変更管理

データモデルの変更（フィールドの追加・削除・型の変更、パイプラインの変更など）は、変更管理プロセスを通して行う。

1. 変更リクエスト: 誰が・なぜ・何を変更したいかを記録する
2. 影響分析: その変更がレポート、ワークフロー、インテグレーションに与える影響を確認する
3. 承認: 管理者が承認し、変更を実施する
4. 通知: 関係者に変更内容を周知する

この運用を面倒に感じるかもしれない。しかし、「誰かが知らないうちにフィールドの選択肢を変えて、ワークフローが壊れた」という事故は、変更管理がない組織で必ず発生する。

品質モニタリング

データ品質は放置すれば劣化する。定期的にモニタリングし、問題を早期に検出する仕組みが必要だ。以下の指標を月次でチェックすることを推奨する。

• 入力率: 主要フィールドの入力率が80%を下回っていないか
• 重複率: 新規作成レコードのうち、重複が検出された割合
• 鮮度: 最終更新日が60日以上前のアクティブな商談がないか
• 「その他」率: 選択式フィールドで「その他」が30%以上を占めていないか（選択肢の再設計が必要なシグナル）
• NULL率: 必須ではないが重要なフィールドの未入力率

リードスコアリングの精度も、元データの品質に完全に依存する。スコアリングモデルの改善以前に、データ品質のモニタリングが前提条件だ。

まとめ——データ設計は営業組織の「OS」である

CRMデータ設計は、営業組織のオペレーティングシステムを構築する行為だ。OSが不安定であれば、どんなアプリケーション（レポート、自動化、AI）を載せても正しく動かない。

本記事で解説した設計プロセスを整理する。

1. オブジェクト設計: コンタクト・会社・取引・チケットの関係性を正しく定義する
2. プロパティ設計: 命名規則を標準化し、データ型を分析目的から逆算して選び、必須項目をステージ連動で設計する
3. データクレンジング: 重複排除と正規化を初期・継続の両面で実施する
4. プラットフォーム選定: 自社の規模と要件に合ったCRMを、データ設計に基づいて評価する
5. データガバナンス: 権限設計・変更管理・品質モニタリングの3層で品質を維持する

この設計を主導するのがGTMエンジニアの役割だ。ツールの設定ではなく、営業プロセスとデータ構造の両方を理解した上での設計行為——それがCRMデータ設計の本質であり、営業DXの土台になる。