CRMの導入で最もよくある失敗は、「運用を始めてからデータ構造がぐちゃぐちゃになる」というものだ。部門ごとに好き勝手にプロパティを追加し、コンタクトと会社の関連付けが不整合になり、レポートを出そうとしたら必要なデータがどこにもない——こうした状況は、初期のデータベース設計を軽視した結果として起きる。
CRMのデータベース設計は、建物の基礎工事と同じだ。後から変更するのは非常にコストがかかる。本記事では、CRMデータベースの3つの構成要素（オブジェクト・プロパティ・関連付け）について、設計思想から具体的な実装パターンまでを体系的に解説する。
本記事はStartLinkの「BtoBマーケティング完全ガイド」関連記事です。
本記事では、HubSpotの活用における重要なポイントを体系的にまとめています。導入前の検討段階から運用改善まで、どのフェーズにいる方にも参考になる内容ですので、ぜひ最後までお読みください。
CRMのデータベースは、以下の3つの要素で構成される。
オブジェクト（Object）: データを格納する「箱」。HubSpotの標準オブジェクトには、コンタクト（個人）、会社、取引（商談）、チケット（問い合わせ）がある。
プロパティ（Property）: オブジェクトが持つ「属性」。コンタクトであれば、氏名、メールアドレス、電話番号、ライフサイクルステージなど。
関連付け（Association）: オブジェクト間の「関係性」。たとえば、コンタクトAは会社Bに所属している、取引CはコンタクトAと会社Bに関連している、といった関係。
この3つの要素の設計精度が、CRMの活用度を大きく左右する。
CRMを「顧客台帳」として使うだけなら、設計はそこまで重要ではない。しかし、CRMを「営業プロセスの管理基盤」「マーケティングの自動化基盤」「経営判断のダッシュボード基盤」として使うのであれば、データ構造の設計は成否を分ける要因になる。
たとえば、「業種別の受注率を分析したい」という要件があったとする。業種情報が会社オブジェクトのプロパティとして設計されていなければ、このレポートは作成できない。後から追加することは可能だが、過去のデータには業種情報がないため、遡及的な分析ができない。
設計の段階で「将来どんなレポートが必要か」「どんな自動化を実現したいか」を考慮することで、こうした問題を予防できる。
HubSpotの標準オブジェクトの役割と、格納すべき情報の設計方針を解説する。
コンタクト（Contact）: 個人単位の情報を管理する。氏名、連絡先、役職、ライフサイクルステージなど。BtoBでは「意思決定に関与する個人」を管理する単位となる。
設計のポイント: コンタクトはあくまで「個人」の情報を持つ。企業情報（業種、従業員数、売上規模など）はコンタクトではなく会社オブジェクトに持たせる。この区別を曖昧にすると、同じ会社に所属する複数のコンタクトに対して、会社情報の更新を個別に行う必要が出てくる。
会社（Company）: 法人・組織単位の情報を管理する。会社名、業種、従業員数、売上規模、所在地など。
設計のポイント: 会社オブジェクトは「ターゲティングとセグメンテーションの基盤」として設計する。ABM（アカウント・ベースド・マーケティング）を実施する場合、会社オブジェクトのプロパティ設計が戦略の精度を直接左右する。
取引（Deal）: 商談・案件単位の情報を管理する。金額、ステージ、クローズ予定日、担当者など。
設計のポイント: 取引は「パイプライン管理と売上予測の基盤」だ。一つの会社に対して複数の取引が発生することは一般的であり、取引と会社は「多対一」の関係になる。
チケット（Ticket）: 問い合わせ・サポート案件を管理する。カスタマーサクセスやサポート部門が利用する。
標準オブジェクトでカバーできない情報がある場合、カスタムオブジェクトの作成を検討する。ただし、カスタムオブジェクトの乱用はデータモデルの複雑化を招くため、慎重に判断すべきだ。
カスタムオブジェクトを検討すべきケース:
カスタムオブジェクトを避けるべきケース:
CRMのプロパティ設計で守るべき5つの原則を紹介する。
原則1：目的から逆算する
「このプロパティは何のために存在するのか」を明確にする。レポート用、セグメンテーション用、自動化のトリガー用、営業への情報提供用——目的のないプロパティは作らない。
原則2：データ型を適切に選ぶ
数値で分析したいデータは「数値型」、選択肢から選ぶデータは「ドロップダウン型」、日時で管理するデータは「日付型」にする。「自由記述テキスト」は最小限に留める。テキストフィールドはレポートやセグメンテーションに使えないため、分析基盤としてのCRMの価値を下げる。
原則3：一つのプロパティに一つの情報
「業種・従業員数」のように複数の情報を一つのプロパティに詰め込まない。後からフィルタリングや分析ができなくなる。
原則4：命名規則を統一する
プロパティの命名規則を事前に決めておく。たとえば、「[カテゴリ] - [項目名]」（例：「営業 - 初回商談日」「CS - NPS回答日」）のように統一することで、プロパティが増えても管理しやすくなる。
原則5：定期的に棚卸しする
使われていないプロパティ、重複しているプロパティ、定義が曖昧なプロパティを定期的に洗い出し、整理する。HubSpotの場合、プロパティの利用状況（入力率）を確認できるため、定量的な棚卸しが可能だ。
アンチパターン1：自由記述フィールドの乱用
「備考」「メモ」「その他」といった自由記述フィールドが大量に存在し、何が入力されているかわからない状態。自由記述に入力された情報は、レポートにもセグメンテーションにも使えない。
アンチパターン2：ドロップダウンの選択肢が多すぎる
業種のドロップダウンに100以上の選択肢があり、営業が選ぶのに時間がかかる。選択肢は10-15個程度に抑え、それ以上の粒度が必要な場合は階層化（大分類→中分類）する。
アンチパターン3：部門ごとに類似プロパティが乱立
マーケが「リードソース」、営業が「流入経路」、CSが「獲得チャネル」という似たようなプロパティを個別に作成し、データが分散する。プロパティの作成ルールと承認プロセスを設けることで防止できる。
関連付けは、CRMデータベース設計において最も見落とされやすく、かつ最も重要な要素だ。
たとえば、ある商談に3名のコンタクトが関与しているとする。取引オブジェクトとコンタクトオブジェクトの関連付けが正しく設計・運用されていなければ、「この取引の意思決定者は誰か」「誰にフォローアップすべきか」がCRM上で把握できない。
標準関連付け: コンタクト⇔会社、コンタクト⇔取引、会社⇔取引など、標準オブジェクト間のデフォルトの関連付け。
関連付けラベル: Professional版以上で利用可能。「意思決定者」「利用者」「請求先担当者」のように、関連付けの「役割」を定義できる。BtoBの商談では、意思決定者・推進者・利用者・反対者などの役割を関連付けラベルで管理することで、アカウントマップをCRM上で可視化できる。
カスタムオブジェクトの関連付け: カスタムオブジェクトと標準オブジェクトの関連付けを設計する。関連付けの方向（一対多 or 多対多）と目的を明確にする。
ステップ1：エンティティ関連図を描く
CRM上で管理する主要なオブジェクト（コンタクト、会社、取引、チケット、カスタムオブジェクト）のER図を描き、それぞれの関係性を可視化する。
ステップ2：カーディナリティを定義する
各関連付けの多重度を定義する。一対一、一対多、多対多のいずれか。たとえば、コンタクトと会社は「多対多」（一人が複数の会社に関与し、一社に複数のコンタクトが所属する）だが、実務上は「一人は一つの会社に所属」という運用ルールを設けることも多い。
ステップ3：関連付けラベルを設計する
特にコンタクトと取引の関連付けでは、ラベルの設計が重要だ。「意思決定者」「技術評価者」「チャンピオン」「エンドユーザー」などのラベルを設計し、営業が商談登録時に設定するルールを定める。
CRM導入の目的と、達成したいゴールを整理する。「どんなレポートが必要か」「どんな自動化を実現したいか」「どの部門がどんな情報を参照するか」を洗い出し、必要なデータ要素を特定する。
オブジェクト、プロパティ、関連付けを設計する。ER図を作成し、関係者でレビューする。この段階で「将来の拡張性」を考慮しておくことが重要だ。
CRM上にデータモデルを実装し、テストデータで動作確認する。特にレポートの出力と自動化ワークフローの動作を検証する。
データの入力ルール、プロパティの追加・変更プロセス、定期的な棚卸しのスケジュールを策定する。運用ルールなしにCRMを運用すると、3ヶ月もすればデータの品質が劣化し始める。
CRMデータベース設計で見落とされがちなのが、初期設計よりも「変更管理」です。導入直後はきれいだったデータモデルが、半年後に崩れてしまう原因の多くは、部門ごとの場当たり的なプロパティ追加にあります。
変更管理では、少なくとも以下の3区分を明確にします。
実務では「営業から要望があったので項目を増やす」が最も危険です。項目追加そのものより、同義項目の重複、選択肢の乱立、レポート定義の分断を招くからです。
おすすめは、月1回のデータガバナンス会議で変更申請をまとめてレビューする運用です。申請理由、利用レポート、入力主体、将来の削除条件まで決めてから追加すれば、CRMは長く使える基盤になります。
CRMデータベース設計の基本を実務に落とし込むには、CRMツールの活用が不可欠です。詳しくは「CRM導入の進め方完全ガイド｜準備・ツール選定・データ移行・定着化の全ステップ」で解説しています。
CRMデータベース設計は、オブジェクト・プロパティ・関連付けの3つの要素を、目的から逆算して体系的に設計することが鍵だ。特に、プロパティの型選択と関連付けの設計は、後からの変更コストが大きいため、初期段階で慎重に設計する必要がある。
「完璧な設計」を最初から目指す必要はないが、「設計の原則」を押さえたうえで開始することで、運用開始後の手戻りを大幅に削減できる。CRMは導入がゴールではなく、蓄積されたデータを活用して事業成果につなげることがゴールだ。そのためには、データの入口であるデータベース設計に、十分な時間と労力を投資する価値がある。
企業規模と要件の複雑さによるが、標準的なBtoB企業（従業員50-300名）であれば、要件整理に2週間、データモデル設計に2週間、実装・テストに2週間で、合計1-1.5ヶ月程度が目安だ。ただし、複数部門が利用する場合は、各部門の要件ヒアリングに追加の時間が必要になる。
まず、現状のオブジェクト・プロパティ・関連付けの棚卸しを行い、「使われているもの」と「使われていないもの」を分類する。次に、理想のデータモデルを設計し、現状とのギャップを特定する。一度にすべてを修正するのではなく、「レポートに影響するプロパティの統合」「重複プロパティの削除」など、優先度をつけて段階的にリファクタリングするのが現実的なアプローチだ。
明確な上限はないが、経験上、カスタムオブジェクトが5つを超えるとデータモデルの複雑性が急激に増す。まずは標準オブジェクトとプロパティの組み合わせで要件を満たせないかを検討し、それでも不十分な場合にのみカスタムオブジェクトを作成することを推奨する。作成する場合は、必ずER図を更新して全体の関連付けを可視化しておくべきだ。
無料プランでも同様に重要だ。むしろ、無料プランは利用可能なプロパティ数やカスタマイズの幅に制限があるため、より効率的な設計が求められる。「将来有料プランに移行した際にスムーズに拡張できる」ように、標準オブジェクトの関連付けと基本プロパティの設計を最初からしっかり行っておくことが、長期的なコスト削減につながる。
カテゴリナビゲーション: