RFP（提案依頼書）の書き方を項目毎にわかりやすく解説！

RFP（提案依頼書）とは

RFP(RequestforProposal)とは企業がシステム開発を外部システム開発会社に依頼する際に、要件をまとめた書類です。おもに開発エンジニアを抱えていない企業が、システム開発を発注する際にRFPを作成します。

要件の具体例として、

• システム開発の背景と課題
• システム化の目的、ゴール
• 機能要件、非機能要件
• 予算
• スケジュール
• 契約にかかわる条件

を提示し、開発システム開発会社から提案を募集します。

要約するとRFPは「こんなシステムがほしいから、提案してください」とシステム開発会社に依頼するために要件をまとめた書類となっています。

RFI（情報提供依頼書）と要件定義書の違い

RFPとよく似た用語で、RFIと要件定義書があります。
それぞれの違いは以下のとおりです。

RFI（情報提供依頼書）との違い

RFI(RequestForInformation)とは情報提供依頼書と翻訳され、その名のとおり情報提供を依頼する書類です。
RFPが発注する際の必要書類であるのに対し、RFIは発注前の情報収集をシステム開発会社に依頼する書類となります。

企業はRFIを行うことで、

• ニーズを満たす開発の可否
• 予算規模

などの情報を得られます。

要するにRFIにより「こんなシステムは（いくらで）作れますか？」がわかります。

要件定義書との違い

要件定義書とは、これから構築するシステムの求められる機能や性能を明確にするプロセスであり、「〇〇できること」といったシステム要件を積み上げ、システムで実現したい項目を確認することができます。

一般的に要件定義書は受託システム開発会社決定後に、受注者が発注者にヒアリングを行う形で作成し、要件定義書により受注者と発注者の認識をすり合わせ、システム開発のトラブル防止が期待できます。

＞＞要件定義支援について詳細はこちら

RFP（提案依頼書）が必要な理由

なぜシステム開発にRFPが必要なのでしょうか？

RFPが必要な理由は、おもに以下3つです。

• システム開発会社に要望を正確に伝えられる
• システム提案を効率よく比較できる
• 価格競争が働き適正価格で開発できる

システム開発会社に要望を正確に伝えられる

RFPによりシステム開発会社に対し、要件や要望を正確に伝えることができます。

もし受注者に対しシステム開発を口頭で指示した場合、発注者のイメージと異なるシステムになる可能性が高くなるため、RFPを行うことで、お互いの認識の差を埋めトラブルを防止できます。

なお、曖昧な要件でシステム開発をスタートした場合、手戻りが発生し予想外のコストが発生することもあるため、注意が必要です。

システム提案を効率よく比較できる

RFPにより自社に最も合致したシステムを効率よく比較できます。
理由はRFPによる公募が、複数のシステム開発会社からの提案に繋がるからです。

複数のシステム開発会社から提案を受けることで、「コスト」「機能」「保守」などさまざまな項目を比較でき、自社の理想に近いシステム開発会社を選定することができるでしょう。

価格競争が働き適正価格で開発できる

RFPにより適正価格でのシステム開発が可能になります。
理由はRFPを行うことで、開発システム開発会社間で受注獲得のため適正な価格提示への力が働くからです。

RFPにより複数システム開発会社から提案を受けることは、システム開発費の適正化に繋がるでしょう。

RFP（提案依頼書）作成までの流れ

RFP作成までのステップは以下のとおりです。

• プロジェクトチームを編成
• 現状課題の把握と目的の明確化
• RFIの実施
• 機能要件書の作成
• RFPを作成し、プロポーザル参加事業者を募集

①プロジェクトチームを編成

まずはRFPのプロジェクトチームを編成しましょう。
情報システム部門とユーザー部門の間でプロジェクトチームを編成し、システム仕様や要件を定めます。

会計システムを例にすると、

• 契約を行う法務部門
• 予算編成や支払いを行う経理部門
• 伝票を作成し経費を使う営業部門

のようにシステムの利用ユーザーをプロジェクトチームに参画させることが重要です。

②現状課題の把握と目的の明確化

次に現状の課題を抽出し、システム開発の目的を明確にしましょう。
システム開発が「だれの」「どんな」課題をクリアするのか目的を明確にします。

課題を把握する際は、システムのユーザー部門にヒアリングを行うとよいでしょう。

③RFIの実施

システム開発の課題・目的が定まったら、RFIを実施し情報収集を行いましょう。
ヒアリング結果をまとめて、開発システム開発会社に「こんなシステムできますか？」と投げかけます。

このときRFIに興味を示したシステム開発会社からシステム要件に対し、「できる」「できない」の答えと見積書が返ってくるため、RFIの結果を参考に、RFPに向けての要件整理を行いましょう。

④機能要件書の作成

RFIの結果により、システム要件の実現性を把握した後、RFPに向けて機能要件書を作成しましょう。
機能要件書とはRFPで作成する文書のひとつですが、システム要件に特化して作成したものを指します。

この時、RFIで収集した情報を活かして要件を盛り込み、可能な範囲で多くのシステム開発会社が参加しやすい要件を心がけましょう。

⑤RFPを作成し、プロポーザル参加事業者を募集

最後にRFPを作成・提出しシステム開発の公募を行います。
RFP提出後は受託候補となるシステム開発会社に対し、RFPの内容を説明するオリエンテーションを開くのが一般的です。

オリエンテーションを通じて、システム要件などの説明を行い、受注候補者と認識のすり合わせを行うとよいでしょう。

なおRFPを提出した後は、

• 各社からの提案書・見積書を受領
• 提案書やプレゼンテーションをもとに受託システム開発会社の選定
• 受託システム開発会社と契約

というプロセスを経てシステム開発を行います。

RFPに記載するべき項目

実際に、RFPで記載するべき項目を説明します。

一般的にRFPでは以下の項目を記載します。

• 背景と課題
• システム化の目的
• ゴール、目標
• 対象範囲
• 機能要件
• 非機能要件
• 予算
• スケジュール
• RFP参加手続きにかかわる情報
• 開発にかかわる条件
• 契約にかかわる条件

①背景と課題

まずはシステム開発を行う背景と課題を明らかにします。
自社で抱えている問題や、システム開発の経緯を詳しく記載しましょう。

より具体的な記載で、開発システム開発会社は問題点を把握し、自社ニーズに合った提案が可能となります。

②システム化の目的

次にシステム開発の目的を記載します。
システム化によって解決したい目的を明確にしましょう。

「ペーパーレス化の実現」のように明確な目的を掲げることで、システム開発会社は適切なアプローチで提案できます。

③ゴール・目標

続いてシステム開発のゴール・目標を記載します。
先ほどの「システム化の目的」で定めたものを、どのように業務に活かすか明確にします。

具体的には、”作業効率を上げ、残業を40時間削減”のように、可能な限り定量的な目標を掲げましょう。

④対象範囲

続いてシステム化業務の対象範囲を記載します。

システム化業務の対象範囲とは具体的に、

• 要件定義
• 設計、開発、試験
• 環境構築
• データ移行
• マニュアル作成

など数ある工程の中で、どの部分の開発を委託するか定める必要があります。

⑤機能要件

続いて構築システムの機能要件を記載します。
機能要件とはユーザーが期待する機能や操作性のことです。

会計システムを例にすると、

• 支払伝票が作成でき、印刷できること
• 作成した伝票に決裁欄を設けること

このようにシステムに必要な機能を記載します。
このとき、必要な帳票一覧も提示しましょう。

⑥非機能要件

続いて構築システムの非機能要件を記載します。
機能要件と似ていますが、おもな違いはユーザーの見えない部分を対象にしている点です。

非機能要件ではおもに、

• 可用性
• 性能、拡張性
• セキュリティ
• 運用、保守

などを記載します。

⑦予算

続いて予算を記載します。
システム構築の上限予算を定め、システム開発会社からのオーバースペックな提案を防ぎます。

なお予算は、

• 開発費などのイニシャルコスト
• 運用保守などのランニングコスト

を分けて記載しましょう。

⑧スケジュール

続いてシステム開発のスケジュールを記載します。
スケジュールの明確化により、システム開発会社は人員などのリソース配分ができるため、より最適なコストでの提案が可能です。

なおスケジュールは、

• プロジェクト開始、完了
• 要件定義
• データ移行
• テスト

のように、工程ごとに目安となるスケジュールを記載しましょう。

⑨RFP参加手続きにかかわる情報

続いてRFP参加手続きにかかわる情報を記載します。

• 提案書の書式
• 見積書の要求事項
• 提出方法や期限
• 選定方法

などを明確に記載し、システム開発会社が応募方法で迷わないように案内しましょう。

なお、選定方法では採点基準を明記するとよいでしょう。

⑩開発にかかわる条件

続いて開発にかかわる条件を記載します。

具体的には、

• サービスレベル契約や品質管理に関する要件
• 機密情報の取り扱い
• 関係者とのコミュニケーション手段

など重要な条件を記載しましょう。

⑪契約にかかわる条件

最後に契約に関する情報を記載します。

具体的には、

• 契約形態（固定価格契約、時間単価など）
• 支払条件（前払い、出来高払い、分割払いなど）
• 契約解除に関する規定

などを明示します。

あらかじめ契約に関する条件を定めることで、システム開発会社はRFPへ参加しやすくなるでしょう。

RFPのよい書き方とダメな書き方のポイント

RFPを作成するうえで、よい書き方とダメな書き方のポイントを記載が難しい以下の項目に絞って説明します。

• 背景と課題
• ゴール、目標
• 対象範囲
• 機能要件
• 非機能要件
• スケジュール

①背景と課題

システム導入の”背景と課題”をシステム開発会社がイメージしやすいように記載しましょう。

（よい書き方）
現在の会計システムが老朽化しており、インボイス制度や電子帳簿保存法などへの対応が困難である。また決裁も紙ベースで行っており、業務効率が悪い。

（ダメな書き方）
現在の会計システムが古いため、新しいものにしたい。

②ゴール、目標

ゴール、目標は可能な限り定量的な目標を掲げましょう。

（よい書き方）
最新の税制および会計基準へ対応する。
ペーパーレス化を実現し、会計業務にかかる時間を30%削減する。

（ダメな書き方）
システムを新しくする。
ペーパーレス化を実現する。

③対象範囲

対象範囲は必要業務を具体的に挙げましょう。

（よい書き方）
データ移行：予算、勘定科目、債権者情報、固定資産
システム開発：ハードウェア調達や環境構築含む
研修：利用者やシステム管理者向けのマニュアル作成およびシステム操作研修実施

（ダメな書き方）
システム構築全般

④機能要件

機能要件には具体的な要件を記載しましょう。

また、”ユーザー補助機能”のように、何を指しているか不明瞭な記載は避けましょう。

（よい書き方）
伝票を部署、作成日、件名、伝票番号による検索が可能なこと。
伝票作成時に過去伝票を複写できる機能を設けること。

（ダメな書き方）
伝票を検索できる機能を設けること。
伝票作成のユーザー補助機能を設けること。

⑤非機能要件

非機能要件は定量的な指標がわかるように記載しましょう。

（よい書き方）
システムログインは同時に100ユーザーまで可能なこと。

（ダメな書き方）
同時に複数ユーザーが利用可能なこと。

⑥スケジュール

スケジュールは工程ごとに区切ったものを提示しましょう。

（よい書き方）
委託契約：令和7年1月から
要件定義：令和7年2月～令和7年3月
設計製造：令和7年4月～令和7年10月
テスト：令和7年11月～令和8年3月
本稼働：令和8年4月

（ダメな書き方）
令和8年4月までに稼働できること

サンプルのDLはこちら

RFPを行う際は、IPAのサンプルを参考にしてください。

https://www.ipa.go.jp/archive/digital/tools/ep/ep3.html

さいごに

本コラムでは、RFPの書き方について詳しく解説させていただきました。

しかし、本コラムで書かれているRFPの書き方の重要性は理解しているが、システム開発にかかわったことのない自分には、RFPの作成に心理的なハードルを感じる、といったお客さまが多くいらっしゃることも理解しております。

そのため、フレシット株式会社では、お客さまがRFPを作らずにシステム開発をお任せいただけるようなサービスを提供しております。

“RFPをどの様に作ったらよいかわからない！”というお客さまがいらっしゃいましたら、下記よりお気軽にお問い合わせをいただければと思います。