RFPの書き方。提案を同じ条件で比べられないなら発注しない

開発会社へ声をかける日が迫っているのに、提案依頼書は白紙のままです。社内では欲しい機能の話が増え、候補会社からは予算と納期を聞かれます。何から書けばよいのか分からず、「RFP 書き方」と検索した人もいると思います。

僕は、RFPを書けない状態で開発を発注してはいけないと考えています。ただし、画面や機能を完璧に決めた文書は要りません。必要なのは、各社の提案を同じ条件で比べ、選んだ理由を社内で説明できる状態です。

RFPを作る作業は、文章が得意な担当者へ任せる事務仕事ではありません。何のために予算を使い、どの業務を変え、何を会社側で引き受けるかを決める経営の仕事です。

RFPとは、発注先へ同じ問いを渡す提案依頼書です

RFPは「Request for Proposal」の略で、日本語では提案依頼書と呼ばれます。発注先候補へ同じ背景と条件を渡し、進め方、体制、費用、期間、リスクへの回答を求める文書です。

RFPの目的は、発注者が設計を完成させることではありません。発注者が決める条件と、開発会社に提案してほしい範囲を分けることです。何も決めずに丸投げする状態と、全機能を先回りして固定する状態の間に、提案を受け取れる場所を作ります。

経営側が最初に決める内容は、なぜ今取り組むのか、どの業務をどこまで変えるのか、誰が利用し、誰が結果を承認するのかです。予算の上限、動かせない公開日、必ず接続する既存システムも会社側で示します。

技術に詳しくない経営者が、データ構造やクラウド構成まで決める必要はありません。一方で、「最適な形を提案してください」の一文だけでは、開発会社が事業上の優先順位まで代わりに決める形になります。現場担当者、予算を承認する人、システムを運用する人が資料を持ち寄り、開発会社へ答えてほしい問いを作ります。

業務の開始地点や終了地点も説明できない場合は、開発一式を固定金額で頼む段階ではありません。現行業務の調査、利用者への聞き取り、画面の試作までを先に依頼し、調査結果から開発範囲を決めます。分からない範囲を隠さず、調査する仕事として切り出すほうが安全です。

最小限のRFPの書き方は、業務の開始と完了から始めます

最初のページには、案件名、責任者、提案の提出期限、選定予定日を書きます。続けて、現在の業務がどこから始まり、誰のどの操作で終わるのかを文章にします。

「受発注を効率化したい」だけでは、対象範囲を見積もれません。「取引先から注文を受け、在庫を確認し、担当者が出荷指示を確定するまで」のように、入力と完了をつなぎます。通常の流れに加え、注文の取消し、入力間違い、外部連携の失敗時に誰が戻すのかも書きます。

次に、変えたい結果を記載します。「使いやすくする」「生産性を上げる」では評価できません。現在使っている表計算シート、処理待ちの件数、問い合わせ記録など、社内で実際に確認できる資料を指定し、導入後に同じ単位で確認する数字を選びます。

対象と対象外も対にして書きます。注文登録は開発対象ですが、会計システムの改修は対象外、過去データの移行は必要ですが、紙資料の入力は社内で行う、という形です。

対象外の仕事には、社内の担当者と完了日も置きます。担当者が空欄なら、開発会社の見積もりへ戻す必要があります。

固定する条件と提案を求める部分を分けます。法令や取引条件による保存期間、利用開始日、接続必須のサービスは固定条件になります。画面配置、使用製品、開発手法を発注側で決める理由がない場合は、候補会社に選択肢と採用理由を書いてもらいます。

提案書の回答形式もRFPへ入れます。作業範囲、予定表、担当者の役割、成果物、前提条件、対象外、初期費用と運用費、公開後の支援、主なリスクを同じ章立てで回答してもらいます。金額だけを一枚で受け取ると、要件定義を含む会社と実装だけを含む会社を比べられません。

相見積もりを同じ条件で取り、見積書の項目とRFPの章を対応させます。未確定の範囲には空欄を認めず、見積もり時に置いた仮定と、金額や期限が変わる条件を書いてもらいます。

RFPの書き方には、質問受付と改訂方法まで含まれます

RFPをメールへ添付した時点で、発注側の仕事は終わりません。候補会社が現行画面を確認できる日時、質問期限、回答日、改訂版を配る方法を先に決めます。

一社から「過去データの移行範囲が読めない」と質問された場合、依頼内容に影響する回答は全社へ共有します。一社だけが詳しい画面やデータを見られると、提案条件が揃いません。会社名や提案上の秘密を除き、RFPへ反映する回答を同じ版で配ります。

2026年7月11日に確認したデジタル庁の標準ガイドライン解説書も、RFPの内容、提案手続、評価基準、審査方法を対応させ、提案へ重要な影響がある応答を関係事業者へ通知する考え方を示しています。政府情報システムの調達を対象にした参考文書であり、民間企業へ同じ様式を求める規則ではありません。候補会社が同じ情報から提案する運用の参考として使います。

質問を受ける担当者には、社内資料を開ける環境と回答期限を与えます。営業部門への確認に毎回一週間かかるのに、翌日回答を約束しても運用できません。業務に関する回答は現場責任者、予算や公開日に影響する回答は決裁者が確認する流れをRFP配布前に決めます。

回答によって対象範囲が変わった場合は、ファイル名に版番号と更新日を入れ、変更点を一ページへまとめます。古い版で作った提案書を受け取らないよう、候補会社から最新版の受領確認も取ります。口頭説明だけを増やさず、次の担当者が同じ条件を追える記録へ戻します。

RFPの評価基準は、提案書が届く前に作ります

評価表はRFPを配る前に作ります。縦の行へ必須業務、対象外、移行データ、接続先、受入条件、公開後の担当を置き、横の列へ候補会社名を置きます。提案書が届く前に空の比較表を作ると、RFPで聞き忘れた項目が見えます。

必須条件は、点数で埋め合わせません。利用者の権限を分けられない提案や、必要なデータを移行できない提案は、価格が低くても発注候補に残せない場合があります。最初に合否条件を確認し、合格した提案だけを費用、進め方、保守、引き継ぎで比べます。

点数を付ける項目には、評価する資料も指定します。「技術力が高い」では担当者の印象になります。「同じ規模の実績」だけでも案件との関係を読めません。

候補会社には、今回と近い業務、移行方法、開発手法について、担当した範囲と今回の提案へ使える知見を説明してもらいます。

提案説明には、契約後に開発を率いる予定の人にも参加してもらいます。営業担当者の説明が上手かではなく、最大の不確実性、発注側が期限までに用意する資料、仕様変更時に動く費用や日程を聞きます。

開発手法を候補会社へ提案してもらう場合は、発注者が選ぶアジャイルとウォーターフォールの違いを先に読み、発注側が仕様を決める時期を確認します。手法名だけを採点せず、会議へ誰が出て、何をいつ決めるのかを提案書へ書いてもらいます。

完成条件は、選定後まで先送りしません。システム開発の検収項目を着手前に作る方法を参考に、誰が、どの画面で、どのデータを使い、何が表示されたら受け入れるのかをRFPへ置きます。詳細を要件定義で詰める場合も、受入条件を決める作業と担当者は見積もりへ含めます。

RFP、選んだ提案書、質疑回答は、発注後の要件定義や個別契約から切り離しません。提案時の前提が最終文書のどこへ反映されたかを照合し、食い違いが残る場合は署名前に両社の責任者と契約担当者で直します。

発注できるRFPか、空の比較表で確かめます

明日は、現在の業務手順、実際に使う帳票やデータ、既存システムの構成図、動かせない予定を机へ出してください。資料が存在しない業務は、現場担当者と開始から完了まで画面を操作し、画面記録と判断箇所を残します。

次に一ページだけ書きます。なぜ今変えるのか、誰が使うのか、業務はどこからどこまでか、動かせない条件は何か、候補会社へ何を提案してほしいかを文章にします。機能一覧から始めるより、提案の目的がぶれません。

一ページを基に空の比較表を作ります。各行について、候補会社が同じ形式で答えられるか、社内の誰が回答を評価するか、根拠資料を開けるかを確認します。空欄が見つかったら、推測で埋めず、RFPの質問へ戻します。

現場担当者が打ち合わせへ出られない、現在のデータを確認できない、提案を選ぶ人が決まっていない場合は、配布日を先に置かないでください。社内の準備不足を短い提案期限で候補会社へ移しても、比較できない見積書が早く届くだけです。

RFPは、ページ数で完成を判断する文書ではありません。同じ問いに対する各社の回答が比較表へ入り、選ばなかった提案の理由まで説明できたら発注へ進めます。説明できない行が残るなら、発注ではなくRFPの改訂を選んでください。