RFP（提案依頼書）とは？書き方・記載項目と、要件定義書から作る手順

1. 要件定義書の章を、提案依頼書の章へ振り分ける。新しく書き足すのは、予算・期間・選定日程・評価基準・提出物などの依頼条件だけ
2. 未決事項と対象外は消さずに残し、「提案で答えてほしい質問」として渡す
3. 評価基準と足切り条件を依頼の前に決め、自社の業務データでの検証を選定の手順に組み込む

反対に、要件定義書の丸渡し、要件の詰め込み、提案がそろった後の条件追加は、どれも各社の提案を比べられなくなる原因です。

当社が2026年10月に、バックオフィス部門で直近3年以内に業務改善やシステム導入に関わったリーダー・管理職221人に行った調査では、システム化を検討した207人のうち、要件定義書を社内だけで作成した人は21.3%でした。60.4%はベンダーや外部の支援を受けて作成しています。

自社の言葉でまとめた要件定義書は、それだけで依頼の質を上げる材料です。依頼先が同じ条件で読める形に整え、比べ方を先に示せば提案依頼書になります。

提案依頼書は「誰に、どう作ってもらうか」を決めるための文書

提案依頼書を作るのは、発注する側です。依頼先が作る提案書や見積書は、提案依頼書に対する回答にあたります。

要件定義書が「業務として何を実現したいか」を書く文書だとすれば、提案依頼書は「それを誰に、どの条件で実現してもらうか」を決めるための文書です。前者は社内の決めごと、後者は社外の読み手に向けた依頼の条件です。

提案依頼書を作る3つのメリット

提案依頼書を作る手間をかける理由は、次の3つです。

1. 複数の依頼先から、同じ条件で提案と見積を集めて比べられる
2. 依頼範囲や前提を文書で示すため、契約後の認識のずれや追加費用を防ぎやすい
3. 何を基準に選んだかが残り、社内の合意形成や稟議の根拠になる

反対に、作成には手間と時間がかかります。ただし要件定義書が手元にあれば、作業の多くは組み替えで済みます。

要件定義書・RFI・RFQとの違いを1つの表で整理

前後で使われる文書を比べると次のとおりです。

一般には「要件定義書は依頼先が提案依頼書を読んで作るもの」と説明されますが、発注側が先に要件をまとめても矛盾はしません。発注側がまとめるのは要求の整理、依頼先が契約後に作るのは設計に入るための詳細な要件定義で、前者は提案依頼書の土台としてそのまま使えます。

手順1 要件定義書の章を提案依頼書の章へ振り分ける

提案依頼書は、大きく「概要」「提案依頼内容」「選定の進め方」の3つのパートで構成します。要件定義書の章のほとんどは、このどこかにそのまま移せます。

上記の図のとおり、要件定義書にない項目は、予算と期間、選定スケジュール、提出物、評価基準、契約条件の5つです。新しく考えるのはこの部分だけです。

手順2 要件を「必須」「できれば」「提案歓迎」に分ける

次に、機能要件の1行ずつに優先度を付けます。満たさなければ選ばない条件は「必須」、満たしていれば加点する条件は「できれば」、依頼先の知見で良い方法を示してほしい部分は「提案歓迎」です。

すべてを必須にすると見積は膨らみます。優先度があれば、依頼先は必須の範囲で見積もり、できればの部分を別建てで示せるため、予算内で何ができるかが見えます。

手順3 未決事項と対象外は「提案で答えてほしい質問」に書き換える

要件定義書の未決事項一覧は、提案依頼書から消してはいけません。決まっていない事項こそ、依頼先の経験を借りて答えを出す対象だからです。

たとえば「基幹システムとの連携方式が未確定」なら、「CSV、API、中間テーブルのうち、どの方式を前提に提案するか、理由とあわせて回答してください」と書き換えます。各社の答え方そのものが比べる材料になります。

対象外一覧も同じく残します。書いておかないと、ある会社は対象外の業務まで見積もり、別の会社は含めない、というずれが起き、見積の範囲がそろいません。

手順4 現行の帳票・Excel・管理表を添付資料としてそろえる

依頼先が最初に求めるのは、いま実際に使っている資料です。次の3つを用意します。

1. 記入済みの帳票（見積書や申請書など、実際に使ったものの写し）
2. 業務で使っているExcelや管理表
3. 誰から誰へ承認がまわるのかが分かる資料

担当者ごとに分かれた管理表は、列を整理してから添付します。

手順5 予算・期間・選定日程・評価基準を書き足す

最後に、要件定義書にない依頼条件を書き足します。予算は上限の幅を示すか伏せるかを社内で決め、回答期限は依頼先が資料を読み込む時間を考えて2〜3週間を目安にします。選定日程は社内の決裁日から逆算してください。

そのまま使える提案依頼書の目次テンプレート

初めて作る場合は、次の目次をそのまま使ってください。表の項目は、この目次のどこかに入ります。

1. 表紙・はじめに（本書の目的、窓口）
2. 背景・目的・現状の課題
3. 対象範囲と対象外
4. 前提条件（利用者数、拠点、既存システム）
5. 提案依頼の範囲
6. 機能要件（必須／できれば／提案歓迎）
7. 非機能要件
8. 外部連携とデータ移行
9. 運用・保守・教育
10. 質問事項（未決事項）
11. 予算と期間
12. 選定スケジュール、提出物、提出方法
13. 評価基準と契約条件
14. 添付資料一覧

概要パートに書く項目

概要パートでは、依頼先が自社の状況を短時間でつかめるようにします。背景と目的、現状の課題、対象業務と対象部門、対象外、利用者数と拠点数が基本です。目的は「業務の効率化」のような抽象的な言葉で終わらせず、表の例文のように現場の困りごとで書くと、提案も具体的になります。

提案依頼パートに書く項目

提案依頼パートには、依頼範囲、機能要件、非機能要件、外部連携、データ移行、運用・保守、教育、依頼先の体制を書きます。要件定義書の内容を移す部分ですが、手順2の優先度と、手順3の質問をここで加えます。

非機能要件のうち、保存年限と権限の範囲の2つは、決まっていなくても後回しにせず、必ず書いてください。後から変えると設計全体に影響する項目だからです。クラウドサービスやノーコードツールが候補に入る場合に、契約前に確認しておきたい7つの制約は、要件定義書の記事の「契約前に提供元へ質問する7項目」にまとめています。提案依頼書の質問事項に、そのまま転記して使えます。

選定パートに書く項目

選定パートには、選定スケジュール、提出物、提出方法と締切、評価基準、質問の受付方法、契約条件と窓口を書きます。

比べやすさを大きく左右するのが提出物の指定です。提案書の章立てと、見積の内訳の様式（初期費用・月額費用・保守費用・追加開発の単価など）を指定しておくと、各社の提案を横に並べて読めるようになります。ある会社からの質問への回答は全社に共有すると、条件の公平さが保てます。

配点より先に「足切り条件」を決める

評価表は、足切りと配点の2段階で作ります。足切りは手順2で「必須」とした要件のうち、とくに重要なもので、1つでも満たさなければ配点に進まない条件です。そのうえで、残った提案を機能、費用、仕様変更のしやすさ、操作性、体制で採点します。

足切りを先に置けば、合計点は高いのに必須の条件を満たさない提案を選ぶ事故を防げます。評価表は稟議資料の根拠にもなります。

個別開発・パッケージ・ノーコードを1枚の依頼書で比べるコツ

前述の調査で、比較した手段を複数回答で聞いたところ、ノーコード・ローコードツールが52.7%、Excelマクロの改修が52.2%、業務特化型のパッケージ製品・クラウドサービスが35.3%、外部委託による個別開発が28.0%でした。

作り方も費用の形も違う提案が並ぶ前提で、初期費用だけで比べず、少なくとも3年分の総額と、項目の追加や承認ルートの変更が出たときに誰が直すのかを、見積の様式で答えてもらうと比べやすくなります。手段ごとの違いはノーコード開発の進め方で整理しています。

デモだけで決めず、自社の業務データでの検証を条件に入れる

同じ調査で、導入を判断する前に自社の実際の業務データで試した人は26.6%にとどまりました。多くは、サンプルデータでの無料トライアルや画面のデモ、資料で判断しています。

デモのデータは整っており、自社の例外処理や担当者ごとの入力のくせは、自社のデータで動かすまで見えません。提案依頼書の選定スケジュールに「最終候補は、当社の帳票とデータで検証してから決定する」と書いておくと、依頼先もその前提で提案を組み立てます。検証の設計はPoC設計の進め方で解説しています。

1. 要件定義書を説明なしで丸ごと渡す。各社が違う前提で読み、提案が比べられなくなります
2. 要件をすべて必須にして詰め込む。見積が膨らみ、検討が止まります
3. 提案がそろった後で条件を書き足す。全社に再見積を依頼することになり、日程が崩れます
4. 社内の合意がないまま出す。選んだ後に「なぜこの会社なのか」を説明できません

4つ目の背景にあるのは、作業の押し付け合いです。当社が情シス実務担当者221人に行った調査では、事業部門との調整でもっともストレスを感じる要因として「情シスに丸なげされること」が52.1%で突出しました（出典：【2026年調査】シャドーITの実態調査）。提案依頼書を情報システム部門や依頼先に任せきりにせず、意思決定者を1名決め、その業務を毎日触っている担当者を作成に加えてください。

添付資料の選び方にも注意が必要です。同じ時期に情シス実務担当者221人へ行った当社の調査では、主要なシステムの設計書と実際のプログラムが「ほぼ完全に乖離している」「ドキュメントは存在しない」と答えた人が、合わせて49.5%でした（出典：【2026年調査】レガシーシステムの実態調査）。古い仕様書だけを添付すると、依頼先は実態と違う前提で提案します。実物の帳票とデータを優先して添付してください。

事例1 やりたいことを一覧にして、回答欄付きで渡した化学メーカー

1社目は、従業員約400名の化学メーカーです。IT部門と、課題を持つ事業部門が組んで検討を進め、7つの課題を1つの一覧にまとめて依頼してきました。

一覧は1行1課題で、誰から誰への業務か、やり取りの方向、登録の方法、困っている背景の列が並び、右端に依頼先の回答欄と発注側の追記欄がありました。依頼先は回答欄に実現方法と「現行の管理簿や指示のメールがあれば試作環境を作れる」といった必要な資料を書き、発注側は連携の範囲を「まずはテキストや数値から」と絞って返すなど、やり取りが具体的に進みました。

社内では「IT部門としては良いツールだが、現場が使えるかどうか」という懸念が挙がっていました。比較対象には別のノーコード製品がありました。一覧の形式がそのまま回答表になること、そして現場の操作性を評価基準に入れておく必要があることが、この事例から分かります。

事例2 基幹システムとの連携を足切り条件にした商社

2社目は、従業員数百名規模で全国に約20拠点を持つ商社です。社内のグループウェアに付属するワークフローを使う案もありましたが、機能が足りず見送っていました。

社内からは「基幹システムにデータを渡せなければ手入力が残るので、連携できないツールでは意味がない」という意見が出ていました。提案依頼書でいえば足切り条件そのものです。

依頼先からは、初期の打合せで次の4点を確認しています。

1. 外部システムとの連携の方法（CSVで取り込む場合の項目を含む）
2. 利用者の範囲と規模（担当者、承認者、取引先など）
3. 試用環境の申し込み
4. スケジュール（段階的に始めるか、要件を満たす時期に合わせるか）

この4点を提案依頼書に先に書いておけば、初回から中身の議論に入れます。一方で評価指標は未設定でした。採点の物差しがなければ最後に迷うため、図3のような評価表を依頼の段階で作っておく意味があります。

なお、記載している業務内容および設計情報は架空のものではなく、弊社が実際に携わった複数の業務経験がベースとなっています。特定の企業や案件を識別できないよう一般化・再構成したうえで整理しています。

Q1 提案依頼書は誰が書くべきですか？情報システム部門がない場合は？

業務の中身が分かる業務部門の担当者が中心になって書くのが基本です。当社が2026年に進めている導入前検証9社のうち4社は、情報システム部門が加わらず、業務部門の担当者が中心となって進めています。情報システム部門がある場合は、非機能要件と外部連携の部分だけ確認を依頼すると負担を分けられます。

Q2 何社に依頼すればよいですか？

読み込める量とのバランスから、3社前後が現実的です。候補が多い場合は、先に情報提供依頼書（RFI）で絞り込んでから提案依頼書を出すと、読み込む負担を減らせます。

Q3 予算は提案依頼書に書くべきですか？

上限の幅だけでも示すほうが、実現できる範囲に合わせた提案が集まりやすくなります。伏せる場合は、必須の範囲とできればの範囲を分けて見積もってもらい、予算に合わせて組み合わせを選べるようにしてください。

Q4 要件定義書をそのまま渡してはいけないのですか？

添付資料として渡すのは問題ありません。ただし、依頼範囲、優先度、提出物、評価基準といった依頼条件が書かれていないと、各社が違う前提で提案し、比べられなくなります。要件定義書は土台として使い、依頼条件を足して提案依頼書にしてください。

Q5 クラウドサービスやノーコードツールの選定でも提案依頼書は必要ですか？

対象業務、必須の要件、比べ方、検証の方法を数ページにまとめた簡易版で十分です。利用者数と業務量も書いておくと、課金方式の違う製品の費用を比べやすくなります。

Q6 提案依頼書を出す前に検証（PoC）をしたほうがよいですか？

提案依頼書で候補を絞り、最終候補を自社のデータで検証する順番が一般的です。要件が書けない場合は、先に小さく試すほうが早いこともあります。

そのうえで、足切り条件と配点の評価表を依頼の前に作り、最終候補は自社の業務データで確かめてから選ぶ。この順番で進めれば、比べられる提案と、社内で説明できる選定理由の両方が手元に残ります。

本記事は執筆時点の一般的な情報にもとづく解説であり、契約条件や個別の取引に関する判断は、専門家にご確認ください。