RFPの書き方｜必須項目とRFI・要件定義との違い

RFPの書き方の話をする前に、そのRFPで何を発注しようとしているのかから始めます。ここを飛ばすと、あとの話が抽象論になるからです。

題材は、勤怠管理のシステムの入れ替えです。

なぜ入れ替えるのかというと、いまの状態がこうだからです。

→ 打刻は紙のタイムカード
→ 集計は総務が毎月Excelで手作業
→ 残業の上限管理も手作業で、月末に3人が3日がかりで確認
→ 対象は850名

そろそろ限界だ、と誰もが思っている。 ここまでは、どこの会社にもある話です。

では、なぜRFPを書くのかというと、発注先が決まっていないからです。

1社に決め打ちで頼めるなら、要らないものです。複数の会社に声をかけて、同じ条件で提案を出してもらい、横に並べて比べたい。 そのために条件をそろえる文書が要る。それがRFPです。

RFP（提案依頼書／Request For Proposal）とは、発注側が実現したいことと条件を整理して、複数のベンダーに提案を求めるための文書です。背景、目的、要件、予算、スケジュール、評価基準を並べます。

似た言葉にRFI（情報提供依頼書）があります。こちらは「そもそも何ができるのか教えてほしい」という段階で、まだ提案は求めません。RFPは、その次の段階です。 「これを実現する方法と金額を出してほしい」まで踏み込みます。

そして、書き方の型はほぼ確立しています。調達の基本動作なので、テンプレートも解説もいくらでも出てきます。

前置きはさておき、本題に入ります。

今日は、そのRFPを教科書どおりに書いて、提案を集めて、そこで何に詰まったかという話をしていこうと思います。

① 教科書どおりに、RFPを書く

RFPの書き方をすでにご存じの方は、② 提案を並べて、比べられないことに気づくから読み進められます。

RFPとは

RFP（Request For Proposal／提案依頼書）は、発注側が「何を実現したいか」を示し、実現方法の提案を求める文書です。書くのは発注側で、受け取った各社が提案書を返してきます。

RFPを作成するメリット

提案が比較できる形で揃う — 同じ前提に対する回答が並ぶ
社内の合意が先に取れる — 書く過程で、目的と範囲を関係部署とすり合わせることになる
選定理由を説明できる — 評価基準を先に示していれば、後から根拠を示せる
認識のずれが早く出る — 提案時点で解釈の違いが見えるので、契約後に発覚するより安い

2つ目は見落とされがちですが、実務では大きいです。RFPを書けないということは、社内で目的が固まっていないということでもあります。

RFPのデメリット

作成に工数がかかる — 現状整理とヒアリングで、数週間かかることがある
書きすぎると提案の幅が消える — 各社が同じ回答を返してくる
提出後の変更が効きにくい — 前提を変えると比較がやり直しになる

3つ目があるので、提出前に社内の合意を固めておく必要があります。出したあとで要件を足すと、各社の見積もりの前提が崩れます。

RFPを作る手順

段階	やること
1. プロジェクトの目的を定める	何のために。誰の何が良くなるのか
2. 現状の課題を洗い出す	現場と承認者の両方に聞く。機能名ではなく作業で聞く
3. 要件を決める	必須・あったほうがよい・不要の3段階に分ける
4. 依頼先の情報を集める	候補が絞れていなければ、ここでRFIを出す
5. RFPを書く	概要／提案依頼内容／選考の進め方の3部で組む
6. 各社へ提示し、質問を受け付ける	質問と回答は全社に共有する
7. 提案書と見積書を受け取る	評価基準に沿って複数人で採点する
8. 発注先を決め、契約する	選定理由を記録に残す

6の「全社に共有」を守らないと、そこまでの工程が無駄になります。1社だけが知っている前提があると、並べても比べられません。

RFPが無い場合と、ある場合で何が変わるか

	RFPが無い	RFPがある
提案の内容	各社が想像で書く。前提がバラバラ	同じ前提に対する回答が並ぶ
見積もり	範囲が違うので比べられない	同じ範囲で比較できる
社内の合意	発注後に「聞いていない」が出る	書く過程で先に取れる
契約後	「それは範囲外です」が発生する	範囲の認識が揃っている

差が出るのは提案の質ではなく、比較できるかどうかです。

RFPを作るタイミング

社内で目的と課題が固まった後、発注先を選ぶ前です。候補が多すぎて絞れない段階なら、先にRFIを出します。

逆に早すぎるRFPは機能しません。何を実現したいかが社内で決まっていない状態で出すと、各社の提案を見比べても判断の基準がありません。

RFPを作る前にすべきこと

この案件が、全社のシステム構成のどこに位置づくのかを確認します。既存システムとの連携範囲、将来的に置き換える予定の有無、同じ領域で動いている他の計画。ここを確認せずに書くと、提案が来てから「それは別プロジェクトと重なる」が発覚します。

RFIとの違い

RFI（Request For Information／情報提供依頼）は、発注先を絞る前に、各社にできることの情報を集めるものです。

	いつ	何を求めるか
RFI	発注先を絞る前	各社にできることの情報
RFP	発注先を選ぶとき	どう実現するかの提案

順番はRFIが先です。候補が最初から絞れているなら、RFIは省けます。市場に何があるか分からない段階でいきなりRFPを出すと、返ってくる提案の粒度が揃いません。

RFQとの違い

RFQ（Request For Quotation／見積依頼書）は、作るものが確定した後に、価格だけを問うものです。

	何を求めるか	いつ
RFI	各社にできることの情報	発注先を絞る前
RFP	どう実現するかの提案	発注先を選ぶとき
RFQ	確定した仕様に対する価格	仕様が決まった後

仕様が固まっていないのにRFQを出すと、安い提案が選ばれて、後から差分が追加費用になります。作り方の提案がほしいのか、値段だけ知りたいのかで使い分けます。

要件定義との違い

違いは順番です。RFPは発注前、要件定義は発注後に受注側と共同で行います。

	いつ	誰が書くか	何を決めるか
RFP	発注前	発注側	何を実現したいか
要件定義	発注後	受注側（発注側と共同）	何を作るか

ここを混同すると、RFPの段階で要件定義をやろうとして止まります。この記事の後半は、まさにその話です。

RFPは3つの部で組む

項目を平置きにすると、どこまで書けばよいか分からなくなります。3つの部に分けると、書く分量が決まります。

部	読み手が判断すること
概要	提案する価値がある案件か
提案依頼内容	自社で実現できるか、いくらか
選考の進め方	いつまでに何を出せばよいか

概要に書くこと

会社名・プロジェクト名、プロジェクトの背景、現状の課題、目的とゴール、発注者の会社情報です。

ここが薄いと、提案が一般論になります。「業務を効率化したい」ではなく、いま何にどれだけ時間がかかっていて、それがどう困っているのかまで書きます。

提案依頼内容に書くこと

対象範囲、現行システムの状況、機能要件、非機能要件、その他の要件（教育・移行・ドキュメント）、予算、スケジュールと本番稼働時期、開発体制と役割です。

「開発体制と役割」では、発注側が何をやるかまで書きます。データの準備、現場への説明、検証の実施を誰がやるのかを書かないと、その工数が見積もりから抜け落ちます。

選考の進め方に書くこと

提出期限、提出物、提案書の評価基準、質問の受付方法と期限、選定スケジュール、契約事項です。

この3つ目の部を書いていないRFPが多いです。選考の進め方が書かれていないと、各社が別々の形式で提案を出してきて、比べられなくなります。

必須項目と、空欄で流されるもの

項目そのものは各社の解説でほぼ共通しています。差がつくのは、どの項目が空欄のまま流されるかのほうです。

項目	空欄だと
会社名・プロジェクト名	—
背景・現状の課題	提案が一般論になる
目的・ゴール	何をもって成功かが各社バラバラになる
対象範囲	見積もりが比較できなくなる
現行システムの状況	移行工数が見積もりに入らない
機能要件	—
非機能要件（性能・可用性・セキュリティ）	後から追加費用になる。最も空欄で流される項目
その他の要件（教育・移行・ドキュメント）	引き渡しの範囲が抜ける
予算	各社が別々の規模で提案してくる
スケジュール・本番稼働時期	—
体制と役割（発注側が何をやるか）	発注側の作業が見積もりに入らない
契約事項	請負か準委任かを示さないと、見積もりの前提が各社で変わる
提案手続と日程	提出物と期限が揃わない
提案書の評価基準	選定理由を説明できなくなる
発注者の会社情報	提案側が業界の前提を掴めない

空欄で流されやすいのは「非機能要件」「体制と役割」「契約事項」の3つです。どれも、書かないと後から費用になります。

要求事項の洗い出し方

情報システム部門だけで書くと、現場が実際に困っていることが落ちます。使う人と、承認する人の両方に聞きます。

現場で「いま何に時間がかかっているか」を聞く。機能名ではなく作業で聞く
例外処理を聞く。手作業で回避している運用が、いちばん要件から漏れる
承認する側に「何が示されれば投資判断できるか」を聞く
出てきた要求を、必須・あったほうがよい・不要の3つに分ける

3段階に分けておくと、予算が合わなかったときに削る順番が先に決まります。

提案書の評価基準の作り方

評価基準を先に書いておくと、提案書の様式が揃います。一般的には、次の観点に配点を割り振ります。

観点	見るところ
要件の充足度	必須要件をどこまで満たすか
実現方法の妥当性	技術構成と、その理由が説明されているか
体制と実績	誰が担当するか。似た規模の実績があるか
スケジュールの現実性	前提条件が書かれているか
費用	内訳が比較できる形か。運用費が含まれるか

「費用」だけを配点の中心に置くと、安い提案が勝ちます。配点の例と、提案書に必ず書かせる3問は、この記事の後半（現場で使うなら、この目次）に置いています。

RFPを出したあとの進め方

質問の受付期間を設ける — 質問と回答は全社に共有する。1社だけが知っている前提があると、比較が壊れる
提案説明会を開く — 書面だけでは、担当者の力量が分からない
評価は複数人で行う — 1人の印象で決めると、後から説明できない

質問への回答を個別に返すのは、いちばんやりがちな失敗です。各社が違う前提で見積もるので、並べても比べられなくなります。

RFPでよくある失敗

失敗	何が起きるか
要件を書きすぎる	提案の幅が消える。各社が同じ回答を返してくる
要件を書かなすぎる	見積もりの前提が各社で変わり、金額が比較できない
予算を隠す	規模のバラバラな提案が集まる
評価基準を決めずに出す	選定理由を社内で説明できなくなる
発注側の作業を書かない	着手後に「それは御社の作業です」が発生する

1つ目と2つ目は、両立しない要求に見えます。どこまで固定して、どこを空けておくのか。この記事の後半は、その線引きの話です。

そのとおりに書きました。勤怠システムなので、機能はかなり具体的に書けます。

“`
・打刻方法：ICカード、スマートフォン、PC（3種）
・シフト管理：日勤／夜勤／変則の3パターンに対応
・残業上限のアラート：36協定の上限に対し、80%到達時に本人と上長へ通知
・既存の給与システムへの連携：月次でCSV連携
・対象人数：850名
・想定予算：〇〇万円
・稼働希望：来年4月
“`

機能を洗い出していくと、要件の行数は200行を超えました。 行が増えるほど、仕事をした感覚があります。

そして、これは正しく機能しました。 5社から提案が返ってきて、全社が要件の一覧に沿って回答してくれた。比較表が作れる状態になっています。

ここまでは、教科書どおりです。

3部で組み、必須項目を埋め、評価基準を先に示す。ここまでやれば、提案は集まります。

この記事の後半で扱うのは、集まった提案を前にしたときの話です。書けば書くほど起きることがあります。

② 提案を並べて、比べられないことに気づく

5社の提案を並べて、評価を始めます。

総額は、きれいに割れました。 高い順に並べて、体制の人数を見て、実績数を見る。それでも、どれを選べばいいのか決まりません。

決まらない理由を考えていて、あることに気づきました。5社とも、要件の一覧に「対応可」と書いているのです。

→ 打刻3種 — 全社が対応可
→ シフト3パターン — 全社が対応可
→ 残業アラート — 全社が対応可
→ 給与連携 — 全社が対応可

200行の要件は、200個の「対応可」を集めただけでした。

当たり前です。勤怠管理は成熟した領域なので、どこも作れます。 要件で差がつくのは、その要件を満たせない会社が混ざっているときだけです。

このとき残る比較軸は、総額と体制の人数と実績数だけになります。そして、その3つはどれも「作れるか」を測る指標です。全社が作れる領域で、作れるかを測っている。

200行が、比較の役に立っていませんでした。

③ 半年後、書いた要件が使えなくなる

もう1つの詰まりは、契約後に来ました。

RFPには「打刻の記録から、残業時間を集計して通知する」と書いてあります。当然の要件です。ところが進めているうちに、打刻の記録以外から取れる情報が増えていることが分かってきました。

具体的には、こういう話です。会議の予定、入退室の記録、業務システムの操作ログ。 これらを突き合わせると、打刻だけより正確に実労働時間が出る。しかも、それを組み合わせて判定する仕組みは、この半年で急に安くなっていました。

ここで、RFPに書いた要件が足かせになります。

→ 要件には「打刻の記録から集計する」と書いてある
→ 契約書には、そのRFPが添付されている
→ 別のやり方に変えるには、契約変更の手続きが要る
→ 手続きを始めると、技術の議論の前に契約の議論が始まる

そして、契約変更には時間がかかります。判断が2週間遅れるたびに、選べたはずの選択肢が1つずつ消えていきました。

これは勤怠システムに限った話ではありません。AIが絡む領域では、この劣化がもっと速く起きます。

たとえば、ある問い合わせ処理の仕組みでは、前段に小さな分類器を1枚置くだけで外部APIの呼び出しが8割以上減るという結果が出ています。もしRFPに「〇〇のAPIを利用して実装すること」と書いてあったら、この構成は提案されません。 契約に書いてあることを変える提案は、提案する側が自分の首を絞めるからです。

要件が、コスト削減の芽を潰します。

比較できない問題と、半年で使えなくなる問題。別々に見えますが、原因は1つでした。

RFPという道具は、「今日の正解は、契約期間中も正解であり続ける」という前提の上に立っています。

→ 前提が保たれるなら、手段を書いて比較するのは合理的
→ 前提が崩れると、手段の記述が、そのまま足かせに変わる
→ そして、手段が横並びになる成熟領域では、そもそも比較の役に立たない

つまり、手段を書くことが、両方の詰まりを同時に生んでいたわけです。

⑤ 直してみる — 固定するものと、空欄にするもの

RFPを書くのをやめる、という話ではありません。書く場所を変えます。

判断の基準は1つです。「これは半年後も同じか」と自分に聞く。

→ 同じなら、精密に書く価値があります
→ 変わるなら、書くほど足かせになります

この基準で仕分けると、こうなりました。

固定するもの（3つ）

1. 達成したい業務上の状態。
「打刻の記録から残業時間を集計して通知する」ではなく、「月末に3人がかりで3日かけている確認作業を、1人が半日で終えられる状態にする」。 手段ではなく、状態で書きます。

2. その達成をどう判定するか。
誰が、いつ、何の数字を見て、成功と言うのか。「確認作業の所要時間を、稼働3ヶ月後に総務部長が計測し、1人日以下であること」。 ここを空欄にしたまま進むと、検収の日に全員が違う定義を持ち寄ることになります。

3. 触ってはいけない制約。
給与システムとの連携が必須である。個人の位置情報は取得できない。監査でログの提示を求められる。これは時間が経っても変わらないので、精密に書く価値があります。

空欄にするもの（3つ）

1. 使用する技術・製品・API。 契約期間中に最適が入れ替わります。指定した瞬間、入れ替えが契約変更になります。

2. 機能一覧と画面数。 全社が「対応可」と答える領域では、比較の役に立ちません。

3. 総額の内訳としての工数。 工数はもうコストと比例していません。工数で縛ると、速く作る方法を選ぶ動機が消えます。

そして、必ず書く1項目

前提が変わったときの、変更手続き。

→ 誰が変更を提案できるか
→ 誰が判断するか
→ 何日以内に決めるか
→ 金額はどう調整するか

これを書いてあるRFPを、私はほとんど見たことがありません。 そして、変更が前提の開発でいちばん高くつくのは、この手続きが無いことです。

⑥ あとで知った — この形は、すでに制度になっていた

素朴な整理のつもりでしたが、調べてみると同じ考え方が、すでに公的な調達制度として運用されていました。

1つ目。 米国の連邦調達では、業務仕様書（SOW／Statement of Work）から、成果仕様書（PWS／Performance Work Statement）へ移行するよう指示が出ています。 そしてPWSの定義が、まさにこれです。

「どうやるか（how）ではなく、どういう結果を出すか（what result）を、一般的な用語で述べる」。

僕が「手段ではなく状態で書く」と整理したものは、すでに名前が付いて、制度として要求されている書き方でした。

2つ目。モジュラー調達（modular contracting）。 大規模なカスタム開発の調達を、小さな契約の集まりに分割するやり方です。1本の巨大な契約にせず、動くソフトウェアを早く利用者に届けることを優先する。

変更が起きることを、契約の単位そのもので吸収しているわけです。僕がやろうとした「変更手続きを書く」より、もう一段先を行っています。

3つ目が、いちばん効きました。 アジャイル向けの契約形式を使えば、調達文書は十数ページで足り、半日で書ける、という運用が実際に行われています。

200行のExcelは、要らなかったということです。

分量が必要になるのは、手段まで指定しようとするからでした。達成すべき状態と、判定方法と、変更手続きに絞れば、短くなるのが自然です。

ただし正直に書いておくと、これらは政府調達の文脈で整備されたもので、民間企業がそのまま使えるわけではありません。モジュラー調達には前提条件があって、発注側にプロダクト思考と、疎結合な設計と、継続的に届ける体制があることが要ると明記されています。分割すれば良いという話ではない。

それでも、方向は同じでした。新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

要件を200行から、状態と判定と制約に書き換えて、もう一度提案を集めました。

総額は、比較できなくなりました。 各社が違う手段を提案してくるので、金額の前提が揃わないからです。

代わりに、提案の中身が割れました。

質問を1つ足したのが効いています。「この前提が崩れたら、どこを直すことになりますか。その作業は何日で、誰が判断しますか」。

回答は、きれいに3種類に分かれました。

→ 「柔軟に対応します」 — 手順を持っていません。柔軟という言葉は、手順が無い人が使います
→ 「変更管理プロセスに則って対応します」 — プロセスはありますが、踏んだかは分かりません。踏んだ人は手順ではなく事故の話をします
→ 「前回はここが変わって、検知にこれだけかかって、直すのに何日でした」 — これです

3つ目を答えられる相手は、変更が起きることを織り込んで見積もっています。 だから総額は高く見えることがあります。それでも、1回目の変更で追加見積もりが出てくる相手と比べて、最終的にどちらが安いかは分かりません。

ひとつ、実際に効く指標があります。修正の見積もりが返ってくるまでの時間です。

ある現場では、不具合の修正見積もりが2分で「火曜日まで」から「1時間後」に書き換わりました。 最初は慎重な数字でしたが、実際に中を見たら1時間で済むと分かった。この「見てから直す」の速さが、そのまま変更への強さです。

見積もりが常に長めに返ってくる相手は、慎重なのではなく、中を見ずに答えている可能性があります。

⑧ 現場で使うなら、この目次

そのまま使える形に落とします。この順で書いてください。

#	項目	書く内容	分量の目安
1	背景	いま何に困っているか。数字で	1ページ
2	達成したい状態	手段ではなく状態。「〇〇が△△になっている」	1ページ
3	判定方法	誰が・いつ・何の数字を見て成功と言うか	半ページ
4	制約	連携必須・取得禁止・監査要件。変わらないものだけ	1ページ
5	予算とスケジュール	開示する	半ページ
6	変更手続き	誰が提案し、誰が何日で判断し、金額をどう調整するか	1ページ
7	提案してほしいこと	手段は自由。下の3問への回答を必須にする	半ページ
8	評価基準と配点	「作れるか」ではなく「直せるか」に配点を寄せる	半ページ

合計6〜7ページ。 200行の機能一覧は入りません。

提案書に必ず書かせる3問

→ 1. この前提が崩れたら、どこを直すことになりますか
→ 2. その作業は何日で、誰が判断しますか
→ 3. 直したあと、壊れていないことをどう確認しますか

3問とも、過去の実例で答えてもらってください。 「〜します」ではなく「前回は〜でした」で書けるかどうかが、そのまま経験の有無になります。

評価の配点（例）

観点	従来	変更後
実績数・体制	40点	15点
保有技術・製品	20点	5点
総額	30点	20点
変更対応（3問の回答）	0点	40点
運用・保守	10点	20点

「作れるか」に60点を配っていたのを、20点まで落とします。 全社が作れる領域で作れるかを測っても、点差が出ないからです。

⑨ この書き方が効き続ける理由

最後に、なぜこの形を推すのかを書きます。

達成したい状態は、技術が変わっても変わらないからです。

→ 「月末の確認作業を1人日以下にする」は、5年後も同じ日本語で通じます
→ 「打刻の記録から集計する」は、半年で古くなりました
→ 手段を書いた条項は、書いた瞬間から劣化が始まります

そして、状態で書かれた要件は、より良い手段を提案する余地を残します。 分類器を1枚挟めば8割安くなる、という提案は、手段が空欄でなければ出てきません。

RFPは、工業製品の調達から来た道具です。仕様を決め、相見積もりを取り、いちばん安いところに発注する。同じものが同じ品質で作られる前提があるから、この方法は合理的でした。

ソフトウェアは元々そこから外れていましたが、それでも「仕様を固めれば同じものが出来る」という建前で運用されてきました。AIは、その建前を維持できないところまで来ています。

この環境で発注側が持つべき能力は、「正しく選ぶ力」から「変わったときに直す力」へ移ります。 RFPも同じです。最初に正解を書き切ろうとするのをやめて、正解が変わったときの決め方を書く。

なお、あの200行のExcelは、いま思えば誰のためでもありませんでした。強いて言えば、書いた人が「詰めた」と言えるようになるためです。

安心を買うのに200行はちょっと高いな、と思います。半日で十数ページ、という運用があると知ってからは、なおさらです。

以上です。

RFPのよくある質問

RFPとRFIは何が違いますか？

RFI（情報提供依頼）は発注先を絞る前に、各社にできることの情報を集めるものです。RFP（提案依頼）は発注先を選ぶときに、どう実現するかの提案を求めるものです。順番はRFIが先で、集めた情報をもとにRFPを出す先を決めます。どちらも書くのは発注側です。

RFPと要件定義はどちらが先ですか？

RFPが先です。RFPは発注前、要件定義は発注後に受注側と共同で行います。ここを混同すると、RFPの段階で要件定義をやろうとして止まります。RFPで書くのは「何を実現したいか」であって、「何を作るか」の確定ではありません。

RFPには何を書けばよいですか？

概要・提案依頼内容・選考の進め方の3部で組みます。概要に会社名とプロジェクト名、背景、現状の課題、目的とゴール。提案依頼内容に対象範囲、現行システムの状況、機能要件、非機能要件、その他の要件、予算、スケジュール、体制と役割。選考の進め方に提出期限、提出物、評価基準、質問の受付方法、契約事項を書きます。

RFPで空欄にすると、あとで困る項目はどれですか？

非機能要件、体制と役割、契約事項の3つです。非機能要件（性能・可用性・セキュリティ）を書かないと後から追加費用になります。体制と役割を書かないと発注側の作業が見積もりに入りません。契約事項で請負か準委任かを示さないと、見積もりの前提が各社で変わって比較できなくなります。

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

上限だけでも書いたほうが比較しやすくなります。予算を書かないと、各社が別々の規模で提案してくるため、並べても比べられません。金額を明かしたくない場合でも、想定する規模感を示すだけで提案の幅は揃います。

RFP（提案依頼書）とは何ですか？

発注側が、実現したいこと・背景・予算・スケジュール・評価基準を整理し、複数のベンダーへ提案を求めるための文書です。RFI（情報提供依頼書）が「何ができるか教えてほしい」であるのに対し、RFPは「これを実現する方法と金額を提案してほしい」という段階になります。提案を横並びで比較できるよう、条件をそろえるのが本来の目的です。

RFPに機能一覧を書かないと、金額を比較できないのでは？

総額の比較をやめて、変更コストの比較に切り替えてください。前提が崩れない開発は存在しないので、崩れたときにどこを直すのか、何日で、誰が判断するのかを提案書に書かせる。総額だけを並べた比較表は、変更が1回起きた時点で無効になります。逆に、変更の手順を具体的に書ける相手は、変更が起きることを織り込んで見積もっています。