注意事項
・本記事は公開時点の情報に基づいています。法令・制度変更等により内容が変わる可能性があるため、最新情報は公式サイト等でご確認ください。
・記事内の画像はイメージです。実際の商品・サービスとは異なる場合があります。
ビジネスを進めるなかで、プロジェクトの一部を協力会社へ依頼したり、業務委託でサポート体制を整えることは日常茶飯事でしょう。
しかし、協力先にこちらの意図が正しく伝わらず、的外れな提案を受けて困った経験はないでしょうか。
そのような失敗を防ぐために欠かせない重要書類が、RFP(提案依頼書)なのです。
この記事では、はじめて発注業務を担当する初心者の方でもわかるように、RFPの基本から、RFIやRFQとの違い、具体的な書き方までを徹底解説しています。ぜひ最後までご覧ください。
2008年に弁護士登録し、大阪市内の法律事務所に勤務したのち、2021年に独立開業しました。契約書のチェックや文書作成、起業時の法的アドバイス等、予防法務を主として、インターネットを介した業務提供を行っております。皆様が利用しやすい弁護士サービスを提供できるよう心掛けております。
RFPは、法律上では必ずしも必要なものではありません。ただ、実務上では、システム開発やプロジェクトなどでは、発注者が作ってほしいものと、受注者が作ろうとしているものが合致していないことが起こりえます。契約締結した後に違いがあることが判明すると、法的なトラブルに発展しかねません。こうした齟齬を予め解消するためにRFPを活用し、契約締結前に発注者・受注者の意思をしっかりと固めることで、トラブルを回避しましょう。
【目次】
【結論】RFP(提案依頼書)=具体的な提案をもらう書類
結論からお伝えすると、RFPとはRequest For Proposalの略称で、外部の協力会社に具体的な提案を依頼するための書類のことです。
物理的な商品の調達だけでなく、ITのシステム開発や建築の施工依頼、マーケティング業務の委託など、さまざまなサービスの発注シーンで広く活用されています。
これを用意することで、自社の要望が相手に正確に伝わります。
RFI・RFQとの違い
RFPとあわせてよく耳にする言葉に、RFIとRFQがあります。
これらは発注のプロセスにおいて、それぞれ異なる役割を持っています。
初心者の方でも一目で理解できるように、RFP・RFI・RFQそれぞれの違いを以下のテーブルにまとめました。
| 正式名称 | 役割(目的) | 実施するタイミング | |
|---|---|---|---|
| RFI | Request For Information(情報提供依頼書) | 会社の情報や技術力を集める | 発注の検討を始めるとき |
| RFP | Request For Proposal(提案依頼書) | 具体的な提案や見積もりをもらう | 依頼内容が決まったとき |
| RFQ | Request For Quotation(見積依頼書) | 最終的な価格や条件を確定させる | 発注先を絞り込むとき |
このように、まずはRFIで情報を集め、次にRFPで具体的な提案を募り、最後にRFQで明確な金額を出してもらうという流れが一般的です。
プロジェクトの規模や内容に合わせて、これらを上手に使い分けましょう。
RFP、RFI、RFQは、いずれも法律上の作成義務があるものではありませんので、個々の事案に応じて、これらの書類を使い分けてください。最終的に契約内容が固まったら、正式な契約書を作成しましょう。なお、取適法やフリーランス保護法の適用のある取引では、発注者は、発注内容や代金額、支払時期などを具体的に明示した書面ないしは電磁的記録を交付する義務があります。そのため、契約締結の最終局面では、発注書や契約書にこれらの法令上の要件を満たす内容の記載を忘れずに行うようにしましょう。
なぜ面倒でもRFPを作るのか?RFP作成の2大メリット

RFPを作るには、会社の中の要望をまとめたり書類に落とし込んだりするための時間と労力がかかります。
そのため、「わざわざ作らなくても、口頭やメールで伝えればいいのでは?」と思うかもしれません。
しかし、面倒な手順を踏んででもRFPを作成することには、ビジネスを成功させるための非常に大きなメリットが2つあるのです。
①ベンダーから、的外れな提案が来るのを防げる
1つ目のメリットは、発注先となるベンダー(協力会社)から、自社の目的とはかけ離れた提案をされるリスクをなくせることです。
口頭だけの説明では、相手の解釈次第でまったく異なるシステムやサービスを提案されてしまうことがあります。
RFPとして文章で明確に提示することで、すべてのベンダーが同じ前提条件で、精度の高い具体的な提案を作成できるようになります。
②社内の「そもそも何がしたいんだっけ?」が整う
2つ目のメリットは、書類を作成する過程で、自社内の意見や目的を綺麗に整理できることです。
サービスの発注では、部署ごとに「あれもやりたい」「これも必要だ」と要望がバラバラになりがちです。
RFPを作るために議論を重ねることで、プロジェクトの本当のゴールがどこにあるのかを社内ですべて統一できます。
RFPを作成するメリットについては、上にもコメントしました通り、契約締結後の法的トラブルの回避ということも挙げられます。契約内容があいまいなままスタートしてしまうと、何度もやり直しが発生したり、代金の支払い拒否や、その他の損害賠償などで、最終的には裁判で争わざるを得ない事態に発展しかねません。また、取適法やフリーランス保護法の適用のある取引では、不当な受領拒否、減額などを理由として、公正取引委員会などの行政庁からの指導、勧告を受ける事態にもなりかねません。このようなことが起こらないようにするためにも、交渉段階で具体的なRFPを作成して、発注者としては何を依頼したいのかを明確に伝えるようにしましょう。
RFP作成時に欠かせない項目3選

RFPを実際に作成するとき、どのような内容を書けばよいのか迷ってしまう初心者の方も多いでしょう。
Excel(エクセル)やWord(ワード)を使って書類をまとめる際は、以下の3つの項目を必ず盛り込むようにしてください。
これらを押さえるだけで、ベンダーが提案を考えやすくなります。
①背景・目的(なぜこのシステム・プロジェクトを行うのか)
なぜそのシステム開発やサービスの発注を行うのかという、プロジェクトの出発点を書きます。
たとえば、「現状の業務にこのような課題があり、それを解決するためにこのプロジェクトを立ち上げた」という経緯を簡潔に伝えてください。
ゴールをあらかじめ共有することで、ベンダーも的外れな提案をしにくくなります。
②提案依頼事項(機能要件・非機能要件・スケジュール)
ベンダーに具体的に何をしてほしいのかをまとめる項目です。
IT系であれば画面に必要な「機能要件」や、セキュリティなどの「非機能要件」を記載します。
建築系や業務委託であれば、対応してほしい作業範囲や、いつまでに納品してほしいかというスケジュールを分かりやすく箇条書きなどで示しましょう。
③選考基準・予算(どうやってベンダーを選ぶのか・いくらなのか)
提案を受け取ったあと、どのような基準で発注先を決定するのかをあらかじめ伝えます。
また、予算の上限についても可能な限り記載してください。
予算が明確であれば、ベンダーもその金額の範囲内で実現できる、最も効果的なプランを提案しやすくなります。
RFP作成の3ステップ

RFPの2大メリットと書くべき項目が分かったところで、次は具体的な作成手順を見ていきましょう。
難しく考える必要はありません。はじめて書類を作る方でも、次の3つのステップを順番に進めていけば、実務で十分に使えるしっかりとしたRFPを完成させることができます。
①ありのままの現場の不満・要望を集める
まずは、実際にシステムやサービスを使う現場の社員から、日ごろの業務における不満や「こうなったらいいな」という要望をすべて集めましょう。
この段階では、内容を綺麗に整える必要はありません。現場の生の声を漏らさずにすくい上げることが、本当に役立つ仕組み作りの第一歩となります。
②集めた要望を“絶対必要なこと”と“できれば”で分ける
とはいえ、現場から集まったたくさんの要望をそのままベンダーに渡してはいけません。
本来の目的がわかりにくくなるだけでなく、すべてを叶えようとすると、コストがいくらあっても足りなくなるためです。
集めた要望は、“絶対に実現したいこと(Must)”と“予算に余裕があれば対応したいこと(Want)”の2つに分けてみましょう。
③構成要素に沿ってまとめる
要望の仕分けが終わったら、先ほど紹介した3つの項目(背景・目的、提案依頼事項、選考基準・予算)に沿って、内容を書類に落とし込んでいきます。
最初から完璧なものを作ろうとせず、まずはA4の用紙2〜3枚程度に簡潔にまとめることを意識してください。
最終的には、ベンダーの立場に立って「わかりやすいか」「読みやすいか」といったことに注力しながらRFPを作成すると、お互いにとって有益な書類になるはずです。
発注者側としては、RFPを作成して依頼内容を明確化しておくことで、もし意図したものと違うものを受注者が制作してきた場合に、「RFPで示した内容と違います。」と主張しやすくなります。契約トラブルに発展した場合にも、RFPを証拠の一つとして使用することができます。こうした事態が起こり得るということを頭の片隅に意識しておいていただけると、より充実した内容のRFPが作成可能になると考えます。
ビジネス現場で起こりがちなRFPの失敗と対策

RFPを丁寧に作ったつもりでも、実際のビジネスの現場では、思わぬ落とし穴にハマってしまうことがあります。
とくに、はじめて発注業務を担当する方がやってしまいがちな、よくある2つの失敗例とその対策をまとめました。
これらをあらかじめ頭に入れておくことで、大きなトラブルを回避できます。
①「あれもこれも」と要望を詰め込みすぎて、予算を大幅に超える
現場の意見を大切にするあまり、すべての要望をRFPに詰め込んでしまう失敗です。
ベンダーから届いた提案書を見て、見積もり金額が予算を大幅に超えていて驚くケースは少なくありません。
対策として、ステップ②で行った「絶対必要なこと」の優先順位を厳守し、予算の範囲に収まる現実的な依頼内容に絞り込みましょう。
②ベンダーを信用しすぎて丸投げし、自社にノウハウが残らない
「専門家だからお任せすれば安心だろう」と、RFPの作成や要件定義をベンダーに丸投げするのはおすすめできません。
なぜなら、これを行うと、自社の業務プロセスを相手に握られてしまい、将来的なシステムの変更や運用の見直しが自社で一切できなくなるからです。
主導権は常に自社が握り、あくまでも協力してもらう、という姿勢を忘れないでください。
知っておくと差がつく、そのほかのR系ビジネス用語

IT業界や大規模なプロジェクトの現場では、RFIやRFPのほかにも、頭文字に「R」がつく専門用語が登場することがあります。
これらを知っておくと、協力会社のエンジニアや専門スタッフとの会話がスムーズになり、ビジネスパーソンとして一歩リードできます。
これまでに登場した用語も含めて、実務で使われる「R系ビジネス用語」のすべてを以下のテーブルにまとめました。頭の中を整理するためのチェックリストとして活用してください。
| 書類名 | 正式名称 | 役割(目的) | 主な活用シーン |
|---|---|---|---|
| RFI | Request For Information(情報提供依頼書) | 会社の情報や技術力を集める | 発注の検討を始めるとき |
| RFP | Request For Proposal(提案依頼書) | 具体的な提案や見積もりをもらう | 依頼内容が決まったとき |
| RFQ | Request For Quotation(見積依頼書) | 最終的な価格や条件を確定させる | 発注先を絞り込むとき |
| RFT | Request For Tender(入札依頼書) | 条件を提示して入札を募る | 官公庁や大規模プロジェクト |
| RFO | Request For Offer(供給依頼書) | 具体的な供給条件を依頼する | 資材調達や海外取引 |
| RFC | Request For Change(変更要求書) | システムや運用の変更を依頼する | 開発中や運用保守のフェーズ |
ここからは、新しく登場した3つの用語について、それぞれの特徴をさらに詳しく解説します。
RFT(入札依頼書)
RFTは、あらかじめ決まった要件に対して、ベンダーに入札を求めるための書類です。
主に官公庁の案件や、大規模な建設工事、国際的なIT調達などで使われます。
金額や条件の競争を行わせるための仕組みであり、一般的な民間企業の通常のサービス発注ではあまり使われません。
RFO(供給依頼書)
RFOは、特定の製品やサービスを供給してほしいときに、その条件を提示して依頼する書類です。
資材の調達や、海外のベンダーと取引を行う際によく見られます。
RFPよりも依頼する内容が具体的で、定型的な取引を開始する前段階で交わされることが多い用語です。
RFC(変更要求書)
RFCは、すでに稼働しているシステムや進行中のプロジェクトにおいて、仕様や運用の変更を正式に依頼するための書類です。
Web(ウェブ)サービスの開発や、ITの運用保守に関する国際的なガイドラインなどでよく使われます。
トラブルを防ぐために、変更内容や影響を記録する大切な役割を持っています。
記事のまとめ:それぞれの役割を理解して、プロジェクトを成功に導こう

RFP(提案依頼書)は、自社の想いや課題をベンダーに正確に伝え、プロジェクトを成功させるための手紙のようなものです。
RFIやRFQ、さらにIT業界などで使われる専門用語の役割をしっかりと理解することで、外部の協力会社と対等でスムーズなコミュニケーションが取れるようになります。
まずは完璧を目指さず、現場の声を整理することから始めて、一歩ずつ充実したビジネスを進めていきましょう。
RFP(提案依頼書)は法律上で作成が義務付けられているわけではありません。しかし、法務の視点から総括すると、RFPは「自社とプロジェクトを守るための防衛ツール」として非常に重要な役割を担っています。
契約前の交渉段階でRFPを用いて依頼内容を明確にしておくことは、契約締結後の仕様を巡るトラブルを防ぐだけでなく、万が一裁判などの紛争に発展した際にも、当初の合意内容を示す大切な「証拠」として機能します。また、取適法やフリーランス保護法の適用を受ける取引において、のちに義務づけられる「具体的かつ適正な書面交付」をスムーズに行うための土台にもなります。
RFPを作成する際は、単なる技術的な要望書としてだけでなく、後々の法的トラブルを回避するための「合意の基準」を作るという意識を持って取り組むと、より実効性の高い書類に仕上がるでしょう。
本記事は、作成時点の法令、ガイドライン、および公的機関の情報に基づいて作成されています。内容の正確性には万全を期しておりますが、法改正や制度変更等により、最新の情報と異なる場合があります。
また、本コンテンツは一般的な情報の提供を目的としており、法律的、税務的その他の具体的なアドバイスをするものではありません。個別具体的な事案については、必ず弁護士、税理士等の専門家にご相談ください。
本記事の情報を利用して行われた判断やアクションによって生じた損害、およびリンク先情報の正確性等について、当社は一切の責任を負いかねます。なお、本記事の記載内容は予告なしに変更することがあります。
この記事を書いた人
TCNBが運営する、ビジネスパーソンのための情報発信メディアです。皆様の業務効率化、最新トレンド把握、知識向上を徹底的にサポート。「困った」を解決するすぐに役立つノウハウや専門性の高いコラムを提供します。