CRMは内製すべきか——HubSpotから自社CRMへ移行した判断軸

この回の役割｜業務境界を決める CRMの機能数ではなく、顧客情報、判断理由、引き継ぎ、改善が一つの流れとして残るかを判断します。

CRMを見直すと、議論はすぐに「SaaSを買うか、自社で作るか」へ向かいます。

しかし、製品比較より先に決めるべきことがあります。自社では、どこからどこまでを一つの業務として扱うのかという境界です。

AMELAはHubSpotをはじめ、複数の営業向けSaaSを活用してきました。標準的な営業活動を早く始めるうえで、優れた製品です。それでも自社CRMへ移行したのは、製品の優劣ではなく、AMELAの営業循環を複数の境界で分断したくなかったからでした。

情報はあっても、判断の流れが残らなかった

AMELAが一続きにしたかったのは、商談台帳だけではありません。

• Web、コンテンツ、イベントから生まれる関心の兆候
• 企業調査、接触、商談、見込み、契約
• 営業開拓から顧客担当への引き継ぎ
• 契約後の活動と顧客の反応
• 結果を次の施策や提案へ戻す改善

個々のSaaSは、それぞれの領域で便利でした。ところがシステムをまたぐたびに、企業IDの対応、データの複製、担当者変更、再入力、手作業での確認が残ります。

情報は存在していても、「なぜこの顧客に、今この対応が必要なのか」を、履歴と責任者を含めて説明できませんでした。

最初から全機能を作る計画ではなかった

CRMの初期設計には、HubSpotとの双方向同期も残っています。最初から外部製品をすべて捨て、全機能を作り直す方針ではありませんでした。

連携で解ける部分は連携する。その一方で、顧客の兆候、担当者の判断、引き継ぎ、結果からの改善など、AMELA固有の営業循環に関わる情報は自社で持つ。実運用を通じて、その境界を見極めていきました。

内製する目的は、機能を所有することではありません。自社固有の判断と学びを、システムの境界で失わないことです。

この事例の根拠と読み方

• 根拠：CRMの初期設計、製品計画、実装履歴、営業開拓から顧客担当までの業務設計
• 対象期間：2026年5月以降のCRM形成過程
• 確認できること：初期案では外部連携も検討し、実運用から自社が持つ境界を広げたこと
• 確認できないこと：HubSpotと自社CRMの一般的な性能比較、移行による売上や生産性の向上
• 公開上の扱い：本記事はHubSpotを否定するものではなく、AMELA固有の適合性に関する判断事例です

実装履歴は、設計と機能が変化した順序を示します。全社員への定着時期や、外部SaaSの契約終了日までを証明するものではありません。

読者が使える実践ツール

機能一覧の前に、候補となる業務領域を次の5軸で採点します。各項目を「低・中・高」で評価してください。

判断の目安は次のとおりです。

• 購入：業務が標準的で、外部製品の運用方法を受け入れられる
• 連携：外部機能を使いながら、ID、履歴、結果を自社の基準データへ戻せる
• 内製：独自の判断、引き継ぎ、改善が競争力であり、境界で失う費用が大きい

AMELAの例では、メールや予定表などの汎用機能は連携対象とし、顧客の兆候から営業、引き継ぎ、結果までの中心は内製対象としました。

内製を選ぶと、新しいリスクが生まれる

自社で境界を持つと決めた瞬間、「理想のCRMを一度に作る」という別のリスクが生まれます。要件が広がり、使い始める前に時間と費用が膨らむからです。

AMELAが最初に作ったのは、大きな統合基盤ではありませんでした。商談、進捗、週次状況、見込みなど、営業会議で同じ問いへ同じ答えを出すための小さな共通画面です。

その後の開発順を決めたのは、競合製品の機能一覧ではありません。使い始めた後に見つかった「まだ判断できないこと」でした。

次回予告：自社CRM開発——小さく始め、実運用から育てる4ステップ（近日公開）

まとめ

CRMの購入と内製に、すべての企業へ当てはまる正解はありません。

見るべきなのは機能数ではなく、自社の価値の流れをどこまで一つの業務文脈として守る必要があるかです。汎用部分は購入・連携し、独自の判断と改善に関わる境界だけを自社で持つ。この切り分けが、過剰な内製も過剰なSaaS依存も避ける出発点になります。