営業支援システムの導入を成功させられるかどうかは、開発やツール選定が始まる前の「要件定義」でほぼ決まると言っても過言ではありません。Gartnerの調査ではSFA導入企業の約80%が失敗するとされますが、その多くは技術ではなく、自社の営業プロセスを言語化しないまま製品を選んでしまったことに起因します。要件定義書やRFP（提案依頼書）は、その失敗を未然に防ぐための設計図であり、ベンダーに自社の意図を正確に伝えるための共通言語です。
本記事は、営業支援システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から実務的に解説する「要件定義特化」の記事です。SaaSパッケージかスクラッチ開発かの選定軸、自社の営業プロセスに適合させる要件の言語化、入力負荷を抑えるための項目設計、MAや会計システムとの連携要件、そして既存データの移行・名寄せ要件まで、押さえるべき論点を順に解説します。なお、製品比較や費用感を含めた全体像を把握したい方は、まず営業支援システムの完全ガイドもあわせてご覧ください。要件定義の質が、その後の定着とROIを左右します。
▼全体ガイドの記事
・営業支援システムの完全ガイド
SaaSパッケージかスクラッチ開発かの選定要件
要件定義の出発点として最初に決めるべきが、SaaSパッケージを採用するのか、自社専用にスクラッチ（フルオーダー）開発するのかという方針です。この選択を曖昧にしたままRFPを作ると、ベンダーから受け取る提案の前提がばらつき、比較できなくなります。まずは自社の営業プロセスの特殊性と、標準化への許容度を見極めることが、要件定義の第一歩です。
SaaS適合性の判断とコスト要件の整理
SaaSパッケージの強みは、初期投資を抑えて早く始められる点にあります。SaaS型SFA/CRMの料金相場は月額1,680円〜30,000円/ユーザーで、Zoho CRMは1,680円〜、Salesforce Sales Cloudは3,000円〜、kintoneは780円〜/ユーザー（ライトコース）、HubSpot CRMは無料プランから利用できます。自社の営業プロセスが比較的標準的で、製品の機能に業務を合わせられるなら、SaaSは合理的な選択肢です。要件定義では、まず自社の業務がパッケージの標準機能でどこまでカバーできるかを検証します。
ここで注意したいのが、SaaSへの過度なカスタマイズが、かえって複雑化と高コストを招くという落とし穴です。標準機能で8割賄えるなら、残り2割は業務側を歩み寄らせるほうが、結果的にシンプルで定着しやすいシステムになります。要件定義の段階で「これは標準機能で対応」「これは業務運用で吸収」「これだけはカスタマイズが必須」と仕分けることで、無駄なカスタマイズ費用を抑えられます。SaaSのコスト要件は、月額のライセンス費だけでなく、このカスタマイズや初期設定の費用まで含めて整理することが重要です。
スクラッチ開発が適するケースと費用感の要件
一方、自社の営業プロセスが他社にない独自性を持つ場合や、基幹システムと深く連携させて全体最適を狙う場合は、スクラッチ開発が選択肢になります。パッケージに業務を無理に合わせると現場が使わなくなるリスクが高いとき、業務に完全にフィットしたシステムを作るスクラッチには明確な価値があります。要件定義では、「なぜパッケージでは満たせないのか」を具体的に言語化することが、スクラッチを選ぶ根拠になります。
スクラッチ開発の費用は要件の範囲によって幅がありますが、受託開発では小規模で300万〜800万円程度から、機能や連携が増えるほど費用が積み上がるのが一般的です。RFPでは、必須機能と、あれば望ましい機能を切り分けて優先度を示すことで、ベンダーが段階的な見積もりを出しやすくなります。riplaはフルスクラッチ受託の立場から、最初から全機能を作り込むのではなく、もっとも効果の大きい範囲から段階的に構築し、定着を確認しながら広げる進め方を重視しています。要件定義では、この優先順位づけこそがコストと成功確率を両立させる鍵になります。
自社営業プロセスへの適合と入力項目の要件設計
要件定義の本丸が、自社の営業プロセスをどうシステムに落とし込むかという適合要件です。SFAが形骸化する最大の原因は、自社のプロセスを無視した汎用的な項目設計を押し付け、現場の入力負荷だけが増えることにあります。だからこそ、現場の実際の動きを起点に要件を組み立てることが欠かせません。理想論ではなく、現場が日々どう動いているかから設計するという姿勢が、成否を分けます。
現状（AsIs）と理想（ToBe）の業務フロー可視化
適合要件を固める第一歩は、現場へのヒアリングを通じて、現状（AsIs）の営業プロセスを可視化することです。リード獲得から初回接触、提案、見積、クロージング、受注後フォローまで、自社の営業が実際にどんな段階を踏み、どこで何に困っているかを洗い出します。このAsIsの可視化を飛ばして製品を選ぶと、システムと実態が噛み合わず、現場は従来のやり方に戻ってしまいます。
そのうえで、システムでどう改善するかという理想（ToBe）の業務フローを描きます。重要なのは、現状をそのままシステム化するのではなく、無駄な手戻りや二重入力を排した「あるべき姿」を設計することです。AsIsとToBeを並べて要件定義書に明記すれば、ベンダーは「この企業はこの課題を、この形で解こうとしている」と正確に理解でき、的外れな提案を避けられます。この業務フローの可視化こそ、RFPの中核に据えるべき要素です。
入力負荷を抑える項目の絞り込みと必須・任意の設計
要件定義で最も差がつくのが、入力項目の設計です。SFAが使われなくなる典型は、各部門の要望をすべて取り込んだ結果、一つの商談を登録するのに膨大な項目を埋めなければならなくなることです。要件定義の段階で、「この項目は本当に意思決定に使うのか」「分析やマネジメントに必要か」を一つひとつ問い、必要最小限まで絞り込むことが定着の鍵になります。項目は足し算ではなく引き算で設計するという原則を持つべきです。
具体的には、必須入力と任意入力を明確に分け、現場が必ず入れるべき項目を数個に絞ります。さらに、選択式やテンプレートで入力を素早く済ませられる設計や、スマートフォンから移動中に入力できる要件を盛り込むことで、入力負荷を下げます。AI音声解析による自動入力を要件に含めれば、入力の手間そのものを大幅に減らせます。RFPには「入力にかける時間の目標」まで明記すると、ベンダーが現場目線の設計を提案しやすくなります。入力されないデータは、どれだけ高度な分析機能があっても無価値だという認識が、項目設計の前提です。
外部システム連携とデータ移行・名寄せの要件
営業支援システムの効果を最大化するには、単体で完結させず、既存の業務システムとどう連携させるかを要件として明確にする必要があります。また、稼働後の品質を左右するのが、既存データをどう移行するかという移行要件です。連携と移行は地味な領域ですが、ここを要件定義で詰めておかないと、稼働後に深刻な問題が表面化します。RFPで必ず言及すべき重要論点です。
MA・会計・基幹システムとの連携要件の定義
連携要件で最初に押さえるべきは、MA（マーケティングオートメーション）との連携です。エレコムの事例では、SFAとMAを連携させ見込み顧客を部門横断で把握することで、受注率が約1.75倍に向上しました。リード獲得から商談、受注後の育成までをシームレスにつなぐと効果が最大化されるため、RFPには「どのMAツールと、どのデータを、どの頻度で連携するか」を具体的に記載します。連携の方向性や対象データを曖昧にすると、後で追加開発が発生し費用が膨らみます。
さらに、受注データを会計システムや基幹システム（ERP）に連携すれば、受注から請求までの流れが自動化され、二重入力やデータ不整合がなくなります。要件定義では、連携相手のシステム名、連携方式（API連携かCSV連携か）、連携するデータ項目とタイミングを明記します。riplaはフルスクラッチ受託の立場から、こうした連携要件を要件定義の段階で丁寧に詰めることで、営業支援システムを孤立させず、業務全体の中で価値を発揮させることを重視しています。連携は後付けではなく、最初から設計に織り込むべき要件です。
データ移行・名寄せ・クレンジングの要件明記
データ移行は、要件定義で軽視されがちですが、稼働品質を直接左右する重要要件です。多くの企業は顧客情報や商談履歴をExcelや名刺、個人の手帳で管理してきました。これらをそのまま移行すると、「株式会社A」「（株）A」のような表記揺れや重複が混在し、システム上で顧客の全体像が見えなくなります。RFPには、移行対象のデータ範囲、名寄せ（重複統合）のルール、クレンジングの方針を明記し、誰がどこまで責任を持つかを定めます。
移行要件で現実的なのは、「すべてのデータを移行する」のではなく、「使うデータだけを、きれいにして移行する」という割り切りです。古い案件や活動していない顧客まで持ち込むと、かえってデータが汚れ、現場の信頼を損ないます。さらに、トップ営業が手帳やローカルPCに抱え込んでいる眠れるデータをどう吸い上げるかも、移行要件の論点です。表記揺れの補正は移行ツールやスクリプトで機械的に行い、最終判断だけを人が担う進め方を要件に盛り込むと、移行工数を抑えられます。移行・名寄せ要件を曖昧にしたまま開発に進むと、稼働初日からデータの信頼性を失うことになります。
RFPに盛り込む定着・運用・評価の要件
要件定義というと機能要件に目が向きがちですが、SFAの成否を最終的に分けるのは「導入後に使われ続けるか」という定着の問題です。だからこそ、RFPには機能だけでなく、運用支援や定着のための要件まで盛り込むべきです。約80%が失敗するという統計の裏には、稼働後の運用設計の欠如があります。これを要件の段階から手当てすることが、失敗を避ける最後の砦になります。
アドミニストレーター育成と運用支援の要件
定着を支えるのが、社内のアドミニストレーター（管理者）の存在です。導入後、現場からの「ここがわからない」「この項目を変えたい」という声に応え、運用ルールを更新し続ける担当者がいないと、システムは少しずつ陳腐化していきます。RFPには、運用マニュアルの整備、管理者向けの操作トレーニング、稼働後の問い合わせ対応といった運用支援を要件として含め、ベンダーにどこまで伴走してもらえるかを明確にします。
riplaはフルスクラッチ受託と運用伴走の立場から、作って納品して終わりではなく、稼働後に現場へ定着させるまでを支援することを重視しています。要件定義の段階で「導入後3か月の定着支援」「管理者育成のためのトレーニング」といった項目をRFPに含めておくと、提案の段階からベンダーの運用面の力量を比較できます。機能だけでベンダーを選ぶと、稼働後の運用で孤立し、形骸化への道をたどりかねません。運用・保守の要件は、機能要件と同じ重みで扱うべきです。
入力を評価制度に紐づける運用要件と目的の共有
SFA定着の難所が、「入力しないベテラン営業」をどう動かすかです。トップ営業ほど自分のノウハウを抱え込みがちで、システムへの入力に消極的なことがあります。これは要件定義だけで解決できる問題ではありませんが、入力状況を可視化する機能や、入力を人事評価やインセンティブに紐づける運用ルールの設計を要件に含めることで、強制力を持たせる土台を作れます。データを共有した人が評価される仕組みは、定着を後押しします。
同時に欠かせないのが、「何のためにこのシステムを入れるのか」という目的を社内で共有することです。管理目的が先行し、現場が「監視されている」と感じると反発を招きます。営業自身の業務が楽になり、成果が出やすくなるという目的を共有できれば、入力は強制ではなく自発的なものに変わります。RFPや要件定義書は、ベンダーへの伝達文書であると同時に、社内の関係者が目的を共有するための合意文書でもあるのです。この二重の役割を意識して要件をまとめることが、定着への第一歩になります。
まとめ
営業支援システムのRFP・要件定義書を整理すると、まずSaaSかスクラッチかの方針を定め、現状（AsIs）と理想（ToBe）の営業プロセスを可視化し、入力負荷を抑える項目設計を行い、MAや会計システムとの連携要件とデータ移行・名寄せ要件を明記し、さらにアドミニストレーター育成や評価制度連動といった定着・運用要件まで盛り込む、という流れになります。約80%が失敗するというSFAにおいて、この要件定義の徹底こそが、失敗を未然に防ぐ最大の保険です。
RFPを作るときに大切なのは、「どんな機能がほしいか」ではなく「自社の営業をどう変えたいか」を起点にすることです。機能の羅列ではなく、業務フローと目的を言語化した要件定義書こそが、ベンダーの的確な提案を引き出し、現場に定着するシステムを生みます。riplaはフルスクラッチ受託と国内開発、運用伴走を組み合わせ、自社業務から逆算した要件整理から定着までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。