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

「CRMを導入したのに、データがぐちゃぐちゃで結局使い物にならない」

「項目が多すぎて現場が入力しない」「レポートを出そうとしても、欲しい切り口で集計できない」「担当者が異動したら、誰がどの商談を持っているのか分からなくなった」

CRM導入支援の現場では、こうした声を数多く耳にします。そして、これらの問題の根本原因はほぼ例外なく、導入前のデータベース設計にあります。CRMは単なるソフトウェアではなく、ビジネスの情報基盤です。その基盤の設計図であるデータベース設計が曖昧なまま導入を進めれば、運用が破綻するのは時間の問題です。

本記事では、数多くのCRM設計案件から体系化した知見をもとに、CRMデータベース設計の3つの構成要素である「オブジェクト」「プロパティ」「関連付け（アソシエーション）」の設計思想を解説します。単に「何をどう設定するか」ではなく、「なぜそう設計するのか」という設計哲学レベルの理解を提供します。具体例としてHubSpotのデータ構造を取り上げながら、どのCRMにも応用可能な普遍的な設計原則をお伝えします。

この記事でわかること

• CRMデータベース設計がなぜ運用の成否を左右するのか
• オブジェクト（データテーブル）の役割と標準/カスタムの使い分け
• プロパティ（データ項目）設計の原則と、項目を増やしすぎない考え方
• 関連付け（アソシエーション）の設計方法と1対多・多対多の判断基準
• データベース設計で守るべき5つの設計原則
• BtoB企業の典型的な設計パターンと応用例
• よくある設計ミスとその対処法

CRMデータベース設計はなぜ重要なのか

設計の良し悪しが運用の成否を決める

CRMの導入プロジェクトにおいて、ツール選定やデータ移行に注力する企業は多い一方で、データベース設計に十分な時間を割く企業は驚くほど少ないのが実情です。導入支援の現場では、運用開始後に「使いづらい」「データが汚い」「レポートが出せない」といった問題が噴出するケースの大半が、設計段階の不備に起因しています。

データベース設計とは、いわば「CRMの骨格」を決める作業です。どんな情報を、どんな単位で、どのような関係性で管理するかを決定する設計が甘ければ、その上に構築されるすべての運用プロセスが歪みます。逆に、設計が的確であれば、入力も・蓄積も・活用もスムーズに回り始めます。

「入力→蓄積→活用」のサイクルが回る設計とは

CRMの価値は「入力→蓄積→活用」のデータサイクルが回って初めて生まれます。このサイクルが回る設計とは、以下の3条件を満たすものです。

• 入力しやすい：項目が必要十分に絞られ、現場が迷わず入力できる
• 蓄積しやすい：データが一意に整理され、重複や矛盾が生まれにくい
• 活用しやすい：必要な切り口でレポートやセグメント分析が可能

この3条件のどれか一つでも欠けると、サイクルは止まります。入力が煩雑なら現場は入力しなくなり、蓄積されたデータが汚れていればレポートの信頼性が失われ、活用できないデータに対して入力するモチベーションは生まれません。データベース設計は、このサイクルを最初から組み込むための起点なのです。

CRMデータベースの3つの構成要素

CRMのデータベースは、基本的に「オブジェクト」「プロパティ」「関連付け（アソシエーション）」という3つの構成要素で成り立っています。HubSpotではこの3つが明確に定義されていますが、この概念はSalesforceやZoho CRMなど他のCRMにも共通する普遍的な構造です。

構成要素1: オブジェクト（データテーブル）

オブジェクトとは、CRM上でデータを格納する「テーブル」のことです。HubSpotのデータ構成では、データがいくつかのテーブル形式で管理されており、初期から存在する「標準オブジェクト」と、業務に応じて追加できる「カスタムオブジェクト」に分かれています。

標準オブジェクトの役割

多くのCRMでは、ビジネスに共通して必要となる情報を管理するための標準オブジェクトがあらかじめ用意されています。HubSpotの場合、以下の4つが基本の標準オブジェクトです。

ここで重要なのは、「人」と「組織」を分けて管理するという設計思想です。コンタクトには個人の情報が格納され、そのコンタクトがどの会社に所属しているのかを別のオブジェクトで管理します。これにより、一人の担当者が転職しても、その人の情報と企業の情報を独立して追跡できます。

同様に、「商談」と「サポート」を別オブジェクトにすることで、営業プロセスとカスタマーサポートのプロセスを独立して管理・レポートできるようになります。

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

標準オブジェクトで表現できない業務データがある場合、カスタムオブジェクトの追加を検討します。ただし、安易なカスタムオブジェクトの追加は複雑性を増大させるため、以下の判断基準で検討するのが望ましいです。

• 独立したエンティティか：既存オブジェクトのプロパティでは表現できない、独立した管理単位か
• 他オブジェクトとの関連が必要か：会社やコンタクト、取引との関連付けが発生するか
• 複数レコードが発生するか：1件だけでなく、複数のレコードが蓄積されるデータか
• レポート対象か：そのデータを軸にした集計や分析が必要か

例えば、「契約」「製品」「プロジェクト」「拠点」など、標準オブジェクトでは表現しきれない情報がカスタムオブジェクトの候補になります。カスタムオブジェクトの設計についてより深く知りたい方は、関連記事「カスタムオブジェクト設計ガイド」もあわせてご参照ください。

構成要素2: プロパティ（データ項目）

プロパティとは、各オブジェクトに紐づく個別のデータ項目です。会社オブジェクトであれば「企業名」「業種」「電話番号」、コンタクトオブジェクトであれば「氏名」「メールアドレス」「役職」、取引オブジェクトであれば「金額」「ステージ」「クローズ予定日」などが該当します。

標準プロパティ vs カスタムプロパティ

オブジェクトと同様に、プロパティにも最初から用意されている「標準プロパティ」と、自社の業務に合わせて追加する「カスタムプロパティ」があります。

プロパティ設計の3原則

導入支援の現場で繰り返し見てきた失敗パターンから、プロパティ設計には以下の3原則を推奨します。

原則1: 必要十分に絞る

「あれば便利かもしれない」という項目は、ほぼ確実に入力されません。「このプロパティは誰が、いつ、何のために入力するのか」を明確にできない項目は作らないのが鉄則です。初期は最小限の項目でスタートし、運用の中で必要性が証明されたものを追加していくアプローチが有効です。

原則2: 命名規則を統一する

プロパティ名がバラバラだと、検索性が下がり、重複プロパティの温床になります。例えば「顧客ランク」「取引先ランク」「企業グレード」が同じ意味で乱立するような状況です。「[オブジェクト名]_[カテゴリ]_[項目名]」のような命名規則を事前に決めておくことが重要です。

原則3: 適切なフィールドタイプを選ぶ

自由入力テキストは入力の自由度が高い反面、データの一貫性が保てません。可能な限り、ドロップダウン（選択式）、数値、日付など、構造化されたフィールドタイプを選択しましょう。例えば「業種」は自由入力ではなく選択式にすることで、レポートでの集計が正確になります。

構成要素3: 関連付け（アソシエーション）

関連付け（アソシエーション）とは、オブジェクト間の関係性を定義するものです。この設計が、CRMデータベースの「立体的な構造」を形づくります。

オブジェクト間の関係性の設計

HubSpotの標準的な関連付けを例にとると、以下のような関係性が定義されています。

• コンタクト → 会社：「その人がどの会社に所属しているのか」という所属関係
• コンタクト → 取引：「誰がその商談の担当・関係者なのか」という参画関係
• 会社 → 取引：「どの企業との商談なのか」という元企業関係
• 取引 → チケット：「その商談から発生した問い合わせ」というサポート関係

この関連付けにより、例えば一つの会社レコードを開くだけで「この会社の担当者は誰か」「進行中の商談はいくつあるか」「過去のサポート履歴はどうか」を一覧できるようになります。

1対多・多対多の使い分け

関連付けの設計では、「1対多」と「多対多」の関係性をどう設定するかが重要な判断ポイントになります。

判断の基準はシンプルです。「Aの1レコードに対して、Bは常に1つだけか？それとも複数ありうるか？逆方向はどうか？」を問うだけです。BtoB企業の場合、一つの商談に複数の担当者（意思決定者・技術担当・窓口担当など）が関与するケースが一般的なので、コンタクトと取引は多対多の関連付けが適切です。

データベース設計の5つの設計原則

オブジェクト・プロパティ・関連付けの構成要素を理解した上で、それらをどう組み合わせるかの指針となる5つの設計原則を紹介します。

原則1: ビジネスプロセスから逆算する

データベース設計は、自社のビジネスプロセスの写像であるべきです。「リードの獲得 → 商談化 → 提案 → 受注 → 納品 → サポート」という自社の業務フローを明確にし、各ステップで「誰が」「どんな情報を」「どう使うのか」を洗い出すことが設計の出発点です。ツールの機能ありきではなく、業務ありきで設計しましょう。

原則2: レポートで見たいKPIから設計する

「最終的にどんなレポートを見たいか」を先に決め、そこから逆算してプロパティやオブジェクトを設計するアプローチが有効です。例えば、「業種別の商談成約率」を見たいなら、会社オブジェクトに「業種」プロパティが必要であり、取引オブジェクトに「成約/失注」のステータスが必要です。レポート要件を先に定義することで、不要なプロパティの乱立を防げます。

原則3: 入力負荷を最小化する

どれほど理想的な設計でも、現場が入力しなければデータは溜まりません。設計段階で「この項目を入力する人の負荷」を常に意識することが重要です。具体的には、必須項目を最小限にする、選択式を活用して入力速度を上げる、自動入力やデフォルト値を設定するといった工夫が効果的です。

原則4: データの一意性を保つ

同じ情報が複数の場所に存在する「データの重複」は、CRM運用における最大の敵です。例えば、会社名をコンタクトのプロパティにも持たせてしまうと、会社名が変更された際に不整合が発生します。情報は原則として1か所で管理し、関連付けを通じて参照する設計にしましょう。メールアドレスや会社ドメインなど、レコードの一意性を担保するキー項目を明確に定義しておくことも重要です。

原則5: 拡張性を考慮する

ビジネスは変化します。新しい事業部ができたり、サービスラインが増えたり、海外展開が始まったりすることを想定し、将来の変化に対応できる柔軟な設計にしておくことが大切です。具体的には、プロパティの選択肢に余白を持たせる、カスタムオブジェクトの追加を見越した関連付け構造にする、命名規則を拡張に耐えるものにするといった配慮が求められます。

よくある設計パターン（BtoB企業の典型例）

基本パターン: 会社→コンタクト→取引→チケット

BtoB企業におけるCRMデータベースの基本パターンは、以下の構造です。

この基本パターンでは、「会社Aの山田さん（コンタクト）が担当する商談X（取引）から、導入後に問い合わせY（チケット）が発生した」という一連の流れが、関連付けによって自然に追跡できます。

コンタクトにはライフサイクルステージ（リード→MQL→SQL→商談→顧客）を設定し、取引にはパイプラインとステージ（見込み→商談中→内示→クローズ）を設定することで、営業プロセス全体の進捗を可視化できます。パイプライン設計の詳細は、関連記事「パイプライン設計ガイド」で解説しています。

応用: 複数パイプラインとカスタムオブジェクトの活用

事業が複数ある場合や、営業プロセスが異なる商材を扱う場合は、複数のパイプラインを設定することで対応できます。例えば「新規営業パイプライン」と「既存顧客アップセルパイプライン」を分けることで、それぞれのプロセスに適したステージ管理とレポーティングが可能になります。

さらに、「契約管理」「製品マスタ」「プロジェクト管理」など、標準オブジェクトでは表現しきれないデータが必要な場合は、カスタムオブジェクトを追加して対応します。ただし、カスタムオブジェクトは増やしすぎると管理が複雑になるため、本当に独立した管理単位として必要かどうかを慎重に判断しましょう。

よくある設計ミスと対処法

数多くの設計案件から見えてきた、典型的な設計ミスとその対処法を紹介します。

設計からAI活用への接続

CRMにおけるAI活用は急速に進んでいますが、AIが正しく機能する前提条件は、整理されたデータベース設計です。AIは与えられたデータの質以上のアウトプットを出すことはできません。

例えば、AIによる商談の成約予測は、取引オブジェクトのステージ遷移データと、関連するコンタクト・会社の属性情報を学習データとして使います。ここでステージの定義が曖昧だったり、関連付けが不完全だったりすると、予測精度は著しく低下します。

同様に、AIによる自動メール生成やレコメンデーションも、コンタクトのプロパティが正確に入力されていて初めて精度の高い結果を返します。つまり、データベース設計の品質は、将来のAI活用の天井を決めるのです。

「今すぐAIを使う予定はないから関係ない」と考えるのは早計です。データは蓄積に時間がかかります。将来のAI活用を見据えて、今のうちからきれいなデータが溜まる設計にしておくことが、長期的な競争優位につながります。

まとめ

CRMデータベース設計は、「オブジェクト」「プロパティ」「関連付け（アソシエーション）」の3つの構成要素で成り立っています。この設計の良し悪しが、CRM運用の成否を根本から左右します。

本記事で解説した設計のポイントを整理すると、以下の通りです。

1. オブジェクト設計：標準オブジェクト（会社・コンタクト・取引・チケット）の役割を理解し、カスタムオブジェクトは本当に必要な場合のみ追加する
2. プロパティ設計：必要十分に絞り、命名規則を統一し、適切なフィールドタイプを選ぶ
3. 関連付け設計：オブジェクト間の関係性を正確に定義し、「1対多」「多対多」を適切に使い分ける
4. 5つの設計原則：ビジネスプロセスから逆算し、KPIから設計し、入力負荷を最小化し、データの一意性を保ち、拡張性を考慮する
5. AI活用への備え：きれいなデータが溜まる設計は、将来のAI活用の基盤になる

データベース設計は一度決めたら終わりではなく、ビジネスの変化に合わせて継続的に見直すものです。まずは本記事で紹介した基本パターンと設計原則をベースに設計を始め、運用の中で改善を重ねていくアプローチを推奨します。

よくある質問（FAQ）

Q. CRMデータベース設計は、導入前にすべて完成させるべきですか？

A. 基本構造（オブジェクトと主要な関連付け）は導入前に固めるべきですが、プロパティの詳細は運用しながら調整するのが現実的です。最初から完璧を目指すより、コアとなる設計を固めた上で「小さく始めて改善する」アプローチが有効です。導入後3ヶ月を目処に、プロパティの利用状況を見直すサイクルを設けることを推奨します。

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

A. 技術的な上限はCRMの契約プランによって異なりますが、設計の観点では「少なければ少ないほどよい」が原則です。カスタムオブジェクトが増えるほど関連付けの管理が複雑になり、運用負荷が上がります。まずは標準オブジェクトのプロパティで対応できないかを検討し、それでも不十分な場合にのみカスタムオブジェクトを追加しましょう。

Q. プロパティが増えすぎてしまった場合、どう整理すればよいですか？

A. まず全プロパティの入力率を集計し、入力率が極端に低い項目（目安として20%以下）をリストアップします。次に、それらの項目が本当に必要かをビジネス部門と協議し、不要なものは非表示または削除します。整理の際は、データクレンジングの手法をあわせて活用すると効果的です。

Q. 関連付け（アソシエーション）を後から変更することはできますか？

A. 多くのCRMでは関連付けの追加や変更は可能ですが、既存データの関連付けを一括で修正するには手間がかかります。特に大量のレコードがある場合、インポートツールやAPIを使った一括更新が必要になることがあります。そのため、基本的な関連付けの方針は導入前に慎重に設計することが重要です。

Q. BtoC企業の場合、データベース設計はどう変わりますか？

A. BtoC企業では「会社」オブジェクトの重要度が下がり、「コンタクト」が中心のデータ構造になります。また、取引の件数が多くなるため、取引オブジェクトのプロパティ設計やパイプラインの設計が変わります。ただし、「オブジェクト・プロパティ・関連付け」という3つの構成要素で設計するという基本的な考え方は同じです。

関連記事

• カスタムオブジェクト設計ガイド｜追加判断と設計パターン（カスタムオブジェクトの詳細な設計手法はこちら）
• CRMデータクレンジング実践ガイド｜データ品質を維持する方法（プロパティ整理とデータ品質改善の実践手法はこちら）
• パイプライン設計ガイド｜ステージ設計と運用の最適化（取引パイプラインの設計詳細はこちら）