CRM/SFAを使いこなせない本当の理由と解決策

結論

• CRM/SFA形骸化の本質はツールではなく営業プロセスとツール設定を翻訳する人材の不在
• 機能追加病・現場不在設計・データ統合欠如の3パターンが活用失敗を生む
• GTMエンジニアが営業プロセス・ツール思想・データ基盤を橋渡しする翻訳者となる

この記事が役立つ状況

• 対象者: CRM/SFA導入後の活用に課題を抱える営業マネージャー・営業企画担当・情報システム部門リーダー
• 直面している課題: Salesforce/HubSpotに高額投資をしたが現場で使われず、データが分散しレポートを手作業で作っている状態から脱却したい
• 前提条件: 営業プロセスの実態を可視化する意思があり、最小構成からの段階的拡張と全体データフロー設計を許容できる組織体制

あなたはCRM/SFA活用の翻訳者として動いてください。

# 自社の現状
- 利用ツール: [Salesforce / HubSpot / その他]
- ライセンス費用規模: [年間◯◯万円・ユーザー数◯名]
- 形骸化している兆候: [Excel併用 / レポート手作業 / 商談管理のみ等]

# 失敗パターン診断
以下3つのうち、自社に当てはまるものと具体症状を教えてください。
1. 機能追加病（カスタムフィールド・ワークフローの肥大化）
2. 現場不在の設計（マネージャー理想と現場実態の乖離）
3. データ統合の欠如（複数システムにデータ分散）

# 出力してほしいもの
- 営業プロセスの可視化から始める初動アクション
- 最小構成で再設計すべき項目とワークフロー
- リード〜CSまでの全体データフロー設計案
- 意思決定から逆算したダッシュボード要件

# 制約
- [現場ヒアリング可能期間: ◯週間]
- [意思決定したい経営指標: ◯◯]

導入したのに使われないCRM/SFA

Salesforceの年間ライセンス費用、いくら払っているか把握しているだろうか。1ユーザーあたり月額18,000円のEnterprise Edition、営業50名で年間1,080万円。HubSpotのSales Hub Professionalでも1ユーザー月額6,000円、50名なら年間360万円。

これだけの投資をしながら、「結局Excelに戻った」「レポートは手作業で作っている」「営業は商談管理にしか使っていない」という企業は珍しくない。ある調査では、CRM導入企業の約40%が「十分に活用できていない」と回答している。導入から1年以内にツールが形骸化するケースも多く、投資対効果を疑問視する声は少なくない。

なぜこうなるのか。ツールが悪いのか。営業のITリテラシーが低いのか。

どちらでもない。問題は「間」にある。

失敗パターン1: 機能追加病

SalesforceもHubSpotも、できることが多すぎる。ワークフロー、スコアリング、シーケンス、レポート、ダッシュボード、カスタムオブジェクト。導入を担当したSIerやコンサルが「こんなこともできるよ」と次々に機能を有効化する。

半年後、誰も全体像を把握できなくなる。

あるSaaS企業では、Salesforceに120個のカスタムフィールドと47個のワークフロールールが設定されていた。退職した前任のSalesforce管理者が作ったもので、どのルールがなぜ存在するのか誰もわからない。フィールドを1つ削除するとワークフローが壊れるかもしれないから、誰も触れない。

機能追加は技術的負債の蓄積だ。CRM/SFAでも、ソフトウェア開発と同じことが起きている。

失敗パターン2: 現場不在の設計

CRMの初期設計を誰が行ったか。多くの企業で、それは情報システム部門か外部のコンサルタントだ。彼らはツールの機能には詳しいが、営業の日常業務を知らない。

「商談のステージ定義を教えてください」と営業マネージャーに聞く。マネージャーは「初回接触、ヒアリング、提案、交渉、受注」と答える。しかし現場の営業に聞くと「初回接触とヒアリングの境目がわからない」「提案前にPoC（検証）が入ることが多い」「交渉と言っても社内稟議待ちと価格交渉は全く別のフェーズだ」と言う。

マネージャーの頭の中の理想プロセスと、現場の実態プロセスは違う。現場の実態に合わない設計をしたツールは、使われなくなる。

失敗パターン3: データ統合の欠如

HubSpotにマーケティングデータがある。Salesforceに商談データがある。カスタマーサクセスのデータはスプレッドシートにある。請求データは会計ソフトにある。

「リードから受注までの全体ファネルを可視化したい」。経営層はそう言うが、データが4つのシステムに分散していて、統合する仕組みがない。結局、月次会議のたびに誰かがExcelで手作業で突合している。

CRM/SFAは単体で完結するツールではない。マーケティング、セールス、カスタマーサクセス、ファイナンスのデータが一気通貫でつながって初めて価値を発揮する。その統合設計を誰もやっていないから、「使いこなせない」のだ。

ツールの問題ではなく「翻訳者」の不在

3つの失敗パターンに共通する本質は何か。それは「営業プロセスとツール設定の間を翻訳する人間がいない」ということだ。

情報システム部門はツールの機能を知っているが、営業プロセスを理解していない。営業マネージャーは営業プロセスを知っているが、ツールの設計思想を理解していない。外部コンサルはベストプラクティスを知っているが、自社固有の業務フローを理解していない。

必要なのは、以下の3つを同時に理解している人間だ。

1. 営業プロセスの実態 — 現場の営業がどのように動いているか、何に時間を使っているか、何がボトルネックになっているか
2. ツールの設計思想と技術的制約 — Salesforceのオブジェクト構造、HubSpotのデータモデル、APIの仕様と限界
3. データ基盤の全体設計 — どのシステムのどのデータをどう統合し、どの指標を算出し、誰がどのレポートで意思決定するか

この「翻訳者」の役割こそが、GTMエンジニアだ。

GTMエンジニアが果たす「橋渡し」の具体

GTMエンジニアがCRM/SFA活用プロジェクトに入ると、何が変わるのか。

やること1: 営業プロセスの可視化から始める

ツールの設定画面を開く前に、営業同行する。商談録画を見る。営業のカレンダーを分析する。「実際に何が起きているか」を把握してから、ツール設計に入る。

やること2: 最小構成で始めて段階的に拡張する

初期設定は必要最低限の項目とワークフローだけ。2週間使ってもらい、フィードバックを回収し、改善する。大規模な初期構築ではなく、アジャイルな反復改善を行う。

やること3: データフローの全体設計を描く

CRM単体ではなく、リードジェネレーションからカスタマーサクセスまでのデータフローを設計する。どのシステムが「正」のデータを持ち、どの方向にデータが流れ、どこで集計するか。この全体図がないまま個別ツールを設定しても、データのサイロ化は解消しない。

やること4: ダッシュボードを先に設計する

「どんなレポートが欲しいか」ではなく「どんな意思決定をしたいか」から聞く。週次の営業会議で見たい数字は何か。マネージャーが毎朝チェックしたい指標は何か。意思決定の場面から逆算して、必要なデータとレポートを設計する。

成功企業のアプローチに学ぶ

CRM/SFAの活用に成功している企業には共通点がある。

共通点1: ツール導入の前に営業プロセスの合意がある。 「うちの営業プロセスはこうだ」という共通認識が、マネージャーと現場の間で一致している。ツールはそのプロセスを支援する道具として位置づけられている。

共通点2: 管理者が営業経験を持っている。 Salesforce管理者やHubSpot管理者が営業出身、もしくは営業と密に連携している。「これは現場で使えるか」という判断基準を持っている。

共通点3: 四半期に一度、設定を棚卸ししている。 使われていないフィールド、形骸化したワークフロー、意味をなさなくなったレポートを定期的に削除している。ツールの設定も、コードベースと同じように保守している。

CRM/SFAは「設定するもの」ではなく「設計するもの」

HubSpotもSalesforceも、優れたツールだ。問題はツールにはない。

問題は、営業プロセスの理解なき設定、全体設計なきデータ統合、保守なき機能追加にある。CRM/SFAは「設定するもの」ではなく「設計するもの」だ。

そして、その設計を担えるのは、営業プロセスとテクノロジーの両方を理解した人間だ。ツールベンダーでも、SIerでも、営業コンサルでもない。営業の現場を知り、データ基盤を設計し、ツール間の統合を実装できる人間。

あなたの会社のCRM/SFAが「使いこなせない」なら、ツールを変える前に、「誰が設計しているか」を問い直してみてほしい。HubSpotとSalesforceの選び方でツール比較の詳細を、CRMデータ設計の教科書でデータ設計の実践方法を確認してほしい。また、GTMエンジニアとはではこの「翻訳者」の役割を体系的に解説している。

HubSpotやSalesforceを使いこなせない本当の理由は何ですか？

ツール自体の問題ではなく、営業プロセスとツール設定の間を翻訳できる人材がいないことが本質的な原因です。情シスはツール機能に詳しいが営業を知らず、営業マネージャーは業務を知っているがツールの設計思想を理解していない。この『間』を埋めるGTMエンジニアの役割が必要です。

CRM導入で失敗する典型的なパターンは何ですか？

3つの典型パターンがあります。SIerやコンサルが次々に機能を追加して全体像が把握不能になる『機能追加病』、現場の実態と乖離した設計をする『現場不在の設計』、複数システムのデータが分断されたままの『データ統合の欠如』です。