HubSpotが使われない・形骸化した状態を立て直す方法｜原因の特定から再定着までの実務ガイド

HubSpot活用支援 HubSpot導入支援 HubSpot新規導入 HubSpot導入・運用

この記事の結論

HubSpotが使われなくなる原因は、機能でも操作性でもありません。「なぜこの設計になっているのか」を誰も説明できなくなることです。
説明できない仕組みは、触ると壊れるかもしれないという理由で放置されます。これが形骸化の実態です。
立て直しは「作り直し」ではありません。現状評価 → 意図の再構成 → 最小限の改修 → 再定着という順序で進めます。

この記事について

本記事は、HubSpotプラチナパートナーである株式会社クリエイティブホープが、実際の立て直し・引き継ぎ現場での経験にもとづいて編集しています。2015年よりHubSpotパートナーとして活動し、他社パートナーからの引き継ぎを10社以上担当してきました。

1. 形骸化の実態 ― よくある5つの状態

まず、自社がどの状態かを確認してください。

状態1：入力されていない

取引もコンタクトも、営業担当者が入れなくなっている。あるいは案件が決まってから事後入力されている。HubSpotが「管理のための入力作業」になっている状態です。

状態2：ワークフローが止まっている／暴走している

誰も止められないワークフローが動き続けている。あるいは、いつの間にか止まっていて誰も気づいていない。目的が記録されていないため、判断ができません。

状態3：プロパティが増え続けている

似た意味のカスタムプロパティが複数ある。誰がいつ何のために作ったか分からない。入力率が1桁の項目が並んでいる。

状態4：レポートが見られていない

作られたダッシュボードを、誰も開いていない。あるいは数字が実態と合わないため、結局スプレッドシートで別管理されている。

状態5：担当者がいなくなった

構築を主導した社内担当者、あるいはパートナーの担当者が変わり、現在の仕組みを説明できる人がいない。

2. 【核心】形骸化の原因は「設計意図の喪失」

上の5つの状態は、症状です。原因はほぼ1つに集約されます。

なぜ触れなくなるのか

HubSpotのポータルには、無数の判断の結果が積み重なっています。

なぜこのカスタムプロパティを作ったのか
なぜこの取引ステージは5段階なのか
なぜこのワークフローは、この条件で分岐しているのか
なぜこの連携は日次バッチで、リアルタイムではないのか

それぞれに、当時の業務要件に基づく理由があったはずです。しかしその理由が記録されていなければ、後任には「何が動いているか」しか見えません。

設計意図が失われると何が起きるか

不要に見えるプロパティを削除したら、実は月次レポートの集計軸だった
冗長に見えるワークフローを統合したら、営業部門固有の例外処理が消えた
使われていないパイプラインを整理したら、年に一度の特殊案件用だった

一度こうした事故が起きると、誰も触らなくなります。そして触らないまま、実態との乖離が広がっていく。これが形骸化の正体です。

だから「作り直し」は間違い

「全部作り直しましょう」という提案には注意してください。

既存の設計にも、当時の理由がありました。それを検証せずに刷新すると、業務上必要だった処理が消え、現場が混乱します。しかも、意図を記録しないまま作り直せば、数年後に同じことが起きます。

立て直しの本質は、設計意図を再構成することです。

3. 立て直しの4ステップ

Step 1：現状評価（アセスメント）

最初にやるべきはここです。改修も追加設定も、評価の後です。

調査対象	確認すること
オブジェクト構造	どの業務単位を、どのオブジェクトで表現しているか
プロパティ	総数、入力率、参照箇所、重複
ライフサイクルステージ	各ステージが指す実際の状態は何か
パイプライン・取引ステージ	遷移条件と、実際の営業プロセスとの対応
ワークフロー	総数、稼働状況、トリガー、依存関係
リスト	動的／静的、参照箇所
連携	同期方向、頻度、エラー発生状況
レポート	誰がどの意思決定に使っているか（使われていないものの特定）
権限	誰が何を見られるか。管理者は誰か
利用実態	ログイン頻度、部門別の利用状況

最も重要な指標は「プロパティの入力率」と「ワークフローの依存関係」です。

入力率は、そのプロパティが業務で必要とされているかの客観的な証拠になります。議論ではなくデータで判断できます。

ワークフローの依存関係は、改修時のリスクを測る指標です。あるワークフローを止めたときに、何が連鎖して止まるかが分かります。

Step 2：業務とのギャップを特定する

ツールを見るだけでは、立て直しはできません。実際の業務プロセスをヒアリングし、ツール上の表現と突き合わせます。

確認する質問の例：

「商談はどういう流れで進みますか。誰がいつ何を判断しますか」
「この取引ステージに進むのは、実際にはどういう状態のときですか」
「HubSpotに入れていない情報は何ですか。それはどこにありますか」
「レポートを見て、次に何をしますか」

「HubSpotに入れていない情報はどこにあるか」という質問が特に有効です。多くの場合、実務はスプレッドシートやメールで回っており、そこにこそ本当の業務プロセスが表れています。

Step 3：優先順位をつけて最小限の改修

全部直そうとしないでください。以下の順で分類します。

分類	対応
クリティカル	業務が回らない／数字が間違っている → 最優先で改修
改善余地あり	不便だが業務は回る → 第2フェーズ
許容範囲	気になるが実害がない → 触らない
削除候補	入力率1桁、参照ゼロ → 影響確認のうえ整理

「許容範囲」を作ることが重要です。すべてを理想形にしようとすると、改修範囲が膨れ、現場の負担が増え、また使われなくなります。

Step 4：ドキュメント整備と再定着

ここを飛ばすと、数年後に同じ状態に戻ります。

整備すべきドキュメント

オブジェクト構造の設計書
プロパティ一覧（名称、型、用途、参照箇所）
ライフサイクルステージの定義（各ステージが指す実際の状態）
パイプラインと取引ステージの定義（遷移条件を含む）
ワークフロー一覧（目的、トリガー、依存関係）
連携仕様書
権限設計

すべてに「なぜそうしたか」を書いてください。これが設計意図の記録です。

再定着の施策

管理者向けトレーニング（設定変更ができる人を社内に2名以上）
エンドユーザー向けトレーニング（入力の目的を説明する。操作方法だけでは定着しません）
入力を減らす（必須項目を最小化する。増やすのではなく減らす）
入力が本人のメリットになる設計にする（レポートで自分の成果が見える、など）

4. 再発を防ぐ5つのルール

1. スーパー管理者を社内に最低2名置く
1名だと、その人が異動・退職した瞬間に管理不能になります。なお、パートナー従業員にスーパー管理者権限を渡したままにするのは推奨されません。HubSpotの「セキュリティー健全性」機能は、この状態をリスクとして提示します。パートナー向けには「パートナー管理者」権限が用意されています。

2. プロパティを増やすときのルールを決める
「誰が承認するか」「何のために使うか」「入力率が一定を下回ったら削除するか」を事前に決めておきます。

3. ワークフローに命名規則と説明を必須にする
名前だけで目的が分かる規則にし、説明欄に必ず目的と依存関係を書きます。

4. 四半期ごとに棚卸しする
入力率の低いプロパティ、稼働していないワークフロー、見られていないレポートを定期的に確認します。

5. パートナー契約の成果物に、ドキュメントと設計意図の記録を明記する
一度作って終わりではなく、更新版の受領を定例の成果物に組み込んでください。

5. 費用と期間の目安

現状評価（アセスメント）

対象範囲	目安
シングルハブ	50万円前後
マルチハブ	100万円前後
マルチハブ＋システム連携	200万円前後

Sales Hubのように業務と直結するHubは、評価コストが高くなります。業務フロー全体の理解が必要になるためです。

立て直し全体

評価から再定着まで、1〜3か月が目安です。改修範囲によって変動します。期間の大半は、改修ではなく現状把握に費やされます。

詳しい費用の考え方は HubSpot導入支援の費用相場と見積もりの読み方をご覧ください。

6. 現行パートナーを変えるべきかの判断

立て直しの相談は、しばしば「今のパートナーを変えるべきか」という問いとセットになります。

先に確認してほしいこと

状況	取るべき行動
要望を明確に伝えていない	まず伝える。改善されるなら変更不要
伝えたが改善されない	第三者による現状評価で、原因の所在を特定する
契約範囲外が原因	範囲の見直しを交渉する
社内担当者の退職が原因	パートナーではなく、現状の言語化を依頼する
設計思想そのものが自社と合わない	引き継ぎを検討する

原因が自社側にある場合、パートナーを変えても再発します。判断の詳細は HubSpotパートナーの乗り換え・引き継ぎ完全ガイドをご覧ください。

よくある質問（FAQ）

Q1. 全部作り直したほうが早いのでは？

推奨しません。既存設計にも当時の理由があった可能性があり、検証せずに刷新すると業務上必要な処理が消えます。さらに、意図を記録しないまま作り直せば数年後に同じ状態に戻ります。まず現状評価を行い、何を残し何を変えるかを決めてください。

Q2. 現状評価では何をするのですか？

オブジェクト、プロパティ（入力率含む）、ワークフローの依存関係、レポートの利用実態、連携状況、権限、ログイン頻度などを棚卸しし、実際の業務プロセスと突き合わせてギャップを特定します。設計意図が記録されていない部分は、リバースエンジニアリングで推定します。

Q3. 社内担当者が退職して何も分かりません。どうすればよいですか？

このケースでは、まず現行パートナーに設計意図の説明とドキュメント化を依頼してください。それが難しい場合、第三者による現状評価で仕組みを解読し、社内に定着させ直すことになります。

Q4. 立て直しにはどれくらいかかりますか？

評価から再定着まで1〜3か月が目安です。ただし大半は現状把握の工程で、改修そのものはその後です。

Q5. どのプロパティを消してよいか、どう判断しますか？

入力率が最も客観的な指標です。直近1年の入力率が1桁の項目は、実質的に使われていません。ただし削除前に、レポート、ワークフロー、リスト、連携での参照箇所を必ず確認してください。

Q6. 現場が入力してくれません。どうすればよいですか？

必須項目を減らしてください。増やすのではなく減らすのが原則です。あわせて、入力が本人のメリットになる設計（自分の成果がレポートで見える、次のアクションが自動で提示される）にすると定着します。「管理のための入力」は続きません。

Q7. パートナーに依頼せず、自社だけで立て直せますか？

可能性はあります。ただし設計意図が失われている場合、社内の誰も判断できない状態になっているはずです。第三者による現状評価だけを切り出して依頼し、その結果をもとに自社で改修するという進め方も現実的です。

まとめ

形骸化の原因は「設計意図の喪失」。説明できない仕組みは、触ると壊れるかもしれないという理由で放置されます
作り直しは解決策ではない。意図を記録しないまま作り直せば、数年後に同じ状態に戻ります
順序は、現状評価 → ギャップ特定 → 最小限の改修 → ドキュメントと再定着
入力率が最も客観的な判断指標。議論ではなくデータで決めてください
「許容範囲」を作る。すべてを理想形にしようとすると、また使われなくなります
スーパー管理者は社内に最低2名。1名では属人化します
ドキュメントには「なぜそうしたか」を書く。これが設計意図の記録です

立て直し・現状評価のご相談

株式会社クリエイティブホープは、HubSpotプラチナパートナーとして、他社パートナーからの引き継ぎを10社以上担当してきました。

まず現状評価だけ、というご依頼を歓迎しています。評価なしに改修を始めると、必ず何かを壊します。評価の結果、現行体制を継続すべきという結論になることもあります。

ご相談いただける内容

導入したが使われていない状態を立て直したい
担当者が退職し、何がどう動いているのか分からない
プロパティやワークフローが増えすぎて整理できない
レポートの数字が実態と合わない
第三者として、現在の状態を評価してほしい

無料で相談する →　支援メニューを見る →　支援事例を見る →

編集：株式会社クリエイティブホープ（HubSpot Platinum Partner）
2015年よりHubSpotパートナー／有資格者30名以上／他社からの引き継ぎ実績10社以上
HubSpot「Customer First in Japan 2021」「Grow Better at Community 2021」受賞
著書『HubSpotワンストップマーケティング』（フォレスト出版・2022年）
https://www.creativehope.co.jp/hubspot

最終更新日：2026年8月29日