商談管理システムの導入を成功させる前提は、発注側が要件を整理し、RFP（提案依頼書）を作ることです。
要件は提案の比較にも導入後の定着にもつながるため、方式選定から連携・移行まで、順に決めておきます。全体像は商談管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・商談管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SaaSかスクラッチかを決める要件整理
要件定義ではまず、既製のSaaSを使うか、スクラッチで開発するかを選びます。方式が曖昧なままでは提案を比較できず、選定が迷走してしまいます。
SaaSは初期費用を抑えて早く始められますが、自社プロセスへの適合には限界があります。一方で、スクラッチは自由度が高いものの、相応の投資と期間が要ります。そのうえで、営業プロセスの特殊性と、許容できる予算・期間を整理しておくことが、方式選定の前提です。
費用相場を踏まえた予算要件の置き方
方式を選ぶには、費用相場を知っておくことも欠かせません。発注側は、SaaSの月額費用とスクラッチの初期投資を、利用期間を含めて比べます。多くの製品は1ユーザーあたりの月額で課金されるため、利用人数が増えるほど費用も増えます。
- Salesforce Sales Cloud：3,000円〜/ユーザー
- Zoho CRM：1,680円〜/ユーザー
- kintone：ライトコースは780円〜/ユーザー
- GENIEE SFA/CRM：10ユーザーで月34,500円〜
- Mazrica Sales：5,500円〜/ユーザー
SaaSの一般的な相場は、月額1,680円〜30,000円/ユーザー程度です。HubSpot CRMのように、無料から始められる製品もあります。
フルスクラッチの受託開発は、小規模で300万〜800万円程度が目安になります。
RFPでは、この相場を踏まえて予算を現実的に設定します。さらに、SaaSの月額は「ユーザー数×利用年数」で積み上げます。
予算は、スクラッチの初期投資と総保有コスト（TCO）で比較します。たとえば、月3,000円×50名を5年使うと900万円となり、スクラッチの初期費用と拮抗します。
TCOは複数年分で示すと、ベンダーが方式を提案しやすくなります。また、費用の前提を明示しておくと、ずれた提案を防ぐ第一歩になります。
営業プロセスの特殊性で方式を見極める基準
方式を分ける基準は、自社の営業プロセスが標準からどれだけ外れているかです。標準的な営業と、特殊な工程がある営業とでは、向く方式が異なります。
- 標準的な営業：初回接触、提案、クロージングの流れなら、SaaSの標準機能で対応できます。
- 特殊な工程がある営業：技術検証、トライアル、独自の稟議代行が商談に入る場合は、スクラッチが適することがあります。
特殊な工程にSaaSを無理にカスタマイズするより、スクラッチで作ったほうが安く使いやすくなる場合があります。
そこで、RFPでは商談プロセスを工程ごとに書き出し、標準ツールで実現できるかを尋ねます。標準機能で対応できる範囲と、カスタマイズが必要な範囲も、ベンダーに明示させます。この回答をもとに、方式を判断します。
ただし、SaaSへの過度なカスタマイズには注意が必要です。自社要件を詰め込みすぎると、更新に追従できず、複雑化して保守できなくなる「カスタマイズ地獄」に陥ります。必要な範囲が膨らむ場合は、スクラッチを再検討します。
riplaはフルスクラッチ受託の立場から、現場へのヒアリングで営業プロセスを可視化し、SaaSでは難しい部分を見極めて方式を提案します。
自社営業プロセスへの適合要件と項目設計
方式が定まったら、機能要件の核にあたる、自社の営業プロセスへの適合と入力項目を設計します。ここが商談管理システムの成否を大きく左右します。
まず、現状（AsIs）の営業の動きを可視化し、あるべき姿（ToBe）を描きます。そのうえで、設計したToBeを商談ステージと入力項目に落とし込みます。この工程を丁寧に行うかどうかで、現場に入力されるシステムと、形骸化するシステムが分かれます。
AsIs/ToBeの可視化と商談ステージの定義
営業プロセスの見直しは、現状を業務フローに起こすところから始まります。作業は次の順に進めます。
- 現状を把握する：営業、営業事務、マネージャーに商談の進め方、記録内容、困りごとを聞きます。
- あるべき姿を設計する：システム化で改善したい点を、ToBeに反映して描きます。
- ステージを定義する：自社固有の段階と、各段階で管理する情報をRFPに明記します。
汎用的なステージ定義をそのまま使うと、自社の売り方と合わず、入力されなくなることがあります。
また、各段階の移行基準も定めます。「提案ステージから見積ステージへ進むには、決裁者と面談済み」といった基準を置くと、確度の付け方がそろい、売上予測の精度を高められます。
ステージを後から変更できるかどうかも、RFPで確認します。営業プロセスは事業の成長とともに変わるため、固定的な設計は将来の妨げになります。
入力負荷を抑える項目設計の要件
適合要件と並んで重要なのが、入力負荷を抑える項目設計です。項目は、営業が無理なく入力でき、意思決定に使うものだけに絞ります。
SFA導入企業の約80%が失敗すると言われ、その最大の原因は入力負荷の増大による形骸化です（Gartner）。そのため、RFPには、必須項目を最小限にする方針と、任意項目の扱いを書いておきます。
入力負荷を下げる具体策として、入力支援の仕組みを要件に盛り込みます。その方法は、次の3つに分けて検討します。
- 選択式入力：プルダウンやテンプレートから選ぶ形式
- スマートフォン入力：携帯端末から簡易に入力できる形式
- 自動入力：AIが音声や議事録から入力する仕組み
これらを要件に含めると、入力を事務作業から、数秒で終わる作業に変えられます。要件定義では、入力に何分かかるかを現場の目線で試算します。
入力に3分以上かかる項目は削る、という基準を設けます。この基準が、形骸化を防ぐ対策になります。項目設計は、機能要件であると同時に、定着のための運用設計でもあります。
連携要件とセキュリティ・非機能要件
機能要件を固めたら、外部システムとの連携と、セキュリティや性能などの非機能要件を整理します。商談管理システムは、マーケティングや会計などの周辺システムとつなぐことで効果が高まります。ただし、RFPに連携要件がないと、会計と連携できないなどの手戻りが起こります。
非機能要件も定義しておけば、各社の提案を同じ条件で比べられます。
MA・会計・基幹システムとの連携要件
連携要件は、次の4項目をRFPに具体的に書き出します。
- 連携先：対象となるシステム名
- 連携データ：受け渡すデータ項目
- タイミング：リアルタイムかバッチか
- 方式：API、CSVなど
MAと連携すれば、マーケティングが獲得したリードを、営業へ商談として自動で渡せます。そのため、リード獲得から受注後の育成までが一本の流れになります。
たとえば、エレコムがSFAとMAの連携で受注率を約1.75倍に高めた事例は、この連携の効果を示しています。
受注時に会計システムへ請求情報を送る仕組みを要件に含めると、二重入力やデータ不整合を防げます。
連携先のAPI仕様や制約は、事前に確認しておく必要があります。連携できると思っていた周辺システムに、APIがない場合もあるためです。
発注側がRFPでベンダーに実現可能性を検証させておくと、開発後半の大きな手戻りを防げます。
セキュリティ・性能・権限の非機能要件
商談管理システムは顧客情報や取引条件を扱うため、セキュリティ要件を次の4項目で明記します。
- アクセス権限：営業は自分の案件、マネージャーは全案件を閲覧できる設定など
- 認証：ログイン認証の方式
- 暗号化：通信データと保存データ
- 操作ログ：取得するログの範囲
Excel管理時代のセキュリティ上の弱さを解消するには、権限の設計も欠かせません。これらを要件として明記しておくと、各社の提案の品質を同じ基準で比べられます。
性能要件では、想定する同時アクセス数とデータ量を定めます。レスポンス速度や可用性（稼働率）も、あわせて要件にします。数値で示しておくと、提案の品質を比べられます。
Excelの動作が重い、同時編集できないといった限界は、システム化で乗り越えます。特に、性能要件は現場の使い勝手に直結します。
将来のユーザー増や機能追加を見据えて、拡張性も要件に含めます。さらに、非機能要件をどれだけ具体的に書くかで、提案の精度が変わります。
データ移行・名寄せ要件と推進体制
見落とされやすいのは、既存データの移行と、導入を推進する体制に関する要件です。データを正しく移行できなければ、システムを初日から使えません。
システムの成果は、導入後に定着させる体制によって決まります。そのため、RFPには移行要件と推進体制の両方を盛り込みます。
Excel・名刺台帳からの移行と名寄せ要件
Excelの案件表や名刺台帳に分かれたデータを統合し、重複や表記揺れを整理します。RFPには、次の4点を明記します。
- 移行対象：対象にするExcelや名刺台帳の範囲
- 表記揺れ：名寄せの方針
- 重複データ：統合ルール
- 移行後：データの検証方法
たとえば、同じ取引先が「株式会社A」「（株）A」「A社」と登録されていると、移行後に商談が重複し、状況を正確につかめません。
手帳やローカルPCに保存されたデータも、どこまで取り込むかを要件として整理します。
名寄せには工数がかかるため、誰が、いつまでに、どの基準で行うかを明確にします。そのうえで、移行前に取引先マスタを確定し、表記ルールを定めます。
その後は、各営業のデータを照合・統合する段取りも、RFPに含めます。特に、移行を軽視すると、システムが「汚れたデータの置き場」になるおそれがあります。移行の質は、導入初日のシステムの信頼性を左右します。
定着を支える推進体制とアドミニ育成の要件
最後に、定着を支える推進体制を要件に組み込みます。社内で目的を共有し、運用を支える体制を、RFPに含めます。
- 段階的な導入：スモールスタートで効果を検証する進め方
- 運用支援：マニュアルの提供範囲
- 管理者育成：管理者向けトレーニングの有無
- 導入後支援：サポート体制の内容
アドミニストレーター（システム管理者）の育成も含めて、ベンダーが定着まで伴走できるかを尋ねます。
また、自社側の役割も明記しておきます。導入責任者、現場教育の担当者、入力と評価制度の結び付け方は、自社で設計する必要があります。
導入後の運用と定着まで要件定義で描くことが、約80%が失敗すると言われるSFA導入の落とし穴を避ける鍵になります。
riplaはフルスクラッチ受託と国内開発の立場から、要件整理、移行、定着まで一貫して支えられるよう伴走し、現場で使われる商談管理システムの実現を支援します。
まとめ
RFP・要件定義書は、まず方式を選ぶところから始まります。そのあとは、営業プロセスへの適合と項目設計、システム連携と非機能要件へと進み、最後にデータ移行と推進体制を定めます。
予算は、SaaSの月額1,680円〜30,000円/ユーザーと、スクラッチの小規模開発300万〜800万円を踏まえて設定します。また、入力負荷の軽減、名寄せ、定着体制も、導入を成功させる要点です。
要件は、機能を網羅するよりも、自社の営業プロセスとデータの実態から絞るほうが大切です。逆に、曖昧な要件のままベンダーに任せると、形骸化するシステムができあがります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、現場へのヒアリングによるAsIs/ToBeの可視化から移行・定着まで一貫して支援します。
要件定義の前に全体像を整理したい方は、完全ガイドをご活用ください。
▼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を創業。