RFPの書き方まとめ｜ RFIとの違いや記載すべき項目、注意点も紹介
2024.10.23
RFPの書き方まとめ｜ RFIとの違いや記載すべき項目、注意点も紹介
RFPとは
RFP（Request for Proposal）とは、日本語で「提案依頼書」を指し、企業がシステム開発やプロジェクトを外部のベンダーに依頼する際に使用される文書です。RFPには、プロジェクトに関する以下のような情報が明示されています。- 目的
- 要求事項
- 予算
- スケジュール など
RFPの目的
RFPの目的は、発注企業がベンダーに対して具体的なニーズや要件を明確に伝え、自社に最適な提案を引き出すことです。 RFPを作成せずに口頭や簡易的な依頼のみでベンダーに依頼した場合、発注企業とベンダーの間で認識のズレが発生しやすく、プロジェクトの目的や要件が正しく伝わらない可能性があります。また、要件の抜け漏れが発生し、後になって追加要件が必要になると、プロジェクトの進行に遅延が生じたり予算が大幅に超過したりする恐れもあるでしょう。 RFPを作成することで、発注企業は各ベンダーからの提案を比較・評価しやすくなり、認識のズレや要件の抜け漏れの発生も防げます。RFIとの違い
RFPと似た言葉としてRFIがありますが、明確な違いがあります。RFIは「情報提供依頼書」と訳され、ベンダーから提供可能なサービスやソリューションに関する情報を収集するために用いられる依頼文書です。 具体的には、各ベンダーの技術力や対応可能なソリューション、導入実績などを記載し、依頼見込みのあるベンダーへRFPを提示するという使い分けがされます。 このように、RFIが情報収集段階で使用されるのに対し、RFPはプロジェクトの要件が確定した段階で使用されます。RFPの記載項目と書き方
RFPの記載内容自体に明確な要件はありません。そのうえで、一般的にRFPに記載されている項目として以下の13点があげられます- 概要・プロジェクトの全体像
- プロジェクトの背景
- 現在抱えている課題
- プロジェクトの目的
- プロジェクトのゴール
- 委託する範囲・スコープ
- 会社概要
- 現在のシステムの状況
- 機能要件
- 非機能要件
- プロジェクトのスケジュール
- プロジェクトの体制
- 予算・概算費用
1.概要・プロジェクトの全体像
RFP（提案依頼書）の最初に記載する「概要・プロジェクトの全体像」では、プロジェクトの目的や内容に関する全体的な情報を簡潔にまとめます。 概要を読んだベンダーが、RFPに記載されている内容を瞬時に理解できるようにしましょう。2.プロジェクトの背景
「プロジェクトの背景」では、プロジェクトを実施する必要性や経緯を説明します。企業が直面している課題や現状のシステム、業務プロセスの問題点を具体的に記載しましょう。 また、プロジェクトを通じて目指したい理想の状態についても触れておくと、ベンダーの理解も深まります。3.現在抱えている課題
「現在抱えている課題」では「プロジェクトの背景」で記した課題や問題点を、具体的な業務や機能面などに落とし込み、解決してほしい点を明確にします。 たとえば「企業の規模が大きくなり、現状のシステムでは顧客からの問い合わせに対応しきれない」というプロジェクトの背景があげられたとします。この時、具体的な課題としては「複数人で同時編集ができない」「管理されているデータの視認性が悪い」といった点があげられるでしょう。 必要に応じて課題を箇条書きで整理すると、ベンダーにとっても要点をつかみやすい文書を作成できます。4.プロジェクトの目的
「プロジェクトの目的」では、プロジェクトを通じて達成したい最終的な目標や成果を記載します。プロジェクトの背景や現在抱えている課題を踏まえ、具体的に何を解決し、どのような結果を得たいのかを示すことが重要です。 また、目指している企業体制や、課題を解決できる機能などの目標がある場合、そちらも明記しておくとベンダーもプロジェクトの成功をイメージしやすくなるでしょう。5.プロジェクトのゴール
「プロジェクトのゴール」では、以下の3項目ごとに、プロジェクトを通じて達成すべき定量的な指標を設定します。- 品質（Quality）
- 費用（Cost）
- 納期（Delivery）
6.委託する範囲・スコープ
「委託する範囲・スコープ」では、プロジェクトにおいてベンダーに委託する具体的な業務範囲や責任の範囲を定義します。これにより、ベンダーが担当する部分や期待されている成果を理解しやすくなり、プロジェクトを円滑に進行できます。 たとえば、システム開発プロジェクトの場合、システムの設計や開発、導入支援といった業務のうち、どのフェーズまでをベンダーに依頼するのか記載しましょう。また、ハードウェアの調達や設定、関係各所への人材教育、マニュアル作成など、システム導入以外の部分でも明確に業務範囲を設定するのがポイントです。7.会社概要
「会社概要」では、発注企業の基本情報や事業内容をベンダーに理解してもらうために、重要な要素を記載します。記載する情報には以下のような項目があげられます。| 記載する情報 | 概要 |
| 会社名 | 正式な社名 |
| 業種 | 企業が行っている事業の業種 |
| 事業内容 | 提供している製品やサービス |
| 所在地 | 本社および主要拠点の所在地 |
| 設立年 | 会社の創立年 |
| 従業員数 | 全社およびプロジェクトに関連する部門の従業員数 |
| 売上規模 | 最近の年度における売上高や経営状況の指標（任意） |
8.現在のシステムの状況
「現在のシステムの状況」では、RFPを作成した発注企業が、現在使用しているシステムの詳細な情報を記載します。現行システムの全体像をベンダーに把握してもらえるよう、以下の情報を記載しましょう。- 使われている業務システムやアプリケーション
- システムの主な機能
- 利用中の技術やプラットフォーム（クラウドやSaaSなど）
- 利用者数
- システムの規模
- システムの連携状況 など
9.機能要件
「機能要件」では、プロジェクトで導入するシステムやサービスに求められる具体的な機能を定義します。たとえば、企業の基幹システムを作成するプロジェクトの場合、財務管理機能や在庫管理機能、顧客分析機能など、備えてほしい機能を提示します。 そして、各機能の内容についても、必要な操作や処理されるデータなどを具体的に記しましょう。既存システムの連携や操作性、使いやすさ（UI/UX）などの要望がある場合、忘れず言及することが重要です。10.非機能要件
「非機能要件」では、システムのパフォーマンスやセキュリティ、可用性など、機能以外に必要とされる品質面での要求を明確にします。主に言及すべき非機能要件としては以下の5点があげられます。| 記載する情報 | 概要 |
| パフォーマンス要件 | システムに必要な処理能力や応答速度 |
| 可用性要件 | システムが維持すべき稼働率 |
| セキュリティ要件 | データの保護やアクセス制御、暗号化、認証プロセスなどのセキュリティ基準 |
| 拡張性（スケーラビリティ） | 将来的なシステムの拡張やユーザー数の増加への対応可否 |
| 運用・保守性 | システムの保守やアップデートへの対応 |
11.プロジェクトのスケジュール
「プロジェクトのスケジュール」では、プロジェクトの進行における主要なマイルストーンと、それぞれの完了期限を記載します。 実際にRFPを作成する際には、まずプロジェクトの開始日と完了予定日を設定しましょう。その後、要件定義や設計の完了日、システムテストの開始日など、プロジェクトにおける重要なマイルストーンをリストアップし、各フェーズにかかる期間を明示します。 また、各フェーズで発生するタスクや成果物、対応する担当者についても言及しておくと、スムーズなプロジェクト進行が期待できます。12.プロジェクトの体制
「プロジェクトの体制」では、プロジェクトの実施における組織構造や関係者が果たすべき具体的な役割と責任を記載します。具体的には、以下のように主要な参加者をリストアップし、彼らが担う役割を明示しましょう。- プロジェクトマネージャー
- 各部門のリーダー
- 技術担当者
- ベンダー側の主要メンバー など
13.予算・概算費用
「予算・概算費用」では、開発されたシステムの初期費用やランニングコストに充てられる予算、総額と内訳について記載します。 これにより、提案依頼を受けたベンダーが適切なコスト見積もりを行い、発注企業の予算に合った提案を行いやすくなります。RFP作成時のポイント・注意点
RFPを作成する際のポイントや注意点として以下の3点があげられます。- 部署や役職をこえて意見・要望を集める
- プロジェクトの課題や目的を明確に伝える
- RFP提出後の要件追加は極力避ける
1.部署や役職をこえて意見・要望を集める
RFPを作成する際には、部署や役職をこえて意見や要望を収集しましょう。社内で使用するシステムの導入はさまざまな部署や関係者が関わるため、それぞれの視点を反映した要件を盛り込むことが重要です。 現場のニーズや実務的な課題を正確に把握しておくと、より具体的かつ適切なRFPを作成し、ベンダーへ提案できるようになります。2.プロジェクトの課題や目的を明確に伝える
RFPには、プロジェクトで解決したい課題や最終的な目標を具体的に記載し、正確にベンダーへ伝えましょう。そのためには、発注企業が自社の課題を把握し、目指すべき理想像を理解する必要があります。 課題や目標の伝達が曖昧だと、ベンダーとの認識にズレが生じ、最終的な成果物が期待と異なるものになりかねません。こうしたトラブルを発生させないためにも、RFPを通してベンダーと認識をすり合わせておくことが重要です。3.RFP提出後の要件追加は極力避ける
RFPを提出した後の要件追加は、極力避けましょう。 ベンダーはRFPの内容にもとづいて人員体制や費用を見積もり、提案や受注を行っています。そのため、提出後に要件を追加すると、あらためて工数や予算、スケジュールの見直しが必要になり、プロジェクト全体の進行に大きな支障を来す恐れがあります。 RFPを作成する段階から、社内関係者と十分な協議を行い、要件漏れや不備がないように努めましょう。営業管理や部門間の情報共有に課題を感じるなら『GENIEE SFA/CRM』
『GENIEE SFA/CRM』は、営業管理や部門間の情報共有といった課題を解決するために設計された、SFA（営業支援システム）およびCRM（顧客管理システム）ツールです。商談の進捗管理や顧客情報の管理など、営業活動を支援する数多くの機能を有しています。 また、RFP（提案依頼書）の仕様書サンプルを数多く用意しており、システム導入を検討する企業がRFPを作成する段階から手厚い支援が可能です。RFPの作成に不安を感じていたとしても、効率的にシステム導入プロセスを進められるでしょう。 『GENIEE SFA/CRM』の詳細を知りたい方は、以下より資料請求や15日間の無料トライアルを行い、比較検討の参考にしてみてください。 ＞＞「GENIEE SFA/CRM」の資料請求はこちら ＞＞「GENIEE SFA/CRM」の無料トライアルはこちらRFPの書き方を把握して最適なシステムを導入しよう
RFPは、自社のシステム開発を外部のベンダーに依頼する際に作成・共有される文書です。プロジェクトの全体像や目的、要件などが盛り込まれており、ベンダーはRFP内の情報を参照することで、発注企業に対して適切な提案を行います。完成度の高いRFPを作成できれば、自社の課題解決だけでなく、将来的な業績向上も実現できるでしょう。 『GENIEE SFA/CRM』は定着率99%を誇る国産のSFA/CRMです。営業業務を支援するツールとして多くの企業から支持を受けています。また、RFPの作成からサポートも可能であり、支援実績も多数抱えています。詳細は資料請求や15日間の無料トライアルで確かめられるため、まずは使い勝手をお試しください。 ＞＞「GENIEE SFA/CRM」の資料請求はこちら ＞＞「GENIEE SFA/CRM」の無料トライアルはこちらSFACRM
03-5909-8187