カスタムCRMをゼロから構築するよう依頼されたことはありますか？その時、「これは不可能だ」と思いますよね？私は2年前、わずか14週間でCRMの準備が必要だったクライアントの案件でそう思いました。典型的なタイムラインではありません。しかし、ここが重要なポイントです。私たちの5段階プレイブックを使えば、単に実行可能なだけでなく、驚くほどスムーズに進みました。Stack OverflowとPostmanは毎日のお供でした。そして、その過程で思った以上のレッスンを学びました。
フェーズ1：ディスカバリーとスコーピング（第1週～第2週）
CRMプロジェクトのほとんどは、コードを1行書く前に失敗します。本当にそうです。その失敗は会議室で起こります。通常はホワイトボードの周りで、誰もが曖昧な要件に頷き、誰も不快な質問をしません。
特定のプロジェクト（バーミンガムの中規模ロジスティクス会社、スタッフ約80人）では、最初の2週間をほぼ聞くだけに費やしました。ワークショップ、録画されたZoomコール、ステークホルダーがCRMに処理させたいあらゆるワークフローを記入できる共有Notionドキュメント。そのドキュメントは47ページまで膨らみました。その多くは矛盾していました。これは実は問題ありません。ディスカバリードキュメント内の矛盾は無料ですが、11週目に発見された矛盾は1スプリントとクライアント関係を失います。
実際にマッピングしているもの
ディスカバリーの目標は、すべての機能を捉えることではありません。データ関係とユーザーロールをマッピングすることです。それらが下流のあらゆるアーキテクチャ上の決定を形作ります。このステージではWhimsicalをフロー図に使用します。迅速で、共有可能で、クライアントはアカウントが不要なままコメントできます。
2週目の終わりには、4つの成果物をロックする必要があります。
- 優先度付けされた機能リスト。MVPと発売後のバケットに分割されたもの
- エンティティ関係の概要（まだ完全なスキーマではなく、名詞だけ：contacts、deals、pipelines、tasks）
- ユーザーロール定義。権限レベルは平文の英語で記述される
- サインオフされたタイムライン。曖昧なフェーズではなく、名前の付いたマイルストーン
その最後のものは交渉の余地がありません。「Phase 2 complete」は何も意味しません。「Contact importと役割ベースのアクセスが28日目までにステージングに本番化」は意味があります。
---
Phase 2：アーキテクチャとテックスタック決定（Week 3）
1週間。このフェーズにはこれ以上与えません。チームがアーキテクチャ議論に1か月間消えて何も出荷しないのを見てきたからです。
このプロジェクトのスタックは、バックエンドに Node.js と Express、データベースに PostgreSQL、フロントエンドに React を使用し、全体を DigitalOcean のマネージド Kubernetes にデプロイしました。ORM として Prisma を選んだのは、スキーマが急速に進化することが予想されており、Prisma のマイグレーションワークフローがそのために本当に優れているためです。
正直なところ、スタック自体はみんなが思うほど重要ではありません。もっと重要なのは：
- このプロジェクトのすべての開発者が、急な学習曲線なしでこのスタックを理解できるか？
- アーキテクチャは、Phase 1 でマッピングした権限モデルをサポートしているか？
- 週 10 に新しいエンティティタイプ（たとえば「supplier」）を追加できるか、認証レイヤーを書き直さずに？
3 番目のポイントは私が以前痛い目を見ています。2021 年、Seahawk は SaaS プロジェクトで週 9 にマルチテナンシーを無理やり追加しました。1 日で済むはずだったものをリトロフィットするのに 4 日かかりました。二度としません。
認証については、よほどの理由がない限り Auth0 をデフォルトにしています。パスワードリセット、MFA、ソーシャルログインといったエッジケースを処理してくれるので、ジュニア開発者を悩ませる問題を避けられます。
---
Phase 3：コアビルドスプリント（週 4～9）
6 週間。ここがエンジンルームです。そしてスコーピングが堅実なら、このフェーズは実際にはプロジェクト全体の中で最も直進的な部分です。
これを3週間の短いスプリント2つに分けて、中間地点で厳密な内部レビューを実施しました。
スプリントA：データレイヤーとAPI（4～6週目）
APIコントラクトが合意されるまで、フロントエンドには何も手をつけません。絶対です。コントローラーを書く前にPostmanですべてのエンドポイントをドキュメント化します。退屈に聞こえるかもしれませんが、後で「あ、このエンドポイントって何を返すんだ？」という会話が2週間分減ります。
データベーススキーマはここで最初の本格的な見直しを受けます。CRMの場合、過小評価されやすいテーブルはアクティビティログテーブルとカスタムフィールドテーブルです。すべてのクライアントがカスタムフィールドを望みます。柔軟なcustom_field_definitionsテーブルを初日からきちんと構築するのは約4時間の仕事です。11週目に即興で作るのは悪夢です。
スプリントB：フロントエンドとワークフロー（7～9週目）
ReactとTanStack Queryをサーバー状態管理に使用しました。2022年に小規模プロジェクトで素のuseEffectとローカル状態でやってみました。もう二度とそんなことはしません。TanStack Queryはキャッシング、バックグラウンドリフェッチ、楽観的更新を処理する方法で、CRMインターフェースを無理なく快適に感じさせます。
UIコンポーネントレイヤーについて、このプロジェクトではshadcn/uiを使いました。従来の意味でのコンポーネントライブラリではなく、コードを所有しているため、ライブラリと戦わずに実際にカスタマイズできます。パイプラインビュー、連絡先テーブル、タスクボードがあるCRMの場合、その柔軟性は重要です。
このスプリントで一貫して落ちるもの：空の状態です。データがないCRMは、ゼロ状態のスクリーンを設計していなければ壊れているように見えます。早めに構築してください。クライアントは空のデータベースで関係者にデモを行い、最初の印象は残ります。
---
フェーズ4：統合とデータ移行（10～11週目）
ここはほとんどのエージェンシーが見積もりを低く出し、計画が甘くなるところだ。毎回見てきた。
バーミンガムのロジスティクスクライアントは、既存のXero会計システムと、移行予定の古いSalesforceインスタンスとの統合が必要だった。2週間は短く見えた。実際そうだったが、Phase 3の段階で統合ポイントをスタブ化していたから対応できた。
Salesforce移行に関しては、Bulk API 2.0を使ってデータを抽出し、Node スクリプトで彼らのフィールド構造を私たちのものにマッピングした。スクリプトの作成に1日、イテレーションに3日かかった。Salesforceのデータはクライアントが信じているほどきれいなことはまずないからだ。データクリーニングの予算を確保すること。常に。
統合が「完了」と言う前に確認することがいくつかある：
- エラーハンドリング：サードパーティのAPIが落ちたときはどうなるか？
- Webhookのべき等性：同じイベントを2回安全に処理できるか、レコードが重複しないか？
- レート制限：現実的な負荷の下でそれに収まっているか？
Xeroの開発者ドキュメントは、実のところまともだ。OAuth 2.0フローはよくドキュメント化されているし、サンドボックス環境も信頼できる。
---
Phase 5：QA、堅牢化、ハンドオーバー（12～14週目）
QAに3週間というのは、実際に進めるまでは余裕があるように聞こえる。
12週目は構造化テストだ。ClickUpボードをクライアントに渡して、すべてのテストケースをタスクとして記載し、クライアントがテストして、マークして、何か壊れたらLoomを添付する。これで実際のユーザーが実際のフローをクリックするようになり、開発者が実行するテストでは見落とすものが必ず見つかる。「メモ」フィールドに4,000文字を貼り付けようとする人もいれば、スマートクォート付きのCSVをインポートする人もいる。こういったことを今のうちに見つけたいんだ。
13週目はフィックススプリントだ。新機能はなし。バグ修正とパフォーマンス改善のみ。主要ページすべてに対してLighthouseを実行する。APIに対してk6ロードテストも実行する。クライアントが要求したわけではないが、13週目で50同時ユーザー下の遅いクエリを見つけるほうが、本番稼働後に見つけるより遥かにいい。
14週目は引き継ぎと本番稼働準備だ。
私が作成する引き継ぎドキュメントは以下をカバーしている：
- インフラストラクチャ概要（何がどこで動いているのか、スケール方法）
- データベースのバックアップと復元手順、テスト済みで検証済み
- コードに触れずに新しいユーザーロールを追加する方法
- 既知の制限事項と見送ったバックログアイテム
最後のものが重要だ。何がカットされたのか正直に伝えよう。クライアントはそれを尊重するし、次のフェーズをスッキリと立ち上げられるようになり、関係に重くのしかかる言わないでおく借金が残らない。
ゴーライブに関する最後のポイント
段階的に展開する。92日目に10人のユーザーを対象にソフトローンチし、Datadogを使って48時間ログを監視してから、80人のチーム全体に公開した。その48時間のウィンドウで、テスト時には出現していなかったパイプラインステージ遷移の2つのエッジケースを捕捉できた。壊滅的なものではなかったが、もしフルスケールで進めていたら初日に15件のサポートチケットが発生していただろう類の問題だ。
ゴーライブは終わりではない。実際のユーザー行動データが流入し始まるきっかけに過ぎない。
---
FAQ
このようなカスタムCRMは一般的にいくら程度かかるのか？
正直なところ、大きく異なるが、このレベルでスコープされた14週間のプロジェクトで、小規模チーム（バックエンド開発者2名、フロントエンド開発者1名、プロジェクトリード1名）の場合、統合とデータ移行の複雑さに応じて通常£60,000～£120,000の間で推移する。フルカスタムビルドで£30,000未満の見積もりを目にしたら、既存テンプレートから実際に構築されているものと単に設定されているものを厳しく詰問すること。
WordPressでカスタムCRMを構築できるか？
できるが、約500レコードまたは20同時ユーザーを超えるものであれば、私はやらない。WordPressのデータレイヤーはリレーショナルCRMワークロード向けに設計されていない。Seahawkでは小規模クライアント向けにWordPress上に連絡先管理層を構築したことはあるが、真剣なものであれば、リレーショナルデータベースを備えた適切なバックエンドが正しい選択肢だ。
CRMビルドでチームが犯す最大の誤りは何か？
パーミッションモデルの過度な単純化。みんなは機能に目を向けて、80人のユーザーを抱えるCRMが「誰がどの案件を見られるのか」という細かい答えを必要としていることを忘れてしまう。API ルートを1本も書く前にこれを決めておく必要があるのに、10週目にロールベースアクセス制御を後付けするのは、実際に一度やるまでは説明しがたいほどに大変だ。
その正確なテックスタックを毎回使うのか？
いや。説明したスタックはこのプロジェクトのチームと制約に合っていただけだ。LaravelとVueでCRMを構築したこともあるし、DjangoとReactでも、Next.jsのフルスタック構成でも船出させたことがある。最後のそれは当初は懐疑的だったが、実際にはうまくいった。アーキテクチャの原則は変わらない。ツールは柔軟に選ぶ。
結局のところ、このカスタムCRMプロジェクトは単なるチャレンジではなく、啓示だった。その厳しい14週間の期限？それが私たちにイノベーション、適応、そして納品を強制した。結局のところ、制約は創造性の触媒になり得るのだ。締め切りが自分たちの職人技についてこんなにも多くを教えてくれるなんて、誰が予想しただろうか。Seahawk Mediaを共同創業した理由を思い出させてくれるのは、こういったプロジェクトなのだ。