RFP（提案依頼書）とは？システム開発で失敗しないための書き方と記載項目8つ
システム開発を外部の会社へ依頼しようと考えたとき、「複数社に声をかけたのに、提案内容も見積金額もバラバラで比較できない」という経験をされた方は少なくありません。その原因の多くは、発注側から開発会社へ伝えている情報がそろっていないことにあります。
この問題を解決する道具が「RFP（Request for Proposal：提案依頼書）」です。本記事では、RFPの役割から、記載すべき項目、作成時の注意点までを発注者の目線で解説します。
1. RFP（提案依頼書）とは
RFPとは、発注者が開発会社に対して「このような目的・条件でシステムをつくりたいので、提案と見積もりをください」と依頼するための文書です。
口頭やメールの断片的なやり取りだけで相談を始めると、開発会社はそれぞれ異なる前提を置いて提案を作ることになります。ある会社は最低限の機能で見積もり、別の会社は将来の拡張まで含めて見積もる、といったことが起こり、金額に数倍の差が出ることも珍しくありません。
RFPを用意して全社に同じ情報を渡すことで、提案の前提がそろい、内容と金額を公平に比較できるようになります。
RFPを作る3つのメリット
- 提案・見積もりを比較しやすくなる：前提条件が統一されるため、差が「会社の実力や考え方の違い」として見えるようになります。
- 社内の認識がそろう：RFPを書く過程で「そもそも何を解決したいのか」を関係者で議論することになり、社内の合意形成が進みます。
- 後工程のトラブルを防げる：最初に伝えた条件が文書で残るため、「言った・言わない」の行き違いを減らせます。
2. RFPに記載すべき8つの項目
RFPに決まった書式はありませんが、最低限次の8項目を押さえておくと、開発会社は精度の高い提案を出しやすくなります。
最も重要な項目です。「なぜ今このシステムが必要なのか」「導入によって何を実現したいのか」を書きます。たとえば「受注処理をExcelと電話で行っており、月末に担当者の残業が集中している。受注から出荷指示までを一元化し、月末の作業時間を半減させたい」といった具体性があると、開発会社は目的に合った手段を提案できます。
現在の業務の流れ、使っているツールやシステム、関わる部署や人数を整理します。業務フロー図があれば理想的ですが、箇条書きでも構いません。課題が現場のどこで発生しているかが分かると、提案の的外れを防げます。
今回の開発で「どこまでを対象にするか」を明記します。同時に「今回は対象外とするもの」も書いておくと、見積もりのブレを大きく減らせます。
必要な機能を一覧にします。この段階では詳細な仕様まで決める必要はありません。「必須」「できれば欲しい」「将来的に検討」のように優先度を付けておくと、予算に応じた提案を受けやすくなります。
利用者数、同時アクセス数、扱うデータ量、稼働時間帯、求めるセキュリティ水準、利用する端末（PC・スマートフォン）などです。機能以外の条件は見落とされやすい一方、費用に大きく影響します。分からない項目は「未定」と書き、提案の中で助言を求めても問題ありません。
会計ソフト、基幹システム、外部サービスなど、データをやり取りする必要があるシステムを列挙します。連携の有無と方式は工数に直結するため、分かる範囲で記載しましょう。
希望する稼働時期と、その理由（繁忙期前に稼働させたい、など）を書きます。予算についても、可能であれば目安を伝えることをおすすめします。予算を伏せると、開発会社は規模感をつかめず、過剰な提案や物足りない提案になりがちです。
提案書に含めてほしい内容（体制、スケジュール、見積もり内訳、保守の考え方など）、提出期限、問い合わせ窓口、選定の評価基準を記載します。評価基準を示しておくと、各社が重視すべき点を理解したうえで提案できます。
3. RFP作成でよくある失敗
| よくある失敗 | 起こりやすい問題 | 対策 |
|---|---|---|
| 機能の羅列だけで目的が書かれていない | 言われた機能を作るだけの提案になり、より良い手段が出てこない | 背景・目的を冒頭に明記する |
| 社内の一部門だけで作成する | 開発途中で他部署から要望が噴出し、追加費用が発生する | 実際に使う現場の担当者にも確認する |
| 最初から細かすぎる仕様を書く | 開発会社の知見を活かせず、手段が固定されてしまう | 「何をしたいか」を中心に書き、「どう作るか」は提案に委ねる |
| 対象外の範囲を書いていない | 会社ごとに想定範囲が異なり、見積もりが比較できない | 「今回はやらないこと」も明記する |
4. RFPを作る前の社内準備
RFPの質は、書き始める前の準備でほぼ決まります。次の3つを先に済ませておくと、作成がスムーズに進みます。
- プロジェクトの責任者を決める：最終的な判断を下す人が決まっていないと、RFPの内容が関係者の要望の寄せ集めになり、優先順位がつけられなくなります。
- 関係部署から課題と要望を集める：システムを使う部署、データを受け取る部署、管理する部署など、関係する部署に事前にヒアリングしておきます。
- 既存の資料を集める：業務マニュアル、使用中の帳票やExcelファイル、現行システムの画面などは、そのままRFPの添付資料として活用できます。
また、RFPを配布する際には、社外秘の情報が含まれることも多いため、必要に応じて開発会社と秘密保持契約（NDA）を結んでから渡すようにしましょう。
5. 要件が固まっていなくてもRFPは作れる
「まだ何を作るべきか決まっていないので、RFPは書けない」と考える方もいらっしゃいます。しかし、RFPは完璧な仕様書である必要はありません。背景・目的・課題・予算感・希望時期が書かれていれば、それだけでも十分に意味があります。
要件が固まっていない場合は、その旨を正直に記載し、「要件整理の段階から支援してほしい」と依頼するのも一つの方法です。いきなり開発の見積もりを取るのではなく、要件定義を先に切り出して依頼する進め方もあります。要件整理の進め方については、過去の記事「要件が固まっていなくても大丈夫？システム開発相談で最初に整理すべき5項目」もあわせてご覧ください。
6. RFPを渡した後の進め方
RFPを各社に配布した後は、次のような流れで進めるのが一般的です。
- 質疑応答：開発会社からの質問に回答します。ある会社への回答は、公平性のため他社にも共有するのが望ましいです。
- 提案書・見積書の受領：期限までに各社から提案を受け取ります。
- 提案説明（プレゼンテーション）：実際にプロジェクトを担当するメンバーから説明を受けると、相性や理解度を確かめやすくなります。
- 評価・選定：事前に決めた評価基準に沿って比較し、発注先を決定します。
評価の際は金額だけでなく、課題への理解度、提案の具体性、コミュニケーションのしやすさ、リリース後の保守体制なども含めて判断することが大切です。開発会社の選び方については「システム開発会社の選び方｜失敗しないための7つのチェックポイント」で詳しく解説しています。
7. まとめ
RFPは、開発会社から質の高い提案を引き出し、発注者自身が納得して発注先を選ぶための重要な文書です。記載すべき8項目をもう一度整理します。
- プロジェクトの背景と目的
- 現状の業務と課題
- システム化の範囲（対象外の範囲を含む）
- 求める機能と優先度
- 性能・セキュリティなどの条件
- 既存システムとの連携
- スケジュールと予算
- 提案依頼の内容と選定方法
最初から完璧を目指す必要はありません。まずは「なぜつくるのか」を言葉にすることから始めてみてください。
K-bridgeでは、RFPの作成前の段階からのご相談も承っています。「何から整理すればよいか分からない」という段階でも、お気軽にお問い合わせください。
要件が固まっていなくても、開発相談から始められます
現状の課題を整理し、優先順位と実行ステップを一緒に明確化します。
30分・無料・オンライン可