「CRMを導入したのに、データがぐちゃぐちゃで結局使い物にならない」
「項目が多すぎて現場が入力しない」「レポートを出そうとしても、欲しい切り口で集計できない」「担当者が異動したら、誰がどの商談を持っているのか分からなくなった」
CRM導入支援の現場では、こうした声を数多く耳にします。そして、これらの問題の根本原因はほぼ例外なく、導入前のデータベース設計にあります。CRMは単なるソフトウェアではなく、ビジネスの情報基盤です。その基盤の設計図であるデータベース設計が曖昧なまま導入を進めれば、運用が破綻するのは時間の問題です。
本記事では、数多くのCRM設計案件から体系化した知見をもとに、CRMデータベース設計の3つの構成要素である「オブジェクト」「プロパティ」「関連付け（アソシエーション）」の設計思想を解説します。単に「何をどう設定するか」ではなく、「なぜそう設計するのか」という設計哲学レベルの理解を提供します。具体例としてHubSpotのデータ構造を取り上げながら、どのCRMにも応用可能な普遍的な設計原則をお伝えします。
CRMの導入プロジェクトにおいて、ツール選定やデータ移行に注力する企業は多い一方で、データベース設計に十分な時間を割く企業は驚くほど少ないのが実情です。導入支援の現場では、運用開始後に「使いづらい」「データが汚い」「レポートが出せない」といった問題が噴出するケースの大半が、設計段階の不備に起因しています。
データベース設計とは、いわば「CRMの骨格」を決める作業です。どんな情報を、どんな単位で、どのような関係性で管理するかを決定する設計が甘ければ、その上に構築されるすべての運用プロセスが歪みます。逆に、設計が的確であれば、入力も・蓄積も・活用もスムーズに回り始めます。
CRMの価値は「入力→蓄積→活用」のデータサイクルが回って初めて生まれます。このサイクルが回る設計とは、以下の3条件を満たすものです。
この3条件のどれか一つでも欠けると、サイクルは止まります。入力が煩雑なら現場は入力しなくなり、蓄積されたデータが汚れていればレポートの信頼性が失われ、活用できないデータに対して入力するモチベーションは生まれません。データベース設計は、このサイクルを最初から組み込むための起点なのです。
CRMのデータベースは、基本的に「オブジェクト」「プロパティ」「関連付け（アソシエーション）」という3つの構成要素で成り立っています。HubSpotではこの3つが明確に定義されていますが、この概念はSalesforceやZoho CRMなど他のCRMにも共通する普遍的な構造です。
オブジェクトとは、CRM上でデータを格納する「テーブル」のことです。HubSpotのデータ構成では、データがいくつかのテーブル形式で管理されており、初期から存在する「標準オブジェクト」と、業務に応じて追加できる「カスタムオブジェクト」に分かれています。
多くのCRMでは、ビジネスに共通して必要となる情報を管理するための標準オブジェクトがあらかじめ用意されています。HubSpotの場合、以下の4つが基本の標準オブジェクトです。
| オブジェクト | 役割 | 管理する情報の例 |
|---|---|---|
| 会社（Company） | 取引先企業の情報を管理 | 企業名、業種、従業員数、所在地 |
| コンタクト（Contact） | 個人（担当者）の情報を管理 | 氏名、メールアドレス、電話番号、役職 |
| 取引（Deal） | 商談・案件の情報を管理 | 案件名、金額、ステージ、クローズ予定日 |
| チケット（Ticket） | 問い合わせ・サポート案件を管理 | 問い合わせ内容、優先度、ステータス、担当者 |
ここで重要なのは、「人」と「組織」を分けて管理するという設計思想です。コンタクトには個人の情報が格納され、そのコンタクトがどの会社に所属しているのかを別のオブジェクトで管理します。これにより、一人の担当者が転職しても、その人の情報と企業の情報を独立して追跡できます。
同様に、「商談」と「サポート」を別オブジェクトにすることで、営業プロセスとカスタマーサポートのプロセスを独立して管理・レポートできるようになります。
標準オブジェクトで表現できない業務データがある場合、カスタムオブジェクトの追加を検討します。ただし、安易なカスタムオブジェクトの追加は複雑性を増大させるため、以下の判断基準で検討するのが望ましいです。
例えば、「契約」「製品」「プロジェクト」「拠点」など、標準オブジェクトでは表現しきれない情報がカスタムオブジェクトの候補になります。カスタムオブジェクトの設計についてより深く知りたい方は、関連記事「カスタムオブジェクト設計ガイド」もあわせてご参照ください。
プロパティとは、各オブジェクトに紐づく個別のデータ項目です。会社オブジェクトであれば「企業名」「業種」「電話番号」、コンタクトオブジェクトであれば「氏名」「メールアドレス」「役職」、取引オブジェクトであれば「金額」「ステージ」「クローズ予定日」などが該当します。
オブジェクトと同様に、プロパティにも最初から用意されている「標準プロパティ」と、自社の業務に合わせて追加する「カスタムプロパティ」があります。
| 区分 | 特徴 | 注意点 |
|---|---|---|
| 標準プロパティ | CRMに初期搭載されている汎用的な項目。システムとの連携や自動処理の基盤になる | 削除・変更に制約がある場合がある。まず標準プロパティで対応できないか検討する |
| カスタムプロパティ | 自社固有の業務要件に合わせて自由に追加できる項目 | 増やしすぎると入力負荷が上がり、データの鮮度が下がる |
導入支援の現場で繰り返し見てきた失敗パターンから、プロパティ設計には以下の3原則を推奨します。
原則1: 必要十分に絞る
「あれば便利かもしれない」という項目は、ほぼ確実に入力されません。「このプロパティは誰が、いつ、何のために入力するのか」を明確にできない項目は作らないのが鉄則です。初期は最小限の項目でスタートし、運用の中で必要性が証明されたものを追加していくアプローチが有効です。
原則2: 命名規則を統一する
プロパティ名がバラバラだと、検索性が下がり、重複プロパティの温床になります。例えば「顧客ランク」「取引先ランク」「企業グレード」が同じ意味で乱立するような状況です。「[オブジェクト名]_[カテゴリ]_[項目名]」のような命名規則を事前に決めておくことが重要です。
原則3: 適切なフィールドタイプを選ぶ
自由入力テキストは入力の自由度が高い反面、データの一貫性が保てません。可能な限り、ドロップダウン（選択式）、数値、日付など、構造化されたフィールドタイプを選択しましょう。例えば「業種」は自由入力ではなく選択式にすることで、レポートでの集計が正確になります。
関連付け（アソシエーション）とは、オブジェクト間の関係性を定義するものです。この設計が、CRMデータベースの「立体的な構造」を形づくります。
HubSpotの標準的な関連付けを例にとると、以下のような関係性が定義されています。
この関連付けにより、例えば一つの会社レコードを開くだけで「この会社の担当者は誰か」「進行中の商談はいくつあるか」「過去のサポート履歴はどうか」を一覧できるようになります。
関連付けの設計では、「1対多」と「多対多」の関係性をどう設定するかが重要な判断ポイントになります。
| 関係タイプ | 説明 | 具体例 |
|---|---|---|
| 1対多 | 一方のレコードに対して、もう一方が複数紐づく | 1つの会社に複数のコンタクトが所属する |
| 多対多 | 双方のレコードが互いに複数紐づく | 1つの取引に複数のコンタクトが関与し、1人のコンタクトが複数の取引に関与する |
判断の基準はシンプルです。「Aの1レコードに対して、Bは常に1つだけか？それとも複数ありうるか？逆方向はどうか？」を問うだけです。BtoB企業の場合、一つの商談に複数の担当者（意思決定者・技術担当・窓口担当など）が関与するケースが一般的なので、コンタクトと取引は多対多の関連付けが適切です。
オブジェクト・プロパティ・関連付けの構成要素を理解した上で、それらをどう組み合わせるかの指針となる5つの設計原則を紹介します。
データベース設計は、自社のビジネスプロセスの写像であるべきです。「リードの獲得 → 商談化 → 提案 → 受注 → 納品 → サポート」という自社の業務フローを明確にし、各ステップで「誰が」「どんな情報を」「どう使うのか」を洗い出すことが設計の出発点です。ツールの機能ありきではなく、業務ありきで設計しましょう。
「最終的にどんなレポートを見たいか」を先に決め、そこから逆算してプロパティやオブジェクトを設計するアプローチが有効です。例えば、「業種別の商談成約率」を見たいなら、会社オブジェクトに「業種」プロパティが必要であり、取引オブジェクトに「成約/失注」のステータスが必要です。レポート要件を先に定義することで、不要なプロパティの乱立を防げます。
どれほど理想的な設計でも、現場が入力しなければデータは溜まりません。設計段階で「この項目を入力する人の負荷」を常に意識することが重要です。具体的には、必須項目を最小限にする、選択式を活用して入力速度を上げる、自動入力やデフォルト値を設定するといった工夫が効果的です。
同じ情報が複数の場所に存在する「データの重複」は、CRM運用における最大の敵です。例えば、会社名をコンタクトのプロパティにも持たせてしまうと、会社名が変更された際に不整合が発生します。情報は原則として1か所で管理し、関連付けを通じて参照する設計にしましょう。メールアドレスや会社ドメインなど、レコードの一意性を担保するキー項目を明確に定義しておくことも重要です。
ビジネスは変化します。新しい事業部ができたり、サービスラインが増えたり、海外展開が始まったりすることを想定し、将来の変化に対応できる柔軟な設計にしておくことが大切です。具体的には、プロパティの選択肢に余白を持たせる、カスタムオブジェクトの追加を見越した関連付け構造にする、命名規則を拡張に耐えるものにするといった配慮が求められます。
BtoB企業におけるCRMデータベースの基本パターンは、以下の構造です。
| 階層 | オブジェクト | 位置付け |
|---|---|---|
| 第1階層 | 会社 | 最上位の管理単位。取引先企業の器 |
| 第2階層 | コンタクト | 会社に所属する担当者。営業活動の直接的な接点 |
| 第3階層 | 取引 | コンタクト・会社に紐づく商談。売上の源泉 |
| 第4階層 | チケット | 受注後の問い合わせ・サポート案件 |
この基本パターンでは、「会社Aの山田さん（コンタクト）が担当する商談X（取引）から、導入後に問い合わせY（チケット）が発生した」という一連の流れが、関連付けによって自然に追跡できます。
コンタクトにはライフサイクルステージ（リード→MQL→SQL→商談→顧客）を設定し、取引にはパイプラインとステージ（見込み→商談中→内示→クローズ）を設定することで、営業プロセス全体の進捗を可視化できます。パイプライン設計の詳細は、関連記事「パイプライン設計ガイド」で解説しています。
事業が複数ある場合や、営業プロセスが異なる商材を扱う場合は、複数のパイプラインを設定することで対応できます。例えば「新規営業パイプライン」と「既存顧客アップセルパイプライン」を分けることで、それぞれのプロセスに適したステージ管理とレポーティングが可能になります。
さらに、「契約管理」「製品マスタ」「プロジェクト管理」など、標準オブジェクトでは表現しきれないデータが必要な場合は、カスタムオブジェクトを追加して対応します。ただし、カスタムオブジェクトは増やしすぎると管理が複雑になるため、本当に独立した管理単位として必要かどうかを慎重に判断しましょう。
数多くの設計案件から見えてきた、典型的な設計ミスとその対処法を紹介します。
| 設計ミス | よくある症状 | 対処法 |
|---|---|---|
| プロパティの乱立 | カスタムプロパティが数百個に膨れ上がり、入力率が極端に低下。どの項目が正式かわからない | プロパティの棚卸しを行い、入力率の低い項目を統廃合する。新規追加は申請制にする |
| 関連付けの設計ミス | コンタクトと会社が紐づいていない。取引がどの会社のものか不明。レポートで正しい数字が出ない | 関連付けルールを明文化し、レコード作成時に関連付けを必須化する。定期的に未関連付けレコードを監査する |
| ライフサイクルステージの曖昧な定義 | 「リード」と「MQL」の違いを誰も説明できない。ステージの進行基準が人によって異なる | 各ステージの定義と進行条件を文書化し、全員に共有する。可能であれば自動化ルールで進行を制御する |
| 重複レコードの放置 | 同じ会社が複数レコードで存在し、情報が分散。正しい全体像が把握できない | 一意キー（ドメイン、メールアドレス等）を定義し、重複チェックの仕組みを導入する。データクレンジングの方法については関連記事で詳しく解説 |
| すべてを1つのオブジェクトに詰め込む | コンタクトに商談情報も契約情報も入れてしまい、1レコードが肥大化。履歴管理ができない | 情報の性質に応じてオブジェクトを分離し、関連付けで接続する。「1つのオブジェクト＝1つの概念」を徹底する |
CRMにおけるAI活用は急速に進んでいますが、AIが正しく機能する前提条件は、整理されたデータベース設計です。AIは与えられたデータの質以上のアウトプットを出すことはできません。
例えば、AIによる商談の成約予測は、取引オブジェクトのステージ遷移データと、関連するコンタクト・会社の属性情報を学習データとして使います。ここでステージの定義が曖昧だったり、関連付けが不完全だったりすると、予測精度は著しく低下します。
同様に、AIによる自動メール生成やレコメンデーションも、コンタクトのプロパティが正確に入力されていて初めて精度の高い結果を返します。つまり、データベース設計の品質は、将来のAI活用の天井を決めるのです。
「今すぐAIを使う予定はないから関係ない」と考えるのは早計です。データは蓄積に時間がかかります。将来のAI活用を見据えて、今のうちからきれいなデータが溜まる設計にしておくことが、長期的な競争優位につながります。
CRMデータベース設計は、「オブジェクト」「プロパティ」「関連付け（アソシエーション）」の3つの構成要素で成り立っています。この設計の良し悪しが、CRM運用の成否を根本から左右します。
本記事で解説した設計のポイントを整理すると、以下の通りです。
データベース設計は一度決めたら終わりではなく、ビジネスの変化に合わせて継続的に見直すものです。まずは本記事で紹介した基本パターンと設計原則をベースに設計を始め、運用の中で改善を重ねていくアプローチを推奨します。
A. 基本構造（オブジェクトと主要な関連付け）は導入前に固めるべきですが、プロパティの詳細は運用しながら調整するのが現実的です。最初から完璧を目指すより、コアとなる設計を固めた上で「小さく始めて改善する」アプローチが有効です。導入後3ヶ月を目処に、プロパティの利用状況を見直すサイクルを設けることを推奨します。
A. 技術的な上限はCRMの契約プランによって異なりますが、設計の観点では「少なければ少ないほどよい」が原則です。カスタムオブジェクトが増えるほど関連付けの管理が複雑になり、運用負荷が上がります。まずは標準オブジェクトのプロパティで対応できないかを検討し、それでも不十分な場合にのみカスタムオブジェクトを追加しましょう。
A. まず全プロパティの入力率を集計し、入力率が極端に低い項目（目安として20%以下）をリストアップします。次に、それらの項目が本当に必要かをビジネス部門と協議し、不要なものは非表示または削除します。整理の際は、データクレンジングの手法をあわせて活用すると効果的です。
A. 多くのCRMでは関連付けの追加や変更は可能ですが、既存データの関連付けを一括で修正するには手間がかかります。特に大量のレコードがある場合、インポートツールやAPIを使った一括更新が必要になることがあります。そのため、基本的な関連付けの方針は導入前に慎重に設計することが重要です。
A. BtoC企業では「会社」オブジェクトの重要度が下がり、「コンタクト」が中心のデータ構造になります。また、取引の件数が多くなるため、取引オブジェクトのプロパティ設計やパイプラインの設計が変わります。ただし、「オブジェクト・プロパティ・関連付け」という3つの構成要素で設計するという基本的な考え方は同じです。