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