RFP（Request For Proposal、提案依頼書）は、システム開発を依頼するときに、ベンダーへ「何を実現したいのか」を伝える文書です。
ただし、発注する側がシステムの仕様をすべて決める必要はありません。
むしろ、技術やシステム設計に詳しくない状態で、画面構成、機能一覧、インフラ構成まで細かく決めてしまうと、本来もっと簡単な方法で解決できたはずの問題まで、その仕様に引っ張られることがあります。
RFPで大事なのは、まず次を言葉にすることです。
- 今、何に困っているのか
- 誰の仕事をどう変えたいのか
- 絶対に外せない条件は何か
- どのくらいの予算を考えているか
- いつまでに必要なのか
つまり、「何を作るか」より先に、「何を実現したいか」を整理することです。
Beekleでも、RFPや業務資料がしっかり整理されている案件では、その情報をもとに短期間でデモを作り、実際に触ってもらいながら要件を詰めています。
生成AIを使った開発では、文章になっている要求から、ユースケース、ユーザーストーリー、シナリオ、画面案、テスト条件まで展開しやすくなりました。
だから今のRFPは、昔以上に「仕様を完璧に書く文書」ではなく、発注者の考えていることを、開発側が正しく読み取れる状態にする文書だと考えています。
RFPとは何か
RFPは、ベンダーに提案を依頼するための文書です。
似たものにRFIやRFQがあります。
- RFI（Request For Information）
どんな会社があり、どこまで対応できるのかを知るための情報提供依頼 - RFP（Request For Proposal）
自社の課題や要求を伝え、それに対する解決方法を提案してもらうための文書 - RFQ（Request For Quotation）
作るものや条件がかなり固まった段階で、価格を提示してもらうための見積依頼
実際の民間のシステム発注では、この3つを厳密に使い分けないこともあります。
大切なのは名前ではなく、ベンダーが提案するために必要な材料が揃っているかです。
RFPは要件定義書ではない
RFPを書くときによくある誤解が、「発注前に仕様を全部決めなければならない」というものです。
たとえば、こんな内容です。
- どんな画面を作るか
- どんなAPIを作るか
- AWSのどのサービスを使うか
- どのデータベースを使うか
- どんな認証方式にするか
- 詳細な非機能要件をどうするか
もちろん、すでに社内で決まっている制約があるなら書いた方がよいです。
しかし、まだ決まっていないことまで発注側で無理に決める必要はありません。
発注側が持っている重要な情報は、技術的な解決策ではなく、業務についての情報だからです。
たとえば、
毎月、経理担当者がExcelへ同じ情報を転記している。
月末に作業が集中し、入力ミスも起きている。
将来的には二重入力をなくしたい。
ここまで分かれば、開発会社は複数の解決策を考えられます。
一方で、
Excelを廃止して、Reactで入力画面を作り、AWSに置く。
まで発注者側で決めてしまうと、その方法が本当に適切なのかを検討する余地が減ります。
発注側は問題と要求を伝え、解決方法はベンダーにも考えさせる。
そのための文書としてRFPを使う方が、提案を受ける意味があります。
RFPに最低限書いてほしい6つのこと
RFPは何十ページもある必要はありません。
まず、次の6つが分かれば、開発会社はかなり具体的な提案を始められます。
1. 背景と目的
最初に書くのは、システムの機能ではなく、なぜこのプロジェクトをやるのかです。
たとえば、
営業担当者が顧客情報をExcelで管理している。
担当者ごとに管理方法が違い、他の担当者が状況を確認できない。
担当変更時の引き継ぎにも時間がかかっている。
この情報があるだけで、開発会社はかなり状況を理解できます。
「CRMを作りたい」だけでは、なぜ必要なのかが分かりません。
何を導入したいかではなく、今何に困っているかを書くのがポイントです。
2. 実現したいこと・要求
次に、「どうなったら嬉しいのか」を書きます。
たとえば、
- 営業担当者以外でも顧客とのやり取りを確認できるようにしたい
- 過去の商談履歴を検索できるようにしたい
- 次に誰が何をするのか分かるようにしたい
- 担当変更時に口頭で引き継がなくても済むようにしたい
この段階では、画面やボタンまで決めなくても構いません。
誰が、何に困っていて、どう変わりたいのか。
そこが分かれば、必要な機能は後から設計できます。
3. 現在の業務と資料
可能なら、現在の業務についても共有します。
- 今使っているExcel
- 帳票
- 業務フロー
- 既存システム
- マニュアル
- 実際の画面
- よくある問い合わせ
- 現場で使っているメモ
きれいに整理されていなくても構いません。
開発側からすると、作り込まれたTo-Beの資料より、実際に今使われているAs-Isの資料の方が役に立つことも多いです。
現状が分かれば、どこを変えれば効果が大きいのかを一緒に考えられるからです。
4. 絶対に外せない条件
すでに決まっている条件は明記します。
たとえば、
- 基幹システムとの連携が必要
- 個人情報を扱う
- 社外からも利用する
- スマートフォンで使いたい
- 特定のクラウドしか利用できない
- データを国内で保管する必要がある
- 既存アカウントとのSSOが必要
逆に、決まっていないものは「未定」で構いません。
未定なのに無理に決めるより、何が決まっていて、何が決まっていないかが分かる方が提案しやすいです。
5. 予算
予算は、できれば書いてください。
金額を確定できなくても、
- 100万円以内でまず検証したい
- 300〜500万円程度を想定している
- 1,000万円までは社内承認できる
- 金額よりも来期までの稼働を優先する
といった情報があるだけで、提案の方向が変わります。
予算が分からない状態では、開発会社側も、
- 小さく作るべきなのか
- 本格的な仕組みを提案すべきなのか
- SaaSを組み合わせるべきなのか
- フルスクラッチで考えるべきなのか
判断できません。
同じ要求でも、100万円で考える場合と1,000万円で考える場合では、提案内容が違います。
6. スケジュール
「いつまでに必要か」も重要です。
ただし、単に日付を書くのではなく、理由があるなら一緒に書いてください。
たとえば、
12月までに欲しい
より、
1月から新しい業務を開始するため、12月中に現場テストを終えたい
の方が、開発会社はスケジュールを考えやすくなります。
絶対に動かせない期限なのか、希望時期なのかも分けてください。
記入例をダウンロードする（架空サンプル）
ここまでの6項目を実際に埋めるとどうなるか、記入済みの見本を用意しました。法人向けの研修・受講管理システムを題材にした架空のサンプルです。背景、現在の業務、要求、外せない条件、予算、スケジュール、ベンダーに提案してほしいことまで、発注者が書く範囲をひととおり埋めてあります。
会社名、業務内容、要求、予算、期限を自社の内容に置き換えれば、そのまま提案依頼に使えます。技術仕様や画面設計は書いていません。そこはベンダーから提案してもらう前提の構成です。
To-Beは発注者だけで決めなくてもいい
RFPのテンプレートを見ると、「To-Beを書きましょう」と書かれていることがあります。
もちろん、理想の業務像が明確なら書いて構いません。
ただし、To-Beまで発注者だけで完成させる必要はありません。
特に、システムやAIを使えばどこまで業務を変えられるのか分からない場合、開発会社と一緒に考えた方がよいケースがあります。
発注側が持っているのは、
現在はこの業務に3時間かかっている
ここをできるだけ減らしたい
という情報です。
その解決策が、
- システム化
- SaaS導入
- AIエージェント
- RAG
- 業務そのものの廃止
- 運用変更
のどれなのかは、提案を受けて考えても構いません。
大切なのは、BeforeとAfterの業務状態を伝えることです。
技術的なHowは、ベンダーにも考えさせましょう。
機能要件はどこまで書けばいいか
すでに必要な機能が分かっているなら書いてください。
ただし、機能一覧を作ること自体を目的にしない方がよいです。
たとえば、
顧客マスタ管理機能
より、
営業担当者が外出先でも顧客情報を確認・更新したい
の方が、なぜその機能が必要なのか分かります。
「何の機能が欲しいか」だけでなく、誰が何をしたいのかを書いておくと、ベンダー側も代替案を出しやすくなります。
詳細な機能仕様は、ベンダー決定後の要件定義で詰めても構いません。
非機能要件も、分からなければ無理に決めなくていい
性能、可用性、セキュリティ、バックアップ、監視。
重要な項目ですが、発注前に全部決められる会社ばかりではありません。
たとえば、
可用性99.9%
とだけ書かれていても、なぜその水準が必要なのか分からなければ、適切な設計にはつながりません。
それより、
平日の9時〜18時に社内20人程度が使う
数時間止まっても業務上は翌日対応できる
と書いてある方が、必要な構成を考えやすい場合があります。
専門用語に変換できなくても、実際の利用条件を書けばよいです。
必要な非機能要件は、そこから開発会社と整理できます。
RFPを書くときに避けたい6つのこと
1. 「DXしたい」だけで終わる
「DXを進めたい」「AIを導入したい」だけでは、何を良くしたいのか分かりません。
業務上の困りごとまで書いてください。
2. As-Isを飛ばして、いきなりシステム案を書く
現状の業務を確認せずに解決策だけ決めると、問題ではないところをシステム化することがあります。
まず、今どう仕事をしているのかを共有します。
3. 技術に詳しくないのにHowまで固定する
技術的な制約がないのに、
AWSで
Reactで
RAGで
ChatGPTで
と決める必要はありません。
何を使うべきかも含めて提案を受けられます。
4. 予算を完全に隠す
予算が分からないと、提案の粒度が揃いません。
金額を確定できなくても、社内で検討可能なレンジを共有した方が話は早く進みます。
5. 期限だけを書いて理由を書かない
期限には事情があります。
法改正なのか、繁忙期なのか、新サービス開始なのか。
理由が分かれば、優先順位を付けた提案もしやすくなります。
6. 完璧になるまでRFPを出さない
最初からすべてを決める必要はありません。
むしろ、
- 決まっていること
- 分からないこと
- 提案してほしいこと
を分けて書いてください。
分からない部分を相談するために、開発会社を使っても構いません。
Beekleにご相談ください
Beekleでは、AI活用や業務システム開発について、作るものの整理、費用感、進め方まで一緒に確認します。まだ曖昧な段階でも、最初に何を決めればよいかから相談できます。
提案依頼書の抜け漏れを確認する
依頼書のたたき台がある場合も、これから作る場合も、開発会社が見積もりやすく、社内で比べやすい内容になっているかを確認します。
良いRFPは、ベンダーごとの提案の違いが見える
RFPを書く目的は、すべてのベンダーから同じ提案をもらうことではありません。
同じ課題に対して、
- A社は既存SaaSを組み合わせる
- B社は小さな業務システムを作る
- C社は業務自体を見直す
- D社はAIを組み込む
という違いが出ても構いません。
むしろ、その違いを見るためにRFPがあります。
ただし、各社が違う問題を解いていたら比較できません。
そのため、
- 背景
- 現状
- 要求
- 外せない条件
- 予算
- 期限
は揃えて渡します。
Howは違ってよい。
WhatとWhyの前提を揃える。
これがRFPの役割です。
ベンダー選定では「要求を理解しているか」を見る
評価表を100点満点で細かく作ることより、まず確認したいのは、この会社が自社の問題を正しく理解しているかです。
提案を見るときは、たとえば次を確認します。
- 自社の課題をどう理解したか
- なぜその方法を提案したのか
- 他にどんな選択肢を検討したか
- 今回作らなくてよいものは何か
- 見積もりに何が含まれているか
- どこに不確実性があるか
- 発注後に何を一緒に決める必要があるか
「全部できます」と言う会社より、分かっていないことやリスクまで説明できる会社の方が比較しやすいです。
価格を見る場合も、総額だけではなく、何をその金額に含めているかを見ます。
300万円と500万円の提案でも、対象範囲が違えば単純比較できません。
生成AI時代は、RFPの「言語化」の価値がさらに高い
生成AIを使った開発では、要求が文章になっていること自体に価値があります。
たとえば、
営業担当者が商談後に次のアクションを登録し忘れ、案件が放置されることがある。
商談後に次にやることが必ず分かる状態にしたい。
という要求があれば、そこから、
- ユーザーストーリー
- 業務シナリオ
- 画面案
- 未決定事項
- テストケース
- デモ
まで展開できます。
逆に、
営業管理システムが欲しい
だけでは、AIを使っても良い仕様にはなりません。
AIによって開発そのものが速くなるほど、最初に何を言語化して渡すかの重要性は上がります。
Beekleでは、RFP、議事録、既存資料などから要求を整理し、必要なシナリオや確認条件に落とし込んでから開発します。
RFPが完成した仕様書である必要はありません。
開発を始めるための材料が、読み取れる形で残っていることが重要です。
AI・RAG開発のRFPで追加したい情報
AIやRAGを使う案件では、通常のシステム開発に加えて、いくつか共有してほしい情報があります。
対象データ
- Word
- Excel
- Webページ
- データベース
- 社内Wiki
- 問い合わせ履歴
など、何をAIに使わせたいのかを書きます。
正確な件数が分からなくても、だいたいの規模で構いません。
誰が何を質問するのか
「RAGを作りたい」だけでは設計できません。
たとえば、
- 営業が過去提案を検索する
- サポート担当者が製品仕様を確認する
- 顧客がFAQを質問する
- 技術者がマニュアルを検索する
では必要な精度も権限も違います。
間違えると困る質問
AI案件では、正常に答えられる質問だけでなく、間違えると困る質問を先に教えてください。
たとえば、
- 価格
- 契約条件
- 製品の適合
- 保証条件
- 法令
- 社内規程
などです。
これが分かれば、どこを人間確認に残すか、根拠表示が必要か、回答を拒否する条件をどうするかを考えられます。
権限
部署や役職によって見てよい文書が違う場合は重要です。
検索精度以前に、見てはいけない情報が出ない設計が必要になります。
本番化の判断条件
PoCなら、
何ができたら本番開発へ進むのか
を決めておきます。
単に「AIが回答できた」ではなく、
- 想定質問のうちどこまで答えられたか
- 引用元を正しく示せたか
- 答えがない質問を無理に答えなかったか
- 人間の確認時間がどれだけ減ったか
など、業務で使えるかを確認します。
よくある質問
Q. RFPは何ページ必要ですか？
決まったページ数はありません。
数ページでも、背景・要求・予算・期限・制約が分かれば、提案できる案件はあります。
逆に50ページあっても、機能名だけ並んでいて背景が分からなければ、良い提案は難しくなります。
ページ数より、判断に必要な情報があるかを見てください。
Q. 機能一覧まで作らないと見積もりできませんか？
概算なら、要求と業務内容から出せる場合があります。
正確な金額を出すには要件を詰める必要がありますが、最初から発注者だけで機能一覧を完成させる必要はありません。
分からない部分も含めて相談してください。
Q. 予算を書くと、その金額いっぱいで見積もられませんか？
その可能性を気にする発注者は多いと思います。
ただ、予算が全く分からないと、ベンダー側も提案の規模を決められません。
気になる場合は、
予算上限は500万円。必要なら、その範囲で何を優先すべきか提案してほしい
という書き方でも構いません。
Q. To-Beまで自社で作るべきですか？
必須ではありません。
As-Isと変えたい状態が分かっていれば、To-Beは開発会社やコンサルタントと一緒に考えられます。
特に技術によって実現方法が大きく変わる案件では、提案を受けた方がよい場合があります。
Q. 自社にIT担当者がいなくてもRFPを書けますか？
書けます。
専門用語にする必要はありません。
普段の業務を、そのまま説明してください。
「誰が」「何をしていて」「何に困っていて」「どう変わってほしいか」が分かれば、開発側でシステムの言葉に変換できます。
Q. AI/RAG案件では、RFPを出す前にPoCをした方がいいですか？
何が技術的に実現できるか分からない場合は、小さく試してから本開発の範囲を決める方法があります。
ただし、PoCの前にも、
- どの業務を改善したいか
- どんな質問に答えたいか
- どんな失敗が困るか
- 何をもって成功とするか
は整理しておいた方が、検証の意味が明確になります。
ベンダー選定後は、RFPを要求・仕様・受入条件へ分解する
RFPは契約後も参照点になりますが、開発が始まったらRFP本文をそのままTaskへコピーして管理するのではなく、要求、機能仕様、非機能要件・制約、受入条件、未決事項へ分けて正本を作ります。
その後、設計・実装・テスト・PR / CI・顧客フィードバックまで接続し、RFP時点の前提が変わった場合は変更の影響範囲を追えるようにします。
要求 → 機能仕様 → 非機能要件・制約 → 受入仕様 → 設計 → 実装 → テスト → PR / CI → 顧客フィードバック → 不具合・変更 → 次の仕様・Regression
Q. RFP時点で要件はどこまで固めるべきですか？
A. ベンダーが提案条件を判断できるだけの課題、成功条件、必須制約、既存システム、既知の要件は明確にします。一方、詳細な画面仕様や実現方式まで発注側だけで決め切る必要はありません。未決事項は明示し、選定後の要件整理で精度を上げる余地を残します。
一般的なシステム開発の相談先を検討している場合はWEB・モバイルアプリ開発、AI案件なら生成AI受託開発も参照してください。
関連ガイド：要件定義 完全ガイド ／ 要件定義の進め方 ／ Gherkin / BDD
まとめ：RFPで決めるのは「解決方法」ではなく「解くべき問題」
良いRFPは、詳細仕様を最初から完璧に決めた文書ではありません。解決したい業務課題、現状、達成したい結果、必須制約、既存システム、ステークホルダー、既知の要件、未決事項を、候補ベンダーが判断できる形で共有した文書です。
従来のRFPの書式や評価表は今も有効です。ただし、発注前の仮説を固定化しすぎず、ベンダーとの対話で詳細仕様を精度向上させる余地を残してください。契約後はRFPを起点に、要求・仕様・受入条件・設計・実装・テスト・変更を接続していくことが重要です。
要件定義全体は要件定義 完全ガイドで解説しています。