商談管理システムのRFP/要件定義書/提案依頼書について

商談管理システムの導入を本格的に進める段階になると、「ベンダーに何をどう依頼すればいいのか」「RFP（提案依頼書）や要件定義書には何を書けばいいのか」という実務的な壁にぶつかります。要件があいまいなままベンダーに丸投げすると、自社の営業プロセスに合わないシステムが出来上がり、入力されず形骸化する――これはSFA/CRM導入で繰り返されてきた典型的な失敗です。だからこそ、発注側が自社の要件を整理し、適切なRFPを作る力こそが、導入成功の最大の前提条件になります。

本記事は、商談管理システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から実務に即して解説する「要件定義特化」の内容です。SaaSとスクラッチの選定基準、自社営業プロセスへの適合要件、入力負荷を抑える項目設計、MA・会計などとの連携要件、Excel・名刺台帳からの移行（名寄せ）要件まで、何を要件として書き出すべきかを順に掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、商談管理システムの全体像をまだ把握していない方は、まず商談管理システムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・商談管理システムの完全ガイド

SaaSかスクラッチかを決める要件整理

要件定義の出発点は、「既製のSaaSを使うのか、スクラッチで開発するのか」という方式選定です。この判断を曖昧にしたままRFPを書くと、提案が比較できず、選定そのものが迷走します。SaaSは初期費用を抑えて早く始められる一方、自社プロセスへの適合に限界があります。スクラッチは自由度が高い反面、相応の投資と期間が必要です。まずは自社の営業プロセスの特殊性と、許容できる予算・期間を整理することが、方式選定の前提になります。

方式選定には、費用相場の理解が欠かせません。SaaS型の商談管理ツールは、Salesforce Sales Cloudが3,000円〜/ユーザー、Zoho CRMが1,680円〜/ユーザー、kintoneが780円〜/ユーザー（ライトコース）、GENIEE SFA/CRMが10ユーザーで月34,500円〜、Mazrica Salesが5,500円〜/ユーザーと、月額1,680円〜30,000円/ユーザー程度が一般的な相場です。HubSpot CRMのように無料から始められる製品もあります。一方、フルスクラッチの受託開発は、小規模で300万〜800万円程度が一つの目安になります。

RFPでは、この相場感を踏まえて予算要件を現実的に設定します。重要なのは、SaaSの月額を「ユーザー数×利用年数」で積み上げ、スクラッチの初期投資と総保有コスト（TCO）で比較することです。たとえば月3,000円×50名を5年使えば900万円となり、スクラッチの初期費用と拮抗します。予算要件は単年の金額だけでなく、複数年のTCOで提示すると、ベンダーも適切な方式を提案しやすくなります。費用の前提を明示することが、ずれた提案を防ぐ第一歩です。

方式を分ける本質的な基準は、自社の営業プロセスがどれだけ標準から外れているかです。一般的な「初回接触→提案→クロージング」の流れに収まる営業なら、SaaSの標準機能で十分カバーできます。逆に、技術検証やトライアル、独自の稟議代行といった特殊な工程が商談に組み込まれている場合は、SaaSをカスタマイズで無理に合わせるより、スクラッチで素直に作る方が結果的に安く・使いやすくなることがあります。RFPでは、自社の商談プロセスを工程ごとに書き出し、標準ツールで実現可能かを問う形にすると、方式判断がしやすくなります。

注意したいのが、SaaSの過度なカスタマイズです。標準ツールに自社要件を詰め込みすぎると、アップデートに追従できず、複雑化してメンテナンス不能になる「カスタマイズ地獄」に陥ります。RFPの段階で「標準機能でどこまでカバーでき、どこからカスタマイズが必要か」をベンダーに明示させ、その範囲が膨らむようならスクラッチを再検討する、という判断ロジックを持っておくべきです。riplaのようなフルスクラッチ受託の立場では、現場ヒアリングで営業プロセスを可視化し、SaaSでは無理な部分を見極めたうえで方式を提案します。

自社営業プロセスへの適合要件と項目設計

方式が定まったら、次は機能要件の核心である「自社営業プロセスへの適合」と「入力項目の設計」です。ここが商談管理システムの成否を最も左右する部分です。要件定義では、現状（AsIs）の営業の動き方を可視化し、あるべき姿（ToBe）を描いたうえで、それをシステムの商談ステージや入力項目に落とし込みます。この作業を丁寧に行うかどうかが、入力されるシステムと形骸化するシステムを分けます。

適合要件の出発点は、現状の営業プロセスの可視化です。営業・営業事務・マネージャーといった関係者に「実際にどう商談を進め、何を記録し、どこで困っているか」をヒアリングし、現状の業務フローを描き出します。そのうえで、システム化で改善したいポイントを反映したToBeを設計し、それを商談ステージとして定義します。RFPには、この自社固有のステージ定義と、各ステージで管理したい情報を明記します。汎用的な定義をそのまま採用すると、自社の売り方と噛み合わず入力されなくなります。

ステージ定義で重要なのは、各段階の移行基準を明確にすることです。「提案ステージから見積ステージへ進むには、決裁者と面談済みであること」といった基準を要件に盛り込めば、確度の付け方が標準化され、売上予測の精度が上がります。RFPでは、ステージ定義の柔軟性（後から変更できるか）も要件として問うべきです。営業プロセスは事業の成長とともに変わるため、ステージを固定的に作り込むと将来の足かせになります。

適合要件と並んで重要なのが、入力負荷を抑える項目設計です。SFA導入企業の約80%が失敗する（Gartner）と言われ、その最大の原因が入力負荷の増大による形骸化です。要件定義では「管理者が知りたい項目」を全部入れるのではなく、「営業が無理なく入力でき、かつ意思決定に本当に使う項目」だけに絞り込むことが鉄則です。RFPには、必須項目を最小限に抑える方針と、任意項目の扱いを明記します。

入力負荷を下げる具体的な要件としては、入力支援の仕組みを盛り込みます。プルダウンやテンプレートによる選択式入力、スマートフォンからの簡易入力、AIによる音声・議事録からの自動入力といった機能を要件化すれば、入力が「事務作業」から「数秒で終わる作業」に変わります。要件定義の段階で「入力に何分かかるか」を現場目線でシミュレーションし、3分以上かかるなら項目を削る、といった基準を持つことが、形骸化を防ぐ最も実効的な対策です。項目設計は機能要件であると同時に、定着のための運用設計でもあります。

連携要件とセキュリティ・非機能要件

機能要件を固めたら、外部システムとの連携要件と、セキュリティや性能などの非機能要件を整理します。商談管理システムは単独で完結させるより、マーケティングや会計など周辺システムとつなぐことで効果が最大化されます。連携要件をRFPに明記しないと、後から「会計と連携できなかった」という致命的な手戻りが発生します。非機能要件もあわせて定義することで、提案の比較精度が高まります。

連携要件の中心は、MA・会計・基幹システムとのデータ連携です。MAと連携すれば、マーケが獲得したリードが商談として営業に自動で渡り、リード獲得から受注後育成までが一本の流れになります。エレコムがSFAとMAの連携で受注率を約1.75倍に高めた事例は、この連携の効果を裏付けています。RFPには、連携先のシステム名・連携するデータ項目・連携のタイミング（リアルタイムかバッチか）・連携方式（API/CSV等）を具体的に書き出します。

受注側の連携も忘れてはいけません。商談が成約した瞬間に会計システムへ請求情報が流れる仕組みを要件化すれば、二重入力やデータ不整合が消えます。連携要件で注意すべきは、連携先システムのAPI仕様や制約を事前に確認しておくことです。連携可能だと思っていた周辺システムにAPIがなかった、という事態は珍しくありません。RFPの段階で連携の実現可能性をベンダーに検証させることで、開発後半での大きな手戻りを防げます。

商談管理システムは、顧客情報や取引条件という機密性の高いデータを扱うため、セキュリティ要件は必須です。アクセス権限の設定（営業は自分の案件のみ、マネージャーは全案件を閲覧可能など）、ログイン認証の方式、通信・保存データの暗号化、操作ログの取得といった要件を明記します。Excel管理時代に課題だったセキュリティの弱さを、システム化で解消する観点からも、権限設計は重要な要件になります。

性能などの非機能要件も定義します。想定する同時アクセス数、データ量、レスポンス速度、可用性（稼働率）といった指標を要件化すれば、提案の品質を比較できます。Excelの「動作が重い」「同時編集できない」という限界をシステム化で乗り越えるのが目的ですから、性能要件は現場の使い勝手に直結します。さらに、将来のユーザー増や機能追加を見据えた拡張性も要件に含めると、長く使えるシステムになります。非機能要件は地味ですが、ここを書き込むかどうかで提案の精度が大きく変わります。

データ移行・名寄せ要件と推進体制

要件定義で最も見落とされやすいのが、既存データの移行要件と、導入を推進する体制の定義です。どれだけ良いシステムを作っても、既存の商談データが正しく移行できなければ初日から使えません。また、システムは作って終わりではなく、定着させる体制があって初めて成果につながります。RFPには、移行要件と推進体制の両方を盛り込むことで、導入の落とし穴を未然に防げます。

移行要件の核心は、Excel案件表や名刺台帳に分散したデータの統合と名寄せです。同じ取引先が「株式会社A」「（株）A」「A社」と複数表記で登録されていると、移行後に商談が重複して正確な状況がつかめません。RFPには、移行対象データの範囲（どのExcel・どの名刺台帳まで）、表記揺れの名寄せ方針、重複データの統合ルール、移行後のデータ検証方法を明記します。手帳やローカルPCに眠るデータをどこまで吸い上げるかも、要件として整理しておくべきです。

名寄せは想像以上に工数のかかる作業のため、誰が・いつまでに・どの基準で行うかを要件で明確にします。移行前にマスタとなる取引先一覧を確定し、表記ルールを定義したうえで、各営業が持つデータを照合・統合する段取りをRFPに織り込みます。この移行・名寄せ要件を軽視すると、せっかくのシステムが「汚れたデータの置き場」になりかねません。移行の質が、導入初日のシステムの信頼性を決定づけます。

最後に、定着を支える推進体制を要件に組み込みます。導入が成功する企業に共通するのは、スモールスタートで効果を検証し、社内に目的を共有し、運用マニュアルとアドミニストレーター（システム管理者）を育成している点です。RFPには、運用マニュアルの提供範囲、管理者向けトレーニングの有無、導入後のサポート体制を要件として書き出します。ベンダーに「作って渡して終わり」ではなく、定着まで伴走してもらえるかを問うことが重要です。

推進体制の要件には、自社側の役割も明記します。誰が導入推進の責任者か、現場への教育を誰が担うか、入力を評価制度にどう紐づけるか、といった運用ルールの設計はベンダー任せにできません。要件定義の段階で「導入後にどう運用し、どう定着させるか」まで描いておくことが、約80%が失敗すると言われるSFA導入の落とし穴を回避する鍵です。riplaはフルスクラッチ受託と国内開発の立場から、要件整理から移行、定着までを一貫して伴走し、現場に使われる商談管理システムの実現を支援します。

まとめ

商談管理システムのRFP・要件定義書は、SaaSかスクラッチかの方式選定、自社営業プロセスへの適合と入力項目設計、MA・会計・基幹との連携とセキュリティなどの非機能要件、Excel・名刺台帳からの移行（名寄せ）と推進体制という四つの柱で構成されます。費用相場（SaaS 1,680円〜30,000円/ユーザー、スクラッチ小規模300万〜800万円）を踏まえた予算設定、入力負荷を抑える項目設計、移行データの名寄せ、定着を支える体制要件のいずれもが、約80%が失敗するSFA導入を成功側に導くための要点です。

RFPを書くときに大切なのは、「機能を網羅すること」ではなく「自社の営業プロセスとデータの実態から逆算して要件を絞ること」です。要件があいまいなままベンダーに丸投げすると、形骸化するシステムが出来上がります。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングによるAsIs/ToBeの可視化から、移行・定着までを一貫して支援します。要件定義の前に全体像を整理したい方は、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。