うまくいかない HubSpot 実装の多くは、間違ったツールや間違ったコンサルタントを選んだから失敗するのではありません。誰かがフェーズを圧縮したから失敗します。実装の弧には 5 つあります、Discovery, Design, Build, Launch, Optimize、各フェーズはチームが守る成果物で終わります。成果物を飛ばすと、次のフェーズはコミットメントではなく会話の上に乗ります。コストは 2 か月後、Build が 2 週目にクローズすべきだった決定を再開するときに現れます。
なぜ今これが重要なのか
デジタル投資が価値を生み出さない理由についての HBR のブリーフは率直に述べました。失敗モードはツーリングではなく、商業組織がインサイトを生み、意思決定し、行動を協調させる方法を再設計できないことです。HubSpot 実装は、B2B SaaS 企業内でその再設計が公の場に強制される数少ない瞬間の 1 つです、スキーマ、Pipeline、オーナーシップ、Reporting がすべて一度にテーブルに乗ります。5 フェーズ方法論は、再設計こそが仕事だからこそ存在します。プラットフォームの構成は最後の成果物です。
Discovery
Discovery はチームがもっとも頻繁に圧縮するフェーズで、圧縮がもっとも高くつくフェーズです。仕事は人と話すことではありません。仕事は、チーム全員がサインオフした書面の成果物を持って去ることです。Pipeline 定義、すべてのオブジェクトの指名されたオーナー、連携マップ、スコープ内とスコープ外のユースケース、実装が測定される成功基準。2 週間が公平な予算です。1 週間はやり直す Design フェーズを生みます。
悪い見え方：使用中のツール、いくつかのインタビュー引用、漠然としたゴールのセットを並べる Discovery デッキ。誰も反対しません。反対するのに十分具体的なものが何もないからです。Design はその後、決定を 1 つずつ、方向性を待つ開発者の前で発見します。
Design
Design はスキーマの決定が住む場所です。本番ポータルに存在するすべてのオブジェクト、Contact、Company、Deal、カスタムサブスクリプションオブジェクト、もしあればポートフォリオオブジェクト、は、ここで、何が構築される前に書面で定義されます。プロパティはデータ型、関連すればピックリスト、オーナー、1 文の定義を持ちます。Pipeline ステージは入場条件、退場条件、ステージが実際に何を意味するかの定義を持ちます。関連付けラベルは綴り出されます。Design 終了時のデリバラブルは、チームが質問せずにエンドツーエンドで読めるスキーマ文書とワークフローインベントリです。
悪い見え方：Design が HubSpot UI 内でクリックして起きる。プロパティがライブで追加される。Pipeline ステージが 3 回リネームされる。スキーマ文書が存在するなら、構築から 1 週間遅れる。3 か月後、Deal ステージ「Verbal」がなぜ存在するか誰も覚えておらず、答えられた唯一の人物は退職している。
Build
Build はスプリントフェーズです。うまくやれば、2〜6 週間の小さく、スコープを切り、レビュー可能なデリバラブルの連続です。サンドボックスにデプロイされたスキーマ、配線されたワークフロー、接続された連携、立ち上がったレポート、構成されたパーミッションセット。保つケイデンスは週次：次のスライスを確認するワーキングセッション、週半ばの構築スプリント、週末のデモ。保たないケイデンスは隔週のチェックインで、構築チームが消え、誰も見ていない完成ポータルとともに再登場するものです。
Build は、Discovery と Design が保たれていれば機能します。保たれていれば、Build はリストに対する実行です。保たれていなければ、Build はスタンドアップ装の議論です。診断テスト：任意の Build の週で、何件の決定が再開されているか？答えが 1 つか 2 つを超えるなら、上流の仕事は終わっていません。
Launch
Launch はカットオーバー、トレーニング、最初の 10 日間です。カットオーバーは金曜日、できれば静かな週の前、で、本番で起きる前にサンドボックスでリハーサルされます。トレーニングはレガシーではなく構築後のシステムに対して提供され、スコープしたリーダーだけでなく実際にシステムを使う人たちに提供されます。最初の 10 日間はハイパーケアウィンドウです。構築チームはオンコールで、ユーザー向けの問題は日ではなく時間でトリアージされ、実際の使用で現れる小さな修正は、チームが回避策で筋肉記憶を作る前にランディングします。
悪い見え方：カレンダーがそうしろと言ったから水曜日に起きる Launch、一度録画され動画として配布されるトレーニングデッキ、カットオーバー翌日に動員解除された構築チーム。3 週目までに回避策は習慣になり、回避策が今やシステムになり、Optimize フェーズはそれを改善するのではなく解きほぐすことになります。
Optimize
Optimize は誰も予算を計画しないフェーズです。実装は Launch までスコープされ、Optimize は誰かのパートタイム管理仕事として扱われます。それが間違いです。すべての HubSpot インスタンスは積み上がります。新しいプロパティが要求され、ワークフローはエッジケースを得て、レポートのニーズは進化し、チームは「見ようと思っていたもの」と「実際に見たいもの」を学びます。Optimize は、それらのシグナルが日次のノイズに吸収されるのではなく、ケイデンス、ほとんどの企業で月次が正しい、でトリアージされるフェーズです。
悪い見え方：Optimize はシニアのオペレーション担当者が火消しの間に手をつけられる範囲のもの、になる。6 か月後、システムは文書化されたスキーマから漂流し、誰も Launch 以来ワークフローを監査しておらず、次にチームに加わる人物は 3 分の 2 が元の設計、3 分の 1 が即興のインスタンスを引き継ぎます。誰も計画しなかった最適化予算が、今や誰も望まなかった移行プロジェクトです。
現場で見たパターン
シリーズ A の終盤の B2B SaaS チームが、6 週間のタイムラインで HubSpot 実装に来ました。Discovery は 4 日にスコープされていました。私たちは押し戻し、2 週間運用しました。成果物は Pipeline 定義、オーナーシップ、連携スコープ、成功基準、v1 でスコープ外にチームが合意したユースケースのリストをカバーする文書でした。Design は 3 週間かかり、スキーマ文書とワークフローインベントリを生成しました。Build はクリーンな 4 週間スプリント、週次デモ、決定の再開なし、でした。Launch は構築チームが配置された 1 週間のハイパーケアウィンドウ付きの金曜カットオーバーでした。Optimize は Launch の 30 日後に月次ケイデンスで始まり、今も走っています。名指しすべき部分：チームが新システム上で行った最初の四半期ビジネスレビューは、手動データクリーンアップを必要としませんでした。それが、圧縮されなかった Discovery が 10 か月後に買ってくれるものです。
解決策：各フェーズにマップするエンゲージメントモデルを選ぶ
5 つのフェーズは 1 つのエンゲージメントタイプの中に住む必要はありません。フェーズが異なれば、サポートの形も異なります。多くの B2B SaaS エンゲージメントで保つマッピング：
- Discovery はワークショップまたはタイトにスコープされたプロジェクトです。シニアの注意、外部の視点、社内チームがサインオフするデリバラブルが必要です。長期間の retainer は不要です。
- Design はプロジェクトです。デリバラブルはスキーマとワークフロー文書、予算は固定、タイムラインは 2〜4 週間。それとして扱ってください。
- Build はプロジェクトまたは組み込みエンゲージメントで、構成業務のうちどれだけを社内チームが吸収できるかに依存します。HubSpot 管理者が席にいればプロジェクトの形が機能します。いなければ期間中に誰かを組み込んでください。
- Launch はハイパーケアの尾を持つプロジェクトです。カットオーバー、トレーニング、最初の 10 日間を 1 つのブロックとしてスコープします。尾の人員配置を構築チームの善意に頼らないでください。
- Optimize は retainer または fractional サポートが対価に見合う場所です。月次ケイデンス、スコープされた時間、定義されたバックログ。間違いは Discovery が終わる前に retainer を買うこと。もう 1 つの間違いは Launch 翌日に失効させることです。
- クロスフェーズ：社内チームにまだシニアな RevOps 機能がないなら、Discovery、Design、Optimize を横断する fractional の組み込み役割がしばしば正しい形です。Build はプロジェクトのままです。
- ステージチェック：シードからプレシリーズ A では、ほぼ常にプロジェクトの形が正しいです、社内チームはまだ retainer を吸収する準備ができていません。シリーズ B 以降では、retainer または fractional モデルは通常 2 四半期以内に元を取ります。Optimize が誰かの副業でなくなるからです。
Checkpoint がどう関わるか
5 フェーズ方法論は、Checkpoint で運営するすべての HubSpot および CRM エンゲージメントの背骨です。グリーンフィールド実装はフェーズを順に走らせます。ブラウンフィールド移行は監査で Discovery を始めます。再設計は Design を伸ばし Build を短くします。フェーズはとどまり、比率が変わります。今実装をスコープしていてタイムラインが 5 つすべてを名指ししていないなら、キックオフ前に私たちにご相談ください。私たちはこれを HubSpot 実装として、GTM 戦略の一部として、そしてスタックを横断する組み込み RevOps サポートとして行います。
出典
- Sinha, Shastri, Lorimer. 「Why Your Digital Investments Aren't Creating Value」 Harvard Business Review、2026 年 2 月 16 日。hbr.org
- Lemkin, Jason. 「Which CRM Should You Use in 2026/2027? Follow the Agents」 SaaStr、2026 年 4 月 6 日。saastr.com