SFAのRFP・要件定義書の作り方｜比較できる依頼項目とテンプレート

SFAのRFP（提案依頼書）は、欲しい機能を並べる文書ではありません。導入目的、対象業務、利用者、データ、権限、連携、移行、支援、費用、契約条件を同じ前提で候補企業へ伝え、回答を比較できる形にする文書です。

RFPが曖昧だと、各社が異なる人数・プラン・支援範囲で回答し、金額も機能も比較できません。本記事では、100名以上のSFA選定で使うRFPの章立て、質問の作り方、評価、PoC、稟議へのつなぎ方を解説します。

RFP・要件定義書・稟議書の違い

RFPは要件定義の代わりではありません。自社の目的と必須条件が未整理なら、まずRFIやヒアリングで市場を把握し、要件を具体化してから提案を依頼します。

SFAのRFPに入れる12章

1. 背景・目的・成功条件

現状の問題、対象業務、導入後に変えたい状態、測定指標を書きます。「営業力を強化する」ではなく、商談後の記録時間、案件情報の欠落、会議集計、引き継ぎなど、導入前後で確認できる指標へ分けます。

2. 対象範囲・利用者・前提条件

対象会社、部門、地域、役割、利用人数、将来人数、言語、端末、勤務形態を示します。営業担当者だけでなく、マネージャー、営業企画、閲覧者、管理者、連携用アカウントを含めて見積条件をそろえます。

3. 現行業務と導入後の業務

顧客獲得から商談、見積、受注、引き継ぎまでの現行フローと、SFA導入後に変える範囲を示します。製品機能の名称ではなく、利用者が完了させる業務シナリオとして記述すると、デモとPoCに再利用できます。

4. 機能要件

顧客・案件・活動・予測・レポート・モバイルなどを、必須、希望、対象外に分けます。「対応可」の回答だけでなく、標準、設定、追加開発、外部製品、対応予定のどれかを指定し、プランと費用も回答させます。

5. データ・移行要件

顧客、担当者、案件、活動、メール、音声、添付、コメント、変更履歴の概数・形式・期間を示します。出力、変換、試行移行、リハーサル、照合、切替、旧環境終了について、担当と成果物を回答させます。

6. 認証・権限・セキュリティ要件

SSO、多要素認証、アカウント自動連携、組織・役職・案件権限、監査ログ、暗号化、保存場所、インシデント通知、再委託先、データ削除を記載します。自社のチェックリストと必要な証跡を添付します。

参考：IT製品の調達におけるセキュリティ要件リスト活用ガイドブック（IPA）

7. 外部連携・AI要件

メール、カレンダー、電話、Web会議、MA、会計、ID基盤などについて、連携対象、同期方向、反映時間、API上限、失敗時の再処理、問い合わせ先を記載します。AIは元データ、処理先、学習利用、保存、確認・修正、上限、追加費用を分けます。

8. 非機能・サービスレベル要件

利用時間、性能、同時利用、データ量、可用性、計画停止、バックアップ、復旧、監視、問い合わせ、変更通知を記載します。抽象的な「十分な性能」ではなく、代表画面・検索・一括処理・締め日の条件を示します。

9. 導入・教育・定着支援

要件整理、設定、移行、管理者研修、利用者説明、マニュアル、問い合わせ、導入後レビューの役割と回数を回答させます。提供者が行う作業と自社が行う作業を分け、追加費用と前提条件を明らかにします。

10. 管理者運用・変更管理

利用者追加、組織変更、権限棚卸し、項目・レポート変更、データ修正、障害確認に必要な管理作業を示します。100名以上では、通常月と組織変更月の作業件数を想定し、実機で管理時間を測ります。

11. 価格・見積条件

同じ人数・期間・利用量・支援範囲で、初期、ライセンス、AI・容量、連携、移行、追加開発、教育、保守、更新、終了の費用を依頼します。未確定費用は0円にせず、単価、算定式、上限、前提を回答させます。

12. 契約・出口条件

契約期間、更新、価格改定、SLA、仕様変更、再委託先変更、監査協力、責任制限、データ所有、出力、解約、削除を確認します。法的な判断は自社法務・専門家と行い、RFP回答と最終契約の差を確認します。

候補を比較できる回答形式を指定する

自由形式の提案書だけでは、得意な機能ばかりが強調されます。各要件に対し、回答区分、対象プラン、実現方法、制約、費用、提供時期、証跡、担当を同じ列で回答してもらい、提案書は補足資料とします。

RFPからPoC・評価へつなげる

書面で適合する候補を絞ったら、重要な業務シナリオをPoCで確認します。各社に同じサンプルデータ、端末、役割、操作、計測方法を適用し、成功デモの印象ではなく事実を残します。

社内稟議へ入れる選定根拠

稟議には、製品紹介よりも、なぜ今必要か、現状値、選定条件、候補比較、期待する直接効果、総コスト、残るリスク、導入体制、撤退条件を示します。売上向上だけを確約せず、入力時間、情報量、会議準備、管理工数など製品が直接変える指標を分けます。

SFAのRFPでよくある失敗

• 他社の機能表をそのまま要件にして導入目的と結び付かない
• 必須要件が多すぎて実際には優先順位がない
• 対応可の意味、プラン、追加費用、制約を指定しない
• 利用人数・AI利用量・移行範囲が候補ごとに異なる
• 営業部門だけで作り、情シス・セキュリティ・法務・購買が後から参加する
• RFP回答をPoC、見積もり、契約条項で再確認しない
• 未実装の対応予定を現在の機能と同じ点数で評価する

SFAのRFPに関するよくある質問

RFPは何社へ送るべきですか？

社数の正解はありません。RFIや公開情報で必須条件を満たす候補へ絞り、回答を評価できる社数にします。候補を増やすほど比較が良くなるとは限らず、質問・デモ・見積もりの条件をそろえる作業も増えます。

RFPを作る前に製品デモを見てもよいですか？

市場理解のためのデモは有用です。ただし、製品の画面を見てから要件を作ると、特定製品の機能がそのまま要件になりやすいため、現状課題と対象業務は先に整理します。

テンプレートをそのまま使えますか？

不要な項目を削除し、自社のデータ、人数、業務、規程、既存システムへ合わせてください。質問数より、各要件の目的・優先度・証跡・判定責任者が明確であることが重要です。

まとめ：RFPは比較と合意の基準を作る

良いRFPは、機能数を競わせるのではなく、自社が変えたい業務と守る条件を同じ前提で候補へ伝えます。回答形式を統一し、書面、PoC、見積もり、稟議、契約を同じ要件IDでつなげると、選定根拠と未解決事項を残せます。