まるで昨日のことのように覚えています。HubSpotがクライアントのニーズに対応できなくなった瞬間です。それは2023年のこと、Shoreditchの活気あるテックスタートアップでした。私たちはHubSpotを使ったプロジェクトに深く取り組んでいましたが、クライアント独自のセールスファネルが丸い穴に四角いペグを無理やり入れようとしているような状況だったことに気づきました。ツールは柔軟性が足りませんでした。彼らには何か独自のもの、自分たちとともに進化するものが必要でした。そこで、私はカスタムCRMの開発に全力で取り組みました。Node.jsからAirtableまで、すべてのツールを使用し、それぞれのツールがぴったり合うように調整しました。目からうろこが落ちる経験でした。
HubSpotが限界に達した実際の兆候
私が話すほとんどのエージェンシーオーナーは、問題がHubSpotにあることに気づいていません。問題はプロセスか、チームか、データの品質管理だと思っています。ほとんどの場合、そうではありません。
私が注視する兆候は次の通りです：
- セールスチームが、HubSpotが「技術的には」対応しているけれど、実際にはできていないものを追跡するために第二のスプレッドシートを作成している
- HubSpotの階層に支払うのは、実際に使用している1つか2つの機能にアクセスするためだけだ
- 開発者がカスタムコード化されたワークフロー拡張を2つ以上書いている
- HubSpotのネイティブダッシュボードが必要なデータを結合できないため、レポート作成にはGoogle Sheetsへのエクスポートが必要だ
- ピーク時間帯にHubSpotの標準エンドポイントのAPIレート制限に達しているHubSpot's standard endpoints during peak usage hours
最後のポイントは過小評価されている。2024年中盤、B2Bロジスティクスのクライアントを担当していたが、彼らは1日40,000件以上の連絡先更新をサードパーティ統合経由で実行していた。HubSpotのAPI制限がキューイング遅延を引き起こし、自動化アウトリーチが同期から外れた。彼らはずっと運用チームのせいだと思い込んでいた。問題はプラットフォームにあったのだ。
自分自身に問いかけるべき素直な質問はこれだ：あなたのビジネスロジックをCRMに合わせて曲げているのか、それともCRMがあなたに合わせて曲がっているのか。前者なら、すでに後れを取り始めている。
数字が実際に合う時
カスタムCRMビルドは初期投資が高い。ごまかすつもりはない。スコープが明確で実績のあるチームであれば、複雑さ、統合、モバイルレイヤーを含めるかどうかによって、£25,000から£120,000の範囲になる。
しかしHubSpotのEnterpriseティアは月額£3,600以上だ。年間£43,200で、これはアドオン前、Ops Hub前、別途支払っているサードパーティコネクター前だ。3年で考えると、所有していなく、コアで修正できないプラットフォームに£130,000以上を費やしていることになる。
数字は多くの人が予想するより素早くシフトする。
コード一行目を書く前に、適切なアーキテクチャを選択する
これが最も高くつく失敗を目にする場所だ。アーキテクチャを決めずに構築を始めて、その後6ヶ月間リファクタリングに費やす人たちがいる。Seahawk は 2024年初頭に、クライアントがモノリシックな Laravel 設定で既に CRM の構築を開始していたフィンテック案件を抱えていた。我々が関与する前に、データ関係性についての仮定が3階層深くまで埋め込まれていた。最初の4週間は構築ではなく、それを解きほぐすのに費やした。
最初に重要となるアーキテクチャ上の決定は2つだ。
モノリス vs. サービス指向アーキテクチャ
ある規模未満の CRM 構築(例えば、並行する社内ユーザーが500人未満)では、構造化されたモノリスは今でも完全に問題ない。Rails、Laravel、Django だ。最高の意味で退屈している。素早く動くことができ、機能をシップしている最中にサービス間通信をデバッグするはめにはならない。
サービス指向アーキテクチャは、独立してスケールする必要がある、本当に異なるドメインを持つときに意味をなす。例えば CRM が、顧客向けポータルとリアルタイムデータ、独立した分析エンジン、モバイルアプリを駆動する場合だ。その時点で、関心事を分離することが報われる。
マイクロサービスが最新に聞こえるからといって、誰かに売り込まれてはいけない。£60k かけるべき構築が £25k のモノリスで十分な場合を見すぎている。
リレーショナル vs. ドキュメントストア
CRM データのほとんどは本質的にリレーショナルだ。連絡先は企業を持つ。企業は案件を持つ。案件は活動を持つ。PostgreSQL はこれを異常に良く処理し、JSON サポートは大幅に成熟して、ドキュメントストアの柔軟性を、リレーショナル整合性を放棄することなく得られるようになった。its JSON support has matured enormously to the point where you get the flexibility of a document store when you genuinely need it, without abandoning relational integrity.
MongoDB は、連絡先レコードがユーザーベース全体で構造が著しく一貫性を欠く場合に意味をなす。一部のビジネスではこれが実際のシナリオだ。ほとんどの場合、そうではない。
2026年の私のデフォルト：PostgreSQL、他に証明されるまでは常にPostgreSQL。
2026年に実際にお勧めするテックスタック
理論的な答えはここにはありません。これは今、私が実際に構築するものです。
- バックエンド：Node.js with Fastify または Python with FastAPI。具体的にはFastifyはCRMバックエンドでは過小評価されすぎています。Expressより高速で、スキーマ検証が組み込まれており、プラグインエコシステムは2022年以降かなり成熟しています。 Node.js with Fastify or Python with FastAPI. Fastify specifically is criminally underused for CRM backends. It's faster than Express, the schema validation is built in, and the plugin ecosystem has matured considerably since 2022.
- データベース：PostgreSQL 16、Node.jsの場合はPrismaをORM として、Pythonの場合はSQLAlchemy。すべてのためにSQL を手書きしないでください。6ヶ月後に自分自身に感謝するでしょう。 PostgreSQL 16, with Prisma as the ORM if you're in Node-land, or SQLAlchemy if Python. Don't hand-write SQL for everything. You'll thank yourself in six months.
- 認証：Auth0 または Clerk。2026年に認証を自分で構築することは、私が本当に理解できない選択肢です。Clerkは特にマルチテナント組織サポートが最初からあるものには、私の常用選択肢になっています。 Auth0 or Clerk. Building auth yourself in 2026 is a choice I genuinely don't understand. Clerk specifically has become my go-to for anything that needs multi-tenant organisation support out of the box.
- フロントエンド：Next.js 14+ with App Router。サーバーコンポーネントへのシフトは、本当に内部ツールがエンドユーザーにとってどれほど高速に感じるかを変えました。 Next.js 14+ with the App Router. The server components shift has genuinely changed how fast internal tools feel to end users.
- メール/通信レイヤー：トランザクショナルメールには Resend、必要に応じてSMSには Twilio。どちらも適切なAPIと妥当なレート制限を備えています。 Resend for transactional email, Twilio for SMS if needed. Both have proper APIs with sensible rate limits.
- バックグラウンドジョブ：Redis上の BullMQ。CRMは多くの非同期作業を行います：同期、スコアリング、リマインダー。信頼できるキューが必要です。 BullMQ on Redis. CRMs do a lot of async work: syncing, scoring, reminders. You need a reliable queue.
- 検索：フルテキストの連絡先/企業検索がコア機能の場合、Meilisearch を早期に追加してください。自己ホスト可能で、高速で、Elasticsearchを実行するよりもはるかに簡単です。 If full-text contact/company search is a core feature, add Meilisearch early. It's self-hostable, fast, and far easier to run than Elasticsearch.
これは、私が対処するカスタムCRMビルドの85%に対する完全なスタックです。残りの15%はモバイルやリアルタイム要件があり、React NativeやWebSocketsが含まれます。
データ移行：誰もが過小評価するパート
正直に言うと、データ移行はプロジェクトが静かに脱線するところです。ビルドではなく、移行です。
HubSpotから移行する場合、エクスポートは思ったより複雑になると覚悟してください。HubSpotのデータモデルは暗黙的なアソシエーションが多くあります。コンタクトと企業間のアソシエーションはエクスポートCSVでは常にクリーンではありません。カスタムプロパティは表示ラベルと一致しない内部フィールド名で出力されます。ディールステージは数値IDで参照され、手動でクロスリファレンスする必要があります。
中規模のHubSpotインスタンス（例：50,000コンタクト、10,000ディール）の場合、最小でも4週間の専任移行作業を予算化します。これには以下が含まれます：
- すべてのカスタムプロパティを監査およびマッピングする
- トランスフォーメーションスクリプトを作成する（Pythonはこれに優れており、特にpandasは複雑な中間ステップに最適です）
- カットオーバー前に少なくとも2週間並行システムを実行する
- ロールバックを計画する。常にロールバックを計画してください。
並行実行をスキップすると、後悔することになります。私のあるクライアントは金曜日の午後にハードカットオーバーを実行しました。月曜日までに3つのデータ整合性の問題が見つかり、解決に2週間かかりました。本番システムでのことです。そのような人にならないでください。
カスタムビルドで本当に重要な連携
CRMは独立して存在することはない。何かに接続する必要が常にある。統合に時間を費やす主な領域は以下の通りだ。
財務と請求
ほとんどのUKベースのクライアントにはQuickBooksかXeroを使う。どちらも堅牢なAPIを持っている。重要なのは真実の方向性だ。CRMが取引価値の源泉か、それとも会計システムか？どちらかを選べ。明確な権限のない双方向同期は、夜11時にデバッグするのが本当に苦しい競合につながる。
カレンダーとコミュニケーション
Google WorkspaceとMicrosoft 365は必須だ。GoogleのCalendar APIはよく文書化されており信頼できる。Microsoft Graph APIは強力だが習得曲線が急だ。予算は適切に配分せよ。Google's Calendar API is well-documented and reliable. The Microsoft Graph API is powerful but has a steeper learning curve. Budget accordingly.
マーケティングオートメーション
HubSpotの一部、特にマーケティング側を保持しつつ、営業CRMを置き換えたいというのがよくある要望だ。それは完全に有効なハイブリッドアプローチだ。HubSpot APIを使ってコンタクト更新と取引ステージの変更をマーケティングリストに戻す。データコントラクトが明確に定義されている場合はうまく機能する。
ビルド対バイ対ハイブリッド：判断を下す
これは常に聞かれる。普遍的な答えはないが、私が使うフレームワークはある。
購入する対象（HubSpot、Salesforce、Pipedrive）を選ぶべき場合：営業プロセスが比較的標準的で、CRM を使用するチームが 20 人未満であり、数ヶ月ではなく数週間で運用を開始したい場合です。 when: your sales process is relatively standard, you have fewer than 20 people using the CRM, and you want to be operational within weeks rather than months.
カスタムビルドを選ぶべき場合：真に独自のデータ関係またはワークフロー ロジックを持っている、社内の独自システムとの深い統合が必要である、または 36 ヶ月間のプラットフォーム コストがビルド見積もりを超えると計算した場合です。 when: you have genuinely unique data relationships or workflow logic, you need deep integration with proprietary internal systems, or you've calculated that platform costs over 36 months exceed your build estimate.
ハイブリッドの場合：HubSpot のようなプラットフォームに付属するマーケティング オートメーションとブランド統合が必要だが、コア CRM ロジックは自分たちが管理できる場所に置く必要がある場合です。これは人々が認めるより一般的です。2025 年に SaaS クライアント向けにこのモデルを運用しましたが、カスタム CRM がすべての取引ロジックと契約管理を処理し、HubSpot はマーケティング ハブのままでした。2 つの間のクリーンな API コントラクト。非常にうまく機能しました。 when: you need the marketing automation and brand-name integrations that come with a platform like HubSpot, but your core CRM logic needs to live somewhere you control. This is more common than people admit. We ran this model for a SaaS client in 2025 where the custom CRM handled all deal logic and contract management, but HubSpot remained the marketing hub. Clean API contract between the two. Worked beautifully.
最悪の結果は、HubSpot が行うことをまったく同じように複製するが、さらに悪い、カスタム CRM を 9 ヶ月かけて構築することです。それは起こります。通常、カスタムビルドの決定が分析的ではなく感情的に下された場合です。
よくある質問
カスタム CRM ビルドは実際にどのくらい時間がかかりますか？
現実的なタイムライン：基本的な連絡先管理、取引追跡、基本的なレポート機能を備えたリーン MVP には、2～3 人のチームでおよそ 10～14 週間かかります。複数の統合、カスタム レポート、モバイル レイヤーを備えたフル機能ビルドは 6～9 ヶ月に達します。複雑なものに対して 4 週間の見積もりを提示する人は、コーナーをカットするか、プロジェクトを適切にスコープしていません。
カスタム CRM をセルフホストしてコストを低く保つことはできますか？
はい、多くのクライアントにとって正しい決定です。Render や DigitalOcean マネージド データベース クラスターのような何かで適切に設定されたセットアップは、インフラストラクチャ コストを予測可能に保ちます。月額 £80 のホスティングで 10,000 人以上の連絡先にサービスを提供している CRM を見てきました。変動コストはサーバー料金ではなく、メンテナンスと更新です。Render or a DigitalOcean managed database cluster keeps your infrastructure costs predictable. I've seen CRMs serving 10,000+ contacts running comfortably on £80 per month in hosting. The variable cost is maintenance and updates, not the server bill.
カスタム CRM を構築するときにチームが犯す最大の失敗は何ですか？
未来の可能性を見据えた構築ではなく、現在の状況に合わせた構築をしているチームを数多く見てきました。AI駆動型のリード スコアリング、予測的なパイプライン予測、フル機能のモバイルアプリなどを設計している一方で、基本的な連絡先の重複排除さえもまだ完成していません。つまらないものから正しく始めるべきです。重複排除、データ検証、監査ログ、ユーザー権限。これらは地味で、絶対に必要不可欠なものです。それ以外はすべてオプションであり、これらが堅牢になるまでは不要です。
HubSpotから本当に移行するのは難しいですか？
ドキュメントの説明より難しく、Salesforceより簡単です。主な摩擦はカスタムプロパティ、ワークフロー ロジック、メール シーケンス履歴です。連絡先とディール データ自体はかなりきれいにエクスポートされます。ワークフロー ロジックで予期しない問題が発生する可能性があるため、対策を講じてください。HubSpot ワークフローには、他の場所に記載されていないビジネス ルールがエンコードされていることが多く、移行の途中になって初めて発見されます。
Shoreditch プロジェクトを振り返ると、明らかなことがあります。既成のソリューションが要件に合わない場合があります。カスタム CRM 開発は単なる最後の手段ではなく、標準を超えて進む準備ができているユーザーのための積極的な選択肢です。企業が成長するにつれて、ツールも進化する必要があります。適切な CRM はあなたの可能性を引き出すための鍵になりますが、あなたのために作られたように感じるべきです。時には、袖をまくり上げてゼロから始める必要があります。