「CRM入れるなら今のツール全部捨てて」と言われて困っている人へ

「CRMを入れるなら、今のRedmineは捨てないとダメですか？」。クライアントとの打ち合わせで、この質問は何度も出てくる。答えはほぼ毎回「いや、捨てなくていい」だ。実際に支援先で検討した、RedmineとHubSpotの併用設計パターンをそのまま共有する。

なぜ「全移行」を疑うべきなのか

CRMベンダーやSIerは「全データを移行して一元管理しましょう」と提案してくる。理想論としては正しい。だが現実には、以下の3つの壁がある。

壁1：現場がすでに最適化済み

開発チームがRedmineを長年使っていて、チケット管理・ワークフロー・カスタムフィールドが業務にフィットしている。これをHubSpotに移すと、同等の機能を再構築するのに数ヶ月かかる。そしてRedmineほどの柔軟性は出ない。

壁2：移行メリットが薄い

実際に検討したOption 1（Redmine→HubSpotへの全移行）の結論は「移行メリットがほぼない」だった。Redmineで十分に回っている案件管理を、わざわざHubSpotに載せ替える理由がない。

壁3：移行コストが見えにくい

データ移行だけでなく、現場のトレーニング、ワークフローの再設計、過去データの整合性チェック。見積もりに出てこない「隠れコスト」が多い。30人規模の会社で、全移行プロジェクトが半年以上かかるのはザラにある。

実例：Redmine+HubSpot併用の設計パターン

打ち合わせで出した結論はこうだ。「Redmineで案件管理を維持し、HubSpotはメルマガ・営業管理に限定する」。それぞれのツールが得意な領域に集中させる。

役割分担の設計

領域	担当ツール	理由
案件管理（チケット・進捗）	Redmine	開発ベンダーが日常的に使用。カスタマイズ性が高く、現場にフィット済み
営業パイプライン管理	HubSpot	商談フェーズの可視化、予実管理、営業レポートはHubSpotが圧倒的に強い
メールマーケティング	HubSpot	メルマガ配信・開封率トラッキング・リードスコアリングはHubSpotの得意領域
顧客マスタ	HubSpot（正）	顧客情報の「正」をHubSpotに置き、Redmineにはプロジェクト単位で同期

ポイントは「顧客マスタの正をどちらに置くか」を最初に決めること。ここが曖昧だと、どちらのデータが正しいかわからなくなる。今回はHubSpotを「正」にして、Redmineへは必要なフィールドだけ同期する設計にした。

API連携：ほぼゼロコストで双方向同期を組む

「2つのツールを使うと、データの二重入力が発生するのでは？」。これが併用設計で最も多い懸念だ。結論から言うと、APIを使えばほぼゼロコストでデータ連携が組める。

連携の具体的な設計

HubSpot → Redmine（案件が受注したとき）

HubSpotの商談が「受注」に変わったら、RedmineにWebhookでチケットを自動作成。顧客名・案件概要・納期をRedmineに渡す。開発チームはRedmineだけ見ればいい。

Redmine → HubSpot（進捗が更新されたとき）

Redmineのチケットステータスが変わったら、HubSpotの対応する取引のカスタムプロパティを更新。営業は「納品進捗」をHubSpot上で確認できる。顧客から「あの件どうなりましたか？」と聞かれても即答できる。

同期頻度

リアルタイム（Webhook）またはバッチ（15分間隔のcron）。案件の状況共有なら15分バッチで十分。Webhookはリアルタイム性が必要なケース（受注通知など）に限定する。

技術的にはHubSpot APIとRedmine REST APIの両方が十分に整備されているので、中間にGoogle Apps ScriptやMake（旧Integromat）を挟むだけで連携が組める。自社でPythonスクリプトを書けるなら、外部サービスすら不要だ。

コスト試算：10人で年間約180万円

実際にこの併用パターンのコストを試算した結果が以下の通り。

項目	月額	年額
HubSpot Starter（10シート）	約12万円	約144万円
Redmine（自社サーバー or クラウド）	約1〜3万円	約12〜36万円
API連携ツール（Make等）	0〜2万円	0〜24万円
合計	約13〜17万円	約156〜204万円

打ち合わせでの試算は「10人で年間約180万円」。全移行した場合（HubSpot Professional以上＋移行コンサル費）と比較すると、初年度で200〜400万円は安くなる。しかも現場の混乱が最小限で済む。

併用設計で失敗しないための3つのルール

ルール1：「正」のデータソースを1つに決める

顧客情報の「正」はHubSpot、案件チケットの「正」はRedmine。同じデータが2箇所にあるとき、どちらが正しいかを明確にしておく。迷ったら「最初にデータが入力される場所」を「正」にする。

ルール2：連携するフィールドを最小限にする

「全フィールドを同期しよう」とすると、連携の複雑さが爆発する。最初は5〜10フィールドに絞る。顧客名、案件名、ステータス、金額、担当者。これだけあれば、営業と開発の情報共有は十分に回る。

ルール3：エラー通知を仕込む

API連携は必ずどこかで失敗する。認証トークンの期限切れ、APIレートリミット、データ型の不整合。Slackにエラー通知を飛ばす仕組みを最初から組んでおく。「気づいたら3日間データが同期されていなかった」を防ぐ。

この設計パターンが合う会社・合わない会社

合う会社	合わない会社
既存ツール（Redmine, kintone等）が現場に定着している	既存ツールが形骸化していて、誰も使っていない
営業と開発/バックオフィスで使うツールが違う	全社で同じツールを使いたい（統一志向が強い）
移行コスト・現場の混乱を最小化したい	予算が潤沢で、半年かけた全移行プロジェクトが許容できる
社内にAPI連携を組めるエンジニアがいる（または外注できる）	技術リソースがゼロで、ノーコードツールの運用もできない

まとめ：「全部乗り換え」の前に、併用設計を検討する

CRM導入の相談を受けると、ほぼ全員が「今のツールを全部捨ててCRMに統一するんですよね？」と思い込んでいる。だが実際に検討すると、併用のほうが合理的なケースは多い。特にRedmineやkintoneのように、特定業務に深くフィットしているツールがある場合、それを無理にCRMに置き換える意味は薄い。

「営業・マーケはHubSpot、案件管理は既存ツール、APIで繋ぐ」。このシンプルな設計が、現場の混乱を抑えつつ、CRMの恩恵を最大化する最も現実的な方法だ。