営業とマーケが「勝てる」HubSpotプロパティ設計:衝突をなくす項目・命名・運用ルールとDX戦略
HubSpotプロパティ設計で営業とマーケが揉める問題、解決します。項目・命名・運用ルールを具体的に解説し、DX視点で両部門が協力し「勝てる」設計を提案。衝突をなくし、成果を最大化する秘訣。
目次 クリックで開く
営業とマーケが「勝てる」HubSpotプロパティ設計:衝突をなくす項目・命名・運用ルールとDX戦略
「HubSpotを入れたがデータがバラバラで使えない」「営業が入力してくれない」……その原因はプロパティ設計の思想不足にあります。100件超のBI研修と50件超のCRM導入支援から導き出した、現場が回り、経営が可視化される「究極の設計ガイド」を公開します。
なぜHubSpotのプロパティ設計で「営業」と「マーケ」は衝突するのか
HubSpotを導入する際、最も重要でありながら最も軽視されがちなのが「プロパティ設計」です。プロパティとは、顧客の社名、メールアドレス、商談金額などを格納する「箱」のこと。この箱の作り方が悪いと、マーケティング部門は「リードの質が分からない」と嘆き、営業部門は「入力項目が多すぎて本来の仕事ができない」と憤慨します。
連携不足が引き起こすデータ活用の「死」
多くの企業で見られるのは、マーケティングが「分析のために」と数十個の必須項目を並べ、営業がそれを無視して「未入力」のまま商談を進める光景です。これにより、HubSpot内には「ゴミデータ」が蓄積され、高額なライセンス料を払っているにもかかわらず、結局は個人のExcel管理に戻ってしまう。これがデータサイロ化の正体です。
現場を50件以上見てきた経験から断言しますが、プロパティの数は「営業担当者が1分以内に更新できる量」に絞るべきです。網羅性を求めて項目を増やすほど、データの正確性は反比例して低下します。設計のコツは、項目を「増やす」ことではなく、いかに「自動で埋めるか(あるいは削るか)」にあります。
営業とマーケのニーズを両立させるプロパティ項目設計の正解
双方が納得する設計には、役割に応じた責務の分離が必要です。以下の表に、実務で推奨するプロパティ構成をまとめました。
| カテゴリ | 項目名(例) | 入力責任 | 目的 |
|---|---|---|---|
| 基本属性 | 会社名、業種、従業員規模 | マーケ(自動補完推奨) | ターゲットセグメンテーション |
| リードソース | 初回参照元、広告キャンペーン | システム(自動) | ROI(投資対効果)の可視化 |
| 検討フェーズ | ライフサイクルステージ | 共通ルール | 部門間の受け渡しトリガー |
| BANT情報 | 予算、導入時期、決定権者 | 営業 | 受注確度の予測 |
| 失注理由 | 競合負け、時期尚早、価格 | 営業 | マーケティング施策の改善 |
「顧客の反応」というプロパティをテキストエリアで作っていませんか?これは分析において最悪の選択です。必ず「ドロップダウン形式」で選択肢を用意し、統計的に処理できるように設計してください。自由記述は、メモ機能や別の「補足プロパティ」に限定すべきです。
公式事例から学ぶ、成果を出すためのデータ構造
HubSpot公式のリファレンスでも、データの「一貫性」が成功の鍵として挙げられています。例えば、Sansan株式会社のような大手企業でも、HubSpotを活用して営業とマーケの連携を強化し、受注率を大幅に向上させています。
【出典URL】Sansan株式会社のHubSpot導入事例(HubSpot公式サイト)
国内外の主要ツール比較とコスト感
CRM/SFAの選定において、HubSpotは非常に優秀ですが、他ツールとの比較も重要です。自社のフェーズに合ったものを選びましょう。
| ツール名 | 特徴 | 初期費用目安 | 月額目安 | 公式サイト |
|---|---|---|---|---|
| HubSpot | マーケ・営業・CSが完全統合。UIが直感的。 | 0円〜(導入支援は50万〜) | 1.2万〜 / 月 (Starter) | 公式サイト |
| Salesforce | 拡張性が世界最高。大規模・複雑な要件向け。 | 20万〜(構築は100万〜) | 1.8万〜 / 月 (Pro) | 公式サイト |
| Senses (Mazrica) | 国産ツール。現場の入力負荷軽減に特化。 | 要問合せ | 10万〜 / 月 (企業単位) | 公式サイト |
誰でも迷わない!プロパティの命名規則と運用管理
プロパティが増えてくると「この項目、誰がいつ作ったの?」という問題が必ず起きます。これを防ぐための「近藤流・命名ルール」を伝授します。
1. プレフィックス(接頭辞)の活用
mkt_:マーケティング部門が管理する項目(例:mkt_lead_source)sls_:営業部門が管理する項目(例:sls_budget_confirmed)sys_:システム連携用(例:sys_kintone_id)
2. 内部名の固定
表示名は「リードソース」でも良いですが、内部名(API参照名)は一度決めたら絶対に変えないでください。内部名を変えると、連携しているBIツールやワークフローがすべて壊れます。
HubSpotの設定画面だけで管理するのは不十分です。Googleスプレッドシート等で「プロパティ定義書(データ辞書)」を作成し、項目の定義、選択肢の意味、必須入力のタイミングを明文化してください。これが無いと、新入社員が入るたびにデータの定義がズレていきます。
具体的な導入・活用シナリオ:製造業BtoB企業の成功例
ある中堅製造業(従業員300名)では、展示会で獲得した年間2,000件のリードが、営業の「追客漏れ」により放置されていました。
- 課題:展示会後のフォロー状況がHubSpot上で見えず、マーケは「営業が動かない」と不満。営業は「質の低いリードばかり」と不満。
- 施策:プロパティに「sls_first_contact_date(初回連絡日)」と「sls_reject_reason(拒絶理由)」を新設。営業が連絡しない場合、自動でアラートが飛ぶワークフローを構築。
- 結果:初回コンタクト率が30%から95%へ向上。拒絶理由を分析することで、マーケは展示会のターゲット選定をブラッシュアップし、有効商談数が前年比1.5倍になりました。
このように、データ基盤を整えることは、単なる管理ではなく「部門間のコミュニケーション」をシステムで解決することに他なりません。こうした基盤の上に、さらに高度なデータ活用を載せる場合は、以下の記事も参考にしてください。
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』高額なCDPは不要?BigQuery・dbt・リバースETLで構築する「モダンデータスタック」
まとめ:プロパティ設計は「事業の地図」を描く作業
HubSpotのプロパティ設計は、単なるツールの設定作業ではありません。自社の営業プロセスを可視化し、マーケティングの羅針盤を作る「事業の地図」を描く作業です。本記事で紹介したルールと項目を参考に、ぜひ「現場が喜ぶ、経営が動く」データ基盤を構築してください。
設計に迷ったら:もし「自社の複雑なビジネスモデルをどうプロパティに落とし込めばいいか分からない」とお悩みであれば、一度実務のプロにご相談ください。多くの企業の泥臭い現場を見てきたからこそ、ツールありきではない、事業成長に直結する設計をご提案できます。
現場の混乱を防ぐための「HubSpot運用チェックリスト」と最新仕様
設計したプロパティを形骸化させないためには、HubSpot独自の仕様と運用ルールを事前に把握しておく必要があります。特にデータの「上書き」や「作成上限」は、後からの修正が困難なため注意が必要です。
1. プラン別プロパティ作成上限と型変更の制約
HubSpotでは契約プランによって、作成できるカスタムプロパティの数に上限があります。また、一度作成したプロパティの「型(ドロップダウンからテキストなど)」は原則として後から変更できないため、初期設計が重要です。
| 項目 | Free / Starter | Professional | Enterprise |
|---|---|---|---|
| カスタムプロパティ上限 | 10個まで | 1,000個まで | 1,000個まで |
| 計算プロパティ数 | 5個まで | 100個まで | 200個まで |
| 主な制約 | 自動ワークフロー不可 | 条件付きフォーム可 | カスタムオブジェクト可 |
※2026年時点の最新仕様。詳細はHubSpot製品・サービスカタログ(公式サイト)をご確認ください。
2. データの「真実」を守る名寄せと同期のルール
HubSpotを導入しても、外部ツールからのインポートでデータが重複しては意味がありません。特に名刺管理SaaS等と連携する場合、どの項目を「正」とするかの優先順位(ソース優先度)を定義しておく必要があります。
例えば、Sansan等のツールと連携する際は、手入力のプロパティよりもシステム連携プロパティを優先する設定が推奨されます。具体的な連携の実務については、以下の記事が参考になります。
3. ライフサイクルステージの「逆戻り禁止」原則
HubSpotの標準プロパティである「ライフサイクルステージ」は、デフォルト設定では「前のステージに戻らない」仕様になっています(例:商談からリードに戻しても自動では更新されない)。この仕様を知らずに運用すると、マーケティングの分析レポートが実態と乖離します。
HubSpotの「オブジェクト設定」にある「ライフサイクルステージの自動更新」をオンにしている場合、商談の作成と連動してステージが自動で進みます。意図しない上書きを防ぐため、運用開始前に「どの操作がどのプロパティを動かすか」の相関図を作成することをお勧めします。
さらなる高度なデータ連携を目指す方へ
プロパティ設計が完了した後は、それらのデータをいかに「止まらない業務フロー」に落とし込むかが次のステップです。SFAとCRM、あるいは会計ソフトまで含めた一気通貫のアーキテクチャ設計については、こちらのガイドもあわせてご覧ください。
📚 関連資料
このトピックについて、より詳しく学びたい方は以下の無料資料をご参照ください:
なお、各種アプリのすべての機能を使用するには、Gemini アプリ アクティビティを有効にする必要があります。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。
【補論】プロパティ「棚卸シート」テンプレ
本文の「データ辞書」を運用に耐える形にするため、最低限のテンプレ列を提示します。Googleスプレッドシートに貼って初回棚卸の出発点に。
| 列名 | 記入例 |
|---|---|
| internal_name | sls_budget_band |
| label | 予算レンジ |
| type | dropdown |
| choices | 〜100万 / 100〜500万 / 500〜2000万 / 2000万〜 |
| owner | 営業企画 |
| update_method | 手動/Workflow/API |
| required_at | 商談作成時/受注時 |
| downstream_use | 予算別案件レポート, BANTスコア |
| archive_condition | 過去90日 0更新で見直し |
「失注理由・受注理由」の標準ドロップダウン
本文では自由記述禁止を強調していますが、選択肢の作り方が運用の8割を決めます。集計可能な3階層構造を推奨。
| L1(大分類) | L2(中分類) | 対応部門 |
|---|---|---|
| 価格 | 予算超過 / 競合より高い | プロダクト+営業 |
| 機能 | 機能不足 / カスタマイズ困難 | プロダクト |
| タイミング | 時期尚早 / 予算次年度 | マーケ(休眠ナーチャ) |
| 競合 | 競合A/B採用 | プロダクト+経営 |
| 体制 | 社内合意取れず/意思決定者不在 | 営業(アプローチ改善) |
計算プロパティ vs DWH算出 の使い分け
| 指標 | 場所 | 理由 |
|---|---|---|
| 取引総額 | HubSpot計算 | SUM/COUNT程度 |
| 直近90日のEngagementスコア | HubSpot計算 | 標準スコアリング |
| LTV予測・解約予兆 | DWH(dbt) | 複雑なロジック・履歴利用 |
| アカウント階層集計 | DWH(dbt) | 親子関係を含む |
3部門(マーケ/営業/CS)の役割分離テンプレ
- ☑ マーケ所有:mkt_lead_source, mkt_first_touch_campaign, mkt_lifecycle_score
- ☑ 営業所有:sls_budget_band, sls_decision_role, sls_close_reason
- ☑ CS所有:cs_health_score, cs_renewal_risk, cs_csat_latest
- ☑ システム所有:sys_dwh_synced_at, sys_dedupe_master_id
- ☑ Salesforce由来:sf_account_id, sf_opp_stage(読み取り専用)
本文「ライフサイクル逆戻り禁止」の運用回避策
仕様上は逆戻りしませんが、復活営業・休眠化が起きると現実は逆流します。代替プロパティ運用が必須。
- ☑ secondary_stage(カスタムプロパティ)を併設し、復活時はそちらを書き換える
- ☑ stage_history(テキストログ)に手動/自動で履歴を残す
- ☑ レポートは secondary_stage側で集計(標準ステージとの差分も可視化)
データクリーニング 月次運用
| 作業 | 頻度 | 担当 |
|---|---|---|
| 重複Contact検出・統合 | 週次 | マーケOps |
| 必須項目の欠損率レポート | 月次 | マーケOps |
| 未使用プロパティのArchive候補抽出 | 四半期 | RevOps |
| 命名規約違反の検知 | 月次 | RevOps |
FAQ(本文への補足)
- Q. プロパティを後からSalesforceへ移行する場合の注意は?
- A. 「内部名統一」「型一致(picklist↔dropdown)」「Owner情報の再マッピング」がポイント。詳細は SFA・CRM・MA・Webピラー。
- Q. プロパティが既に300超ある状況の整理手順は?
- A. 「過去90日の参照ゼロ → Archive候補」「重複定義 → 統合」「Owner不明 → オーナー指定 or 廃止」の3ステップ。
- Q. 自由記述プロパティを撲滅できない場合は?
- A. 「自由記述用は別フィールド(notes)に集約」+「集計対象は dropdown 限定」に分離するのが現実的。
関連記事
- 【HubSpot×CDP/Reverse ETL】(ID 543)
- 【HubSpot×広告連携】(ID 554)
- 【Marketo×Salesforce連携】(ID 601)
- 【BtoB Data Cloud】(ID 556)
※ 2026年5月時点。本文の補完を目的とした追記です。
CRM・営業支援
Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。