RFP（提案依頼書）の書き方：載せる項目と注意点

RFP（提案依頼書）とは、システム開発などを外部に頼むときに、目的や条件をまとめて開発会社に渡し、提案と見積もりを出してもらうための文書です。目的・現状・範囲・要件・制約・評価の基準・スケジュールの7つの項目を押さえると、複数の会社の提案を同じ物差しで比べられます。

RFPは、開発会社のためだけの文書ではありません。書く過程で、社内の考えや優先順位がまとまり、後の要件定義や契約の土台にもなります。

RFPを作る理由

RFPを作る理由は、同じ条件で提案を比べること、社内の考えをまとめること、後の食い違いを減らすことの3つです。

口頭や短いメールだけで依頼すると、会社ごとに受け取り方が違い、提案の範囲も前提もばらばらになります。金額だけが並び、何が違うのかが分からないまま選ぶことになりがちです。

依頼先の候補を探す段階では、RFPの前にRFI（情報提供依頼書）で、各社の得意分野や対応できる範囲を尋ねる方法もあります。候補を絞ってからRFPを渡すと、双方の手間を減らせます。

載せる7つの項目

RFPには、次の7つの項目を、目的から順に具体的にしていく並びで載せます。

目的

目的には、作るものではなく、作って何を実現したいかを書きます。「受注の入力の手間を減らし、担当者が顧客への対応に時間を使えるようにする」のように、業務や経営の言葉で書くと、開発会社はよりよい手段を提案しやすくなります。成果をどう測るかも、分かる範囲で添えます。

現状

現状は、提案と見積もりの精度を左右する項目です。業務の流れ、使っているシステムと製品名、データの件数や形式、手作業で補っている部分を書きます。業務の流れの図や、画面・帳票の見本を添えると、伝わり方が変わります。

範囲

範囲では、頼む作業と頼まない作業を分けて書きます。データの移行、既存のシステムの改修、操作の研修、稼働後の運用は、書いていないと会社ごとに扱いが分かれやすい作業です。

要件

要件には、「どう作るか」ではなく「何ができればよいか」を書きます。必要な機能に加えて、速さ、使える時間帯、利用者の数、安全性などの非機能の条件も挙げます。AIを使う場合は、使えるデータと、どの程度の正しさなら業務で使えるかの考えも書いておくと、提案の前提がそろいます。要件の決め方は要件定義で決めること：はじめての方へで説明しています。

制約

制約は、提案の自由度を決める条件です。予算の枠を示すかどうかは判断が分かれますが、示すと、枠の中で実現できる案を出してもらいやすくなります。社内の規程で使えない基盤や、社外に出せないデータがあれば、ここで伝えます。

評価の基準

評価の基準は、提案の前に決めて、RFPに載せておきます。金額、提案の内容、体制と経験、進め方、稼働後の支えなど、何をどのくらい重く見るかを示すと、各社は力を入れる点が分かり、社内でも選んだ理由を説明しやすくなります。選び方の考え方は、用語集のベンダー選定もご覧ください。

スケジュール

スケジュールには、選定までの日程と、使い始めたい時期の両方を書きます。質問の受付の期間を設け、受けた質問と回答は、すべての候補の会社に同じように共有します。

提案の出し方もそろえる

提案書と見積もりの形を指定しておくと、比べる作業がずっと楽になります。

• 提案の概要と、目的に対する考え方
• 見積もり（工程別・機能別の内訳、前提条件、範囲外）
• 体制（担当する人の役割、窓口）
• 進め方とスケジュール
• 稼働後の保守・運用の提案と費用

社内の資料や業務の情報を渡す前には、秘密保持契約（NDA）を結んでおきます。見積もりの読み方はシステム開発の見積もりは、どこを見ればよいかで詳しく説明しています。

よくある抜け

RFPでよくある抜けは、決まっていないことの扱い、稼働までに要る周辺の作業、社内の体制の3つです。

決まっていないことを書かずにおくと、各社が別々の前提を置いて提案するため、比べにくくなります。決まっていないことは決まっていないと明記し、提案で考えを示してほしい部分として分けて書きます。

移行・研修・運用は、開発の本体に目が向くと抜けやすい作業です。社内の体制については、窓口になる担当者、判断する人、現場で確認に協力する人を書いておくと、開発会社は必要な関わり方を見込めます。

当社のご支援

RFPを書く前の、目的と優先順位の整理が難しいと感じる場合は、AI・DXコンサルティングでお手伝いします。業務の流れ、使っているシステム、データの置き場所をうかがい、何をシステムやAIに任せるか、どの順番で進めるかをまとめます。2〜4週間で優先順位と計画をまとめるAI活用の診断もご用意しています。