顧客管理システムの要件定義は、業務フローの整理、入力項目の設計、連携・移行要件の明確化を順に進めることで、現場に定着するシステムにつながります。
RFP（提案依頼書）と要件定義書は、発注企業の視点で作ります。SaaSかスクラッチかの判断から、連携・移行、運用までを順に扱います。
▼全体ガイドの記事
・顧客管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SaaSとスクラッチを選び分ける要件整理
要件定義では、既製のSaaSを使うか、自社専用のスクラッチ（フルスクラッチ／カスタム）開発にするかを最初に選びます。ここが曖昧なままだと、提案を比べる軸が定まらず、選定が迷走します。
自社の業務が一般的な型に収まるか、独自性が強いかを整理します。そのうえで、予算・期間・拡張性の優先順位を決めます。この分岐を最初に固めておくと、後続の要件整理が一本道になります。
料金相場を踏まえたSaaS／スクラッチの判断軸
判断材料として、費用の相場を先に押さえておきます。SaaS型CRM／SFAは月額1,680円〜30,000円／ユーザー程度が相場です。
費用は、月額料金の積み上げと初期投資の総額を合わせ、数年スパンのTCO（総所有コスト）で比べます。
- Salesforce Sales Cloud：3,000円〜／ユーザー
- Zoho CRM：1,680円〜／ユーザー
- HubSpot CRM：無料から。有料Starterは月2,400円〜
- kintone：ライトコースは780円〜／ユーザー
無料プランを持つ製品もあります。SaaSは初期投資が小さく、すぐに始められます。無料で試してから本格導入する進め方もあります。
既製SaaSの項目や画面が自社の業務に合わないほど独自性が強い場合は、スクラッチ開発が選択肢になります。初期費用はかかりますが、業務フローをそのまま反映でき、不要な機能に振り回されずに済みます。
受託開発は、小規模な案件でも数百万円から始まります。連携や独自要件が増えるほど費用が積み上がるため、SaaSのカスタマイズで足りるか、業務に合わせて作るかを数字で比べます。
現状（AsIs）と理想（ToBe）の業務フロー整理
SaaSかスクラッチかを判断する前に、自社の業務フローを書き出して整理します。
- 現状（AsIs）：顧客情報の管理場所、商談手順、無駄や手戻りを洗い出す
- 理想（ToBe）：導入後の姿を描く。現状を見ずに理想だけを描くと、現場と乖離しがち
- 機能から始めない：「あの機能が欲しい」と先走ると、現場に合わないシステムになりやすい
- 業務ヒアリング：十分に聞かずにベンダーへ丸投げすると、誰も使わず、巨額の投資が無駄になる失敗が起きる
- 解決する課題：機能だけでなく、どの業務のどんな課題に応えるかを要件定義書に記す
AsIsとToBeの整理は、要件定義書の骨格になります。業務フローを起点に考えると、SaaSで足りるか、開発が必要かも見えてきます。
営業プロセスへの適合と入力負荷の要件設計
現場への定着は、営業プロセスへの適合と入力負荷の抑制に左右されます。SFA導入企業の約80%が失敗する最大の原因は、入力が事務作業になり、現場が使わなくなることです。
SFA満足度調査では、導入済み企業の55%が「課題を解決していない」と回答しています。そのため、入力の範囲と自動化の範囲を要件定義で決めておくことが、定着の鍵になります。
自社の商談フェーズを反映する項目設計
商談フェーズや入力項目は、実際の営業の流れに合わせて設計します。一般的な「初回・提案・受注」の区分では、自社の細かなプロセスを表現できないことがあります。
要件定義書には、実際の商談ステップと、各段階で入力する内容、次の段階へ進む条件を定義します。設定がずれると、現場は仕事の進め方と違うと感じて入力をやめてしまいます。プロセスとシステムが一致していることが、自然な入力を生む前提になります。
入力項目は、本当に必要なものだけに絞ります。各部門の要望をすべて入れると項目が増え、1件の登録に時間がかかり、現場が疲弊するためです。
- 使い道を確認する：誰がどんな判断に使う項目かを問う
- 不要な項目を省く：使い道のない項目は削る
- 入力の優先度を決める：必須と任意を分けて、必須にする項目を定める
「使うから入れる」と言える基準で項目を選ぶと、入力負荷を抑えつつ、データ品質も保てます。
入力負荷を下げる自動化・連携の要件
入力負荷を下げるには、手入力を減らす要件が有効です。要件定義書に明記しておくと、ベンダーの提案で自動化の範囲を比べられます。
- 名刺の読み取り：スキャンした名刺から顧客情報を自動で登録
- メール・カレンダー連携：活動履歴を自動で記録
- AI音声解析：商談メモのテキスト化
AIによる入力負荷の軽減は、近年の製品選定で重みを増している観点です。さらに、自動化では入力後に現場へ何が返るかも設計します。たとえば、次のアクションの提示、上司の的確なフォロー、過去の経緯の確認などが、現場への還元になります。
定着には、入力を減らす工夫と、入力のメリットを返す工夫の両方が欠かせません。見返りがないまま負荷だけを求めるとシステムは形骸化しますが、現場にメリットが返る仕組みがあれば、多少の入力も自分のためになると受け止められます。
現場・トップ営業を要件定義に巻き込む進め方
現場に馴染む要件にするには、要件定義の段階から現場を巻き込みます。
- 現場の参加：トップ営業を含める。管理部門だけで決めると、実態とずれやすい
- 営業の知見：営業の動きを手本にし、担当者の暗黙知を要件に取り込む
- 導入後の協力：入力に非協力的なベテランを主役にし、勝ちパターンを要件に反映して当事者意識を育てる
要件定義は技術文書づくりだけでなく、社内合意を形成する過程です。誰を巻き込むかが、導入後の定着率を左右します。
連携・データ移行をRFPに落とし込む要件
顧客管理システムでは、他システムとの連携と既存データの移行が論点になります。どちらも、後から発覚すると追加費用や工期の膨張を招く領域です。
RFPでは、連携要件と移行要件を別の項目に分け、ベンダーに具体的な対応方針と概算を求めます。後戻りしにくいため、入口の段階で定義しておく必要があります。
MA・会計など連携範囲を明確にする要件
連携要件では、接続するシステム、やり取りするデータ、その方向を明らかにします。たとえば、MA（マーケティングオートメーション）からリードを引き継ぐ連携があります。
会計システムへ受注情報を送って請求につなげる連携や、名刺管理ツールと顧客データを同期する連携もあります。ただし、頻度やデータの粒度は連携ごとに異なります。
- 連携先：接続するシステム
- データ項目と方向：何をどちらへ送受信するか
- 頻度：リアルタイムか日次か
- 障害時の整合性：障害が起きた際にデータの食い違いをどう防ぐか
これらの項目をRFPに一覧にすると、提案の精度が上がります。
要件が曖昧だと、想定した連携ができない、APIに制約があって追加開発が必要になる、といった事態が起きます。SaaSでは、標準連携とAPI仕様を確認します。
スクラッチ開発では、連携先システムの仕様を提供してもらえるかを確認します。また、MA連携は、リード獲得から商談、受注後の育成までをつなぐ役割を担います。
エレコムの事例にあるように、MA連携は受注率の向上にも寄与します。連携を「あれば便利な機能」で終わらせず、効果を最大化する投資の一部として要件に置きます。
名寄せを含むデータ移行の要件定義
データ移行はRFPで軽視されがちですが、失敗の温床になりやすい領域です。要件定義では、対象や品質、担当範囲を明確にします。
- 対象と品質：移行範囲・データ量・重複や欠損の程度を記す。Excel顧客リストや名刺台帳の表記揺れ・重複はデータを汚し、正しい示唆を妨げる
- 担当範囲：名寄せ（表記統一・重複統合）を、発注側とベンダーのどちらが受け持つかを決める。曖昧だと責任の所在が不明になる
- 名寄せの基準：「株式会社A」と「（株）A」の統一ルールと、重複レコードの判定基準を定める
- データ収集範囲：手帳やローカルPCにあるデータを、どこまで集めるか決める
- 移行後の状態：データ品質を作り直し、稼働後に現場が古いExcelへ戻る事態を防ぐ
連携や移行といった裏方の要件は、要件定義書の完成度を測る指標になります。
移行手順・検証・スケジュールの要件
名寄せのルールが決まったら、移行の手順も定義します。全データを一度に移すか、稼働中のデータと過去のデータを分けて段階的に移すかを選びます。
移行リハーサルで本番前に問題を洗い出す工程も、検討しておきます。RFPに記載すれば、現実的な計画をベンダーから得られ、稼働直前のトラブルを避けられます。
移行は工期が遅れやすいため、手順を明確にしておく必要があります。そのうえで、移行後のデータを検証する方法も要件に入れておきます。
- 件数の突合：移行前後で数が合うかを確認する
- サンプル確認：データを抽出して目視する
- 主要顧客の確認：レコードの欠落がないか調べる
検証を省くと、過去の取引履歴が一部消えていたなどの欠陥が、稼働後に発覚しかねません。手順・検証・スケジュールまで要件に含めると、移行を管理された工程として進められます。
非機能要件・運用体制とベンダー選定の要件
機能や連携・移行を決めただけでは、要件定義書は完成しません。RFPには、セキュリティや性能、導入後の運用体制を含めます。さらに、公平なベンダー評価の基準も書いておきます。
目立たない領域ですが、定義を怠ると稼働後のトラブルや形骸化につながります。
セキュリティ・権限・性能の非機能要件
顧客管理システムは機微な顧客情報を扱うため、セキュリティ要件を明記します。
- アクセス権限：役割ごとに閲覧・編集を制御する
- 暗号化：通信データと保存データを保護する
- 監査ログ：操作の記録を取得する
権限設計が不十分だと、情報漏えいや、必要な情報にアクセスできない不便が生じます。さらに、曖昧だったExcel管理の権限を明文化できることも、システム化の価値です。
ユーザー数の増加に耐える性能と、スマートフォン利用を想定した対応を定義します。加えて、サービスの可用性とサポート体制を定めます。
Excel管理で生じる動作の重さや同時編集の難しさを解消できるかは、非機能要件で決まります。機能だけでなく土台を整えることが、長く使える条件になります。
運用体制とベンダー評価基準の要件
導入後に誰が管理し、改善を続けるかを決めます。項目の見直しや利用促進を担うアドミニストレーターがいないと、システムは放置されます。
運用が放置されると、約80%の失敗例と同じ道をたどりかねません。そのため、運用ルールの整備、アドミニの育成、定着支援を、ベンダーの支援範囲に含めるかどうかをRFPに記します。
ベンダー評価では、機能の充足度だけでなく、業務理解、導入後の定着支援や保守体制、総保有コストを総合的に見ます。
- SaaSベンダー：標準機能への適合度の評価
- スクラッチ開発ベンダー：業務への作り込みと運用伴走の評価
方式ごとの提案の性質を踏まえて評価すると、公平に比べられます。
riplaは、フルスクラッチ受託と国内開発の立場から、要件定義からRFP作成、ベンダー選定を経て、導入後の定着まで一貫して伴走します。
要件定義に時間をかけることが、結果として成果に最短で届く近道になります。
まとめ
顧客管理システムの要件定義とRFP作成では、SaaSかスクラッチかを選び、業務フローを整理したうえで、項目と入力負荷を設計します。
さらに、MA・会計との連携と、名寄せを含むデータ移行の要件を詰めます。SaaSは月額1,680円〜が相場で、手軽に始められます。
業務の独自性が強い場合は、業務への適合という点でスクラッチが優位になります。誰が何のためにどう使うかを業務の流れから言葉にして、約80%という失敗率を避けます。
業務課題を起点に要件を組み立てます。そのうえで、入力負荷を抑え、連携と移行を定義しておくと、ベンダーの提案を的確に比べられます。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、業務ヒアリングとAsIs／ToBeの整理を土台に、要件定義書の作成から連携・移行設計まで一貫して支援します。全体像は、完全ガイドで確認できます。
▼全体ガイドの記事
・顧客管理システムの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。