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

CRM（顧客関係管理）の導入を本格的に進める段階で避けて通れないのが、要件定義とRFP（提案依頼書）の作成です。どんなに高機能なCRMでも、自社が何を実現したいのか、どんな業務プロセスに合わせるのかを明確にしないまま選定や開発に入ると、現場に合わないシステムができあがり、誰も使わない状態に陥ります。Gartnerの調査でSFA導入企業の約80%が失敗するとされる背景には、この要件定義の甘さが大きく関わっています。

本記事は、CRM導入のための要件定義書・RFPの作り方を、発注企業の視点から実務に即して解説する「要件定義特化」の内容です。SaaS型を選ぶかスクラッチ開発するかの判断、自社の営業・顧客対応プロセスへの適合要件、入力負荷を抑える項目設計、MAや会計との連携要件、そしてExcelや名刺台帳からの移行（名寄せ）要件まで、RFPに盛り込むべき観点を順に整理します。なお、CRMの定義や費用相場、機能の全体像をまだ把握していない方は、まずCRMの完全ガイドから読むことをおすすめします。

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

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

CRMの要件定義で最初に向き合うべき分岐が、既製のSaaS型を導入するか、自社専用にスクラッチ開発するか、という選択です。この判断を曖昧にしたまま進めると、後工程で大きな手戻りが発生します。RFPの冒頭で、自社の業務がどれだけ標準的か、既製品の枠に収まるかを整理し、選定の前提を明確にしておくことが重要です。

選定要件を整理するうえで、コスト構造の理解は欠かせません。SaaS型CRMの料金相場は月額1,680円から30,000円程度とユーザー単位で、無料プランを持つ製品もあります。具体的には、Salesforce Sales Cloudが3,000円から、HubSpot CRMが無料（有料Starterは月2,400円から）、Zoho CRMが1,680円から、kintoneが780円からといった価格帯です。SaaS型は初期費用を抑えて始められる一方、ユーザー数が増えるほど月額が積み上がる構造です。

一方、スクラッチ開発は初期に開発費がかかりますが、ライセンスの月額が積み上がらず、自社の業務に完全に合わせられます。RFPでは、想定ユーザー数と利用年数を前提に、SaaS型の累計コストとスクラッチの初期投資を比較できるようにしておくことが大切です。ユーザー数が多く長期利用する場合や、独自業務が多い場合は、スクラッチの方が結果的に有利になることもあります。予算は単年ではなく、複数年の総コストで捉える要件設計が判断の精度を高めます。

たとえば、GENIEE SFA/CRMは10ユーザーで月額34,500円からといった料金設定で、これを5年使うと単純計算で200万円を超えます。ユーザー数や利用年数が増えれば、SaaS型の累計コストはさらに膨らみます。一方、スクラッチ開発の受託相場は規模により幅がありますが、小規模なものでおおむね300万円から800万円程度が目安です。両者を同じ土俵で比べられるよう、RFPには想定ユーザー数と利用想定年数を必ず明記しておきます。

コスト比較で見落としがちなのが、SaaS型でも独自業務に合わせるためのカスタマイズ費や、連携・初期設定の費用がかかる点です。月額の安さだけに目を奪われると、後から積み上がる追加費用で総額が読めなくなります。RFPの段階で、ライセンス費だけでなく、初期構築費・カスタマイズ費・移行費・運用保守費まで含めた総所有コスト（TCO）を各社に提示させる要件にしておくと、見かけの安さに惑わされず正しく比較できます。

SaaSかスクラッチかは、コストだけでなく、自社の業務が既製品の枠にどれだけ収まるかで判断します。RFPに自社の独自業務、たとえば特殊な会員ランク制度や、業界特有の承認フロー、複雑な料金体系を書き出し、それらが既製品の標準機能やカスタマイズで実現できるかをベンダーに問う構成にします。標準機能で収まるなら、過度なカスタマイズで複雑化させるより、シンプルなSaaS型を素直に使う方が定着します。

逆に、独自業務が多く、既製品に無理やり合わせると入力項目が膨れ上がって形骸化を招くようなら、スクラッチを検討すべきサインです。riplaはフルスクラッチ受託と国内開発の立場から、まず業務を可視化し、本当にスクラッチが必要な領域と既製品で足りる領域を切り分ける支援を重視しています。RFP段階で「自社のどこが標準的で、どこが独自か」を明確にしておくことが、選定の軸を定め、ベンダーから的確な提案を引き出す前提になります。

適合度を見極めるうえで、リプレイスを検討している企業はとくに注意が必要です。すでに導入したCRMが形骸化している場合、別の製品に乗り換えるべきか、現行を再構築すべきかという判断が要ります。過度なカスタマイズで複雑化したシステムは、無理に使い続けるよりも、いったん要件を棚卸しし、本当に必要な機能だけにそぎ落として巻き直す方が定着します。RFPには、現状のどこが使われ、どこが死んでいるかを書き出し、新システムで引き継ぐ機能と捨てる機能を切り分ける要件を含めると、二の轍を踏まずに済みます。

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

CRM要件定義の核心は、自社の営業・顧客対応プロセスにシステムをどう適合させるか、という点にあります。多くの失敗は、自社のプロセスを無視して既製品の標準フローをそのまま押し付けた結果、現場が使いづらさを感じて入力をやめることから始まります。RFPには、自社が今どんなプロセスで顧客と向き合っているかを正確に記述し、そのプロセスをシステムでどう支えるかを要件として落とし込む必要があります。

適合要件を固めるには、まず現状の業務フロー（AsIs）を可視化することから始めます。リード獲得から初回接触、商談、受注、受注後のフォローまで、誰がどの段階で何をしているかを書き出します。そのうえで、CRMを入れたらどう変えたいのか、あるべき姿（ToBe）を描きます。AsIsとToBeを並べて比較することで、システム化で解決すべき課題が明確になり、要件の優先順位がつけられます。

この工程を飛ばして、いきなり機能要件のリストを作ろうとすると、現場の実態とかけ離れた絵に描いた餅になりがちです。riplaはフルスクラッチ受託と国内開発の立場から、開発に入る前に現場ヒアリングを徹底し、AsIs/ToBeを描き直す進め方を重視しています。受注担当、営業、サポート、経理といった関係者に実際の業務を聞き取り、どこに無駄や手戻りがあるかを把握することが、現場に使われる要件定義の出発点になります。

適合要件の中でも、CRMの成否を直接左右するのが入力項目の設計です。CRMが形骸化する最大の原因は、入力負荷の増大による事務作業化です。あれもこれもと項目を増やすと、1件の登録に時間がかかり、現場は入力を後回しにし、やがてデータが入らなくなります。RFPでは、入力必須項目を最小限に絞り、本当に意思決定に使う情報だけを残す、という項目設計の方針を明記すべきです。

具体的な要件としては、必須項目と任意項目を明確に分ける、自動取得できる情報は手入力させない、AIによる音声入力など入力を省力化する仕組みを検討する、といった観点が挙げられます。SFA満足度調査では導入済み企業の55%が課題を解決していないと回答していますが、その多くは入力が運用に乗らないことに起因します。「現場が無理なく入力を続けられるか」を要件の中心に据えることが、形骸化を防ぐ最も実践的な対策になります。

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

CRMは単体で完結するものではなく、既存の他システムと連携してこそ効果を最大化します。RFPには、CRMとどのシステムを、どの方向に、どんなタイミングで連携させたいかを具体的に記述する必要があります。連携要件が曖昧だと、導入後に「このデータがつながらない」という問題が頻発し、二重入力の手間が残ってしまいます。

連携要件の中でも効果が大きいのが、MA（マーケティングオートメーション）との連携です。MAが獲得・育成した見込み顧客の情報をCRMへ引き継ぎ、リード獲得から商談、受注、受注後の育成までをシームレスにつなぐことで、効果が最大化されます。RFPには、MAのどのデータ（リードスコアや行動履歴など）をCRMに渡し、CRM側でどう活用するかを具体的に書き込みます。

連携の威力を示す事例として、SFAとMAを連携させて見込み顧客を部門横断で把握し、受注率を約1.75倍に高めたケースが報告されています。要件定義の段階で、自社のリード獲得から受注後までの流れのどこに断絶があるかを洗い出し、そこをつなぐ連携を優先的に要件化することが、投資対効果を高めます。連携は「できたらいい」ではなく、成果に直結する中核要件として位置づけるべきです。

連携と並んで見落とされがちなのが、既存データの移行要件です。多くの企業は、Excelの顧客リストや紙の名刺台帳、個人PCに眠るデータからCRMへ移行します。RFPには、どのデータを、どんな形式で、どれくらいの量、いつまでに移行するかを明記し、移行作業の責任分担をベンダーと取り決めておく必要があります。移行を軽視すると、汚れたデータごと引っ越してしまい、CRMが稼働初日から使いものにならなくなります。

移行要件の肝は、データクレンジング（名寄せ）です。「株式会社A」と「（株）A」のような表記揺れや、複数ファイルに散らばった重複データを統一する作業を、移行計画に必ず組み込みます。会社名だけでなく住所や電話番号で同一顧客を突き合わせ、自動判定できないケースは人の目で確認する、といった具体的な手順まで要件化しておくと安心です。移行は単なるデータの運搬ではなく、データをきれいにする工程だと捉え、RFPで明確に要件化することが、CRM稼働後の品質を決定づけます。

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

選定の前提が整ったら、それをRFP（提案依頼書）という一つの文書に落とし込みます。RFPは、自社が何を実現したいかをベンダーに伝え、各社から比較可能な提案を引き出すための共通の土台です。書き方が曖昧だと、各社がばらばらの前提で見積もりを出し、提案の優劣を正しく比べられなくなります。ここでは、RFPに盛り込むべき構成と、提案を評価しベンダーを選ぶための基準を整理します。

RFPには、まず自社の背景と目的を記し、なぜCRMを導入したいのかを明確に伝えます。続いて、対象とする業務範囲（スコープ）を具体的に書きます。どの部門の、どの業務を、どこまでシステム化するのかを線引きしないと、ベンダーごとに想定範囲がずれ、見積金額が大きく食い違います。スコープを明示することが、比較可能な提案を引き出す第一歩です。

あわせて、機能要件と非機能要件を分けて記載します。機能要件は案件管理や活動記録といった「何ができるか」、非機能要件はセキュリティや可用性、想定ユーザー数といった「どう動くべきか」です。さらに、希望する導入スケジュール、想定予算のレンジ、自社とベンダーの役割分担、運用開始後のサポート体制まで盛り込みます。体制要件を最初に明示しておくと、稼働後の責任の所在が曖昧になる事態を防げます。

RFPを各社に渡したら、返ってきた提案を共通の評価軸で採点します。価格だけで選ぶと、安くても自社業務に合わない、あるいは導入後の支援が薄いベンダーを掴んでしまいます。評価軸は、要件への適合度、価格、導入実績、サポート体制、開発・運用の進め方など複数を設け、それぞれに重みをつけて総合点で比べる構成にすると、判断がぶれにくくなります。

とくに重視したいのが、自社の業務を理解したうえで提案しているか、という観点です。標準機能の説明に終始する提案よりも、自社のAsIs/ToBeを踏まえて「ここは標準で足り、ここは作り込むべき」と切り分けて示すベンダーの方が信頼できます。riplaはフルスクラッチ受託と国内開発の立場から、まず業務を可視化し、既製品で足りる領域とスクラッチが要る領域を切り分けて提案する進め方を重視しています。約80%が失敗するとされるCRM導入では、価格表ではなく「自社をどこまで理解しているか」をベンダー選定の中心軸に据えることが、選定の精度を高めます。

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

要件定義は、システムを作って終わりではなく、導入後に定着させて使い続けるところまで見据えるべきです。Gartnerの約80%失敗という数字が示すように、CRMは作ることより使い続けることのほうが難しいからです。RFPには、導入後の運用体制やサポート、教育まで含めた要件を盛り込むことで、稼働後に放置されるリスクを下げられます。

定着を見据えた要件として有効なのが、スモールスタートの前提を組み込むことです。最初から全機能・全部門で一斉導入するのではなく、効果の大きい一部の機能や部門から始め、現場が使えると実感してから広げる進め方です。RFPには、最小限の機能で早期に稼働させ、段階的に拡張していく構成を要件として記述すると、初期の負担を抑えつつ定着を確認しながら進められます。

段階導入の要件を設けることで、もし途中で想定と違う部分が見つかっても、軌道修正がしやすくなります。一度に大きく作り込んでから現場に渡すと、合わなかったときの手戻りが致命的になります。直感的なUIで現場が迷わず使えること、最初は小さく始められることを要件に含めることが、形骸化を避ける実践的な備えになります。定着は要件定義の段階から設計するものだと捉えてください。

CRMを定着させるには、社内で運用を主導する担当者、いわゆるアドミニストレーターの育成が欠かせません。RFPには、運用マニュアルの提供や、アドミニ育成のための支援、現場向けの操作教育まで、ベンダーにどこまで支援してもらうかを要件として明記します。システムを渡されただけで自走できる組織は多くないため、教育・サポートの要件は定着の生命線になります。

riplaはフルスクラッチ受託と国内開発に加え、導入後の運用に伴走する立場から、作って終わりにせず、現場に定着するまで支える進め方を重視しています。要件定義の段階で、稼働後の問い合わせ対応、改善要望への対応、データ品質の維持といった運用面まで視野に入れておくことが、約80%が失敗するとされるCRM導入で生き残るための備えになります。要件定義書とRFPは、導入のゴールではなく、定着までの設計図として作るべきものです。

運用体制の要件を固めると同時に、社内で投資を承認してもらうための稟議材料も、要件定義の延長として準備しておくと進みが速くなります。稟議では、月額や開発費といった投資額に対して、どれだけの効果が見込めるかを数字で示すことが求められます。たとえば「月額◯円×◯名の利用で、1人あたり月◯時間の入力・集計作業を削減し、人件費換算で年間◯円の効果」「受注率が数%向上すれば投資を◯年で回収」といったモデルケースを、自社の数値に当てはめて作ります。

効果の根拠には、公開されている導入実績を引くと説得力が増します。SFAとMAを連携させて受注率を約1.75倍に高めた事例のように、具体的な数字を自社の見込みと結びつけて示すと、経営層が判断しやすくなります。要件定義で整理したAsIs/ToBeは、そのままROIシミュレーションの土台になります。何の業務がどれだけ楽になるかを要件段階で押さえておけば、稟議の数字も後から作るのではなく、要件から自然に導けます。導入後の効果検証にも同じ指標を使えるため、要件定義とROI設計は一体で進めるのが得策です。

まとめ

CRMの要件定義・RFP作成を振り返ると、押さえるべき柱は、SaaSかスクラッチかの選定要件、自社プロセスへの適合要件、MAや会計との連携要件、データ移行・名寄せの要件、そして定着・運用体制の要件です。AsIs/ToBeを可視化して自社のプロセスを正確に捉え、入力負荷を抑える項目設計を中心に据え、移行を単なる運搬ではなくデータをきれいにする工程として要件化する。これらを丁寧に積み上げることが、Gartnerの約80%失敗という現実を回避する道筋になります。

要件定義で大切なのは、機能の網羅ではなく、自社の業務から逆算して本当に必要なことを過不足なく定義し、定着までを設計に織り込むことです。RFPは選定のための文書であると同時に、導入後に現場で使われ続けるための設計図でもあります。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングからの要件整理と、導入後の定着まで一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社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を創業。