CRM開発を発注する前に決めること—要件・権限・履歴・分析・保守

「顧客情報を一元化したい」だけでは検収できない

営業は案件を更新し、マーケティングはメール許諾を抽出し、管理者は月末の商談数を見る。三者が同じCRMを使う場面でも、見える顧客、編集できる項目、履歴の残し方、数字の締め時刻は違います。ここを「相談しながら」に残すと、見積範囲と完成条件が会社ごとに変わります。

ランサーズには2026年6月終了のCRM開発募集があり、顧客・対応履歴・営業活動・分析・権限、要件整理からリリース、可能なら保守までが挙げられていました。これは外注需要の具体例です。募集予算、提案数、募集結果をCRM開発の一般相場や成果の根拠には使いません。

発注書は6つの合意に分ける

IPAの非機能要求グレードは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティなど、画面機能以外の要求を利用者と開発者で確認する枠組みです。CRMでも「顧客を登録できる」に加え、月末集中時の性能、障害時の復旧、退職者の権限停止、データ移行を要件にします。

権限・履歴・分析は後付けにしない

• 権限：役職名ではなく、対象データ×操作（閲覧、登録、編集、承認、出力、削除）で表にする
• 履歴：顧客名の変更だけでなく、担当変更、ステータス、金額、削除、CSV出力を誰がいつ行ったか残す
• 分析：「商談数」を新規作成数、指定期間に一度でも商談中だった数、月末時点の数のどれにするか決める

項目名と入力ルールの整理はCRMデータ定義の記事、見積内訳の比較はアプリ開発費用の記事も参照してください。

受入テストは見積依頼と同時に渡す

1. 営業担当が自分の顧客を登録し、重複候補が表示される
2. 別部署の非担当者は機微項目を閲覧・出力できない
3. 担当変更後も変更前後、変更者、日時が履歴に残る
4. 同じテストデータから画面とCSVで同じ集計値になる
5. 移行失敗時に対象を特定し、再実行して重複しない
6. 外部連携停止時に通知され、手動代替と復旧手順が動く

IPAの情報システム・モデル取引・契約書は、多段階契約、役割分担、変更管理、検収、保守運用などの論点を整理しています。契約書をそのまま転用するのではなく、自社案件で誰が要件を決め、成果物を確認し、変更を承認するかの確認材料にします。

責任分界と保守終了時の返却まで書く

• 発注者：業務判断、データの正解、テスト担当、承認者を用意する
• 受注者：設計・実装、技術テスト、既知の制約、ログ、復旧手順を提示する
• 共同：仕様変更、移行判定、リリース、障害連絡、追加見積の境界を合意する
• 終了時：データ形式、ソース、設計書、アカウント、鍵、操作履歴の返却・削除を決める

来週の一歩：実在する顧客1件を受入シナリオにする

1. 個人情報を伏せた顧客1件と、受付から完了までの履歴を用意する
2. 営業、管理者、他部署がそれぞれできる操作を表にする
3. 変更履歴と月次指標の期待値を手計算する
4. 正常、重複、権限違反、連携失敗の4シナリオを書く
5. 同じ資料を候補各社へ渡し、範囲外と責任者を明記した見積を依頼する

before / afterで測る

• 顧客検索、履歴確認、月次集計にかかる時間
• 重複、必須項目の空欄、権限違反、手修正の件数
• 受入テストの合格率、差し戻し件数、解決日数
• 障害検知から復旧までの時間と保守範囲外の件数

よくある質問