なぜHubSpot運用は
「属人化」するのか

国内トップクラスのDX支援を手がけるコンサルティング企業（従業員約150名）は、Marketoを使った高度なマーケティング自動化を実現していました。しかし数年後、その環境は「誰も全体を把握できない」状態に変わっていました。ワークフローは複雑に絡み合い、変更するたびに何かが壊れるリスクがある。設定の意図が特定の担当者の頭の中にしかない。

同社がHubSpotへの移行と同時に基盤を再設計した結果、分析工数を約30%削減し、顧客行動の100%可視化を実現しました。専門担当者以外でも施策を実行できる体制が整い、引き継ぎ可能な運用構造に変わりました。

この問題は「担当者の能力不足」ではありません。MAツールを設計思想なしに運用し続けると、必ず起きる構造的な問題です。

あなたのHubSpotは大丈夫か——5つの確認項目

1. 特定の担当者がいなければ、ワークフローの修正ができない

   「この設定、○○さんしか分からない」という会話が社内で起きていませんか。

2. プロパティの数が増え続け、どれが正しいか分からない

   「Lead Source」と「Lead Source 2」が混在し、正のデータがどこにあるか誰も把握できていない。

3. ワークフローに触ると「何かが壊れそう」で手が出せない

   条件分岐が積み重なり、影響範囲が不明なため改善を止めている。

4. SalesforceやSansanとの連携ルールが文書化されていない

   どちらが更新元か、何が同期されるかが担当者の記憶にしか存在しない。

5. 担当者が退職したとき、引き継ぎができるか自信がない

   設計書がなく、現在の運用が個人の知識に依存している。

3つ以上当てはまる場合、HubSpotは「組織の資産」ではなく「個人の負債」になっています。ツールの問題ではなく、設計構造の問題です。

属人化を生む3つのパターン

1. プロパティが増殖し続ける

   「とりあえず追加」を繰り返した結果、類似するプロパティが乱立します。どのプロパティを参照すべきかが不明になると、レポートの数字に対する信頼が失われます。

   判断基準：使用されていないプロパティが全体の20%を超えていたら、増殖が始まっています。

2. ワークフローがスパゲッティ化する

   条件分岐・自動更新・通知・ステータス変更が積み重なり、誰も全体構造を説明できなくなります。前述の企業でも、ワークフロー変更に「高いリスクと工数が発生する」状態が続いていました。

   判断基準：「このワークフロー、全部説明できますか」と聞いたとき、担当者が言葉に詰まったらスパゲッティ化しています。

3. 設計書が存在しない

   ライフサイクルステージの定義、MQL・SQLの条件、Salesforceとの同期ルール——これらが文書化されていない組織では、担当者が変わるたびに運用が変わります。設計書がないことが、属人化の最大の原因です。

   判断基準：「HubSpotの設計書を今すぐ見せてください」と言われて即座に出せるものがなければ、設計書は存在しないと考えてください。

再設計後に何が変わったか

前述のコンサルティング企業では、HubSpotへの移行と同時に運用構造を再設計したことで、以下の変化が起きました。

1. 分析工数を約30%削減

   自動化ロジックをシンプルに再設計し、専門担当者以外でも施策を実行できる体制になりました。

2. 顧客行動の100%可視化を実現

   Web・MA・CRMが一本化され、どの施策がどの顧客に影響を与えているかが把握できるようになりました。

3. Salesforce・Sansan・GA4との連携を再設計

   接点情報から商談データまで、不整合のないデータ循環を確立しました。担当者が変わっても同じ運用が継続できます。

ツールを変えるだけでは同じ問題が再現します。変えるべきは「設計思想」です。

まず3日でできること

1. 使われていないプロパティを棚卸しする

   HubSpotのプロパティ一覧を開き、過去90日間使用されていないプロパティをリストアップします。「削除できるか確認する」ではなく「なぜ存在するか説明できるか」を基準に棚卸しします。

2. すべてのワークフローに責任者を1人定義する

   全ワークフローに「このワークフローの責任者は誰か」を紐づけます。責任者を決めるだけで、変更が必要になったときに「誰に聞けばいいか」が明確になります。

3. ライフサイクルとMQLの定義を1枚の文書にまとめる

   MQL・SQLの条件、ライフサイクルステージの定義、Salesforceとの同期ルールを1枚のスプレッドシートに書き出します。この文書が存在するかどうかが、引き継ぎ可能な運用構造かどうかの分岐点です。

まとめ：属人化はツールの問題ではない

HubSpotが属人化する本質的な理由は、ツールの柔軟性ではなく、設計思想がないまま運用が積み重なることにあります。プロパティ・ワークフロー・ライフサイクル定義・連携ルールが構造として設計されていなければ、どれだけ高機能なツールも個人依存のシステムになります。

引き継ぎができる。変更しても壊れない。担当者が変わっても同じ運用が続く——この状態は、設計書1枚から始まります。