システム開発におけるRFP（提案依頼書）の作り方【サンプルあり】
2021.06.22
「システム開発をアウトソーシングするベンダーの選定に向けてRFP（提案依頼書）を作る必要があるものの、どのような項目を書けば良いのかわからない」
「RFP（提案依頼書）を作る際に押さえるべきポイントを、改めて確認したい」
このような方に向けて、本記事では、RFP（提案依頼書）を作成する目的をおさらいした上で、システム開発におけるRFP（提案依頼書）の作り方のポイントを解説していきます。すぐに使えるRFP（提案依頼書）サンプルもご用意しているので、ぜひご一読ください。
目次
システム開発向けRFP（提案依頼書）のWordサンプルを無償公開
システム開発でRFP（提案依頼書）を作成する目的とは？
システム開発におけるRFP（提案依頼書）の一般的な記載項目とは？
システム開発におけるRFP（提案依頼書）の作り方・書き方のポイントとは？
まとめ
※最終更新日：2023年12月19日（2021年6月に公開されたものを、最新情報を踏まえ編集部で校正・更新しました。
システム開発向けRFP（提案依頼書）のWordサンプルを無償公開
Word形式でご用意したシステム開発向けRFP（提案依頼書）のサンプルを、下記からダウンロードいただけます。いずれも編集可能ですので、貴社の具体的な状況に応じて内容を書き換えてご活用いただけます。
また、本記事の内容はサンプルで取り上げている内容と連動しているので、サンプルを参照いただきながら記事を読み進めていただくことでより理解を深めていただくことができます。
>>RFP（提案依頼書）サンプルをダウンロードする（Word形式）
システム開発でRFP（提案依頼書）を作成する目的とは？
システム開発において、RFP（提案依頼書）を作成する目的は、システムの新規開発やリプレイスをアウトソーシングするITベンダーを決める際、ITベンダーを客観的に比較検討するため複数社から提案を受けるためです。
IT技術は進歩を続け、AIや機械学習といった先進技術を活用している企業も増えつつあります。また、開発手法については従来のウォーターフォール型開発だけではなく、アジャイル型開発を採用する動きもあります。
このような状況で、「経理業務を効率化するためのシステムを開発したい」「既存の労務管理システムよりも運用工数がかからないシステムにリプレイスしたい」といった抽象的な要件を提示すると、それぞれの候補ベンダーが開発手法、開発期間、設計、予算などが大きく異なる提案を行ってくる可能性が高いです。
これでは、客観的な視点から適切に比較検討を行った上で最適な発注先ベンダーを見極めることが困難となってしまいます。
候補ベンダーには一定の制約の中で提案内容を検討してもらう必要があります。そのため、提案に先立ってできる限り要件を具体的に記載したRFP（提案依頼書）を提示することが欠かせません。
システム開発におけるRFP（提案依頼書）の一般的な記載項目とは？
RFP（提案依頼書）には、一般的に次の項目を記載します。
概要・基本情報
前提課題
ゴール
スコープ
成果物
機能要件
非機能要件
予算
スケジュール
提案に関する情報
契約に関する情報
各項目について、以降で詳しく解説していきます。
1.概要・基本情報
簡単な挨拶文を添えた上で、システム開発（あるいはリプレイス）プロジェクトの概要を説明します。あわせて、正式な社名や拠点所在地といった自社の基本情報も記載するのが一般的です。
2.前提課題
システムの新規開発あるいはリプレイスを検討するに至った前提課題を説明します。例えばある業務の効率化が課題である場合には、テキストによる説明のほか、現状の業務のどこがボトルネックとなっているのかをフロー図で示しておくと候補ベンダーの理解が深まります。
3.ゴール
システムを新規開発あるいはリプレイスすることで到達したいゴールを記載します。「ユーザー部門の時間外労働を10%削減する」「システム運用に関わるコストを20%削減する」といった定量的な数値で示しておくと、その後の候補ベンダーからの提案の解像度が高まるほか、実際に運用を開始した後に具体的な数値にもとづいて効果を検証しやすくなります。
4.スコープ
対象となっている業務のどの部分で、これから開発あるいはリプレイスするシステムを利用するのかを示します。業務の全容を示した上でプロジェクトのスコープ（対象）を明確化しておくことで、候補ベンダーが提案可能な範囲を限定することができ、提案の精度を高めることができます。
5.成果物
成果物の多寡は、ベンダー側が負うことになる設計、開発、運用それぞれ工数に大きな影響を与えます。そのため、あらかじめRFP（提案依頼書）に成果物を明記しておくようにしましょう。特に、実運用に際しての教育や研修で用いるマニュアルをクライアントと発注先ベンダーのどちらが作成するのかは認識のずれが生じやすいのでRFP（提案依頼書）段階から定義しておくことをおすすめします。
【主な成果物】
要件定義書
基本設計書
詳細設計書
テスト仕様書
WBS
運用マニュアル
など
6.機能要件
機能要件とは、これから開発あるいはリプレイスするシステムの機能や動作、振る舞いなどの定義を指します。具体的には、入力するデータの形式・構造や処理内容、操作方法、出力するデータの形式・構造や帳票のフォーマットなどが含まれます。
機能要件は、発注先ベンダー決定後の要件定義段階で決めていきます。とはいえ、提案依頼の段階ですでにある程度は必要とする機能が決まっているはずです。そして、RFP（提案依頼書）にそのような機能要件を記載しておいた方が、候補先ベンダーからの提案の精度が高まるので比較検討をしやすくなります。そのため、箇条書きで良いのですでに想定している機能要件を書き出しておくようにしましょう。
7.非機能要件
入力してからのレスポンスが遅く、業務が滞ってしまう
データ量が一定以上になると、エラーメッセージが返ってきてしまう
機能要件を満たしていたとしても、上記のような状況に陥ってしまってはシステムの開発やリプレイスによって業務効率化やコスト削減といったゴールに到達することはできません。
そのため、機能要件だけではなく非機能要件についてもRFP（提案依頼書）に記載しておく必要があります。非機能要件とは、端的には機能要件以外のすべてのシステム要件を指します。一般的には、IPA（※1）が定義している「非機能要求グレード」が用いられることが多いです。
具体的には、下記のような項目です。
性能・拡張性
セキュリティ
運用・保守性
移行性
可用性
システム環境・エコロジー
とはいえ、提案依頼の段階で上記すべての項目を想定することは困難な場合が多いです。また、そのシステムの内容によってはそもそも想定をする必要がない非機能要件もあります。そのため、特に提案あるいはその後の設計や開発で発注先ベンダーとの間で認識の齟齬が生じやすい非機能要件をRFP（提案依頼書）に記載しておきましょう。
特に、「運用・保守性」は齟齬が生じやすい非機能要件です。皆さんも、「導入後の運用保守をクライアントと発注先ベンダーのどちらが担うのかで揉めた」といった話を耳にしたことがあるのではないでしょうか？このようなトラブルを防ぐためにも、自社ユーザー部門や情報システム部門のリテラシーやリソースを鑑みた上で、運用保守をどちらが担う想定であるのかといったことを「運用・保守性」に含む要件の1つとしてRFP（提案依頼書）に記載しておきましょう。
その他、運用開始後の保守を発注先ベンダーに任せる場合には「運用・保守性」に含む要件の1つとして具体的な保守期間を記載しておくことが欠かせません。また、中長期的には運用保守を自社で行うという場合には、運用開始にあたって発注先ベンダーによる研修が必要になることがあります。そのような場合に備えて、研修やマニュアルなどのドキュメンテーションに関する要望も記載しておくと良いでしょう。
※1：独立行政法人 情報処理推進機構
8.予算
候補ベンダーから見ると、予算次第でそのプロジェクトのために構築可能な体制や投下できる工数が大きく異なります。そのため、「想定予算：〇〇万円〜〇〇万円」といった形で予算範囲を示しておくと良いでしょう。
一方で、予算を超えてしまうものの有益な提案を提示できるという候補ベンダーが存在するケースもあります。そういった候補ベンダーからの提案機会を確保するためにも、「予算を超過する場合には、提案書内でその理由を説明すること」といった注釈を設けておくと良いでしょう。
ただし、相場感がわからない場合にはあえて予算を記載しないことも選択肢の1つです。RFP（提案依頼書）で相場よりも高い予算を提示してしまった場合には、候補ベンダーから不必要に高い見積が含まれる提案を受けることになってしまう恐れがあるからです。
9.スケジュール
プロジェクト全体スケジュール
発注先ベンダー決定から要件定義、開発、検収、運用開始に至るまでのスケジュールを示します。詳しいスケジュールは、選定完了後に発注先ベンダーとの間ですり合わせることになります。そのため、この段階では「YYYY年MM月W週までに開発完了」といった粒度でスケジュールを示す程度で十分です。
ベンダー選定スケジュール
候補先の選定は、一般に下記のスケジュールで進みます。
| 一般的なベンダー選定スケジュール |
1.RFP（提案依頼書）公開
2.RFP（提案依頼書）に対する質問受付
3.RFP（提案依頼書）への回答
4.提案・見積提出
5.提案プレゼン
6.提案内容に対する質問と回答
7.選定結果の通知 |
RFP（提案依頼書）には、それぞれのステップの期間や期限を明記しましょう。
10.提案に関する情報
RFP（提案依頼書）の公開後は、候補ベンダーからの提案を待つことになります。期日までに必要な情報を抜け漏れなく提出してもらうために、RFP（提案依頼書）には下記のような情報を明記しましょう。
提出期限
提出先
データ形式
備考
11.契約に関する情報
一部のドキュメントについて二次利用料を請求された
運用開始後、ある機能に不具合が見つかったが、何ら対応をしてもらえなかった
このようなトラブルを防ぐために、RFP（提案依頼書）には契約に関する主に下記のような情報を記載しておく必要があります。
当社の権利
検収・支払条件
瑕疵担保責任
秘密保持契約
システム開発におけるRFP（提案依頼書）の作り方・書き方のポイントとは？
1.並行して評価シートを作成する
RFP（提案依頼書）提示後、候補ベンダーはその内容にしたがった提案を行います。そして、クライアントは提案内容を客観的に評価した上で最終的な発注先ベンダーを決める必要があります。
各候補ベンダーが行った提案への評価は、点取表や○×表を作成して各項目あるいは提案全体の評価を定量化するのが一般的です。限られた時間、限られた枚数の提案で評価項目を漏れなくチェックするには、提案の前提となるRFP（提案依頼書）を、評価シートを意識した設計にしておくことが欠かせません。
そのため、RFP（提案依頼書）と評価シートは並行して作成を進める必要があります。また、評価シートは、特定のメンバーが作ったものを共有するのではなく、比較検討に関わるメンバー間で事前に項目のすり合わせを行った上で作り上げるようにしましょう。
2.専門用語や社内用語を多用しない
専門用語や社内用語が頻繁に用いられているRFP（提案依頼書）が少なくありません。このようなRFP（提案依頼書）をもとに提案を受けた場合、これまでに取引実績がある候補ベンダーへの評価が高まる傾向があります。彼らは過去の取引を通じて、すでにこうした用語への理解を深めているからです。
過去に取引実績がない候補ベンダーも含めて、あくまでも公平な視点で比較検討するのであれば、RFP（提案依頼書）では専門用語や社内用語を多用しないように留意しましょう。また、使用する場合には注釈を加えるといった方法で誰でもその用語の意味を理解できるように配慮する必要があります。
一方で、「本当に過去に類似案件の実績があるのか？」「自社が属する業界に精通しているのか？」といったことを見極める目的で、RFP（提案依頼書）であえて専門用語や社内用語を多用することもテクニックの1つです。
3.提示後もすべての候補先に同じ情報を開示する
RFP（提案依頼書）提示後には、候補先企業向けに説明会を実施することがあります。また、各社から電話やメールで寄せられた質問に対して個別に回答することがあるでしょう。
こうしたRFP（提案依頼書）提示後のやり取りで特に重要になるのは、提案日を迎えるまで、すべての候補ベンダーに対して同じ情報を開示することです。ある候補ベンダーだけが特定の情報を知っているという状態では、提案後に公平な評価を下すことが困難になってしまうのは明らかです。そのため、「説明会Aでの質疑応答で回答した内容は、説明会Bにも反映する」「各社からの問い合わせ内容と回答を、一定期間ごとにすべての候補先に開示する」といった候補ベンダー間での情報格差を防ぐ工夫が欠かせません。
まとめ
今回は、RFP（提案依頼書）について作成の目的や作り方・書き方のポイントを解説してきました。冒頭でご紹介したサンプルを活用していただきつつ、本コラムで解説した内容を参考にしてぜひRFP（提案依頼書）を作成してみてください。
一方で、システム開発をアウトソーシング先を選定するにあたって次のような課題を感じている方も多いのではないでしょうか？
「過去に取引実績がないベンダーからの提案も受けたいが、どのような手段で提案を依頼すれば良いのかわからない」
「開発したいシステムが特殊で、なかなか候補になるベンダーを見つけられない」
このような悩みをお持ちの方は、Ready Crew（レディクル）をご活用ください。Ready Crew（レディクル）は、完全無料のビジネスマッチングサービスです。
お客様のお悩みを丁寧に伺い、要件定義をサポート。 ヒアリングした内容をもとに、問題解決に最適な企業をご紹介します。
従来のビジネスマッチングサービスとは一線を画し、ご利用は最初から最後まで完全無料。相談料や、中間マージン、成果報酬などは一切いただきません。紹介する業者の押しつけもいたしませんので、お気軽にご相談ください。
※2：日本マーケティングリサーチ「2020年 12 月期 ブランドのイメージ調査」
この記事のタグ
提案依頼書
RFP
発注
システム開発
