HubSpot提案・要件定義7ポイント｜コンサルタントが押さえるべき実務の急所

HubSpot案件特有の要件定義7ポイントと、提案フェーズで見落としがちな判断軸を実務視点で解説します。

「提案書を出したのに、いざ要件定義に入ったら期待と全然違った」「導入後に『こんな機能要件があった』と追加発注が続き、炎上した」——HubSpotコンサルタントの実務でこうした事態は珍しくありません。

HubSpotは汎用CRM/MAとして広く普及していますが、その柔軟性ゆえに設計の余地が大きく、要件定義の質が後工程の全てを左右します。「どこまで設定するか」の境界が曖昧なまま案件を進めると、スコープクリープ・品質低下・定着失敗のどれかが必ず起きます。

本記事では、HubSpot案件の提案・要件定義で必ず確認すべき7つのポイントを、失敗例とベストプラクティスとともに整理します。あわせて、提案書の構成テンプレート、顧客のNGサイン、案件を断る判断軸まで解説します。StartLink（HubSpot Gold Solutions Partner）がコンサルティング実務で実際に使っているチェック観点に基づきます。

この分野の体系的な情報はHubSpot導入・活用ガイドでまとめています。

本記事はStartLinkの「HubSpotコンサルタント向けシリーズ」の一部です。

この記事でわかること

• HubSpot案件特有の要件定義7ポイント — 業務フローの確認、パイプライン設計、データ連携範囲、権限設計、KPI定義、移行データ、運用責任分担まで、各ポイントで確認すべき設問と失敗のパターンを整理します。
• 提案書の構成テンプレート — 顧客が意思決定しやすい提案書の組み立て方と、明記すべきスコープの境界線について解説します。
• 顧客のNGサインと案件を断る判断軸 — 受けてはいけない案件の特徴と、コンサルタントとして断りやすくなる軸の持ち方を説明します。
• 責任分担の明文化 — 定着失敗の最大要因は責任分担の曖昧さです。顧客側とコンサル側で何を分担するかを、契約前に合意する方法を解説します。

HubSpot案件で提案・要件定義を担当するコンサルタント、パートナー企業経由で案件に入る業務委託の方に向けた実務内容です。

HubSpot案件の要件定義が難しい理由

「何でもできる」が引き起こすスコープの曖昧さ

HubSpotの最大の強みは機能の幅広さと拡張性ですが、これは要件定義においてはリスクにもなります。「HubSpotなら何でもできる」という顧客の期待値は、実際の機能範囲や設定工数とかけ離れていることが多く、提案時に境界線を引かないまま進めると後から「あの機能も要件だったはず」という話が際限なく出てきます。

また、Salesforceやkintoneのようにエンジニアが設定する前提のシステムとは異なり、HubSpotは「ビジネス担当者が設定できる」という設計思想があります。このため、コンサルタントがどこまで設定し、どこから顧客に移管するかの境界線が曖昧になりやすいという特性があります。

他のCRM案件との違い

Salesforce案件では要件定義書が数十ページに及ぶことが当たり前ですが、HubSpot案件では「そこまで書かなくてもよいのでは」という空気が流れやすく、かえって認識齟齬の温床になります。要件定義の粒度を下げすぎないことが、HubSpotコンサルタントにとって重要な姿勢です。

HubSpotコンサルタントとしてのキャリア全体像については「HubSpotコンサルタントになるには｜未経験から案件獲得までのロードマップ」も参照してください。

要件定義7ポイント

ポイント1: 業務フローと期待成果のすり合わせ

要件定義の入口は、「HubSpotで何をしたいか」ではなく「今の業務フローとビジネス上の課題は何か」の確認から始めます。ツールありきで進める要件定義は、実際の業務に合わない設計を生みます。

確認すべき設問

• 現在の営業フロー・マーケティングフローを図示できるか
• Excel・スプレッドシートで管理していると感じる限界はどこか
• 1年後の理想状態（KPI・業務変化）を具体的に言語化できるか

失敗例: 「マーケティングを自動化したい」という要望だけを受けて、ライフサイクルステージの設計もフォームの設計もなしにメール自動配信だけを構築した結果、リードデータが蓄積されず自動化が機能しなかった。

ベストプラクティス: ヒアリングシートを提案前に送付し、業務フロー図（現状as-is / 理想to-be）を顧客自身に書いてもらうプロセスを挟む。顧客が図を書けない段階では、要件定義自体の前提が整っていないサインです。

ポイント2: ライフサイクルステージとパイプライン設計

HubSpotの根幹をなすのがライフサイクルステージとパイプラインの設計です。ここを提案フェーズで固めずに進めると、設定が始まってから「実は営業とマーケで定義が違った」「ステージの定義が全部担当者の主観で決まっている」という問題が必ず発生します。

確認すべき設問

• 「リード → MQL → SQL → 商談 → 顧客」の各ステージを定義できるか
• 各ステージへの移行条件を担当者以外にも説明できる状態か
• パイプラインは1本か複数か（商材・顧客セグメント別に異なるか）
• 各ステージでの受注確度（角度）を合意できるか

失敗例: パイプラインのステージ定義を担当営業マンの経験知だけで設定し、マネジャーと定義が異なることが判明。プロジェクト中盤で設計を全面見直しになった。

ベストプラクティス: ステージ定義はマネジャー・トッププレイヤー・マーケ担当の3者で合意する場を設ける。「アポ取得＝ミーティング設定済み」「見積もり提示＝導入判断テーブルに上がった提案」のように、全員が同じ状況を想像できる言葉で定義することが結構ミソになってきます。

ポイント3: データソース・既存システムとの連携範囲

HubSpotは単体で使うのではなく、既存のシステムと組み合わせて使われることがほとんどです。「何とつなぐか」の連携範囲を要件定義で明確にしないと、後から「Salesforceとの二重管理が発生した」「freeeへの入力が自動化されていない」という課題が噴出します。

確認すべき設問

• 現在使っているシステム一覧（SFA・MA・会計・ERPなど）
• HubSpotと連携させる対象システムと、連携方向（プッシュ/プル/双方向）
• 連携はHubSpotネイティブアプリかiPaaS（Zapier/Yoom）か、カスタムAPIか
• 連携の優先度と後工程での対応可否

失敗例: SalesforceとHubSpotの二重管理が前提のはずが、連携設計を後回しにしたため、営業がどちらに入力すればよいか判断できなくなった。

ベストプラクティス: システム連携マップ（どのデータがどこからどこへ流れるか）を提案書の付属資料として作成し、スコープ内/スコープ外を色分けして明示する。連携は初期フェーズではスコープ外にし、運用が安定した段階でフェーズ2として追加するスモールスタートのアプローチが現実的です。

ポイント4: ユーザー権限・チーム体制

HubSpotはユーザー権限の設計が甘いと、誰でもパイプラインを変更できる状態になり、レポートの信頼性が崩壊します。一方で権限を絞りすぎると、現場の入力がおろそかになる逆効果も生まれます。

確認すべき設問

• HubSpotを使う部門・役割（マーケ・インサイドセールス・フィールドセールス・CSなど）
• 管理者権限を持つのは誰か、その人は設定変更の判断ができるポジションか
• 閲覧のみ・入力のみ・設定変更できるの3レベルを誰に割り当てるか
• 有償シートと無償シート（表示のみ）の割り当て方針

失敗例: 全営業担当者にスーパー管理者権限を付与した結果、誰かがパイプラインステージを独自に追加・変更し、レポートの数値が合わなくなった。

ベストプラクティス: 権限設計は「役割ごとにできること/できないことを明文化した表」として要件定義書に含める。経営層・管理部門は「表示のみ」の無償シートで運用し、コスト最適化も合わせて提案するのが喜ばれます。

ポイント5: レポート・KPI定義

「HubSpotでレポートが見れるようになる」ことを導入目的に掲げる顧客は多いですが、どのKPIをどの頻度でどの会議で見るかが決まっていない状態では、導入後に「ダッシュボードを誰も見ていない」という結末になります。

確認すべき設問

• 月次/週次の営業会議・経営会議でどのデータが必要か
• 現在どんな方法でKPIを集計しているか（Excelか、SFAの標準レポートか）
• 「見たいKPI」と「測定可能なKPI」のギャップを認識しているか
• レポートを定期配信する仕組みが必要か

失敗例: 「商談金額のフォーキャスト」をKPIとして定義したが、パイプラインに金額を入力する運用が定着しておらず、レポートがゼロ表示のまま放置された。

ベストプラクティス: KPI定義と「そのKPIに必要なデータ入力項目」をセットで要件定義する。KPIが決まれば、必須プロパティの設定・ワークフロー設計・レポート設計が一貫して決まります。KPIの優先順位は「まず受注件数・受注金額から始めて、段階的に追加する」スモールスタートを提案するのが合理的です。

ポイント6: 移行データのスコープと品質基準

既存のシステム・Excelからのデータ移行は、多くのHubSpot案件で最もトラブルが起きやすい工程です。「全部入れてください」という要望をそのまま受けると、データクレンジングの工数が膨らみ、スケジュールが崩れます。

確認すべき設問

• 移行するデータの種類（コンタクト・会社・取引・添付ファイルなど）
• 移行対象の時間軸（過去何年分か、全件か活性データのみか）
• データ品質の現状（重複・表記揺れ・欠損の発生率）
• 移行作業の責任分担（顧客がクレンジングするか、コンサル側でスクリプト対応するか）

失敗例: 過去10年分・5万件のコンタクトデータを全件移行する要件を受けたが、データの重複率が40%超・姓名が全角/半角混在・メールアドレスの欠損が20%という状態で、クレンジングだけで追加1.5ヶ月を費やした。

ベストプラクティス: 移行データは「過去1〜2年間の活性データのみ」でスタートし、必要に応じてフェーズ2で追加移行する方針を提案する。移行前のサンプルデータ（1,000件程度）を確認し、品質基準（重複率・必須項目の充足率）を合意した上でスコープを確定する。CSVはExcel形式でのやり取りを推奨します（UTF-8 CSVは文字化けリスクがあるため）。

ポイント7: 運用定着の責任分担（顧客側 vs コンサル側）

定着失敗の最大の要因は、「コンサルが設定してくれれば使えるようになる」という顧客の誤解です。HubSpotは設定するだけでは動かず、現場がデータを入力し、マネジャーが確認し、改善を回すサイクルがあって初めて成果につながります。

確認すべき設問

• 導入後の設定変更・ワークフロー修正は誰が担当するか
• 社内でHubSpotの運用オーナーになれる人材がいるか
• コンサルのサポートは導入後も継続するか（月次契約の有無）
• 定着確認のマイルストーン（入力率・使用率のKPI）を設定できるか

失敗例: 「設定完了=プロジェクト終了」の契約で納品したが、3ヶ月後には社内で誰もHubSpotを使っていなかった。担当者が異動し、引き継ぎがなかったことが原因。

ベストプラクティス: 導入フェーズとは別に「運用定着フェーズ（3〜6ヶ月）」を契約の選択肢として提示する。最低でも月次の振り返りミーティング（30分）を設定し、入力率・活用率を追跡する仕組みを提案書に含める。「仕組み化」の観点から、マニュアル・操作動画・FAQドキュメントの整備も定着要件として明示することが重要です。

提案書の構成テンプレート

顧客が意思決定しやすい提案書の組み立て

HubSpot案件の提案書は、機能説明を並べるカタログ型ではなく、顧客の課題解決ストーリーとして構成することが結構ポイントになってきます。以下の構成がスタンダードです。

提案書の推奨構成

1. 現状課題の整理（ヒアリングで把握した内容の確認）

「御社の現在の課題として、○○・○○・○○を認識しています」という形で、顧客の言葉を使いながら整理する。顧客が「うちのことをわかってくれている」と感じる部分。

1. ゴール設定（1年後に実現する状態）

具体的なKPIを記載。「月次リード件数を○件から○件へ」「商談化率を○%へ」など数値を入れる。

1. 提案概要（HubSpotで解決するアプローチ）

機能説明ではなく、業務フローがどう変わるかを示す。「現状フロー→導入後フロー」の図を添付するのが効果的。

1. スコープ定義（何をするか、何をしないか）

「今回のスコープに含まれるもの/含まれないもの」を必ず明記する。この区分があることで後のスコープクリープを防げます。

1. フェーズ計画（段階的な導入ロードマップ）

フェーズ1（基盤設定）→フェーズ2（自動化・連携）→フェーズ3（分析・改善）という構成が典型。スモールスタートを示すことで顧客の安心感を高める。

1. 費用・期間

初期設定費用・ランニング費用（HubSpotライセンス）・月次サポート費用を分けて提示。

1. 体制・責任分担表

顧客側・コンサル側の担当者と責任範囲を一覧にした表を添付。

1. リスクと前提条件

「顧客からの情報提供が○週以内に完了しない場合はスケジュールが遅延する可能性がある」などの前提条件を明記する。

顧客のNGサインと案件を断る判断軸

受けてはいけない案件の特徴

要件定義のヒアリングを通じて、以下のサインが複数出ている場合は案件をお断りすることも選択肢に入れるべきです。受けてしまった後に問題が発覚するより、提案段階で見極める方がコスト・信頼コストともに低く抑えられます。

NGサイン一覧

案件を断る判断軸

断ることに心理的抵抗を感じるコンサルタントは多いですが、「全ての案件を受ける」姿勢は中長期の評判を傷つけます。以下の3軸で判断することをお勧めします。

軸1: 成功の前提が整っているか

コンサルがどれだけ良い設計をしても、顧客側の運用オーナーがいなければ定着しません。「弊社が介在することで成功確率が上がるか」を問いかける習慣を持ってください。

軸2: 適正な工数を確保できるか

「最安値で全部やってほしい」という要件は、工数的に不可能なことを無理に受けることになります。工数計算に基づいた見積もりより20%以上の値引きを要求される案件は、品質担保が難しくなります。

軸3: 自社の専門領域にフィットしているか

HubSpotコンサルタントとしてのスキルマップについては「HubSpotスキルマップ｜10領域で見る現場で求められる力」を参考に、自分が対応できる領域かどうかを確認してください。自分の専門外の要件が含まれる場合は、サブコントラクターを立てるか、案件の範囲を限定する交渉をする方が誠実です。

AI活用とコンサルタントの判断

AIで効率化できる部分と、人間が判断すべき部分

近年、HubSpotのBreeze AIなど生成AI機能が提案・要件定義フェーズにも影響を与えています。ヒアリングメモの構造化、要件定義書のドラフト生成、提案書テンプレートの作成などはAIで効率化が可能です。

ただし、ライフサイクルステージの定義・パイプラインのステージ分け・責任分担の合意はAIが代替できない領域です。これらは顧客のビジネス理解と人間間の信頼構築が不可欠で、AIに出力させたドラフトをそのまま顧客に提示することは避けるべきです。AIは「叩き台を作る道具」であり、最終判断と顧客合意は必ずコンサルタントが担う——この原則はHubSpot案件でも変わりません。

AI活用を含むコンサルタントの新しいスキルセットについては「HubSpot×AIコンサルタントに必要なスキルセット」で詳しく解説しています。

まとめ：提案・要件定義の品質が案件の成否を決める

HubSpot案件の提案・要件定義で押さえるべき7ポイントを整理します。

• 業務フローの確認: ツールありきではなく、現状の課題と理想状態から始める
• ライフサイクルステージ・パイプライン設計: ステージ定義を関係者全員で合意する
• 連携範囲の明確化: スコープ内/外を提案書でビジュアル化して境界を引く
• 権限設計: 管理者権限の範囲を役割ごとに明文化する
• KPI定義: 「見たいKPI」と「測定可能なKPI」のギャップを詰める
• 移行データのスコープ: 全件移行ではなく活性データのスモールスタートを提案する
• 責任分担の合意: 定着フェーズの責任を契約書レベルで明文化する

この7ポイントを要件定義書に落とし込む習慣を持つことで、案件の炎上リスクを大幅に下げられます。HubSpotコンサルタントとして案件管理の全体観については「HubSpot案件のプロジェクト管理｜炎上させないための実務設計」も参照してください。

案件獲得・受注チャネルについては「HubSpotフリーランスの案件獲得チャネル完全ガイド」で詳しく解説しています。

StartLinkは独立・フリーランスとしてのキャリアを全面的に応援しています。LinkProjectへの参加はキャリアの一段階として活用していただくことを想定しており、今後の独立を見据えた方も遠慮なくご相談ください。