%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
HubSpotの展開は、全部門を同時に始めず、データの依存関係と完了基準で順番を決めると定着します。フェーズごとの範囲・設定場所・次へ進む判断を整理します。
HubSpotの段階展開計画とは、使う部門と機能を一度に広げず、データの依存関係と「次へ進む条件」を決めたうえで、順番に追加していく計画のことです。 多くの場合、顧客情報の起点になる営業から始め、マーケティング、カスタマーサクセス（CS）、請求などのバックオフィスの順に広げると手戻りが少なくなります。ただし、順番は業種と現状の痛みで変わるため、固定の答えではなく判断の軸で決めます。
全部門を同時に立ち上げると、定義がそろわないまま入力が始まり、「どの数字が正しいのか分からない」状態で止まります。反対に、営業だけで止めてしまうと、マーケティングやCSが別のツールに残り、CRMの価値が部分的にしか出ません——どこから始め、どこで広げるかの判断が、導入の成否を分けます。
この記事でわかること
- 広げる順番を決める3つの軸 ── データの起点・現状の痛み・他部門からの依存を表で判断する方法
- 5つのフェーズの範囲と完了基準 ── 営業から始めてバックオフィスまで、各段階の設定場所つき
- 営業フェーズの最小構成の手順 ── パイプライン・プロパティ・インポート・ダッシュボードの作り方
- 広げるときの設計と失敗の避け方 ── 権限・ワークフロー・AIの足し方と、止める判断
一度に全部門で始めると止まる理由
HubSpotは、営業・マーケティング・サービス・コンテンツ・データ管理・請求といった複数の機能を、Smart CRMという共通のデータ基盤の上で使う構成です。公式の製品紹介（HubSpot）でも、Smart CRMを基盤に各チームをつなぐ位置づけで説明されています。基盤が共通だからこそ、最初の定義が全部門に影響します。
共通の基盤が、定義のずれを全部門に広げる
会社・コンタクト・取引・チケットといったオブジェクトは、部門をまたいで同じレコードを参照します。営業が「顧客」と呼ぶ会社と、CSが「契約中」と呼ぶ会社の定義がずれたまま入力が始まると、後からそろえるために全件の見直しが必要になります。
たとえばライフサイクルステージを営業とマーケティングで別々に運用すると、同じコンタクトが部門ごとに違う状態に見えます。どちらかを正にするという判断が、展開の最初に必要になります。
立ち上げの負荷が現場の入力を止める
新しいツールの立ち上げ期は、現場の負荷が最も高い時期です。複数部門が同時に入力ルールを覚え、同時に移行データの確認を求められると、本来の業務が止まります。
その結果、入力が遅れ、データが古くなり、会議でHubSpotを開かなくなります。定着の問題は機能の不足ではなく、同時に求めすぎたことから起きることが多いと考えています。
「広げる」ことを最初から計画に入れる
スモールスタートは、小さく始めて終わりにすることではありません。範囲を絞る代わりに、「どの条件がそろったら次を足すか」を最初に決めておく進め方です。
最初の設計は、次のフェーズで追加する部門のデータが載る余地を残して作ります。広げる順番と条件が決まっていれば、最初の範囲が小さくても、全体像を見失いません。
広げる順番は3つの軸で決める
本記事は、広げる順番を決める判断軸を扱います。90日計画の立て方はスモールスタートDXの始め方、導入の手順全体はHubSpot導入完全ガイドにまとめています。
順番を「営業が先」と決め打ちする前に、自社の状況を3つの軸で確認します。軸ごとに、先に広げるべき側の見分け方が異なります。
| 判断の軸 | 確認すること | 先に広げる側の判断 |
|---|---|---|
| データの起点 | 顧客情報が最初に作られるのはどの部門か | 最初に会社・コンタクトを作る部門から始める |
| 現状の痛み | 情報の散らばりで、最も損失が出ている業務はどこか | 痛みが大きく、効果が数字で見える業務を先にする |
| 他部門からの依存 | その部門のデータを、他の部門が必要としているか | 他部門が待っているデータの源から先に整える |
データの起点で決める
問い合わせフォームからの流入が中心の事業では、マーケティングが起点になります。紹介や既存顧客からの商談が中心の事業では、営業が起点です。定期契約の更新が収益の中心なら、CSの情報が最初に必要になるかもしれません。
起点の部門から始めると、その後に広げる部門が、すでに入っているレコードを使えます。逆に起点を後回しにすると、他部門のレコードに関連付ける先がなく、あとから大量の補完が必要になります。
現状の痛みで決める
痛みの大きさは、「その情報が散らばっていることで何が起きているか」で測ります。たとえば、担当者の異動で案件の経緯が引き継げない、更新時期を見落とす、請求の漏れが出るといった事象です。
痛みを一つ決めて、その解消を最初のフェーズの目的にします。目的が一つに絞られていると、設定する項目も絞れ、完了の判定も明確になります。
他部門からの依存で決める
部門間には、データの依存関係があります。マーケティングの成果を売上で測るには、取引のステージ定義が先に必要です。請求を自動化するには、取引と商品項目が先に整っている必要があります。
次の表は、一般的な依存関係です。矢印の左が先に整えるもの、右がそれに依存するものです。
| 先に整えるもの | それに依存するもの | 依存の理由 |
|---|---|---|
| 会社・コンタクトの定義 | 取引・チケット・フォーム | すべてのレコードの関連付け先になるため |
| 取引のパイプラインとステージ | マーケティングの成果測定・請求 | 受注の定義が成果と請求の起点になるため |
| 契約・商品の情報 | CSの更新管理・見積・請求 | 更新日や請求の根拠になるため |
| ここまでのデータの品質 | ワークフロー・Breezeなどの自動化 | 自動化は入力の不備を増幅するため |
この表で、他のものが依存している「左側」を持つ部門から先に着手する、という見方ができます。
5つのフェーズの範囲と完了基準
広げる単位は、部門ではなく「フェーズ」で区切ります。各フェーズに、扱う範囲と、次へ進む完了基準を置きます。完了基準を満たしてから次へ進むことが、スモールスタートを広げる際の約束事です。
| フェーズ | 扱う範囲 | 次へ進む完了基準 |
|---|---|---|
| 0 現状整理 | 業務フロー・データの所在・決める項目の洗い出し | 起点部門・目的・用語の定義が合意されている |
| 1 営業 | 会社・コンタクト・取引、パイプライン、ダッシュボード | 週次の会議がHubSpotの画面で進み、別資料が不要になっている |
| 2 マーケティング | フォーム、ライフサイクルステージ、リスト、メール | 流入から商談化までが同じ定義で数えられている |
| 3 CS | チケット、ヘルプデスク、更新管理 | 問い合わせと更新が、顧客のレコードから追える |
| 4 バックオフィス | 見積・請求・会計の連携 | 受注から請求までの手入力の転記が除かれている |
フェーズ0〜4の5段階とは別に、ワークフローやBreezeによる自動化・AI活用を、各フェーズの品質が安定したところで重ねます。AIの活用は、入力されたデータの質に依存するためです。
フェーズ0：現状整理で「決める項目」を出し切る
最初に、既存の業務フローと、情報がどこにあるかを一覧にします。表計算、名刺、メール、共有フォルダ、チャットなど、置き場の数を数えます。
このとき、後から変えにくい設定（プロパティの内部名など）に当たる項目を洗い出し、先に決めます。変えにくい設定の代表例として、プロパティの内部名とオブジェクトタイプは作成後に編集できないと、公式ナレッジに記載されています。内部名は表示名と違い、あとから直せないため、命名規則をフェーズ0で決め切ります。
フェーズ1：営業を起点にする場合の完了基準
営業フェーズの完了は、「入力が済んだ」ではなく「会議が画面で進む」かどうかで判定します。週次の商談会議で、別の資料を作らずにパイプラインの画面を見て議論できれば、定着の入口に立てたといえます。
この基準は、定着を数字で見る習慣にもつながります。会議の運用は、HubSpot運用体制の構築ガイドでも整理しています。
フェーズ2以降は「前のフェーズの定義を借りる」
マーケティングやCSは、営業で決めた会社・コンタクト・取引の定義を借りて始めます。新しく作るのは、そのフェーズ固有のもの（フォーム、チケットのパイプラインなど）だけに絞ります。
借りられる定義が増えるほど、後のフェーズの設計が軽くなります。これが、起点から順に広げる最大の利点です。
営業フェーズの最小構成を作る手順
フェーズ1では、営業の取引管理に必要な最小の構成を作ります。ここでは、公式ナレッジで確認できた設定の場所を示します。最小構成に絞る理由は、あとから足せる設定は足し、変えにくい設定だけを慎重に決めるためです。
- プロパティの定義を先に決める。 設定アイコンから左サイドバーの「プロパティー」を開き、「オブジェクトを選択」でオブジェクトを選んで「プロパティーを作成」を押します。作成には「プロパティー設定の編集」権限が必要です。ラベルは後から直せますが、内部名は編集できないため、命名規則を先に決めます。詳細はプロパティーを作成・編集する（HubSpotナレッジ）で確認できます。
- 取引パイプラインを作る。 設定アイコンから「データ管理」の「オブジェクト」を選び、対象のオブジェクトを選んで「パイプライン」タブを開きます。「パイプラインを作成」から「ゼロから作成」を選びます。カスタムパイプラインの作成はStarter・Professional・Enterpriseで可能で、数の上限は契約体系によって異なります。手順はパイプラインの設定（HubSpotナレッジ）にあります。
- 既存データを取り込む。 「その他」の「データ管理」から「データ連携」を開き、「データをインポート」を選びます。重複を防ぐため、コンタクトはEメール、会社はドメイン名など、固有の識別子を必ず設定します。ファイルの準備はインポートファイルの準備（HubSpotナレッジ）、画面の手順はオブジェクトのインポート（HubSpotナレッジ）で確認します。
- ダッシュボードを1枚作る。 「その他」の「レポート」から「ダッシュボード」を開き、「コンテンツを追加」でレポートを置きます。最初は取引のステージ別件数と、担当者別の進捗の2つ程度に絞ります。詳細はダッシュボードをカスタマイズする（HubSpotナレッジ）です。
- 週次の会議で使い、足りない項目だけを足す。 運用してみて必要になった項目を追加します。最初から項目を増やさないことが、入力負荷を抑える要点です。
パイプラインのステージは「会議で使う区切り」にする
ステージは、細かく作りすぎると入力が負担になり、粗すぎると進捗が見えません。目安は、週次の会議で「次の一手」が変わる区切りだけをステージにすることです。
ステージの定義を、各ステージの入口の条件として一文で書いておくと、担当者ごとの解釈の違いを防げます。定義は、パイプラインの設計書に残します。
最初のダッシュボードは「会議で使う1枚」にする
ダッシュボードの目的は、会議で議論する材料を一か所に集めることです。公式ナレッジによれば、ダッシュボードに載せられるレポート数は契約プランによって異なるため、載せる指標は絞る必要があります。
見る指標が多すぎると、会議が数字の説明に終わります。「止まっている取引」と「次のステップ未設定の取引」のような、行動につながる指標を優先します。
マーケティングとCSへ広げるときの設計
営業フェーズが安定したら、次の部門を足します。足すときは、新しい部門のための設定を作る前に、すでにあるデータとの関係を決めます。
マーケティングは「ライフサイクルステージ」の定義を先に合わせる
マーケティングを足す最初の作業は、フォームやメールを作ることではなく、ライフサイクルステージの意味を営業と合わせることです。どの状態から営業の対応対象にするか、という受け渡しの定義です。
定義が決まれば、フォームの送信から営業への引き渡しまでを、同じ基準で数えられます。フォームの作成場所は、「その他」の「マーケティング」の「フォーム」です（フォームを作成（HubSpotナレッジ））。ライフサイクルの設計はライフサイクルステージ設計の手順に詳しくまとめています。
CSは「顧客のレコードから追える」状態を目標にする
CSを足すときは、問い合わせと更新の情報を、営業で作った会社・コンタクトのレコードに関連付けて持ちます。チケットは別のオブジェクトですが、会社に関連付けることで、顧客単位の履歴として見られます。
ヘルプデスクの設定は、HubSpotヘルプデスク設定ガイドで扱っています。ここでは、営業とCSで同じ会社レコードを見ているかを、完了基準にします。
各フェーズで追加する設計項目
次の表は、フェーズを進めるごとに追加する設計の例です。前のフェーズの項目は引き継ぎます。
| フェーズ | 追加する設計項目 | 前のフェーズから借りるもの |
|---|---|---|
| 2 マーケティング | フォーム項目、リストの条件、ライフサイクルの受け渡し基準 | 会社・コンタクトの定義、取引ステージ |
| 3 CS | チケットのパイプライン、更新日などの契約情報の持ち方 | 会社レコード、取引の受注情報 |
| 4 バックオフィス | 商品項目、見積・請求の連携項目、承認の流れ | 取引、会社、契約情報 |
バックオフィスと外部システムへつなぐ
請求・会計は、営業と顧客のデータが整ったあとの段階で接続します。先に接続すると、取引や商品項目の入力の不備が、そのまま請求の誤りになるためです。
HubSpotの製品紹介では、見積もり作成・請求・決済を1か所に集約する製品としてRevenue Hubが示されています。会計ソフトとの連携は、取引と商品項目の品質が決め手になります。
手入力の転記が残る箇所から連携する
最初に連携する対象は、手入力の転記が最も多い箇所です。たとえば、受注後に会計ソフトへ取引先と請求書を転記している業務です。
StartLinkは、HubSpotゴールドパートナーであり、Sync for freee / Sync for Notion の開発元です。HubSpotとfreeeをつなぐ場合の連携の考え方は、HubSpotとfreeeの業務自動化設計や、Sync for freeeの製品ページで確認できます。
連携の前に「どちらを正とするか」を決める
システム間で同じ項目を持つときは、どちらを正（元データ）とするかを先に決めます。取引先名や請求先の情報は、HubSpotを正にするのか、会計側を正にするのかで、同期の方向が変わります。
決めないまま双方向に同期すると、上書きの衝突が起きます。この判断は、連携を作る前の設計項目に入れます。
権限・ワークフロー・AIを足す順番
機能の追加にも順番があります。人と自動化の設定は、フェーズが進んでから足すほうが、運用が安定します。
権限はフェーズごとに見直す
ユーザーの権限は、設定アイコンの「ユーザーとチーム」から管理します。CRMオブジェクトごとに、表示は「全て」「チームの」「自分の」、編集・削除はこれに「なし」を加えた範囲から選べます（HubSpotユーザー権限の設定（HubSpotナレッジ））。
最初のフェーズでは、広く見せて入力を促し、フェーズが進んで他部門が入るときに、チーム単位で範囲を絞る、という流れが取りやすい進め方です。権限の設計の詳細はHubSpotパーミッション権限設計ガイドで扱っています。
ワークフローは手作業の型が決まってから
ワークフローは、「その他」の「自動化」から「ワークフロー」で作成します。公式ナレッジでは、公開前に「確認および公開」の画面で内容を確認する流れと、公開後にワークフロー履歴で登録されたレコードを確認する流れが示されています（ワークフローを作成（HubSpotナレッジ））。
手作業で数回回して型が固まってから自動化すると、条件の見直しが少なくて済みます。型が決まる前に自動化すると、直すたびに既存のレコードへの影響を確認する手間が増えます。
AIは「データが整ったフェーズ」に重ねる
BreezeなどのAI機能は、入力されたデータを材料にします。営業の入力が安定し、パイプラインの定義が固まったフェーズで重ねると、結果の良し悪しを判断できます。
AIを組み込んだ業務設計の考え方は、AIエージェントの導入ロードマップでも3段階で整理しています。
展開を止める判断とよくある失敗
計画どおりに進まない場合に、広げるのを止めて整える判断も計画の一部です。次の表は、段階展開でよく起きる失敗と、その回避策です。
| よくある失敗 | 起きること | 回避策 |
|---|---|---|
| 完了基準を決めずに次へ進む | 前のフェーズの入力が不安定なまま、次の部門が始まる | 各フェーズに「会議が画面で進む」など確認できる基準を置く |
| 部門ごとに別の定義で作る | ライフサイクルや取引の意味がずれ、集計が合わない | 共通の定義を先に決め、設計書に残す |
| 自動化を先に作り込む | 入力の不備が増幅され、修正の影響範囲が広がる | 手作業で型を固めてから、ワークフローに置き換える |
| 全プランの機能を最初に契約・設定する | 使わない設定が増え、運用の負担だけが残る | フェーズに必要な機能だけを使い、広げる段階で見直す |
契約プランは、広げる段階で見直す
プランの違いは、機能の使える範囲に影響します。たとえば、リードのパイプライン管理はProfessionalまたはEnterpriseが対象で、プロパティーへの条件付きロジックの追加もProfessionalまたはEnterpriseが必要です（プロパティーを作成・編集する（HubSpotナレッジ））。ワークフローも、各製品のProfessionalおよびEnterpriseが対象です。
必要になった段階で、使いたい機能とプランの対応を確認し、見直します。判断の基準はHubSpotアップグレードの判断基準で整理しています。
止める判断の目安
次のような状態なら、広げるのをいったん止めて、前のフェーズに戻ります。
- 週次の会議で、HubSpotの画面とは別の資料が使われ続けている
- 必須の項目の空欄が増え続けている
- 同じ指標を部門ごとに別の定義で数えている
StartLinkの進め方：工程と段階展開の対応
StartLinkのHubSpot導入支援は、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の5つの工程で進めます。段階展開では、この工程を、フェーズごとに小さく回します。
| 工程 | 段階展開での役割 | 主な成果物 |
|---|---|---|
| 現状の整理・要件定義 | 起点部門と目的を決め、展開の順番を設計する | 業務フロー、用語の定義、フェーズ計画 |
| 設計・構築 | フェーズの範囲だけを設計し、構築する | プロパティ・パイプライン・ダッシュボードの設計書 |
| データ移行 | 範囲内のデータだけを移し、件数を照合する | 移行前後の件数照合表 |
| テスト・検証 | 完了基準を満たしているかを確認する | 検証結果と次フェーズの可否 |
| 定着・運用改善 | 週次の運用を定着させ、次の拡張を判断する | 運用ルール、改善の記録 |
準委任で、フェーズごとに範囲を見直す
段階展開は、最初に全体の範囲を固定しにくい進め方です。そのため、準委任で伴走し、フェーズの完了ごとに、次の範囲を見直せる形が合います。進め方の違いは、HubSpot導入プロジェクトのPM実務で標準の6フェーズとして扱っています。
企業様（チーム）によって最適な形は異なりますので、起点部門と順番は、現状を整理したうえで決めるのが確実です。
よくある質問
Q1. HubSpotは営業から始めるのが正解ですか。
営業から始める進め方が多いのは、顧客と案件の情報がそこで最初に作られることが多いためです。ただし、問い合わせの流入が中心の事業ではマーケティング、定期契約の更新が中心の事業ではCSが起点になることもあります。データの起点、現状の痛み、他部門からの依存の3つの軸で確認してください。
Q2. 1つのフェーズは、どのくらいの期間で区切ればよいですか。
期間ではなく、完了基準で区切ります。営業フェーズなら「週次の会議が画面で進む」といった、確認できる状態を基準にします。期間で区切ると、基準を満たさないまま次へ進んでしまうためです。
Q3. 最初から全部のHubを契約したほうが効率的ではありませんか。
機能の契約と、運用の開始は別の判断です。使う機能が多いほど、設定と入力のルールも増えます。フェーズで使う機能に絞って始め、広げる段階でプランと機能の対応を確認する進め方を勧めます。プランごとの違いは、公式の製品・プランの情報で確認できます。
Q4. 途中で順番を変えてもよいですか。
変えられます。ただし、先に整えるべきデータ（会社・コンタクト・取引の定義）を飛ばさないことが条件です。順番を変えるときは、依存関係の表に戻り、新しい順番でも必要な定義が先に決まっているかを確認します。
Q5. 段階展開の途中でデータ移行が必要になった場合はどうしますか。
移行は、フェーズの範囲内のデータだけを対象にします。取り込み前に、重複を防ぐ固有の識別子と、関連付けの扱いを決めます。取り込み後は、元のデータと件数を照合します。取り込みの手順は、公式のインポートの記事で確認できます。
まとめ：順番と完了基準を先に決めてから広げる
- 広げる順番は、データの起点・現状の痛み・他部門からの依存の3つの軸で決める
- 各フェーズに「次へ進む完了基準」を置き、満たしてから広げる
- 営業フェーズは最小構成（プロパティ・パイプライン・取り込み・ダッシュボード1枚）で始める
- 権限・ワークフロー・AIは、データの型が固まったフェーズで足す
- 前のフェーズの定義を借りて広げ、部門ごとの別定義を作らない
最初の一歩は、起点になる部門と、解消したい痛みを1つ決めることです。そのうえで、5つのフェーズのどこまでを最初の範囲にするかを紙に書き出してみてください。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。サービスの全体像はHubSpot導入・活用支援で紹介しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
