【Wordサンプル付き】RFPに必要な項目とは?書き方を分かりやすく徹底解説!

TOP » ブログ一覧 » システム調達 » 【Wordサンプル付き】RFPに必要な項目とは?書き方を分かりやすく徹底解説!
RFP Wordサンプル アイキャッチ画像

RFP(提案依頼書)とは、システム開発やリプレイスなどを委託したい企業が、発注先候補のベンダーに対して依頼内容や要件を正しく伝えるための資料ですが、「何を書けばいいのかよく分からない・・・」と書き方に迷われている方も多いのではないでしょうか。

 

そこで今回は、システム開発を委託するベンダーの選定に向けてRFPを作る必要があるものの、どのような内容を書くべきか分からないという方に向けて、具体的な例文サンプルをご用意しました。

また、本記事の内容と連動したシステム開発向けRFP(提案依頼書)のWordサンプルもダウンロードいただけますので、ぜひ雛形としてご活用ください。

目次

1.RFP(提案依頼書)とは?

RFP(提案依頼書)とは「Request for Proposal」の略で、企業がシステム開発やリプレイスなどを依頼する際に、ベンダーから自社に合った最適な提案を受けるために発注側企業が作成する文書のことです。

 

RFPには、システム構築にあたって必要な機能要件はもちろんのこと、プロジェクトを通して解決したい自社の課題や実現したい理想の姿などをまとめて記載します。

ベンダーは受け取ったRFPの記載内容にしたがって提案書や見積書を作成し、発注側企業は複数のベンダーから出された提案内容を比較・評価して、最終的な発注先の選定を行います。

RFP 誰が作成

なお、RFPの作成が必要な理由やメリットについては、以下の記事にて詳しく解説しておりますので、こちらも併せてご参照ください。

2.RFPの目的

RFPを作成する最大の目的は、発注側の依頼内容を候補先のベンダーに対して漏れなく正確に伝えることにあります。

 

発注側が要件をきちんと文書化せずに口頭だけの説明にとどめてしまうと、発注側とベンダー側双方の認識の食い違いや要件の抜け漏れが発生しやすくなり、ベンダー側から的を射た適切な提案を受けられなくなってしまいます。

また、RFPが無いと複数ある発注先候補のベンダーに対して平等に情報を提供できず、各社から予算、手法、期間などが大きく異なる提案が寄せられて比較・評価をしにくくなってしまうというデメリットも生じます。

 

このような状況を防ぐためには、「今○○という課題を抱えており、その解決のために○○の機能が欲しい」といった要件について、ベンダー各社による解釈違いが起こらないようしっかりと文面に書き起こし、発注側の意向を正しく反映した提案書を作成するようRFPを通してベンダー側に働きかける必要があるのです。

3.RFPの項目ごとの書き方

RFPには特に決まったフォーマットはありませんが、以下のような目次構成で作成すると上手くまとめることができます。

rfp-contents-structure

ここからは、RFPにはどのようなことを記載する必要があるのか、項目ごとに詳しく見ていきましょう。

①全体の概要

自社の現状や解決したい課題、プロジェクトで目指すべきゴールについてベンダー側に伝える部分です。

表紙

自社の会社名とプロジェクト名を記入し、何についてのRFP(提案依頼書)か明記します。

顧客管理システム導入プロジェクト提案依頼書(RFP)

YYYY年mm月dd日

株式会社AAA

本書の概要

読み手が本格的に読み進める前に全体感をつかめるよう、RFPの位置付けや記載内容を簡潔にまとめます。

現在、当社では顧客管理を適切に行うことによる営業効率の向上を目指し、顧客管理システム導入のためのプロジェクトを立ち上げております。

 

本書(提案依頼書/RFP)では、貴社が提供可能なご支援内容について取り纏めていただく際に参考となるよう、本プロジェクトについての背景や目的、機能要件、具体的にご提案いただきたい内容について記載しています。

 

当社では、貴社からの提案書をもとに本プロジェクトの発注先選定を行わせていただきます。

プロジェクトの背景

なぜそのプロジェクトを立ち上げることになったのか、背景が分かるように記載します。

当社では、従来エクセルで顧客管理を行ってきましたが、顧客からの問い合わせ増加(月150件程度)に伴い、対応の遅延によるクレームが度々発生しており、受注率も減少傾向にあります。

 

このような現状を踏まえ、手作業による現業務のシステム化を目的として○○年○○月に顧客管理システム導入プロジェクトが発足しました。

現状の課題

現在抱えている主な課題について記載します。

必要に応じて箇条書きにしたり、業務フロー図を交えたりしながら説明すると、読み手により伝わりやすくなります。

ヒューマンエラーの多発
現在は顧客情報を一元管理できるシステムがなく、エクセルを使ってすべて手動でデータ入力、更新、削除を行っています。そのため、顧客数の増加に伴いヒューマンエラーが多発しています。

 

複数人での共有や同時編集が難しい
エクセルで顧客情報を管理しているため、ある担当者が顧客情報を更新している最中に、別の担当者が同じ情報を更新することができないという問題があります。

 

データのセキュリティが不十分
エクセルで顧客情報を管理しているため、セキュリティに関する機能が限られており、データの不正アクセスや漏えい、改ざんのリスクがあります。

 

データの可視性が低い
エクセルで顧客情報を管理しているため、グラフィカルなレポートを即座に作成することが難しく、データの傾向を一目見て直感的に把握しづらい状態となっています。

システム化の目的

プロジェクト発足の背景や現状の課題を受けて、何のためにシステム化を行うのか明確な目的を記載します。

この目的をどれだけ明確にできるかがプロジェクト成功の鍵を握っているといえます。

上記背景および課題を踏まえて、株式会社AAAではシステム化の目的を以下のように設定しました。

 

・顧客管理の自動化による業務効率の向上およびヒューマンエラーの軽減

・データのセキュリティ強化による情報漏えいやデータ紛失の防止

・データ可視性の向上による意思決定の迅速化

・情報共有の円滑化によるチームコラボレーションの促進

ゴール・目標

プロジェクトが目指すゴールを記載します。

ゴールは、「品質(Quality)」「費用(Cost)」「納期(Delivery)」ごとに、なるべく定量的な指標を設定しましょう。ベンダー各社から想定通りの提案を受けやすくなり、プロジェクト終了後に具体的な数値に基づいて成果を評価できるようになります。

 

なお、費用(Cost)欄には自社のプロジェクト予算を明記しても良いですが、ベンダー各社からの提案が「コストありき」になってしまう可能性があります。

幅広く質の高い提案を集めたいなら、あえて予算を記載しないという選択肢もありますので、状況に応じて書き分けると良いでしょう。

品質(Quality)

・現状の課題をすべて解決できること

・50名が同時にアクセスして、全画面における検索、保存、更新処理が3秒未満で完了すること

・システム稼働日に、新顧客管理システムを使う全社員が使い方を十分理解している状態であること

 

費用(Cost)

・見積金額以内でプロジェクトを完了すること

 

納期(Delivery)

・YYYY年mm月dd日までにシステムを本格稼働させること

スコープ

プロジェクトのうち、ベンダー側に提案を依頼したい範囲を記載します。

システム開発だけで良いのか、IT機器の購入や保守も含むのかなど、スコープ(範囲)を明確化しておくことで、提案の精度向上につながります。

・顧客管理システムの開発・導入

・サーバー、ネットワーク、PC端末など、必要なIT機器の購入・設置・設定

・新業務フローの定義

・操作マニュアルの作成

・関係各所への導入教育

・新システムの運用・保守体制の確立

発注側の会社・組織情報

発注側企業の会社概要(代表者・所在地・設立・資本金・売上高・従業員数・事業内容・組織図など)を記載します。

必要に応じて自社ホームページへのリンクを掲載したり、会社パンフレットを添付したりしても良いでしょう。

会社名:株式会社AAA(HP:https://www.aaa.co.jp/)

代表者:代表取締役 ○○

所在地:東京都千代田区丸の内×-×-×

設立:○年○月

資本金:○○億円

売上高:○○億円

従業員数:○○人

事業内容:○○の製造、販売

組織図:図を添付

システムの利用者情報

新システムの使用者(運用管理者、社内利用者)情報を記載します。
システムの刷新・リプレイスを依頼する場合は、既存システムの使用者情報も併せて記載しておきます。

一部の部門のみで使われるシステムであれば、対象部門名や人数を記載しましょう。

新システムの利用者

(1)運用管理者
○○部 ○○名

(2)社内利用者
○○部 ○○名(契約社員、パート、アルバイト含む)

現在のシステム構成

新システムの導入による既存システムへの影響範囲を明確にするため、現行のシステム構成を記載しておきます。必要に応じて図式化するとより分かりやすくなります。

現在は、Excelを使用して顧客情報を管理しています。
社員の各PCにExcelがインストールされており、それぞれのデバイス上で顧客情報を編集しています。

これらのデバイスは社内ネットワークに接続されており、共有フォルダを通して顧客情報が各関係者に共有されています。

RFP システム構成図

現状のIT資産

現在社内で使用しているPCやサーバーなどのIT資産を種類別にリストアップします。

ハードウェアは台数とスペック、ソフトウェアは名称やバージョン情報を記載します。

サーバー(10台)
Windows Server 2016を搭載

クライアントPC(70台)
機種:Lenovo X280 OS:Windows 10

Microsoft Excel(※すべてのクライアントPCにインストール)
名称:Excel 2016 バージョン:16.0

②提案依頼内容

提案書を作成する上で具体的に盛り込んでほしい情報は何か、ベンダー側へ伝える部分です。

ベンダー側の会社・組織情報

ベンダーの会社情報や開発実績、提供可能なサービスに関する情報の提示を求めるRFI(Request For Infomation)の作成を省略し、RFPのみで発注先の選定を行う場合は、ここでRFIの代わりにベンダー側に対して情報開示を依頼します。

ご提案の内容に関連するすべての会社、組織の明示をお願いします。

プロジェクト内の一部の役割に再委託がある場合は、その相手先、内容も明示してください。

提案システム概要・構成

ベンダー側から提案してもらうシステムについて、どのような形で情報の提示をお願いするか記載します。

【概要】

・ご提案いただくシステムの機能一覧を明示してください。

・ご提案いただくシステムの概要がわかる機能関連図を明示してください。

・主要機能の画面キャプチャを提示してください。

・他社製品に対する優位性や、特に当社に適合する点があれば補足をお願いします。

 

【構成】

・ご提案いただくシステムのハードウェアとネットワーク構成図を明示してください。

・システムを構成するハードウェアのスペック情報を明示してください。

・オンプレ型かクラウド型か、サービスの利用体系を明示してください。

機能要件

システムに必要な機能は何か、どのような機能を実装して欲しいのか、具体的な要件を記載します。

なお、詳しい機能要件は発注後の要件定義フェーズでベンダー側とすり合わせを行いますが、RFPにもできるだけ機能要件を記載しておいた方が提案の精度は高まります。

以下の機能要件を満たす顧客管理システムのご提案をお願いします。

 

1.顧客情報の一元管理機能

・顧客情報を一覧で表示し、編集・削除・新規登録ができる機能が必要

・顧客情報には、会社名、部署名、氏名、メールアドレス、電話番号を含む必要がある

・顧客情報には、顧客の属性情報や商談履歴も含められるようにする必要がある

 

2.顧客情報の検索・抽出機能

・顧客情報を複数の条件で検索できる機能が必要

・検索条件には、会社名、部署名、氏名、属性情報、商談履歴が含まれる必要がある

・検索結果をエクセル形式で出力できる機能が必要

 

3.顧客情報の履歴管理機能

・顧客情報の変更履歴を保存し、過去の情報を参照できるようにする機能が必要

・変更履歴には、変更内容と実施者、実施日時などを含める必要がある

・変更履歴を表示する機能が必要

 

4.システム連携機能

・システムから登録された顧客に対して、自動的にメールを送信できる機能が必要

・他の社内システムとのデータ連携ができる機能が必要

・他社が提供するAPIを用いて、外部システムとデータを共有できる機能が必要

非機能要件

システムの性能・可用性やセキュリティなど、機能要件に含まれない部分に関する要求事項を記載します。

以下の非機能要件を満たす顧客管理システムのご提案をお願いします。

 

1.可用性

・システムは24時間365日稼働し、最小限の停止時間でメンテナンスを実施できること

・システムの故障時には、適切なエラーメッセージを表示し、ユーザーに対処方法を提供すること

・システムには冗長性を持たせ、一時的な障害が発生してもデータの損失がないこと

 

2.セキュリティ

・システムは、一定のセキュリティレベルを確保するために、認証、認可、暗号化などのセキュリティ機能を備えること

・システムは、内部および外部からの脅威に対する適切な防御策を持ち、攻撃があった場合にはログを取り、追跡できること

・システムは、データの保護を確保するために、バックアップと復旧機能を備えること

 

3.拡張性

・システムは、顧客数の増加に対応できるように設計されていること

・システムは、新しい機能やモジュールの追加が容易であること

・システムは、将来的な要件の変更に対応できるように柔軟性を持っていること

 

4.パフォーマンス

・システムは、一定のユーザー数において快適なレスポンス時間を保証すること

・システムは、データ処理の効率性を確保するために最適化されていること

・システムは、システムの負荷を分散することができるスケーラビリティを持っていること

 

5.ユーザビリティ

・システムは、直感的で使いやすいインターフェースを備えていること

・システムは、適切な説明文を提供し、ユーザーが迷わないようにすること

・システムは、エラーメッセージが分かりやすく、ユーザーに対処方法を提供すること

プロジェクトのスケジュール

発注先の決定から要件定義、開発、テスト、リリースに至るまでの全体のスケジュールを明示してもらいます。

プロジェクトを遂行する中で自社がどのように関わっていくのか、自社で発生する具体的なタスクは何か、全体像が分かるように明示してもらうことがポイントです。

・週単位での全体スケジュールを明示してください。

・全体スケジュールの中で発生するタスクをすべて明示してください。
なお、個々のタスクの担当(貴社・当社・委託先など)が分かるように記載をお願いします。

プロジェクトの体制

上記の全体スケジュールと併せて、プロジェクトをどのような体制で進めていく予定なのかについても明示してもらいましょう。

特に、プロジェクトの成功はプロジェクトマネージャーの手腕に大きく左右されることが多いため、プロジェクトマネージャーの経歴は忘れずに明示してもらうと良いです。

・プロジェクトに参画する全メンバーとその役割について明示してください。
現時点で確定していないメンバーに関しては「未確定」とし、役割についてはすべてを網羅するようにお願いします。

・プロジェクトマネージャーの方の経歴が分かる資料の提示をお願いします。

成果物

ベンダー側との間で納品物の内容に認識のズレがあると、後からトラブルに発展しかねませんので、ここで納品を希望する成果物をあらかじめ明記しておきます。

納品して欲しいドキュメントが決まっていない場合は、納品物の内容や形態を一覧で提示してもらうようにしましょう。

 

また、納品されたドキュメントが使い物にならない・・・という事態を避けるためにも、過去のサンプルを提示してもらい納品物の品質をチェックしておくと良いでしょう。

納品を希望する成果物の一覧は次の通りです。

可能であれば、以下成果物のうち3~5点ほどドキュメントサンプルの提示をお願いします。

 

・要件定義書

・基本設計書

・詳細設計書

・WBS

・ソースコード一式

・テスト仕様書

・テスト結果・証跡

・リリース手順書

・運用・操作マニュアル

・社内研修用資料

・各種会議体の議事録

サポート体制

納品・本稼働後のサポート・運用体制に関する項目です。

システムに障害が発生して業務に影響があった際にどのような対応を行ってもらえるのか、しっかりと確認しておくことが重要です。

システム本稼働後のサポート体制、窓口の受付時間と対応フロー、緊急時窓口、SLAなどを明示してください。

また、緊急時に業務へ支障を与えない運用方法についても明示をお願いします。

概算費用

概算費用の見積については、金額の妥当性が判断できるよう、初期費用、月額費用別にそれぞれ内訳を明示してもらうことがポイントです。

・初期費用は、システム開発費用、機器購入費用、ユーザー教育費用などの項目別合計金額とその内訳がわかるように明示してください。

・月額費用は、システム保守費用、ネットワーク費用、サポート費用などの項目別単価とその内訳がわかるように明示してください。

制約事項

同時アクセス数やデータベースの登録上限数といったシステム上の制約事項がリリース直前に見つかると、スケジュール遅延や追加費用の発生などの問題につながりかねないため、提案するシステムの制約事項はあらかじめ明示してもらいましょう。

今回のプロジェクトに関して、現時点で明らかな制約事項やリスクを提示してください。

契約内容

システム開発の場面では、曖昧な要求や口約束、認識の相違を原因としたトラブルが発生するケースが非常に多くなっています。

こうしたトラブルの発生を未然に防ぐためにも、著作権や知的財産権等の取扱い、検収・支払条件、契約不適合責任、再委託、機密保持といった契約内容はしっかりと明示してもらうようにしましょう。

契約内容と支払い方法について明示をお願いします。

項目別に契約内容・支払い方法が異なる、または複数回に分けて支払いが発生する場合は、そのことがわかるように明示してください。

③発注先ベンダー選定の進め方

ベンダー各社から提案書をもらった後に、どのような手順で発注先の選定を進めるのか、スケジュールや評価基準などを伝える部分です。

選考スケジュール

自社が想定しているベンダー選定スケジュールを記載します。

 

一般的に、RFPの公開から提案書の提出期限までは2~3週間程度の期間が必要になりますが、システムの規模や複雑さによってはさらに検討期間が必要になるケースもあります。

ベンダー側の意向も反映しつつ、スケジュールを柔軟に調整することがポイントです。

発注先の選定にあたり、以下のスケジュールを予定しております。

日程に不都合がございましたら、あらかじめ希望する日程をご連絡ください。

 

1.YYYY年mm月dd日:RFP公開

2.YYYY年mm月dd日~YYYY年mm月dd日:RFPに対する質問・回答

3.YYYY年mm月dd日:提案書締め切り

4.YYYY年mm月dd日~YYYY年mm月dd日:提案書の内容精査、提案プレゼン

5.YYYY年mm月dd日~YYYY年mm月dd日:提案内容に対する質問と回答

6.YYYY年mm月dd日~YYYY年mm月dd日:社内合意

7.YYYY年mm月dd日:選定結果の通知

8.YYYY年mm月dd日~YYYY年mm月dd日:発注手続き

9.YYYY年mm月dd日:プロジェクト開始

提案書の提出先・提出締め切り

誰に、いつ、どのような方法で提案書を提出すれば良いのか記載します。

なお、提案書の提出期限に間に合わない場合は「選考対象外」となる旨をあらかじめ伝えておくことで、プロジェクトのスケジュール維持や納期の厳守といった観点において、より信頼性の高いベンダーを抽出するのに役立ちます。

本RFPに基づき取り纏めいただいた貴社が提供可能なご支援内容に関する提案書については、電子ファイル形式で以下の宛先までご提出をお願いします。

 

株式会社AAA

担当部門名:○○部 担当者名:○○

メールアドレス

 

なお、提案書のご提出はYYYY年mm月dd日17:00厳守でお願いします。

期限を過ぎてもご提出いただけない場合、選定対象外とさせていただく場合がございますので、あらかじめご了承ください。

評価基準

選定時に何を重視して評価するのか、自社の評価ポイントを記載します。

評価基準が明確になっていることで、ベンダー各社も発注側の意図に沿った提案を行いやすくなります。
自社にマッチした提案を数多く受けられるように、事前に評価項目を策定してRFPに明記しておきましょう。

貴社から頂いた提案につきましては、以下の観点から評価を実施する予定です。

 

1.要件に対する適合性

・本RFPに記載の要件をすべて満たし、運用に必要十分な機能を有していること

・機能の追加等が短期間・低コストで実現できるような拡張性の高いものになっていること

・直感的なインターフェースと操作性を備え、ユーザビリティの高いものになっていること

・システムおよびデータの信頼性、可用性、保全性が高いものになっていること

・データの情報漏えいや改ざん等が起きにくい機密性の高いものになっていること

 

2.サポート・運用体制の充実性

・障害発生時に、迅速に復旧できる体制が整っていること

・ユーザーが問題を迅速に解決できるよう、マニュアルやFAQ、ヘルプデスクサポートが充実していること

 

3.マネジメント評価

・プロジェクトの全体スケジュールが妥当であること

・今回のプロジェクトの位置付けを正しく認識していること

・プロジェクトマネージャーの経歴が十分であること

・プロジェクトに参画するメンバーの資質・能力・業務への理解度が十分であること

・プロジェクト全体で発生するタスクについて、その内容と責任範囲が明確になっていること

 

4.価格評価

・初期費用および月額費用の見積金額が妥当であること

・初期費用、月額費用別にそれぞれ内訳が明確になっていること

 

5.ベンダー評価

・貴社の事業継続性、安定性が十分であること

・貴社に豊富な技術経験や過去実績があること

4.RFP作成の際に意識したいポイント

最後に、RFPを作成する際のポイントを2つご紹介します。

プロジェクトの目的・背景を明確にする

RFPの作成にあたり最も重要なのが、「システムを使って何を実現したいのか?」「どのような課題を解決したいのか?」という本質的な部分を突き詰め、プロジェクトの目的・背景を明確にすることです。

 

システム化の目的を明確にしないままプロジェクトを進めてしまうと、

「完成したシステムが思っていたものと違う」

「せっかく導入したのに全然使われないシステムになってしまった」

など、巨額の費用を投じてどうにかこうにか推し進めたシステム導入が失敗に終わることになりかねませんので、こうしたトラブルを未然に防ぐためにも、ベンダー側と目的・ゴールを共有してしっかりと認識を合わせておくことが重要です。

様々な立場の人から幅広く意見をヒアリングする

新システムの導入は、少なからず社内で現在利用している他システムへ影響を及ぼすため、RFPを作成する際は経営層、管理職、ユーザー部門など、社内の様々な立場の人から話を聞き、意見を集めるようにしましょう。

 

特に、実際にシステムを利用する現場の声は漏れなくピックアップしたいところです。

ユーザー部門の担当者にもRFP作成から参画してもらうことで、現場にプロジェクトへの当事者意識が芽生え、その後の工程でも協力体制を組みやすくなります。

5.まとめ -RFPのWordサンプルダウンロードはこちらから

いかがでしたでしょうか?

 

冒頭でもお伝えした通り、今回は「RFPの書き方が分からない」という方に向けて、本記事の内容と連動したシステム開発向けRFP(提案依頼書)のWordサンプルをご用意しました。

実際のプロジェクト内容に合わせて適宜カスタマイズしていただき、RFPの作成にお役立ていただければ幸いです。

「RFP作成に際して、専門家の視点から具体的なアドバイスが欲しい」

「RFPを作成してみたが、このまま公開に踏み切っても問題ないか不安を感じる」

・・・など、自社だけでRFPの作成を完結するのが難しいという企業様向けに、当社では「RFI/RFP伴走支援サービス」を行っております。

 

以下リンクより「RFI/RFP伴走支援サービス」に関する資料を無料でダウンロードすることができますので、興味のある方はぜひチェックしてみてください。

お電話・FAXでのお問い合わせはこちら

03-5828-7501

03-5830-2910

【受付時間】平日 9:00~18:00

フォームでのお問い合わせはこちら

この記事を書いた人

Y.M(マーケティング室)

2020年に株式会社コンピュータマネジメントに新卒入社。
CPサイトのリニューアルに携わりつつ、会社としては初のブログを創設した。
現在は「情シス支援」をテーマに、月3本ペースでブログ更新を継続中。