RFP（提案依頼書）とは？書き方・記載項目と、提案が比較できなくなる本当の原因

2026-08-21

「同じRFPを3社に送ったのに、返ってきた提案の金額が3倍近く開いた」

システム開発の発注を担当したことのある人なら、一度は経験があるはずです。しかも困るのは、どの提案が高すぎるのかを判断できないことです。安い会社は本当に安いのか、それとも読んでいる前提が違うだけなのか。比較表を作っても、比べているのが金額だけになり、最後は「なんとなく感じが良かった会社」で決めてしまう。

RFP（提案依頼書）は、本来この状態を防ぐための文書です。それでも比較できない提案が並ぶのは、RFPの書式が悪いからではありません。発注側がまだ決めていないことと、開発会社に提案してほしいことが、同じ文書の中で区別されないまま渡されているからです。

この記事では、RFPとは何かという定義から、RFI・RFQとの違い、記載項目、書き方の手順、提出後の進め方までを、発注側・進行担当者の目線で整理します。テンプレートを埋める作業ではなく、「どの情報を、どの粒度で、誰に渡すか」を設計する作業としてRFPを扱います。

※ 発注全体の流れや費用感は「Webシステム開発の外注費用｜相場と失敗しない会社の選び方【2026年】」で、依頼前の情報整理は「システム開発の要件定義はどう依頼する？発注前に整理すべき5つの論点と依頼方法」で解説しています。本記事は、そのうちRFPという文書そのものに絞って深掘りする内容です。

RFPが書けていない段階のご相談も歓迎です。「何を書けば比較できる提案が集まるのか分からない」という状態のままで構いません。

▶ 自社の場合、何から整理すべきか 無料で相談する

1. RFPとは？提案依頼書は「配る書類」ではなく「揃える設計」

RFPとは「Request for Proposal」の略で、日本語では提案依頼書と呼ばれます。システム開発やWeb制作などを発注する企業が、解決したい課題、システムの目的、必要な機能、予算、スケジュール、体制といった情報を提示し、開発会社に具体的な提案を求めるための文書です。

一般的には「複数社を比較検討するために出すもの」と説明されます。それは間違いではありませんが、比較は結果であって目的ではありません。RFPが果たしている本当の役割は次の2つです。

• 発注側と開発会社の前提を揃えること。口頭で説明すると、説明する相手ごとに情報量も表現も変わります。文書にしておけば、全社に同じ前提が渡ります。
• 社内の合意を先に取りきること。RFPを書く過程で、経営・現場・情報システム部門の期待がずれていることが必ず表面化します。ここで揃えておかないと、提案を受けた後に社内で揉めます。

逆に言えば、社内で決まっていないことをそのまま書いたRFPは、決まっていない状態を各社に配布しているだけです。開発会社は空白を一般的なベストプラクティスで埋めるため、返ってくるのは「間違ってはいないが、自社の業務には合っていない提案」になります。そして各社が別々の埋め方をするので、金額も体制も比較できなくなります。

RFPの良し悪しを決めるのは、ページ数でも書式の美しさでもありません。判定基準はひとつ、「誰が読んでも1通りにしか読めないか」です。

2. RFP・RFI・RFQの違い｜出す順番を間違えると提案の精度が落ちる

RFPと混同されやすい文書に、RFIとRFQがあります。違いは「何を求めているか」と「要件がどこまで固まっている前提か」です。

実務でよく起きる事故は、要件が固まっていないのにRFQ（見積依頼）から始めてしまうことです。仕様が未確定のまま金額だけを比べると、前提を薄く見積もった会社が最安値に見えます。そして開発が始まってから「それは要件に入っていません」という話になり、追加費用と納期調整の交渉が発生します。

逆に、候補企業のことを何も知らない段階でいきなり分厚いRFPを送るのも効率が悪くなります。開発会社にとって提案作成には相応の工数がかかるため、情報収集が目的だと分かると提案の熱量も下がります。まずRFIで候補を絞り、絞った数社にRFPを出す。この順番が、結果的に比較できる提案を集める近道です。

3. 「同じRFPを配ったのに比較できない」ときに起きている5つのズレ

提案が比較できない状態には、いくつかの決まった型があります。自社のRFPに当てはまるものがないか確認してみてください。

目的は書いてあるが、成功の判定基準がない

「業務を効率化したい」「顧客体験を向上させたい」は、達成できたかどうかを後から判定できません。判定できない目的は、提案の絞り込みにも使えません。「1件20分の受注入力を10分以内に」のように、数字で判定できるところまで落とす必要があります。

やらないことが書かれていない

提案の粒度を揃えるのは、やることのリストではなくやらないことのリストです。対象外の業務・拠点、今回は変更しない運用、次フェーズに回すものが明示されていないと、各社が思い思いの範囲を想定して見積もります。金額差の多くは、技術力の差ではなく想定スコープの差です（参考：スコープ管理が崩れる本当の原因）。

意思決定者と承認フローが書かれていない

要件定義が長引く原因の多くは技術ではなく承認です。レビューする人、最終承認する人、意見は言うが決定権はない人を分けて書く。「誰の承認をもって確定とするか」がRFPに書かれているだけで、提案側はスケジュールの前提を正しく置けます。

非機能要件が「一般的な水準で」のまま

応答速度、同時利用者数、停止の許容範囲といった非機能要件が空欄だと、各社は自社の標準値で埋めます。ここが埋まっていない状態の金額比較は、ほぼ意味を持ちません。リリース後に「業務時間帯に画面が固まる」と発覚したときも、要件に書かれていなければ追加費用の話になります。

決めたことと、提案してほしいことが混ざっている

最も多いのがこれです。「認証方式はSSOとする」と書かれた項目と、「認証方式について最適な案を提案してほしい」項目が同じトーンで並んでいると、読む側は前者を要望、後者を決定事項と取り違えます。各項目に「決定」「検討中」「提案依頼」のラベルを付けるだけで、この事故はほぼ消えます。

Enlytディレクターの現場から｜空欄のまま渡されたRFPほど、最初に聞く

Enlytのディレクターが受け取ったRFPで最初に確認するのは、書かれている項目ではなく、書かれていない項目です。空欄には「まだ決まっていない」「決まっているが書き漏れた」「あえて提案してほしい」の3種類があり、扱いがまったく違うためです。

そこで初回のご相談では、空欄を一つずつ指して「これは決まっていないのか、社内では決まっているのか」と伺います。埋まっていない箇所がどこか分かっている状態は、それ自体が良い依頼の条件です。空欄を隠したまま進むと、その空欄は必ず検収前に戻ってきます。

4. RFPの記載項目｜提案の粒度を揃える11項目

RFPの構成に唯一の正解はありませんが、提案を同じ土俵に乗せるという目的から逆算すると、最低限そろえるべき項目は次の11です。「抜けると起きること」まで併せて確認してください。

特に⑪は軽視されがちですが、選定基準を送付前に決めておくと、提案の質そのものが上がります。何を重視して選ぶかが分かれば、開発会社はそこに合わせて情報を出してくるためです。逆に選定基準が示されないRFPには、各社が「一般に評価されそうなこと」を並べた提案が返ってきます。

5. RFPの書き方｜作成手順を5ステップで整理する

ステップ1｜社内で目的と成功基準を確定させる

要件定義は開発会社に依頼できますが、「何を実現したいか」という要求定義は原理的に依頼できません。業務を持っている側にしか答えがないためです。粗い箇条書きで構わないので、目的と成功基準は自社で言語化してからRFPに入れてください。

ステップ2｜やらないことを、やることより先に書く

スコープの章は、対象外から書き始めると精度が上がります。「今回は変更しない業務」「対象外の拠点」「次フェーズに送る機能」を先に固定すると、残りが自動的に今回の範囲になります。書かれていないものは、すべて「当然入っているはず」として扱われると考えてください。

ステップ3｜項目ごとに「決定」「検討中」「提案依頼」のラベルを付ける

打ち合わせを重ねると、決まったことと決まっていないことが同じ資料に混在します。これが「合意したはず」問題の温床です。検討中の項目には必「誰が」「いつまでに」「何を判断すれば決定になるか」を併記してください。期限と担当のない検討中は、実質的に放置されます。

ステップ4｜曖昧語を、数値と挙動に置き換える

RFPには特有の曖昧語があります。「最新技術を活用し」「将来的な拡張性を考慮した」「ユーザーフレンドリーな画面」「必要に応じて対応」。いずれも読み手が自由に解釈できてしまうため、そのままでは各社の前提がばらつきます。次の問いを当てて具体化してください。

• 拡張性 →「3年後に想定する利用者数・拠点数・取扱件数はいくつか」
• 使いやすさ →「誰が、1日何回、どんな環境で使うのか。習熟にかけられる時間は」
• 必要に応じて →「どの条件を満たしたときに、誰が判断するのか」

自社で具体化できない箇所があっても構いません。「ここは自分たちでは具体化できない」と自覚して依頼できるかで、開発会社の掘り下げ方は変わります。

ステップ5｜選定基準と配点を、送付前に決める

提案を受けてから評価軸を作ると、目の前の提案に引きずられます。送付前に「実現性」「進め方・体制」「費用」「保守運用」「実績」などの観点と重みを決め、社内で合意しておく。特に、進め方や体制の観点を明示的に入れておくかどうかで、選定の結果は大きく変わります。

Enlytディレクターの現場から｜見るのは金額の差ではなく、前提の差

複数社の提案を並べたとき、Enlytのディレクターがご一緒して確認するのは合計金額の差ではなく、各社が置いた前提の差です。同じ機能でも、想定ユーザー数、既存システムとの連携方式、テストの範囲、移行データの量が違えば、金額は簡単に倍以上ずれます。

そこで有効なのが、各社の提案から前提条件だけを抜き出して一覧化する作業です。前提を並べると、安いのではなく狭いだけの提案が見えてきます。ここを飛ばして金額表だけで比較すると、選定の理由を後から社内に説明できなくなります。

6. RFPの非機能要件は、IPAの「非機能要求グレード」で揃える

非機能要件を自社だけで言語化するのは現実的ではありません。公開された枠組みを使うほうが確実です。IPA（独立行政法人情報処理推進機構）の「非機能要求グレード」は、非機能要求についてユーザーと開発者の認識の行き違いを防ぐことを目的に、要求項目を網羅的にリストアップし、要求レベルを段階的に示したツール群です。

項目は次の6つの大項目に分類されています。

• 可用性（運用時間、稼働率、目標復旧時間など）
• 性能・拡張性（応答時間、同時利用者数、将来の増加見込みなど）
• 運用・保守性（監視、バックアップ、障害時の対応体制など）
• 移行性（移行データ、並行稼働、切戻し手順など）
• セキュリティ（認証・認可、暗号化、ログ、遵守すべき規程など）
• システム環境・エコロジー（設置環境、電力・重量などの制約）

RFPの段階では、全項目を埋める必要はありません。この6項目について自社の想定レベルを言葉にし、シートを添付して各社に同じ前提で回答してもらえれば、見積の比較はぐらつかなくなります。資料はIPAのサイトから無償で入手できます（IPA「非機能要求グレード」）。

7. RFP提出後にズレを出さないための3つの取り決め

RFPは送って終わりではありません。提出後の運用を決めておかないと、せっかく揃えた前提がここで崩れます。

質問対応（Q&A）の窓口・期限・共有範囲を決める

提案期間中、各社から必ず質問が来ます。個別にメールで返していると、A社にだけ伝わった情報が生まれ、前提が再びばらつきます。質問の受付窓口と締切を決め、回答は原則として提案依頼先の全社に共有する。これだけで、比較可能性は保たれます。

提案説明会では、提案内容より「質問の質」を見る

提案説明会は、こちらが説明を受ける場であると同時に、開発会社の進め方を見極める場でもあります。「その業務、例外的な処理はありますか」「この機能がないとリリースできない優先度は」「どなたの合意をもって確定としますか」。こうした問いが相手から出てくるかを確認してください。機能の話だけで見積もりに向かう場合は、途中で認識齟齬が出る可能性が高いと考えたほうが安全です。

契約前に、成果物・完了条件・変更管理・責任分界を書面化する

要件は必ず変わります。問題は変わることではなく、変わったときの扱いが決まっていないことです。変更要望の窓口、影響を回答するまでのリードタイム、誰の承認で確定するか、軽微な変更の線引き。これを先に決めておくと、変更の話が「お願いできませんか」という交渉から「影響はこうです、判断をお願いします」という手続きに変わります。

8. 多拠点・オフショア体制へ発注するときにRFPへ加えたい項目

開発チームが海外拠点にある場合、RFPに書くべき項目が増えます。契約形態そのものの選び方は受託開発とは？ラボ型・アジャイル・SESの違いと自社に合う選び方で整理していますが、RFPの提案依頼事項としては次を明示的に求めてください。

1. 開発チームの所在地と人数、日本側の窓口体制
2. 仕様を誰が翻訳し、どこまで構造化して開発チームに渡すのか
3. 標準化・明文化されているドキュメントは何か（担当者が替わっても粒度が揃うか）
4. 進捗として何が可視化されるか（進捗率ではなく、動くものが見える頻度）
5. 週次でリスク（まだ起きていない懸念）と問題（すでに起きた事象）を分けて扱っているか

確認すべきは「多様性を尊重していますか」ではありません。どこを標準化し、どこを明文化し、誰が翻訳し、どこでズレを早期発見しているかです。問題だけを追う体制は火消しに終始し、リスクを拾う体制は火種の段階で手を打てます。

あわせて、似た案件で一番揉めたのは何だったかを聞いてみてください。揉めた経験を構造として説明できる会社は、同じ火種を先回りして潰す設計を持っています。「特に問題は起きませんでした」は、そのままでは安心材料になりません。

Enlytディレクターの現場から｜RFPは、そのままの形で開発チームには渡らない

日本語のRFPをそのまま翻訳して開発チームに送ると、主語の省略や「基本的に」「原則として」といった含みが、そのまま解釈のゆれになります。Enlytでは、日本のディレクターがブリッジとなり、RFPを画面・データ・処理条件の粒度に構造化し直してから開発チームへ渡します。

このとき、どの言葉を具体化してから渡すかという観点をチームで共有しているため、担当ディレクターが誰であっても、開発チームに届く要件の粒度が揃います。属人的な調整力ではなく標準化された運用として持っていることが、多拠点でも進行品質を落とさない前提になっています。

よくある質問（FAQ）

Q. RFPは必ず作らないといけませんか？

小規模な案件や、すでに信頼関係のある会社への追加発注であれば、正式なRFPは不要な場合もあります。ただしその場合でも、目的と成功基準・やらないこと・意思決定者の3つは文書で残してください。RFPという体裁が必要なのではなく、この3つが口頭のままだと後で揉める、というのが本質です。

Q. RFPに予算を書くと、上限いっぱいの見積が出てきませんか？

予算を伏せると、開発会社は前提が立てられず提案の粒度が下がります。現実的なのは「上限額」ではなく「投資判断のレンジと、その根拠」を伝えることです。あわせて「これがなければ導入する意味がない」機能を1〜3個に絞って示すと、予算調整が必要になったときの判断軸になります（相場はWebシステム開発の外注費用を参照）。

Q. RFPのテンプレートをそのまま使ってもいいですか？

項目の抜け漏れを防ぐ用途としては有効です。ただしテンプレートは項目名を教えてくれるだけで、中身の粒度までは決めてくれません。埋めた後に「この文章は、誰が読んでも1通りにしか読めないか」を1項目ずつ確認する工程を必ず入れてください。埋まっていない項目は、空欄のまま「未確定」と明記して出すほうが安全です。

まとめ｜RFPの質は、書式ではなく「社内で決めた量」で決まる

RFPをどう書くかは、突き詰めると発注側が持つ情報と決定を、どの粒度で、誰に、いつ渡すかの設計の話です。目的と成功基準、やらないことの境界、意思決定者、例外運用、譲れない一線、これらは開発会社が代わりに決められません。ここが渡されないまま集めた提案は、比較しているようで、実は各社の想像を比較しているだけになります。

この記事の要点

• RFPは比較のための書類ではなく、前提を揃え、社内の合意を先に取りきるための設計図
• 情報収集はRFI、提案依頼はRFP、確定仕様の価格比較はRFQ。要件が固まる前のRFQは最も事故りやすい
• 記載項目は11。特にやらないこと・意思決定者・非機能要件・選定基準は抜けやすく、抜けると比較不能になる
• 各項目に「決定」「検討中」「提案依頼」のラベルを付ける。検討中には期限と担当を併記する
• 非機能要件はIPAの非機能要求グレードの6大項目で想定レベルを示し、各社の前提を揃える
• 質問対応は窓口・期限・全社共有をルール化する。個別回答は前提を再びばらつかせる
• 多拠点体制なら、どこを標準化し、誰が翻訳し、どこでズレを早期発見するかまで提案依頼事項に入れる

RFPを書き切れないまま止まっているなら、そこが相談のタイミングです

RFPが書けないのは、文章力の問題ではありません。社内でまだ決まっていないことが、決まっていない形のまま残っているだけです。そして、その「決まっていないことの整理」こそ、開発会社に発注する前に最も価値が出る工程でもあります。

Enlytでは、受注前の要件整理から、要件・完了条件の構造化、UI/UX起点の体験設計、見える化された進行管理までをワンチームで支援しています。日本のディレクターがブリッジとなり、ベトナム拠点の開発チームへ仕様を翻訳・構造化して渡す体制を、属人的な調整力ではなく標準化された運用として持っています。

「他社に出すためのRFPを一緒に整理してほしい」「前回の発注で何がまずかったのかを言語化したい」といったご相談からでも構いません。曖昧さを減らし、期待値を揃え、事後発生を先回りして防ぐところから、ご一緒します。

RFPが白紙の段階からご相談いただけます。まずは「何が決まっていないのか」を一緒に洗い出すところから始めましょう。

▶ 自社の場合、何から整理すべきか 無料で相談する

▶ お役立ち資料をダウンロードする

▶ 開発実績を見る

あわせて読みたいEnlytの記事

システム開発の要件定義はどう依頼する？発注前に整理すべき5つの論点と依頼方法

なぜシステム開発は「合意したはず」なのに揉めるのか｜合意形成のズレを防ぐ進め方

システム開発の責任範囲はどこまで？発注者と開発会社が「検収間際」で揉めないための切り分け方

岡山 拳大

Enlytにて、UI/UXデザイン、コーディング、開発ディレクションを担当。 ユーザー視点を重視したUI設計と、開発実装を見据えた現実的なデザイン提案を得意とし、プロジェクト全体の品質・一貫性向上に貢献。 クライアント・エンジニア双方と密に連携しながら、スムーズな開発進行を支えている。

View More