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