RFPの書き方とは？記載項目・章立てサンプルと作成手順を発注者目線で解説

RFP（提案依頼書）は、書き方しだいで返ってくる提案の質が変わる文書です。同じ予算を提示しても、課題と対象範囲が具体的に書かれたRFPには実現方法まで踏み込んだ提案が集まり、要望を箇条書きしただけのRFPには各社横並びの一般論が返ってきます。この記事では、RFPを書き始める前に固めておく目的・体制・スケジュールから、章立てサンプルと各章の記載項目、配布からベンダー選定までの手順、要件定義書との書き分けまでを発注者目線で整理しました。そのうえで、RFPを作り込むべき案件と簡易版で足りる案件の線引き、書いても提案が集まらない失敗パターンと回避策まで踏み込みます。

まとめ｜RFPの書き方で提案の質を分ける記載項目と作成の順序

RFPの書き方で成否を分けるのは、体裁ではなく記載する順序と粒度です。先に「なぜ作るのか」「誰が決めるのか」「いつまでに選ぶのか」を社内で固め、そのうえで背景・課題・対象範囲・提案依頼事項・提案条件・評価基準という順に書く。この順序であれば、ベンダーは自社の課題を理解したうえで提案を組み立てられます。逆に、機能一覧から書き始めたRFPは、課題の共有が抜け落ちるため、機能を満たすだけの見積書に近い提案しか集まりません。

記載粒度の基準はひとつです。要求（何を実現したいか）は具体的に、実現方法（どう作るか）はベンダーに委ねる。この線を引けているRFPは、各社の技術的な提案力が比較できる形で表れるものです。ただし全案件でフル仕様が要るわけではなく、複数社コンペや基幹システム刷新では必須、単一ベンダーへの小規模改修では過剰になります。この線引きは判断章で条件を付けて言い切ります。

RFPを書き始める前に固める作成目的・社内体制・全体スケジュール

RFPの品質は、文書を書く工程ではなく、書き始める前の合意形成でおおよそ決まります。ここが曖昧なまま書くと、章立てだけ整った中身の薄い文書になります。

RFP作成の目的を言語化する手順と社内で先に決める判断の範囲

最初に決めるのは、このRFPで何を選ぼうとしているのかという範囲です。開発ベンダーを選ぶのか、パッケージ製品を選ぶのか、その両方を含めて提案を募るのかで、書くべき内容はそれぞれ別です。製品選定を含むなら要求は業務要件寄りに書き、開発ベンダー選定なら現行システムの構成や連携先まで開示する必要が出てきます。あわせて、社内でどこまで決着させておくかも決めます。対象業務の範囲、予算の上限、稼働希望時期、既存システムの継続可否。この4点が未決のままRFPを出すと、提案を受け取ってから前提が動き、再提案や再見積もりで数週間を失います。RFPという文書そのものの定義や目的から確認したい場合は、RFP（提案依頼書）とは何かを整理した解説を先に読むと、本記事の各章が何を埋める作業なのか把握しやすくなります。

RFP作成チームの編成と情報システム部門・業務部門の役割分担

RFPを情報システム部門だけで書くと、機能要件は詳しいのに業務上の課題が薄い文書になりがちです。逆に業務部門だけで書けば、既存システムとの連携条件やデータ移行の制約が抜けます。実務では、業務部門が「解決したい課題と業務の流れ」を、情報システム部門が「現行構成・連携・非機能要件・セキュリティ要件」を担当し、発注窓口を1名に集約する形が破綻しにくい編成です。窓口を複数にすると、ベンダーからの質問に対する回答が担当者ごとにぶれ、その差分がそのまま提案のばらつきになって返ってきます。

RFP発行から契約までの標準的な期間と逆算したスケジュール例

スケジュールは稼働希望日からの逆算で組みます。中規模の業務システム開発で複数社コンペを行う場合、RFP作成に3〜6週間、配布から提案書提出までに3〜4週間、提案評価とプレゼンテーションに2〜3週間、社内決裁と契約交渉に2〜4週間を見るのが目安です。合計すると、RFPの検討開始から契約締結まで3〜4か月かかります。提案の提出期限を2週間に切り詰めると、ベンダー側は既存の提案書を流用せざるを得ず、自社向けに作り込まれた提案は集まりません。RFP本文には、質問受付の締切日、回答の返送日、提案書の提出期限、プレゼンテーションの実施週、選定結果の通知時期を日付で明記します。日付が入っていないRFPは、ベンダー側で社内リソースを押さえられず、辞退の理由になります。

RFPに記載する項目と章立てサンプル｜提案依頼書の構成例と書き方

RFPに法定の様式はありません。ただし提案を比較する目的から逆算すると、載せるべき情報はおおむね決まります。まず全体像を対応表で示し、そのうえで各章の書き方を見ていきます。

RFP全体の章立てサンプルと各章へ記載する内容を整理した対応表

次の8章構成は、システム開発の発注で使われる標準的な章立てです。テンプレートや雛形を探している場合も、この対応表の粒度で各章を埋めれば体裁は整います。

章の数を増やす必要はありません。上の8章で足りない情報が出てきたときだけ、現行システム構成図や業務フロー、帳票サンプルを付録として添付します。

表紙とプロジェクト概要に書く発注背景・現状課題の記載サンプル

提案の質を左右するのは、2章のプロジェクト概要です。ここで書くのは、機能ではなく困っている事実です。「受注データを基幹システムへ手入力しており、月末に1人あたり20時間の残業が発生している」「顧客情報が営業部門と保守部門で二重管理になり、問い合わせ対応で最新情報を特定できない」。このように、誰が・どの業務で・どれだけ困っているかを数値付きで書くと、ベンダーは解決策の優先順位を判断できます。目的は「業務効率の向上」といった抽象語で終わらせず、達成したい状態まで書きます。たとえば「月次の締め処理を3営業日から1営業日に短縮する」「二重入力をなくし、顧客情報の更新を1系統に統合する」といった水準です。

提案依頼事項に書く機能要件と非機能要件の記載粒度と書き方の型

4章の提案依頼事項では、機能要件を「〜できること」の形で、実現方法を指定せずに書くのが原則です。「承認ルートを部署ごとに設定できること」は要求ですが、「ワークフロー機能をノーコードで実装すること」は実現方法の指定であり、ベンダーの提案余地を削ります。要求には必須と希望の区分を付け、必須は数を絞ります。すべて必須にしたRFPは、対応可否の表が全項目「対応可」で埋まって返ってくるため、比較材料になりません。非機能要件は書き漏らしが起きやすい領域です。IPAが公開している「非機能要求グレード2018」は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーという6つの大項目で非機能要求を体系化しており、2026年8月時点ではIPAのアーカイブページで参照できます。全項目を埋める必要はなく、稼働時間、同時利用者数、障害時の復旧目標時間、データ保持期間、認証方式など、自社の業務が止まると困る観点だけ拾って記載すれば十分な粒度になります。

予算・スケジュール・契約条件といった提案条件の書き方と開示範囲

予算は、上限額または想定レンジまで開示するのが実務的な判断です。「初期費用3,000万円以内、年間保守300万円以内」のように枠を示せば、その枠内で何ができるかという提案の競争になります。契約条件も配布前に記載します。開発工程の契約形態（請負か準委任か）、検収の考え方、瑕疵対応の期間、成果物の権利帰属、再委託の可否。工程によって契約形態を分ける進め方が一般的で、要件定義を準委任、設計以降を請負とする組み合わせが多く採られます。契約形態ごとの責任範囲の違いは準委任契約と請負契約の使い分けの解説で整理しているため、RFPには自社が想定する形態と、変更提案を受け付けるかどうかだけ書けば足ります。

提案書の様式・評価基準・選定方法を先に示す記載項目と提示の例

提案書の様式を指定しないRFPは、比較の手間を自ら増やす原因です。記載してほしい項目（提案の全体方針、機能要件への対応可否、体制と要員のスキル、開発工程とスケジュール、費用の内訳、保守運用の条件、実績）と、ページ数の上限、提出形式、部数を指定します。ページ数を切ることで、各社の主張の優先順位が見え、読む側の負担も下がります。評価基準は、評価軸と配点まで開示する形が誠実です。「提案内容40点、体制と実績25点、価格25点、保守運用10点」といった配点を示せば、ベンダーは注力すべき点を判断でき、提案の密度が上がる仕組みです。価格の配点を明示しない場合、多くのベンダーは価格勝負と解釈して構成を削るため、提案の質は下がります。選定方法（一次審査は書面のみ、二次はプレゼンテーションと質疑）と結果の通知時期も、同じ章に書き添えます。

RFP作成から配布・提案・ベンダー選定までの手順とスケジュール

文書が書き上がってからが本番です。配布の仕方と質疑応答の運用で、集まる提案の中身は変わります。

RFI・情報収集からRFP配布までの準備工程と社内合意の取り方

候補ベンダーの当たりが付いていない段階では、RFPの前にRFI（情報提供依頼書）で実績や体制、対応可能領域を集めます。RFIで10社前後に声をかけ、書面回答をもとにRFPの配布先を3〜5社に絞る流れが標準です。配布先が2社では比較にならず、6社を超えると評価工数が跳ね上がるうえ、辞退や手抜き提案が増えることになります。RFIとRFP、RFQ（見積依頼書）の役割の違いはRFI・RFP・RFQの違いと発行の流れの解説で比較しているとおりで、情報収集はRFI、提案の依頼はRFP、価格の確認はRFQという分担です。配布前には、経営層と業務部門の双方からRFP本文の承認を取ります。承認を取らずに配布し、提案受領後に「その要件は社として認めていない」となる展開は、ベンダーの工数を無駄にし、次回の提案参加を敬遠される原因になります。

提案依頼の説明会と質疑応答からベンダー選定・契約までの進め方

RFP配布と同時に、説明会の実施可否を決めます。現行業務が複雑な案件では、1時間程度の説明会を設けたほうが提案の精度が上がります。質問は個別対応にせず、締切を設けてメールで受け付け、回答は質問者名を伏せて全社へ一斉展開する運用が原則です。個別に答えると情報量の差がそのまま提案の差になり、公平な比較ができなくなります。提案書を受け取ったら、評価シートで各社を採点し、上位2〜3社にプレゼンテーションを依頼します。この場で確認するのは、提案書に書かれた体制の実在性、想定リスクへの回答、追加費用が発生する条件の3点です。選定後は、選定理由と不採用理由を各社へ通知します。理由を伝えない対応は次回のコンペ参加率を下げるため、簡潔でも文面で返すほうが得策です。契約交渉では、RFPと提案書のどちらを契約の前提とするかを明記し、齟齬がある場合の優先順位を決めておきます。

要件定義書・仕様書との書き分けとRFPに書く要求の粒度の基準

RFPと要件定義書を混同すると、書きすぎるか、書かなすぎるかのどちらかに振れます。両者の役割の違いを押さえておきます。

RFPと要件定義書の役割の違いと書く時点で決まっている情報量

RFPは発注先を決めるための文書、要件定義書は決まった発注先と作るものを確定させる文書です。時間軸が違います。RFPを書く時点では、業務上の課題と実現したい状態は決まっていても、画面数やデータ項目、外部連携の方式までは決まっていないのが普通の状態です。そこを無理に確定させようとすると、RFP作成に半年を費やし、市場の状況も社内の優先度も変わってしまいます。RFPには「何を解決したいか」と「どこまでを対象にするか」を書き、「どう作るか」は提案とその後の要件定義で詰める。この分担が原則です。契約後の要件定義でまとめる文書の書き方は要件定義書の書き方と章立てサンプルの解説に譲ります。RFPの段階で要件定義書に近い精度の資料を作れているなら、それは提案の前提資料として添付すればよく、RFP本文に溶かし込む必要はありません。

要求を書きすぎたRFPが提案の幅を狭める境界線と粒度の決め方

粒度の判断に迷ったら、その記述がベンダーの選択肢を潰していないかを確認します。「基幹システムとリアルタイムに連携すること」は要求、「REST APIで連携すること」は方式の指定です。後者を書いた瞬間、ファイル連携やデータベース連携のほうが安く早い場合でも、その提案は出てきません。既存環境の制約で方式を固定せざるを得ないケースはあります。その場合は「現行の連携基盤がファイル転送のみに対応しているため、方式はこの制約を前提とする」と理由を添えて書きます。理由が書かれていれば、ベンダーは制約の妥当性を検証し、代替案を添えて提案できるからです。制約と要求を区別せず並べたRFPは、ベンダーから見ると全てが動かせない前提に見えるため、提案の幅がそのぶん狭まります。

RFPを作り込むべき案件と簡易版で足りる案件を分ける判断の条件

ここからは、競合のテンプレート解説があまり踏み込まない判断の話です。RFPは常に作り込むべき文書ではありません。条件を付けて線を引きます。

RFPを作り込むべき案件の条件と規模・関係者数からの見極め方

フル仕様のRFPを作るべきなのは、次の条件のいずれかに当てはまる案件です。3社以上のコンペで発注先を決める、初期費用が1,000万円を超える、複数部門の業務が対象で要求の取りまとめ自体が必要、基幹系の刷新や移行を含む、公的資金や補助金が絡み選定過程の説明責任がある。このいずれかに該当するなら、作成に3〜6週間を投じても回収できます。理由は単純で、選定を誤ったときの損失が作成工数を大きく上回るからです。基幹システムの刷新で発注先の選定を誤れば、損失は数千万円と1年以上の遅延という規模になります。業務システムの刷新でどこまでを対象範囲にするか迷う段階であれば、業務システム・基幹システム開発の相談窓口で現行業務の整理から相談する方法もあります。

簡易版のRFPで足りる案件と作成を省いてよい小規模発注の線引き

一方、次の場合はフル仕様のRFPを作らないほうが早く進みます。既存ベンダーへの機能追加や改修で、金額が数十万〜200万円程度に収まる案件。要求が単一部門で完結し、関係者が3名以内の案件。パッケージ製品の標準機能をそのまま導入し、カスタマイズを行わない案件。これらで20ページのRFPを書くのは過剰で、依頼内容を1〜3ページにまとめた依頼書と、現行の課題を整理したヒアリングシートがあれば足ります。省いてよい理由は、比較の必要性が低いからです。ただし、金額が小さくても複数社から相見積もりを取るなら、簡易版でも対象範囲と評価基準だけは文書化します。この2項目がないまま集めた見積もりは、前提が揃わず比較できないためです。

書き方を誤ったRFPで提案の質が落ちる失敗パターンと事前の回避策

RFPを作っても提案が集まらない、あるいは各社の提案が似通ってしまう。この2つの症状には、それぞれ典型的な原因があります。

課題を書かない丸投げ型RFPで提案が横並びになる失敗と修正の方向

もっとも多い失敗が、現状の課題を書かずに「貴社の知見で最良の提案をお願いします」と委ねる書き方です。ベンダー側は判断材料を持たないため、汎用的な構成と標準的な体制を提示するしかなく、結果として各社の提案が横並びになります。提案が似通えば、選定は価格だけの比較に落ちます。修正の方向は、課題を1つでも数値で書くことです。処理件数、作業時間、エラー発生率、対応の遅延日数。どれか1つでも実測値が入れば、提案はその数値を改善する構成へ寄ってきます。あわせて、社内で「これは譲れない」という条件を2〜3点だけ明示します。条件がゼロのRFPは丁寧なようで判断を放棄しており、提案の作り込みを引き出せません。ベンダーが最初に知りたいのは、要望の一覧ではなく、この案件で何が評価されるのかという軸です。

実現方法まで指定したRFPが提案の質を下げる過剰記載の見直し

もう1つの失敗が、書きすぎです。画面遷移図、テーブル定義、使用する言語やフレームワークまで指定したRFPは、実質的に発注仕様書であり、ベンダーは指定どおりに見積もるだけになります。技術選定の知見を持つ会社ほど、この形式では差を出せないと判断して辞退します。見直しの手順は、記述を要求と方法に仕分けし、方法に分類されたものを付録の参考情報へ移すことです。付録に置けば、ベンダーは前提として読みつつ、より良い方法があれば代替案の提示が可能です。もう1点、記載量が増えるほど矛盾が生まれやすくなります。本文で「クラウド前提」と書きながら付録の構成図が自社データセンターのままという矛盾は、質疑応答の工数を増やし、提案期間を実質的に削ります。配布前に、要求・制約・前提の3分類で通し読みし、互いに矛盾する記述がないか確認する工程を挟んでください。

よくある質問

RFPの書き方について、発注担当者から実際に多く挙がる質問を5つ取り上げます。

RFPの書き方に決まったフォーマットはありますか？

法令や業界標準で定められた様式はありません。ただし提案を比較するという目的から、表紙、プロジェクト概要、対象範囲、提案依頼事項、提案条件、提案書の様式、評価基準と選定方法、質問と連絡先という8章構成が事実上の標準形です。公共調達では発注機関ごとに様式が指定される場合があるため、その場合は指定様式に従います。民間の発注であれば、章の順序を入れ替えるより、各章に書く内容の具体性を上げるほうが提案の質に効きます。

RFPのテンプレートや雛形はどこで入手できますか？

ITベンダーやコンサルティング会社が公開している無料テンプレートが多数あり、章立ての参考にはなります。ただし、テンプレートの空欄を埋めるだけでは、各社横並びの提案しか集まりません。テンプレートは章の抜け漏れを防ぐチェックリストとして使い、プロジェクト概要と対象範囲、評価基準の3章は自社の言葉で書き下ろしてください。この3章が提案の差を作る部分で、テンプレートの例文をそのまま残すと、課題が伝わらないRFPになります。

RFPに予算はどこまで書くべきですか？

上限額または想定レンジまで書くのが実務上は妥当です。予算を伏せた場合、ベンダーは自社の標準構成で見積もるため、提示された金額が自社の想定と乖離し、再提案で時間を失う原因です。開示に抵抗があるなら、金額を1つに絞らず「初期費用2,000万〜3,000万円を想定」といったレンジで示す方法があります。あわせて、保守運用費の年額上限も書いておくと、初期費用だけ安く見せて保守費で回収する提案を避けられます。

RFPは何ページくらいのボリュームが目安ですか？

案件規模によりますが、数千万円規模のシステム開発で本文20〜30ページ、付録として現行構成図や業務フローを別添するのが一般的な分量です。数百万円規模の改修案件なら5〜10ページで足ります。ページ数を増やすこと自体に意味はなく、機能要求の一覧が長くなるようであれば、本文には必須要求だけを載せ、詳細な一覧は別紙に切り出してください。本文が長すぎると、ベンダー側で読み込みに時間がかかり、提案作成に充てる時間が減ります。

RFPの作成期間はどのくらい見ておけばよいですか？

関係部門へのヒアリングを含めて3〜6週間が目安です。すでに課題の整理が済んでいる案件なら2週間程度で書き上がりますが、複数部門から要求を集める段階から始めるなら、ヒアリングだけで3週間前後かかります。RFP発行から契約締結までは全体で3〜4か月を見込み、稼働希望日から逆算して着手時期を決めてください。期間を圧縮する場合は、RFP作成ではなく提案評価の並行作業で吸収するほうが、提案の質を落とさずに済みます。

関連記事

• RFPとは？提案依頼書の意味・目的・記載項目を発注者視点で解説：RFPという文書の定義と目的から確認したい場合の親記事です。
• RFI・RFP・RFQの違いとは？意味・使い分けと発行の流れを実務目線で整理：RFPを出す前の情報収集と、価格確認との使い分けを比較しています。
• 要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説：発注先が決まった後、要求を確定させる文書の書き方です。
• ヒアリングシートとは？システム開発の発注前に準備する項目とテンプレートの使い方：簡易版で進める案件で、課題整理に使える様式を扱っています。
• 仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点を解説：RFPより後の工程で作られる文書との関係を整理しています。