自社CRM開発——小さく始め、実運用から育てる4ステップ

この回の役割｜開発順を決める 完成形を先に作らず、止まった判断から最小機能と検証方法を決めます。

自社CRMを作るなら、どこまで完成させてから使い始めるべきでしょうか。

AMELAの実装履歴が示した答えは、完成を待たないことでした。最初の意思決定に必要な範囲から使い、次に作るものは、実運用で止まった判断から決める。これにより、機能一覧ではなく、業務上の不足が開発順を作りました。

最初に必要だったのは、同じ数字を見ること

2026年5月21日の最初の実装には、商談、進捗、週次状況、見込み、KPI、理想顧客像など、営業運営の基礎がありました。

どの会社と話しているか。商談はどの段階か。誰が担当しているか。いつ、どれだけを見込むか。

高度なAIや自動化より先に、会議で同じ問いへ同じ答えを出すための土台を作りました。「小さなCRM」ではなく、最初の意思決定に合わせて境界を絞ったCRMです。

二日後、商談より前の顧客行動が必要になった

二日後には、マーケティング、イベント、流入元別の効果測定が加わりました。

商談が生まれた後だけを管理しても、「なぜその顧客が現れたか」が分かりません。Web、コンテンツ、イベントという入口から営業までをつながなければ、次の施策へ結果を戻せないと分かったためです。

その後、受信メール、企業情報の補完、理想顧客像、社内連絡、見込み顧客の流れが加わりました。さらに、SNS上の接点やWebアクセス元から企業を推定する仕組みも入りました。

CRMは、担当者が後から記録する台帳から、仕事が起きた場所で兆候を受け取る業務基盤へ変わり始めました。

最初の自動化は、最初の誤りも生んだ

Webアクセス元から企業を推定する機能は、通信事業者や接続事業者の通信を企業の関心として扱う誤検知を生みました。翌日の修正で、対象外とするルールが追加されています。

兆候を増やせば、営業判断が良くなるとは限りません。誤った兆候は、もっともらしい優先順位を作ります。自動化には、入力作業を減らす力と、誤りを速く増幅する力の両方があります。

この時、開発の問いは「次にどの機能を作るか」から、「どの判断が、どの情報不足で止まったか」へ変わりました。

この事例の根拠と読み方

• 根拠：CRMリポジトリの実装履歴、初期計画、業務設計資料
• 対象期間：2026年5月21日から同月末を中心とした初期形成期
• 確認できること：営業の基礎機能から、顧客の兆候収集と誤検知対策へ広がった実装順
• 確認できないこと：各機能の全社利用開始日、利用率、売上や成約率への効果
• 公開上の扱い：日付は実装履歴であり、組織への展開時期や成果発生日ではありません

実装順からは、何が作られたかを確認できます。なぜ必要だったかは設計資料と変更内容からの解釈を含むため、事業成果とは分けて読んでください。

読者が使える実践ツール

開発候補を、次の4項目を持つ一枚のカードにします。抽象的な質問だけで終わらせず、確認方法まで書きます。

運用手順は4ステップです。

1. 会議、入力、問い合わせ、手戻りから「止まった判断」を一つ選ぶ
2. 不足を、単なるデータ不足ではなく意味・責任・履歴まで分ける
3. 理想の基盤ではなく、判断を再開できる最小変更を作る
4. 正しさと副作用を確認し、次のカードを作る

競合製品の機能一覧は参考資料にはなりますが、開発優先順位の基準にはしません。

データが増えると、次は意味がずれる

小さく始めると、実際の問題を早く発見できます。一方で、情報源が増えるほど、同じ「売上」でも、進行中商談の期待値、見込み、確定売上を別の意味で使う問題が現れます。

市場や担当組織が増えると、同じ商談段階でも、責任と次の行動が異なります。次に必要だったのは、情報を増やすことではなく、AIと人が同じ意味で使えるようにすることでした。

次回予告：AI CRMの改善——人の修正を次の判断へ戻す仕組み（近日公開）

まとめ

自社CRMは、完成形を作ってから使う必要はありません。最初の意思決定に必要な範囲から始め、現場で止まった判断を、情報不足、最小機能、検証方法へ変えることで育てられます。

重要なのは、速く機能を増やすことではありません。追加した機能が判断を改善したか、誤りを増やしていないかを確かめながら、次の開発順を決めることです。