HubSpotのデータモデルを設計する

管理者としてアカウントを設定する場合は、HubSpot でのデータの取り扱い方法を決定する必要があります。どのようなデータを保存し、どのような形式で保存し、それらは互いにどのように関連するのでしょうか？HubSpotの導入において、どのようなデータアーキテクチャを選択するかは、ビジネス目標の達成にとって極めて重要です。

データアーキテクチャの計画を立てなければ、データが乱雑になったり、CRM内に重複するレコードやプロパティーが生じたりするリスクがあるほか、適切な計画を立てていれば予見できたはずの問題を解決するために、CRMの一部を再構築せざるを得なくなる恐れがあります。こうした問題を回避するには、ビジネス目標と、CRM上でユーザーにどのような行動をとってほしいかを明確にし、データがそれらの目標やユーザーの行動とどのように関連しているかを把握した上で、その具体的なデータモデルを実装するための計画を策定すればよい。HubSpotでプロセスの構築を始める前にこのモデルを作成しておくことで、チーム全員が初日から計画について足並みを揃えることができます。

こうした取り組みを支援するため、本ガイドには以下の内容が含まれています：

• データの要件を特定するための質問です。
• エンティティ・リレーションシップ図（ERD）を作成する手順。
• 特定の収益モデルに関するERDの例。

データ要件を明確にする

HubSpotへのデータインポートやカスタムオブジェクトの作成を始める前に、自社の目標達成に最も適したデータの種類を把握しておく必要があります。

データに関するニーズを把握するために、以下のカテゴリーに分類された質問について考えてみてください。

収益創出

自社の収益モデルを整理することで、ビジネスを成功させるためにどのような指標を追跡すべきかを理解するのに役立ちます。

• どのような事業で収益を生み出していますか？
• 御社のビジネスにおける主な収益源はどのようなものですか（例：営業担当者による販売、顧客による直接購入、契約、サブスクリプションなど）？
• 現在、売上や収益はどのように管理していますか？

顧客ライフサイクル

顧客が自社ビジネスにおいてどのような流れをたどるかを理解することで、各レコードにどのようなデータが必要か、またどのオブジェクトにパイプラインが必要かを把握しやすくなります。また、ライフサイクルステージと取引ステージを同一のものとして扱うという、よくある間違いも浮き彫りにしています。

ライフサイクルステージ（例：見込み客、顧客、離反顧客など）とは、その人物が貴社との全体的な関係においてどのステージにあるかを表すものです。「取引ステージ」は、特定の商談の進捗状況を追跡するものです。この2つを混同すると、レポートの信頼性が損なわれてしまうため、HubSpotでレコードの作成を始める前に、これらの要素を理解しておくことが極めて重要です。

• 顧客ライフサイクルの主なステージにはどのようなものがありますか？
• どのようなイベントによって、レコードがある段階から別の段階へと移行するのでしょうか？特定の段階で承認プロセスはありますか？
• 各段階において、リーダーシップは何を測定すべきでしょうか？

ビジネスの要素

収益モデルと理想的なカスタマージャーニーを理解すれば、ビジネスにおいて追跡すべき具体的な項目、つまりビジネスの「名詞」を特定できるようになります。HubSpot では、これらの名詞はオブジェクトタイプ（連絡先、企業、商談、チケット、またはユーザーが定義したカスタムオブジェクトなど）として表現されます。HubSpotで作成するレコードは、これらのオブジェクトタイプのいずれかに分類されるため、データのインポートを開始する前に、それぞれの定義を明確にしておくことが重要です。

目標は、必要となるあらゆる種類のレコードを列挙することであり、それが標準オブジェクトかカスタムオブジェクトかについては、現時点では決定しない。その決定は後ほど行われます。収益モデルの概要を説明した後、そのモデルを支える具体的な要素について詳しく説明することができます。

• 御社のビジネスにおける中核となる要素（例：「連絡先」、「商談」、「定期購読」、「予定」など）は何ですか？
• 場所、実装、ベンダー、プログラムなど、より専門的な対象を追跡する必要がありますか？
• これらの要素は互いにどのように関連しているのでしょうか（例：特定の「場所」で行われる「アポイントメント」、より大きな「注文」の一部である個別の「出荷」、あるいは「取引」の一環として締結される「契約」など）？

利用許諾および使用方法

ビジネスのデータ要件の計画を立て始めるにあたっては、どのチームが特定のプロセスを担当するのか、また各チームが目標を達成するためにどのようなデータへのアクセスが必要なのかを把握しておくと役立ちます。

• どのチームがHubSpotを「システム・オブ・レコード」として活用するのでしょうか？特定のプロセスを追跡するために、独自のレコードタイプを必要とするチームはありますか（例：営業チームが、特定の「連絡先」とのやり取りを「リード」として個別のレコードで追跡する場合など）？
• それらのチームがタスクを遂行する際に、行動を起こすために必要な重要なデータポイントとは何でしょうか？
• チーム間の責任の引き継ぎは、どこで行われるのでしょうか？

これらの質問への答えは、自社のビジネスにとって重要なデータの種類や、そのデータをどのように形式化できるかを理解する手助けとなるでしょう。次のステップでは、この情報をもとにデータモデルの図を作成し、HubSpotでのCRM活用に関する計画をチームに提示します。

エンティティ・リレーションシップ図（ERD）を作成する

HubSpotに保存したいデータの種類がわかったところで、これらのデータ項目が互いにどのように関連しているかを整理してみましょう。このデータと関係の図が、御社のエンティティ・リレーションシップ・ダイアグラム（ERD）となります。ERDは、CRM内でデータをどのように構成するかを定義するのに役立ちます。

HubSpotにはカスタムオブジェクトを作成できるデータモデルビルダーが用意されていますが、実際にカスタムオブジェクトの作成に取り掛かる前に、アプローチをしっかりと計画しておくことが重要です。HubSpotの外でERDを作成することで、チーム間でデータ戦略の認識を統一できるほか、特定のオブジェクトタイプを確定させる必要なく、実験を行う場を確保することができます。ERDを精緻化したら、その戦略をHubSpotでより効率的に実行できるようになります。

1: 事業体のリスト（例）

ビジネスの要素をすべて書き出してください。その実体が「何を表しているか」について、簡単な説明を加えると役立つ場合があります。

たとえば、工業用機器の設置や保守を主な業務とするサービスモデルを基盤とするビジネスであれば、図には（他にもありますが）次のようなエンティティを含めることができます：

• 貴社の最終顧客を表す会社レコード。
• 各企業の連絡先を担当者ごとにまとめたコンタクトレコード。
• 契約期間中に設置され、その後保守サービスが提供される機器の販売を記録した取引レコード。
• 設置場所の記録。機器が設置される具体的な場所を示す。
• 特定の機械に対して行われた保守作業を記録した整備記録。

以下は、この架空の会社についてリストアップされた事業体です：

2: 標準オブジェクトとカスタムオブジェクトの選択（例）

ビジネスの構成要素を見直し、どのエンティティがHubSpotの標準オブジェクトでカバーされているか、またどのエンティティに対してカスタムオブジェクトの作成が必要になるかを判断してください。

例えば、当社の産業機器メーカーでは、企業、見込み客、商談、サービスといったHubSpotの標準オブジェクトを利用することができます。彼らは、ロケーション用にカスタムオブジェクトを作成することを選ぶでしょう。

3: オブジェクト間の関係のマッピング（例）

エンティティが一覧表示されたら、それらを適切な関係で結びつける必要があります。

例えば、産業機器メーカーは、次のような関係（他にもあるが）を指摘するだろう：

• 1つの会社には、1つ以上の連絡先がある場合があります。各連絡先には、1つの会社しか登録されていません。
• ある企業は、任意の数の取引を持つことができます（あるいは、取引がゼロの場合もあります）。各取引は、正確に1つの企業に関連付けられています。
• また、取引には少なくとも1人の連絡先が関連付けられています。1つの連絡先は、任意の数の取引に関連付けることができます（あるいは、取引を一切関連付けないこともできます）。
• 各取引には、少なくとも1つの場所が関連付けられています。1つのロケーションには、1件以上の取引を関連付けることができます。
• 整備記録は特定の機器ごとに作成されるため、その記録に割り当てられる設置場所は1か所のみとなります。また、各サービス記録は、1つの取引に関連付けられています。

このステップでは、事業体（つまり、HubSpotで使用されるオブジェクト）が、互いにどのように関連付けられているかを示す線で結びつけられています。これらの行には、関連付けの種類（例：1対多、多対多など）も表示されます。

4: 関連付けラベルの追加（例）

エンティティ間の関係の中には、複雑なものが含まれる場合があります。ERDでは、関係にラベルを付けることで、特定のレコードが別のレコードとどのように関連付けられているかを正確に示すことができます。

例えば、当社の産業機器会社では、取引の成約のために多くの担当者とやり取りを行う場合がありますが、販売契約に署名する権限を持つのはその中のたった1人の担当者だけです。彼らは、商談と連絡先の関係にラベルを追加し、その連絡先の「役割」を明記することができます：

収益モデル別のERD例

以下に、さまざまな収益モデルを採用している企業を表した4つのERDの例を示します。各ERDの例は、その架空の企業に対する一つの解決策として設計されています。

さらに、各例では、同社が使用しているオブジェクトの一部にのみ焦点を当てています。完全なERDでは、マーケティング活動や顧客サービスプロセスなど、ビジネスの他の側面を追跡するためのオブジェクトも追加されることになるでしょう。

各例には以下の内容が含まれています：

• 架空の企業について、その事業運営の概要と、オブジェクトの使用に関して下されたいくつかの決定事項についての説明。
• CRMで使用する予定の主要なオブジェクトの一覧。実際には、これらの各事業では、ここに挙げたものよりも多くのオブジェクトタイプが使用されることになるでしょう。ここでは、さまざまな収益モデルを持つ企業が、それぞれの特定のニーズに合わせて標準オブジェクトやカスタムオブジェクトをどのように構成できるかを確認することを目標としています。
• 彼らのERDの概要。繰り返しになりますが、これらのスクリーンショットは、これらの事業に関するERDに含まれる内容の一部に過ぎません。

例：SaaS／サブスクリプション／MRR

SPRKTは、発明家が新しい携帯型ガジェットのモデルを作成できるクラウドベースのデザインスタジオを提供するソフトウェア企業です。このソフトウェアは、さまざまなプランが用意されたサブスクリプション方式で販売されています。

発明家は、このソフトウェアを使って、自分のガジェットのためのユニークなデザインをいくつも作成することができます。これらのデザインは、特定のソフトウェアインスタンス、すなわち顧客アカウント内で作成されます。SPRKTは、顧客がどの機能を利用しているかを追跡できるようにするため、顧客アカウントをカスタムオブジェクトとしてモデル化することにしました。

使用したオブジェクト：

• 連絡先：個人を表します。
• 企業：企業を表します。
• 「Deals」：ソフトウェアのサブスクリプション販売を表します。
• サブスクリプション：ソフトウェアの定期的な支払いを指します。
• 顧客アカウント：顧客のソフトウェアアカウントの個々のインスタンスを表します。顧客アカウントの記録では、ソフトウェアの利用イベント（新しいデザインの作成、特定の機能の利用など）を追跡することができます。

例：サービス／リテーナー

スプロケット・グループは、携帯型ガジェットの発明家向けにビジネスアドバイスを提供するコンサルティング会社です。同社では、特許出願や会社設立といったテーマに関する、1回限りのコンサルティングパッケージを販売しています。また、発明者が発明の販路開拓や販売プロセスの整備を行えるよう、継続的なコンサルティングサービスも提供しています。

必要なデータを洗い出した結果、HubSpotの標準オブジェクトで、自社が追跡したい項目をすべてカバーできることに気づいた。必要に応じて、これらの標準カスタムオブジェクトをカスタマイズすることも可能です。例えば、関連付けラベルを活用することで、企業が単発のサービスを購入した場合と、継続的なコンサルティング契約を結んだ場合とを区別することができます。

使用したオブジェクト：

• 連絡先：個人を表します。
• 企業：企業を表します。
• 「Deals」：コンサルティングパッケージの販売を表します。
• 定期契約：継続的なコンサルティングパッケージの料金を指します。
• サービス：単発のサービスまたは継続的なコンサルティングにおけるコンサルティング時間の提供を指します。サービス記録では、どのコンサルタントが当該顧客を担当しているか、また（単発サービスの 경우）パッケージに残っている時間が何時間あるかを把握することができます。また、サービスオブジェクトを使用して、その顧客に関連するすべての社内メモをまとめて管理することもできます。

例：eコマース取引

Sprockets ‘R’ Usは、携帯型ガジェットを販売するeコマース企業です。同社には2種類の顧客がいます。1つは一般消費者（ウェブサイトから直接注文する顧客）、もう1つは小売店（実店舗での再販を目的として商品をまとめて仕入れる顧客）です。

一般消費者への販売は、購入額が少額で、配送先も1か所に限られるため、追跡が比較的容易です。こうした顧客については、標準の取引レコードにすべての購入情報を記載することができます。しかし、小売店への販売はより複雑であり、複数の出荷を追跡する必要があり、サプライチェーンもより複雑になっています。彼らは、このより複雑なデータをカスタムオブジェクトを用いてモデル化することにした。

使用したオブジェクト：

• 連絡先：個人を表します。彼らの取引先のほとんどは、ウェブサイトから直接購入する一般消費者となるでしょう。
• 企業：商品をまとめて仕入れる小売店を指します。
• 「Deals」：売上を表します。同社は、2つの異なるパイプラインを活用することで、消費者への直接販売と小売販売を区別している。
• 小売出荷：まとめて出荷された荷物を指します。小売販売の中には、複数の出荷を必要とするものもあるため、出荷データを個別のレコードとして管理しておくと便利です。こうすることで、配送や返品を効率的に追跡することができます。
• 倉庫：出荷元の具体的な場所を表し、その場所にある在庫状況を追跡します。

例：プラットフォーム／マーケットプレイスのコミッション

Sprocket-Martは、ガジェットの発明者と顧客をつなぐプラットフォームです。このプラットフォームを利用すれば、発明家はシンプルなオンラインショップを作成し、そこで自作のガジェットを販売することができます。顧客は、マーケットプレイスの出品情報を検索・絞り込み、販売者を比較し、ガジェットを購入することができます。売上の一部が、コミッションとしてスプロケット・マートに支払われます。

Sprocket-Martは、マーケットプレイスのユーザーや、販売によって得られるコミッションを表現するために、HubSpotの標準オブジェクトを使用します。しかし、彼らは、発明者の公開プロフィールや、顧客がそれらの販売者プロフィールに投稿できるレビューを表すために、カスタムオブジェクトを使用することにした。そうすることで、一般に公開されるデータ（販売者のプロフィールやレビュー）と、社内の業務データ（ユーザー情報やコミッション）を区別することができます。

使用したオブジェクト：

• 連絡先：個人の発明者や顧客の代理を務めています。
• 取引：マーケットプレイスを通じて行われた販売により得られたコミッションを指します。
• プロフィール：特定の市場における販売者の詳細情報を表します。ごくまれに、個人の発明家が複数の店舗を運営している場合もあるため、contactオブジェクトとprofileオブジェクトの間には「1対多」の関係が確立されていることが重要です。
• マーケットプレイスでの取引：マーケットプレイス上で売り手と買い手の間で交わされる特定の取引を指します。マーケットプレイスでの売上は、販売者のプロフィール記録、購入を行った連絡先、およびマーケットプレイスのコミッションが記録されている取引レコードに関連付けられています。

次のステップ

• HubSpot でのデータモデルの管理について、詳しくはこちらをご覧ください。
• カスタムオブジェクトの作成と編集について、詳しくはこちらをご覧ください。