ソフトウェアに触れる前にCRMデータモデルを設計する

40人規模のSaaS営業チームが12か月以内にCRMデータモデルを2回再構築しました。最初の構築には3週間のConfigurationが必要でした。2回目の再構築は、Q2の中盤に、コンタクトモデルが異なるロールを持つ複数のコンタクトを1件の案件に対してサポートできないと発覚したために起きました。3回目の試み、ソフトウェアに触れる前に紙上で行われたものは、18か月間、構造的な変更なしに稼働し続けています。

その3回目の試みはホワイトボードから始まりました、ノートパソコンからではなく。

核心的な教訓：崩壊するCRM導入は、誰かが考える前にクリックを始めたことが原因です。コンタクト vs. リード vs. アカウント vs. 案件：これらのオブジェクト間のリレーションシップが、何をレポートできるか、何を自動化できるか、Pipelineがどのように機能するかを決定します。間違えるとQ1に入力したデータをQ3に移行することになります。

このガイドでは、単一のフィールドを設定する前に、CRMデータモデルを紙上で設計する方法を説明します。

ステップ1：コアビジネスオブジェクトをリストアップする

すべてのCRMに標準で搭載されている4つのデフォルトオブジェクトから始めます：

  • コンタクト：チームがやり取りする個人
  • 企業（アカウント）：コンタクトが属する組織
  • 案件（Opportunity）：クローズ日と金額を持つアクティブな営業活動
  • 活動：通話、メール、ミーティング、タスク（インタラクション記録）

何か追加する前に、この4つが営業活動の90%をカバーしているかを確認してください。通常はカバーされています。カスタムオブジェクトを追加したい誘惑は強いですが、標準オブジェクトでは対応できないユースケースが証明されるまで抵抗してください。

カスタムオブジェクトは以下の場合にのみ複雑さに見合う価値があります：

  • 人、会社、または案件ではないものを追跡している（物理的な資産、プロジェクトの成果物、製品のインストールなど）
  • リレーションシップ構造がコンタクト-企業-案件とは根本的に異なる
  • このエンティティにのみ適用される3つ以上のフィールドがある

Salesforceではカスタムオブジェクトは強力ですが、ライセンスとメンテナンスのオーバーヘッドが増えます。HubSpotでは、カスタムオブジェクトはEnterpriseプランで利用可能で、ますます強力になっています。Pipedriveでは同じ方法でカスタムオブジェクトは存在しません。既存のオブジェクトにカスタムフィールドを使います。

Salesforce EnterpriseまたはHubSpot Enterpriseでない場合、カスタムオブジェクトを前提にモデルを設計しないでください。CRMがサポートできるものに対して設計してください。

ステップ2：リレーションシップをマッピングする

CRMを開く前にこれを図示してください。カーディナリティを理解する必要があります：どちらのオブジェクトがどちらにどれだけ関連できるか。

定義すべき標準リレーションシップ：

リレーションシップ タイプ 注記
コンタクト → 企業 多対一 1つのコンタクトは1つの企業に属する（デフォルト）
コンタクト → 企業 多対多 1つのコンタクトが複数の企業と関係する（SalesforceのAccountsの機能、HubSpotのAssociations）
コンタクト → 案件 多対多 複数のコンタクトが1件の案件に含まれる（委員会による購買）
案件 → 企業 多対一 1件の案件は1つの企業に属する
活動 → コンタクト 多対一 活動は単一のコンタクトに対して記録される
活動 → 案件 多対一 活動は単一の案件に対して記録される

自明でない質問：コンタクトは複数の企業に属せますか？多くのB2B営業では、誰かが2つの企業の取締役会メンバーである場合や、複数の子会社を持つホールディング企業に販売している場合にこれに遭遇します。

Salesforceはこれをアカウントリレーションシップとコンタクトロールで処理します。HubSpotは2022年にマルチアソシエーションサポートを追加しました。Pipedriveはあまりエレガントに処理しません。

営業活動で複数のアカウントにまたがるコンタクトが定期的に発生する場合、Configurationの前にそれを前提にモデルを設計してください。レアなケースの場合、データモデルに複雑さを組み込むのではなく、メモのエッジケースとして処理してください。

ステップ3：各オブジェクトに何が含まれるかを定義する

各オブジェクトについて、フィールドをリストアップしてください。「Configuration中に考える」という理由でこのステップを省略しないでください。そうならず、3か月目までに80のフィールドが加わります。

各フィールドについて定義してください：

  1. 名前：何と呼ぶか。命名規則に一貫性を持ち、タイトルケースか文章ケースかを今決めてください。
  2. タイプ：テキスト、ピックリスト、数値、日付、チェックボックス、数式、ルックアップ
  3. 必須？：はいかいいえ。このリストは短く保ってください。
  4. 目的：レポートする、セグメント分けする、オートメーションをトリガーする、または担当者に表示する

コンタクトオブジェクトの定義のサンプルは次のようになるかもしれません：

フィールド タイプ 必須 目的
名 テキスト はい 表示
姓 テキスト はい 表示
メールアドレス テキスト はい メール同期、オートメーション
電話番号 テキスト いいえ 表示
役職 テキスト いいえ 表示
リードソース ピックリスト はい レポート、オートメーション
リードステータス ピックリスト はい ルーティング、レポート
ICP適合度 ピックリスト いいえ セグメンテーション
最終活動日 日付（システム） — システム生成
コンタクトオーナー ルックアップ → ユーザー はい ルーティング

案件オブジェクト：

フィールド タイプ 必須 目的
案件名 テキスト はい 表示
Pipelineステージ ピックリスト はい Pipeline、予測
クローズ日 日付 はい 予測
案件金額 通貨 はい レポート
案件タイプ ピックリスト はい セグメンテーション
失注理由 ピックリスト いいえ（クローズロスト時必須） レポート
アカウント ルックアップ → 企業 はい リレーションシップ
主担当コンタクト ルックアップ → コンタクト はい リレーションシップ
予測カテゴリー ピックリスト いいえ 予測

これがカスタムフィールドに関する議論が迷走するのを防ぐ作業です。すべてのフィールド要求に対する意思決定の枠組みについてはカスタムフィールドガイドを参照してください。

ステップ4：チームでピックリスト値を構築する

ここから悪いデータが始まります：ある担当者がIndustryフィールドに「Financial Services」と入力し、別の担当者が「Fintech」、また別の担当者が「Banking & Finance」と入力します。すると業界レポートは役に立たなくなります。

ピックリストは一貫性を強制します。しかし値がデータ入力のためではなく、レポートのために設計されている場合にのみ機能します。

Go-live前に定義すべきコアピックリスト：

リードソース：コンタクトがCRMに入ってくる場所。 サンプル値：インバウンドWeb、アウトバウンドSDR、紹介、パートナー、イベント、コンテンツダウンロード、有料広告、トライアル登録。これらをソースレベルで保持し、「Facebook広告 - キャンペーン名 - 2026年3月」のようにしないでください。ソースレベルの値はクリーンに保てます。キャンペーンレベルはマーケティングアトリビューションツールに属します。

Industry：一貫したタクソノミーを使用してください。最初は10〜12の値から始め、最初の90日間での追加要求に抵抗してください。SaaS、Financial Services、Healthcare、Manufacturing、Professional Services、Retail、Media、Education、Non-Profit、その他。

失注理由：学習のために重要ですが、ほぼ常に混乱します。良い失注理由は誠実で実行可能です：予算なし、競合他社を選択（名前入り）、意思決定なし、タイミング、適合性なし、応答なし。「その他」のような漠然としたオプションはキャッチオールとして避けてください。

Pipelineステージ：これを慎重に定義してください。担当者の活動ではなく購買マイルストーンに基づいてステージを構築する方法についてはPipelineステージガイドを参照してください。

案件タイプ：新規ビジネス、拡張、更新、再活性化。1つのタイプだけ販売している場合はスキップしてください。複数の動きがある場合、このフィールドでPipelineを個別のFunnelに分けます。

各ピックリストについて定義してください：誰が値を所有するか、新しい値がどのように追加されるか（承認プロセスかオープンか）、および古い値が不正確になった場合に何が起こるか（削除ではなくアーカイブ）。

ステップ5：データ入力だけでなくレポートのために設計する

すべてのフィールドのテスト：レポートでクエリしたりグループ化したりできない場合、フリーテキストとして保存しないでください。

「顧客メモ」はテキストフィールドとして担当者が通話前にコンテキストを読むのに便利です。しかし集計分析には使えません。「ペインポイント」をフリーテキストフィールドとして保存すると、案件の60%が「手動プロセス」をコアの問題として挙げていることは決してわかりません。

誰かがフリーテキストフィールドを要求したとき、聞いてください：このフィールドのさまざまなカテゴリに何件の案件が入るかを数えたいと思いますか？はいなら、ピックリストであるべきです。真に文脈的な記述であれば、テキストも構いません。しかしそれはメモセクションまたは活動記録にのみ属します。

数式フィールドは有用ですが、メンテナンスが必要です。フィールド値が他のフィールドから計算できる場合（例：ステージ滞在日数 = 今日 - ステージ参入日）、数式を使用してください。しかしSalesforceの数式フィールドには制限があり、HubSpotではOperations Hub Professionalが必要です。数式フィールドに依存するモデルを設計する前に、CRMの機能を把握してください。

ステップ6：スキーマシートにモデルをドキュメント化する

何もConfigurationする前に、シンプルなスプレッドシートにデザインをドキュメント化してください。オブジェクトごとに1つのタブ、フィールド名、フィールドタイプ、必須、値（ピックリスト用）、目的の列を用意してください。

基本的なスキーマシートには以下が含まれます：

  • オブジェクト定義タブ：すべてのオブジェクト、その目的、標準かカスタムかのリスト
  • リレーションシップタブ：カーディナリティが記録されたすべてのオブジェクト間リレーションシップ
  • フィールド定義タブ：上記のテーブル形式でオブジェクトごとに1つ
  • ピックリスト値タブ：すべてのピックリストとすべての値（誰が所有するかのメモ付き）

このドキュメントが導入の仕様書になります。CRM管理者はここからConfigurationします。チームはGo-live前にレビューします。マネージャーはCRMを開かずに読めます。

スキーマシートは頭の中だけでなく、共有ドライブに保管してください。CRM管理者は変わります。将来の自分が感謝するでしょう。

CRMによる違い

スキーマを確定する前に、特に軽量なオプションを検討している場合は、ReworkのデータモデルとSalesforceのデフォルトオブジェクト構造の比較を確認する価値があります。

Salesforce：Salesforceのデータモデルは最も強力で最も複雑です。リードからコンタクトへのコンバージョンプロセスには意図的な設計が必要です。リードはいつコンタクトになるか、アカウントとOpportunityに関連付けられるか？この移行は混乱の一般的なソースです。カスタムオブジェクトとカスタムリレーションシップはほとんどのライセンス層で利用可能ですが、AdminまたはDeveloperの専門知識が必要です。

HubSpot：HubSpotのデフォルトモデルはコンタクト、企業、案件、チケットです。Associations機能（すべての有料層で利用可能）はマルチオブジェクトリレーションシップを可能にしますが、低い層ではアソシエーションタイプに制限があります。HubSpotにはデフォルトではリードオブジェクトがありません。コンタクトがその役割を果たします。カスタムオブジェクトはEnterprise限定です。

Pipedrive：Pipedriveはモデルをシンプルに保ちます：People、Organizations、案件、活動。カスタムオブジェクトはサポートされていません。リレーションシップはシンプルで、柔軟性は少ないですが、間違える余地も少ないです。

Close：Closeはリードをトップレベルオブジェクトとして使用し、コンタクトをその下に置きます。これはほとんどのCRMとは異なり、SalesforceやHubSpotから移行する場合は調整が必要です。このモデルはインサイドセールスに適していますが、複雑なエンタープライズアカウント構造には柔軟性が低いです。

よくある失敗

初日から多すぎるカスタムフィールド。 平均的なCRMでは6か月以内にフィールドの80%が使われなくなります。最初はフィールドを少なく（オブジェクトごとに15〜20）保ち、レポートやオートメーションのニーズが証明された場合にのみ追加してください。

ピックリストの乱立。 ガバナンスプロセスなしに複数の人がピックリスト値を追加できると、Industryフィールドに「Financial Services」の12バリエーションができます。Go-live前にピックリストの所有権を定義してください。

エッジケースのために構築する。 ある担当者は4つのコンタクトがそれぞれ異なるロールを持つ案件を持っています。それは現実ですが、一般的なケースではありません。例外のためにデータモデル全体を設計しないでください。

スキーマレビューに適切な人材を関与させない。 スキーマシートは少なくとも1人の担当者（これは自分の働き方に合っているか？）、1人のマネージャー（必要なレポートを作成できるか？）、1人の財務担当者（案件データが予測をサポートしているか？）によってレビューされるべきです。

次のステップ

構築したスキーマシートを3人に確認してもらってください：担当者1名、マネージャー1名、財務またはオペレーション担当者1名。それぞれに1つの質問に答えてもらいます：「このモデルに基づいて、CRMワークフローで最も頻繁に行うことができますか？」誰かがノーと言ったら、ソフトウェアを開く前にモデルを修正してください。

その後、導入中に来るすべてのフィールド要求の意思決定の枠組みを得るためにカスタムフィールドガイドを読んでください。多くの要求が来るでしょう。

関連記事