RFP（提案依頼書）の書き方｜制作会社・ベンダー選定で外さないための項目とテンプレート
制作会社やシステムベンダーを選ぶ場面で、「上がってきたものが想定と違う」「各社の見積の前提がバラバラで比較にならない」といった事態は珍しくありません。その多くは、依頼内容を文書化しないまま提案を求めてしまうことに原因があります。それを防ぐための文書がRFP（提案依頼書）です。この記事では、RFPとは何かという基本から、RFI・見積依頼書との違い、記載すべき項目、そのまま流用できるテンプレートまでを整理します。
RFPとは「Request For Proposal」の略で、日本語では提案依頼書と訳されます。発注者が、システム開発・Webサイト制作・広告運用などの外部委託にあたって、候補となる企業に「こういう課題を、こういう条件で解決したい。どう実現するか提案してほしい」と依頼するための文書です。
ここで押さえておきたいのは、RFPは仕様書ではないという点です。RFPが定義するのは「解決したい課題」と「満たすべき条件」であり、「どう作るか」という手段は提案側に委ねます。手段まで細かく指定してしまうと、ベンダーが持つ知見やより良い代替案を引き出せなくなり、RFPを出す意味が薄れてしまいます。
逆に、発注先がすでに決まっていて金額も小さい単発業務であれば、正式なRFPまで整えず、簡易な依頼メモで足りるケースもあります。RFPは作成にも評価にも工数がかかるため、案件の規模と比較の必要性で判断してください。
RFPと混同されやすい文書がいくつかあります。目的と登場するタイミングで整理すると分かりやすくなります。
流れとしては、RFI → RFP → 選定 → 契約 → 要件定義、という順序になります。RFPの段階で要件定義書レベルの精度を求める必要はありません。
条件を揃えずに提案を求めると、A社は保守費込み、B社は初期構築のみ、といった具合に前提が食い違い、価格も内容も比較できなくなります。RFPで前提を明示すれば、提案は同じ条件下で並べられます。
RFPを書く過程では、関係部署の要望を集めて優先順位をつける作業が必ず発生します。この作業自体が、社内で曖昧なままだった目的や譲れない条件を可視化してくれます。
プロジェクト後半で発覚する「聞いていない」「含まれていると思っていた」というトラブルは、スコープが文書化されていないことが原因です。RFPは、契約後の認識合わせの土台としても機能します。
評価基準を事前に定めたRFPがあれば、「なぜこの会社を選んだのか」を稟議や監査の場で客観的に説明できます。属人的な判断に見えない選定プロセスは、社内の合意形成を大きく楽にします。
業種やプロジェクトの性質を問わず、おおむね次の11項目を押さえておけば提案依頼書として成立します。
なぜ今このプロジェクトに取り組むのか、達成したい状態は何かを書きます。「サイトを新しくしたい」ではなく「問い合わせ件数を月30件から60件に増やしたい」のように、目指す成果まで書くと提案の質が変わります。自社の事業概要や体制も簡潔に添えます。
現行システムやサイトの構成、運用フロー、実績データ（アクセス数、処理件数、工数など）と、そこで起きている問題を具体的に記載します。数値と事実で書くほど、提案側は的確な打ち手を出せます。
依頼する範囲と、依頼しない範囲の両方を書くのがポイントです。「原稿・写真は自社で用意」「保守は別契約」のように境界を明示しておくと、後の追加費用トラブルを避けられます。
必要な機能（機能要件）に加えて、性能、セキュリティ、可用性、対応ブラウザ、アクセシビリティ、既存システムとの連携といった非機能要件も忘れずに記載します。それぞれに「必須」「推奨」「任意」の区分をつけると、予算に応じた提案の幅が生まれます。
何が納品されれば完了とみなすかを定義します。デザインデータ、ソースコード、設計書、マニュアル、著作権・ソースコードの帰属など、後から揉めやすい部分ほど先に書いておきます。
公開・稼働の希望日と、動かせない制約（キャンペーン開始日、既存契約の満了日など）を書きます。制約が明確なら、提案側は実現可能性を踏まえた工程を組めます。
上限額または想定レンジを提示します。初期費用と運用費用を分けて示すと、比較しやすい見積が返ってきます。予算を隠すと、実現不可能な提案や過剰な提案が混ざり、比較工数が無駄に増えます。
自社側の担当者と意思決定者、稼働可能な工数、会議の頻度などを示します。発注側がどれだけ動けるかによって、ベンダーが提案すべき進め方は変わります。
提案書に含めてほしい項目（実現方針、体制図、スケジュール、見積内訳、類似実績、リスクと対策など）を列挙します。目次レベルで指定すると、各社の提案書が同じ構成で揃い、比較が一気に楽になります。
何を、どの重みで評価するかを事前に開示します。たとえば「課題理解と提案内容40点、実績・体制25点、費用25点、運用サポート10点」といった配点です。基準を先に公開しておくと、提案の焦点が定まり、社内の評価もぶれません。
提出期限、提出先、ファイル形式、質問受付期間と回答日、プレゼンテーションの有無と日程、選定結果の通知時期を記載します。秘密保持の扱いについても一言添えておきます。
以下の構成をそのまま見出しとして使い、各項目を埋めていけばRFPとして機能します。A4で10〜20ページ程度が目安です。
利用部門、情報システム部門、経営層など、関わる立場ごとに困りごとと期待を集めます。この段階では取捨選択せず、まず全部出し切るのがコツです。
集めた要求を「必須（これがないと導入する意味がない）」「推奨（あると効果が上がる）」「任意（余力があれば）」に仕分けます。すべてを必須にしてしまうと、予算内で収まる提案が返ってこなくなります。
前章の構成に沿って書き上げ、配布前に決裁者の合意を取っておきます。提案を受け取ってから前提が覆るのが、最も避けたい事態です。
質問は書面で受け付け、回答は全社に共有するのが公平です。この質疑応答で出てくる質問の内容自体が、RFPの不足箇所を教えてくれます。
RFPで公開した配点に沿って、複数名で個別に採点してから議論します。先に議論すると声の大きい意見に引きずられるため、採点を先に済ませるのが定石です。
開示を推奨します。「安く抑えたいから隠す」という発想は理解できますが、実際には予算感の合わない提案が混ざって比較が難しくなるだけです。上限を示したうえで、その範囲内での最善案を求めるほうが、結果的に良い提案が集まります。
A4で10〜20ページ程度が一般的です。ただし分量より、判断に必要な情報が揃っているかが重要です。詳細な画面一覧やデータ定義は本文に詰め込まず、別添資料に分けると読みやすくなります。
出せます。むしろRFPは、要件が完全に固まる前に「解決したい課題」を提示して知恵を借りる文書です。固まっていない部分は「未確定」と明記し、その領域についての提案も歓迎する旨を書いておくと、建設的な提案が返ってきます。
必要です。工数をかけて提案してもらった以上、結果は速やかに通知し、可能な範囲で理由も伝えます。丁寧な対応は自社の評判につながり、次回以降のコンペで良い会社に参加してもらえるかどうかを左右します。
RFP（提案依頼書）は、外部パートナーに「解決したい課題」と「満たすべき条件」を伝え、比較可能な提案を集めるための文書です。背景と目的、課題、スコープ、要件、予算、評価基準という骨格を押さえれば、形式にこだわらなくても十分に機能します。
作成の手間は決して小さくありませんが、その過程で社内の要求が整理され、選定後の手戻りが減ることを考えれば、投じる価値のある工数です。まずは本記事のテンプレート構成をたたき台に、自社の案件に合わせて項目を足し引きするところから始めてみてください。
Web制作・広告施策の見積もりはなぜ比較しづらいのか。見積書で確認すべき欄、人月計算の仕組みと費用相場の目安、陥りやすい6つの落とし穴、妥当性を判断するチェック項目を解説します。
