CRMのRFP/要件定義書/提案依頼書について

CRM導入の要件定義とRFP作成は、業務の流れを書き出し、要件を整理し、評価基準を文書にする順で進めるのが基本です。この順に進めると、現場に定着するシステムの選定につながります。

CRMの定義・費用相場・機能は、CRMの完全ガイドで扱っています。

▼全体ガイドの記事
・CRMの完全ガイド

SaaS型かスクラッチ開発かの選定要件

SaaS型とスクラッチ開発を、初期費用や月額費用、独自業務への適合で対比した図
複数年の総コストもあわせて比べる構成です。

CRMの要件定義では、最初に既製のSaaS型を導入するか、自社専用にスクラッチ開発するかを判断します。ここが曖昧なまま進めると、後工程で大きな手戻りが起きます。

RFPの冒頭では、自社業務がどれだけ標準的か、既製品の枠に収まるかを書き出します。選定の前提がはっきりしていれば、各社の提案を同じ条件で比べられます。

予算とコスト構造を踏まえた選定要件

選定要件を整理するには、コスト構造を理解しておくことが欠かせません。方式によって料金の出方が違うため、料金や利用規模を方式ごとに比べます。

  • SaaS型:初期費用を抑えやすく、ユーザー数に応じて月額費用が積み上がる
  • スクラッチ開発:初期費用がかかる一方、月額ライセンスがなく独自業務に合わせられる
  • 総コスト:月額だけでなく、追加費用も含めたTCOで比べる

SaaS型CRMの料金相場は、ユーザー単位で月額780円から30,000円程度で、無料プランを持つ製品もあります。

Salesforce Sales Cloudは3,000円から、HubSpot CRMは無料です。有料Starterは月2,400円からで、Zoho CRMは1,680円から、kintoneは780円からです。

ユーザー数が多く長期に使う場合や、独自業務が多い場合は、スクラッチが有利になることもあります。なお、予算は複数年の総コストで捉えると、判断の精度が高まります。

たとえば、GENIEE SFA/CRMは10ユーザーで月額34,500円からです。これを5年使うと単純計算で200万円を超え、利用者や年数が増えるほど累計費用も膨らみます。

スクラッチ開発の受託相場は規模によって幅があり、小規模なものはおおむね300万円から800万円程度が目安です。

RFPには、想定ユーザー数と利用想定年数を明記します。各社には、総所有コスト(TCO)の内訳として、ライセンス費、初期構築費、カスタマイズ費を示してもらいます。加えて、連携・初期設定費、移行費、運用保守費も含めて提示してもらいます。

月額だけを比べると、後から積み上がる追加費用を含めた総額が読めなくなります。

既製品適合度を見極める要件

方式はコストだけでなく、自社業務が既製品の枠にどれだけ収まるかで判断します。そのうえで、RFPに独自業務を書き出し、標準機能やカスタマイズで実現できるかをベンダーに問います。

  • 独自業務:特殊な会員ランク制度や業界特有の承認フロー
  • 複雑な料金体系:既製品の標準機能やカスタマイズで実現できるかを確認
  • 現行CRM:使われている機能と使われていない機能を洗い出す

標準機能で収まるなら、過度なカスタマイズで複雑化させず、シンプルなSaaS型を使うほうが定着します。一方で、独自業務が多く、既製品に合わせて入力項目が膨れ上がる場合は、スクラッチを検討するサインです。

riplaは、フルスクラッチ受託と国内開発の立場から、業務の流れを整理し、スクラッチが必要な領域と既製品で足りる領域を分けて考える支援を重視しています。RFPで標準業務と独自業務を明確にすると、的確な提案を引き出せます。

適合度を見極めるとき、リプレイスを検討している企業は特に注意が必要です。導入済みのCRMが形骸化している企業は、別製品への乗り換えか、現行システムの再構築かを判断します。過度なカスタマイズで複雑化した場合は、要件を洗い出し、本当に必要な機能だけに絞るほうが定着します。

RFPでは、新システムに引き継ぐ機能と捨てる機能を分けて書きます。こうすると、同じ失敗を繰り返さずに済みます。

ポイント

SaaS型かスクラッチかは、初期費用や月額だけでなく、複数年の総コストと、自社業務が既製品の枠に収まるかで決めます。迷ったときは、この2点を各社の提案に当てはめて比べます。

営業・顧客対応プロセスへの適合要件

CRM要件定義で最も大切なのは、自社の営業・顧客対応プロセスにシステムを合わせることです。自社のプロセスを無視して標準のフローを押し付けると、現場が入力をやめることにつながります。

RFPには、現在の顧客対応プロセスと、そのプロセスをシステムでどう支えるかを具体的に記述します。

現状と理想を整理する業務フロー要件

適合要件を固めるには、現状と導入後の業務を順に整理し、課題と優先順位を明確にします。

  1. 現状の業務フロー(AsIs)を描き、リード獲得から初回接触、商談、受注、受注後のフォローまで、担当者と各段階の作業を書き出す。
  2. CRM導入後のあるべき姿(ToBe)を示し、AsIsと比べて、システム化で解決する課題と要件の優先順位を決める。

機能要件のリストを先に作ると、現場の実態とかけ離れた内容になりがちです。まず、受注担当や営業、サポートなどの関係者に業務を聞きます。経理など関係部門にも同じように聞き、無駄や手戻りを把握します。

riplaは、フルスクラッチ受託と国内開発の立場から、開発前に現場ヒアリングを行い、実際の業務に沿って要件を整理する進め方を大切にしています。

入力負荷を抑える項目設計の要件

入力項目の設計はCRMの成否を左右します。形骸化の最大の原因は、入力が負担になって事務作業化してしまうことです。

項目を増やすと、1件の登録に時間がかかります。その結果、現場が入力を後回しにして、データが入らなくなります。

現場が無理なく入力を続けられるよう、入力負荷を抑える要件をRFPで具体化します。

  • 項目の区分:必須項目と任意項目を明確に分ける
  • 情報の取得:自動取得できる情報は手入力させない
  • 入力の省力化:AIによる音声入力などの仕組みを検討する

SFA満足度調査では、導入済み企業の55%が課題を解決していないと回答しています。その多くは入力が運用に乗らないことに起因するため、入力を続けられるかを要件の中心に置くことが、形骸化の防止につながります。

ポイント

営業・顧客対応プロセスに合うかは、現状と理想の業務フローを並べ、課題と要件の優先順位を決められるかで判断します。現場が入力を続けられる設計かどうかも、同じ基準で見極めます。

MA・会計など他システム連携の要件

MAからCRMへ渡す情報と、データ移行で整理する表記揺れや重複データを示す図
連携情報の活用と顧客データの整理を並行して捉えられます。

CRMは単体で完結せず、既存システムと連携して効果を高めます。RFPには、どのシステムと、どの方向・タイミングで連携するかを具体的に記します。

連携要件が曖昧だと、導入後にデータがつながらず、二重入力が残る問題が起きます。

MA連携でリードをつなぐ要件

MA(マーケティングオートメーション)が獲得・育成した見込み顧客情報をCRMへ引き継ぐと、リード獲得から商談、受注、受注後の育成までをつなげられます。連携要件では、MAからCRMへ渡す内容と、その使い方を具体化します。

  • 連携データ:リードスコアや行動履歴など、MAからCRMへ渡す情報
  • CRMでの活用:引き継いだ情報をCRM側でどう使うか
  • 優先順位の高い箇所:自社の流れが途切れている場所を洗い出し、そこをつなぐ連携を先に定める

SFAとMAを連携し、見込み顧客を部門横断で把握して受注率を約1.75倍に高めた事例が報告されています。そのため、連携は成果に直結する中核要件として扱うことが、投資対効果を高めます。

データ移行・名寄せの要件

連携と並んで見落とされがちなのが、既存データの移行要件です。Excelの顧客リストや紙の名刺台帳、個人PCのデータからCRMへ移行する企業は多くあります。

RFPには、データの種類、形式、量を明記します。さらに、移行の期限と、移行作業の責任分担をベンダーと決めておきます。

移行を軽視すると、汚れたデータごと引き継いでしまい、CRMが稼働初日から使えなくなるおそれがあります。移行要件では、名寄せの手順を定めます。

  • 表記揺れ:「株式会社A」と「(株)A」のような違いを統一する
  • 重複データ:複数ファイルに散らばったデータの整理
  • 同一顧客の判定:会社名、住所、電話番号で照合し、自動判定できない場合は人が確認する

移行は、データを運ぶ作業ではなく、データをきれいにする工程です。RFPに具体的な手順まで書いておくと、CRM稼働後もデータの品質を保てます。

ポイント

連携とデータ移行は、導入後にデータがつながるかを左右します。そのため、接続先と連携の方向、移行の手順まで、RFPに具体的に書いておくことが基本です。

RFPの書き方と評価項目・ベンダー選定基準

RFPのベンダー提案を要件適合度、価格と実績、支援と進め方で評価するチェックリスト
価格に加えて、業務への適合と導入後の支援も見比べます。

選定の前提が整ったら、自社が実現したいことをRFP(提案依頼書)にまとめます。RFPは、各社から比較できる提案を引き出すための共通の文書です。

書き方が曖昧だと、各社の見積もり条件がばらつき、提案を正しく比べられません。そのため、構成と評価基準をそろえておく必要があります。

スコープと体制を明記するRFPの構成要件

RFPは、背景・目的から対象範囲、機能・非機能要件、導入・運用体制までをそろえて記載します。

  • 背景・範囲:導入目的と、対象部門・業務・システム化する範囲
  • 機能・非機能要件:案件管理・活動記録、セキュリティ・可用性・想定ユーザー数
  • 導入・運用体制:スケジュール、予算レンジ、役割分担、稼働後のサポート

対象範囲が曖昧だと、ベンダーごとに想定がずれて見積金額に差が出ます。そのため、スコープを明示することが、比較可能な提案を引き出す第一歩になります。

RFPに体制と役割を明示しておくと、稼働後の責任が不明確になる事態を防げます。

提案を比較する評価軸とベンダー選定基準

提案を受け取ったら、共通の基準で採点します。価格だけで選ぶと、自社業務に合わない、または導入後の支援が薄いベンダーを選ぶおそれがあります。

評価の観点を設け、それぞれに重みをつけて総合点で比べると、判断がぶれにくくなります。

  • 要件適合度:自社の業務要件に、提案が合っているか
  • 価格と実績:費用に加えて導入実績も見る
  • 支援と進め方:サポート体制、開発と運用の段取り

提案が自社業務をどこまで理解しているかも、比べるうえで欠かせません。AsIs/ToBeを踏まえ、標準機能で足りる部分と作り込む部分を分けて示す提案は、自社の状況に合っているかを確かめる材料になります。

riplaは、フルスクラッチ受託と国内開発の立場から、業務の流れを整理し、既製品で足りる領域とスクラッチが必要な領域を分けて提案する進め方を心がけています。

CRM導入は約80%が失敗するとされ、自社への理解を選定の中心に置くことが、判断の精度を高めます。

ポイント

各社の提案を同じ条件で比べられるかは、RFPの構成と評価の観点がそろっているかで決まります。価格だけで比べる前に、この2点を確かめます。

定着・運用体制を見据えた要件

要件定義では、導入後に現場へ定着させ、使い続けてもらうところまで見据えます。Gartnerの約80%失敗という数字が示すとおり、CRMは作ることより使い続けることの方が難しいためです。

RFPに運用体制、サポート、教育の要件を盛り込むと、稼働後に放置されるリスクを下げられます。

スモールスタートと段階導入の要件

定着を見据えた要件として有効なのは、スモールスタートを前提に組み込むことです。

  1. 全機能・全部門で一斉導入せず、効果の大きい機能や部門に絞り、負担を抑えて早期に稼働させる。
  2. 現場の定着を確かめながら、使えると実感した段階で機能や対象部門を広げる。

途中で想定と違う部分が見つかっても、段階導入であれば手直しできます。一方で、一度に作り込んで現場に渡すと、合わない場合の手戻りが大きくなります。

また、直感的なUIで現場が迷わず使えることも要件に含めます。小さく始める進め方と組み合わせると、形骸化を避ける備えになります。

アドミニ育成・教育・サポートの要件

CRMの定着には、社内で運用を主導するアドミニストレーターの育成が欠かせません。RFPには、ベンダーに求める支援範囲を明記します。

  • 運用マニュアル:提供を依頼する
  • 担当者育成:アドミニ育成の支援を求める
  • 現場教育:操作教育の範囲を定める

システムを渡されただけで自走できる組織は多くありません。そのため、教育とサポートの要件が、定着を大きく左右します。

riplaは、フルスクラッチ受託と国内開発に加えて導入後の運用にも伴走する立場から、現場に定着するまで支える進め方を重視しています。さらに、稼働後の問い合わせ対応、改善要望、データ品質の維持も要件に含めます。

要件定義書とRFPは、導入のゴールではなく定着までの設計図です。特に、約80%が失敗するとされるCRM導入では、運用面まで視野に入れることが備えになります。

社内で投資を承認してもらうための稟議材料も、要件定義と並行して準備します。稟議では、投資額に対して見込める効果を数字で示します。

たとえば「月額◯円×◯名の利用で、1人あたり月◯時間の入力・集計作業を削減し、人件費換算で年間◯円の効果」というモデルを、自社の数値に当てはめます。

また、「受注率が数%向上すれば投資を◯年で回収」というモデルケースも作ります。受注率の向上幅や回収年数は、自社の数値で検討します。

公開されている導入実績を効果の根拠にすると、稟議の説得力が増します。たとえば、SFAとMAの連携で受注率を約1.75倍に高めた事例があります。この事例のように、具体的な数字を自社の見込みと結びつけます。

要件定義で整理したAsIs/ToBeは、ROIシミュレーションの元になります。加えて、業務ごとの改善内容を要件段階で押さえると、稟議の数字を要件から導けます。

導入後の効果検証にも同じ指標を使えます。そのため、要件定義とROI設計は一体で進めます。

ポイント

要件定義は、導入後に現場が使い続けられるかまで見て決めます。小さく始められるか、教育とサポートの範囲が決まっているかが、定着を見極める手がかりになります。

まとめ

CRMの要件定義では、SaaS型かスクラッチかの選定と、自社プロセスへの適合を押さえます。さらに、MAなどとの連携、データ移行、定着・運用体制も要件に含めます。

AsIs/ToBeで業務の流れを整理し、入力負荷を抑える項目設計を中心に置きます。データ移行も、運搬だけでなくデータをきれいにする工程として扱います。

これらを丁寧に積み上げることが、Gartnerの約80%失敗という現実を避ける道筋になります。

必要な機能を並べ尽くすより、自社業務から必要事項を定め、定着までを設計に織り込むことが大切です。

RFPは選定のための文書であり、導入後に現場で使われ続けるための設計図でもあります。riplaは、現場ヒアリングから要件の整理、導入後の定着まで一貫して支援します。

全体像の確認には、あらためて完全ガイドをご活用ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。