CRMデータベース設計の基本｜オブジェクト・プロパティ・関連付けの設計思想

CRMデータベースの3つの構成要素の設計原則 — オブジェクト・プロパティ・関連付け（アソシエーション）の役割と、それぞれの設計で押さえるべきポイントを解説します。

CRMの導入で最もよくある失敗は、「運用を始めてからデータ構造がぐちゃぐちゃになる」というケースです。部門ごとに好き勝手にプロパティを追加し、コンタクトと会社の関連付けが不整合になり、レポートを出そうとしたら必要なデータがどこにもない——こうした状況は、初期のデータベース設計を軽視した結果として起きます。

CRMのデータベース設計は、建物の基礎工事と同じです。後から変更するのは非常にコストがかかります。本記事では、CRMデータベースの3つの構成要素（オブジェクト・プロパティ・関連付け）について、設計思想から具体的な実装パターンまでを体系的に解説します。

この記事でわかること

• CRMデータベースの3つの構成要素の設計原則 — オブジェクト・プロパティ・関連付け（アソシエーション）の役割と、それぞれの設計で押さえるべきポイントを解説します。
• HubSpotを例にした具体的なデータモデル設計パターン — コンタクト・会社・取引・チケットの標準オブジェクトに、何をどう持たせるべきかの判断基準を紹介します。
• プロパティ設計で陥りやすいアンチパターンと回避策 — 自由入力テキストの乱用、命名規則なし、プロパティの重複など、運用破綻につながる典型的な失敗を解説します。
• 関連付け（アソシエーション）の設計がなぜ重要なのか — レポートや自動化の精度を左右する関連付け設計の考え方をお伝えします。

「CRMを導入したがデータが活用できていない」「プロパティが増えすぎて管理できない」という方に、特に読んでいただきたい内容です。

CRMデータベースの全体像

3つの構成要素

さらに深掘りしたい方はパイプラインとライフサイクルステージの設計もあわせてお読みください。

CRMのデータベースは、以下の3つの要素で構成されます。

オブジェクト（Object）: データを格納する「箱」です。HubSpotの標準オブジェクトには、コンタクト（個人）、会社、取引（商談）、チケット（問い合わせ）があります。

プロパティ（Property）: オブジェクトが持つ「属性」です。コンタクトであれば、氏名、メールアドレス、電話番号、ライフサイクルステージなどが該当します。

関連付け（Association）: オブジェクト間の「関係性」です。たとえば、コンタクトAは会社Bに所属している、取引CはコンタクトAと会社Bに関連している、といった関係を表します。

この3つの要素の設計精度が、CRMの活用度を大きく左右します。

なぜ設計が重要なのか

CRMを「顧客台帳」として使うだけなら、設計はそこまで重要ではありません。しかし、CRMを「営業プロセスの管理基盤」「マーケティングの自動化基盤」「経営判断のダッシュボード基盤」として使うのであれば、データ構造の設計は成否を分ける要因になります。

たとえば、「業種別の受注率を分析したい」という要件があったとします。業種情報が会社オブジェクトのプロパティとして設計されていなければ、このレポートは作成できません。後から追加することは可能ですが、過去のデータには業種情報がないため、遡及的な分析ができません。

設計の段階で「将来どんなレポートが必要か」「どんな自動化を実現したいか」を考慮することで、こうした問題を予防できます。

オブジェクトの設計

標準オブジェクトの役割

実務での応用についてはCRM×DWH連携設計で具体例とともに紹介しています。

HubSpotの標準オブジェクトの役割と、格納すべき情報の設計方針を解説します。

コンタクト（Contact）: 個人単位の情報を管理します。氏名、連絡先、役職、ライフサイクルステージなどが含まれます。BtoBでは「意思決定に関与する個人」を管理する単位となります。

設計のポイント: コンタクトはあくまで「個人」の情報を持つ。企業情報（業種、従業員数、売上規模など）はコンタクトではなく会社オブジェクトに持たせる。この区別を曖昧にすると、同じ会社に所属する複数のコンタクトに対して、会社情報の更新を個別に行う必要が出てきます。

会社（Company）: 法人・組織単位の情報を管理します。会社名、業種、従業員数、売上規模、所在地などが含まれます。

設計のポイント: 会社オブジェクトは「ターゲティングとセグメンテーションの基盤」として設計する。ABM（アカウント・ベースド・マーケティング）を実施する場合、会社オブジェクトのプロパティ設計が戦略の精度を直接左右します。

取引（Deal）: 商談・案件単位の情報を管理します。金額、ステージ、クローズ予定日、担当者などが含まれます。

設計のポイント: 取引は「パイプライン管理と売上予測の基盤」だ。一つの会社に対して複数の取引が発生することは一般的であり、取引と会社は「多対一」の関係になります。

チケット（Ticket）: 問い合わせ・サポート案件を管理します。カスタマーサクセスやサポート部門が利用します。

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

標準オブジェクトでカバーできない情報がある場合、カスタムオブジェクトの作成を検討します。ただし、カスタムオブジェクトの乱用はデータモデルの複雑化を招くため、慎重に判断すべきです。

カスタムオブジェクトを検討すべきケース:

• 標準オブジェクトのどれにも該当しない「独立したエンティティ」がある場合（例：サブスクリプション、拠点、プロジェクト）
• そのエンティティに固有のプロパティが複数あり、他のオブジェクトのプロパティとして管理するのが不自然な場合
• そのエンティティが他のオブジェクトと「多対多」の関係を持つ場合

カスタムオブジェクトを避けるべきケース:

• 既存オブジェクトのプロパティとして管理できる情報を、別オブジェクトに切り出そうとしている場合
• 「将来使うかもしれない」という不確実な想定に基づいている場合
• 標準オブジェクトの関連付けを工夫すれば解決できる場合

プロパティの設計

プロパティ設計の5原則

CRMのプロパティ設計で守るべき5つの原則を紹介します。

原則1：目的から逆算する

「このプロパティは何のために存在するのか」を明確にします。レポート用、セグメンテーション用、自動化のトリガー用、営業への情報提供用——目的のないプロパティは作りません。

原則2：データ型を適切に選ぶ

数値で分析したいデータは「数値型」、選択肢から選ぶデータは「ドロップダウン型」、日時で管理するデータは「日付型」にする。「自由記述テキスト」は最小限に留める。テキストフィールドはレポートやセグメンテーションに使えないため、分析基盤としてのCRMの価値を下げる。

原則3：一つのプロパティに一つの情報

「業種・従業員数」のように複数の情報を一つのプロパティに詰め込まない。後からフィルタリングや分析ができなくなる。

原則4：命名規則を統一する

プロパティの命名規則を事前に決めておく。たとえば、「[カテゴリ] - [項目名]」（例：「営業 - 初回商談日」「CS - NPS回答日」）のように統一することで、プロパティが増えても管理しやすくなる。

原則5：定期的に棚卸しする

使われていないプロパティ、重複しているプロパティ、定義が曖昧なプロパティを定期的に洗い出し、整理する。HubSpotの場合、プロパティの利用状況（入力率）を確認できるため、定量的な棚卸しが可能です。

よくあるアンチパターン

アンチパターン1：自由記述フィールドの乱用

「備考」「メモ」「その他」といった自由記述フィールドが大量に存在し、何が入力されているかわからない状態。自由記述に入力された情報は、レポートにもセグメンテーションにも使えない。

アンチパターン2：ドロップダウンの選択肢が多すぎる

業種のドロップダウンに100以上の選択肢があり、営業が選ぶのに時間がかかる。選択肢は10-15個程度に抑え、それ以上の粒度が必要な場合は階層化（大分類→中分類）する。

アンチパターン3：部門ごとに類似プロパティが乱立

マーケが「リードソース」、営業が「流入経路」、CSが「獲得チャネル」という似たようなプロパティを個別に作成し、データが分散する。プロパティの作成ルールと承認プロセスを設けることで防止できる。

関連付け（アソシエーション）の設計

なぜ関連付けが重要なのか

関連付けは、CRMデータベース設計において最も見落とされやすく、かつ最も重要な要素です。

たとえば、ある商談に3名のコンタクトが関与しているとする。取引オブジェクトとコンタクトオブジェクトの関連付けが正しく設計・運用されていなければ、「この取引の意思決定者は誰か」「誰にフォローアップすべきか」がCRM上で把握できない。

HubSpotにおける関連付けの種類

標準関連付け: コンタクト⇔会社、コンタクト⇔取引、会社⇔取引など、標準オブジェクト間のデフォルトの関連付け。

関連付けラベル: Professional版以上で利用可能。「意思決定者」「利用者」「請求先担当者」のように、関連付けの「役割」を定義できる。BtoBの商談では、意思決定者・推進者・利用者・反対者などの役割を関連付けラベルで管理することで、アカウントマップをCRM上で可視化できる。

カスタムオブジェクトの関連付け: カスタムオブジェクトと標準オブジェクトの関連付けを設計する。関連付けの方向（一対多 or 多対多）と目的を明確にする。

関連付け設計の実践ガイド

ステップ1：エンティティ関連図を描く

CRM上で管理する主要なオブジェクト（コンタクト、会社、取引、チケット、カスタムオブジェクト）のER図を描き、それぞれの関係性を可視化する。

ステップ2：カーディナリティを定義する

各関連付けの多重度を定義する。一対一、一対多、多対多のいずれか。たとえば、コンタクトと会社は「多対多」（一人が複数の会社に関与し、一社に複数のコンタクトが所属する）だが、実務上は「一人は一つの会社に所属」という運用ルールを設けることも多い。

ステップ3：関連付けラベルを設計する

特にコンタクトと取引の関連付けでは、ラベルの設計が重要です。「意思決定者」「技術評価者」「チャンピオン」「エンドユーザー」などのラベルを設計し、営業が商談登録時に設定するルールを定める。

設計プロセスの進め方

フェーズ1：要件の整理

CRM導入の目的と、達成したいゴールを整理する。「どんなレポートが必要か」「どんな自動化を実現したいか」「どの部門がどんな情報を参照するか」を洗い出し、必要なデータ要素を特定する。

フェーズ2：データモデルの設計

オブジェクト、プロパティ、関連付けを設計する。ER図を作成し、関係者でレビューする。この段階で「将来の拡張性」を考慮しておくことが重要です。

フェーズ3：実装とテスト

CRM上にデータモデルを実装し、テストデータで動作確認する。特にレポートの出力と自動化ワークフローの動作を検証する。

フェーズ4：運用ルールの策定

データの入力ルール、プロパティの追加・変更プロセス、定期的な棚卸しのスケジュールを策定する。運用ルールなしにCRMを運用すると、3ヶ月もすればデータの品質が劣化し始める。

データモデルを壊さない変更管理のルール

CRMデータベース設計で見落とされがちなのが、初期設計よりも「変更管理」です。導入直後はきれいだったデータモデルが、半年後に崩れてしまう原因の多くは、部門ごとの場当たり的なプロパティ追加にあります。

変更管理では、少なくとも以下の3区分を明確にします。

• 新規追加: 何の意思決定に使う項目かを定義してから作る
• 仕様変更: 型変更や必須化の影響範囲を事前に確認する
• 廃止: 参照レポートとワークフローを洗い出してから止める

実務では「営業から要望があったので項目を増やす」が最も危険です。項目追加そのものより、同義項目の重複、選択肢の乱立、レポート定義の分断を招くからです。

おすすめは、月1回のデータガバナンス会議で変更申請をまとめてレビューする運用です。申請理由、利用レポート、入力主体、将来の削除条件まで決めてから追加すれば、CRMは長く使える基盤になります。

CRMで実現するCRMデータベース設計の基本

CRMデータベース設計の基本を実務に落とし込むには、CRMツールの活用が不可欠です。詳しくは「CRM導入の進め方完全ガイド｜準備・ツール選定・データ移行・定着化の全ステップ」で解説しています。

このテーマに関連する記事はCRM基礎・導入カテゴリで網羅的にまとめています。

あわせて読みたい

• 医療・クリニックのCRM活用ガイド｜患者管理・予約・リマインドをCRMで効率化する方法
• カスタマーサクセスとCRM｜既存顧客の維持・拡大をデータドリブンで実現する方法
• SFAの選び方と主要ツール比較｜営業現場が本当に使えるSFAの見極め方

まとめ

CRMデータベース設計は、オブジェクト・プロパティ・関連付けの3つの要素を、目的から逆算して体系的に設計することが鍵だ。特に、プロパティの型選択と関連付けの設計は、後からの変更コストが大きいため、初期段階で慎重に設計する必要がある

実践にあたっては、以下のポイントを押さえておくことが大切です。

• 「完璧な設計」を最初から目指す必要はありませんが、「設計の原則」を押さえたうえで開始することで、運用開始後の手戻りを大幅に削減できます
• CRMは導入がゴールではなく、蓄積されたデータを活用して事業成果につなげることがゴールです
• そのためには、データの入口であるデータベース設計に、十分な時間と労力を投資する価値があります

よくある質問（FAQ）

Q. CRMのデータベース設計はどのくらいの期間が必要ですか？

企業規模と要件の複雑さによりますが、標準的なBtoB企業（従業員50-300名）であれば、要件整理に2週間、データモデル設計に2週間、実装・テストに2週間で、合計1-1.5ヶ月程度が目安です。複数部門が利用する場合は、各部門の要件ヒアリングに追加の時間が必要になります。

Q. 既にCRMを運用しているが、データ構造がぐちゃぐちゃな場合どうすればよいですか？

まず、現状のオブジェクト・プロパティ・関連付けの棚卸しを行い、「使われているもの」と「使われていないもの」を分類します。次に、理想のデータモデルを設計し、現状とのギャップを特定します。一度にすべてを修正するのではなく、「レポートに影響するプロパティの統合」「重複プロパティの削除」など、優先度をつけて段階的にリファクタリングするのが現実的なアプローチです。

Q. カスタムオブジェクトはどのくらいの数まで作ってよいものですか？

明確な上限はありませんが、経験上、カスタムオブジェクトが5つを超えるとデータモデルの複雑性が急激に増します。まずは標準オブジェクトとプロパティの組み合わせで要件を満たせないかを検討し、それでも不十分な場合にのみカスタムオブジェクトを作成することを推奨します。作成する場合は、必ずER図を更新して全体の関連付けを可視化しておきましょう。

Q. HubSpotの無料プランでもデータベース設計は重要ですか？

無料プランでも同様に重要です。むしろ、無料プランは利用可能なプロパティ数やカスタマイズの幅に制限があるため、より効率的な設計が求められます。「将来有料プランに移行した際にスムーズに拡張できる」ように、標準オブジェクトの関連付けと基本プロパティの設計を最初からしっかり行っておくことが、長期的なコスト削減につながります。