システム開発のRFP（提案依頼書）の書き方｜5ステップと記載項目一覧

システム開発のRFP（提案依頼書）は、①導入の背景・目的・対象範囲を固める、②現状と将来のシステム構成を1枚に整理する、③要求機能一覧を作る、④納期・保守などの納品条件を決める、⑤1つの文書にまとめて複数社へ送る、の5ステップで作成します。開発会社への発注で失敗する原因の多くは、要求が文書化されていないことによる認識のズレです。この記事では、記載すべき項目の一覧と各ステップの実務、中小企業がつまずきやすいポイントまで、発注前の準備を具体的に解説します。

RFP（提案依頼書）とは？なぜ必要？

RFP（Request for Proposal・提案依頼書）とは、システムを発注したい会社が「どんな背景で、何を解決するために、どんなシステムが欲しいか」を文書にまとめ、開発会社に提案を依頼するための書類です。複数の開発会社に同じRFPを渡し、返ってきた提案書と見積もりを比較して1社に絞り込む、という使い方をします。

RFPが必要な理由の1つ目は、見積もり条件の統一です。口頭の説明だけで依頼すると、各社が自分の解釈で見積もるため、同じ依頼のつもりでも金額が数百万円から数千万円まで開くことがあります。同じ文書を基準にすることで、金額・体制・スケジュールを同じ土俵で比較できるようになります。

2つ目は認識違いの防止です。システム開発のトラブルの多くは、発注側と開発側の認識のズレから始まります。「そんな要望は聞いていない」「その機能は追加料金になる」という言った言わないの争いは、最初に要求を文書化しておくことで大部分を防げます。文書化は開発会社のためではなく、発注側自身を守る作業です。

似た用語に、情報収集のためのRFI（情報提供依頼書）と、概算費用を把握するためのRFQ（見積依頼書）があります。何を作るべきかが固まっていない段階ではまずRFIで各社から情報を集め、必要ならRFQで概算を取り、最後にRFPで正式に提案を依頼する、という順番で使い分けます。

RFPに書く項目の一覧

RFPの項目は「概要」「要求事項」「選定の進め方」の3ブロックで整理すると書きやすくなります。概要には背景・目的・対象範囲と現状を、要求事項には必要な機能と納品条件を、選定の進め方には提案手続き・評価の観点・予算と契約条件を書きます。

すべての項目を完璧に埋める必要はありません。特に性能やセキュリティなどの非機能要件は専門知識が必要なため、分かる範囲で「重視すること」を書き、詳細は提案側に確認してもらう形で問題ありません。項目の抜けよりも、目的と要求機能が曖昧なことのほうが提案の質を下げます。

RFP作成の5ステップ

①背景・目的・対象範囲を固めます。「受注処理に毎日2時間かかっており半分にしたい」のように、解決したい課題と対象業務を具体的な言葉にします。目的が曖昧なままだと、この後の機能整理がすべてぶれるため、最初に時間をかける価値があります。

②現状と将来のシステム構成を整理します。いま使っているツール・データ・帳票の流れを1枚の図にまとめ、システム導入後にどう変わるかを並べて描きます。1枚に収めることで全体像が把握でき、データの流れの矛盾にも気づけます。③要求機能一覧を作ります。RFPの中核なので、作り方は次の章で詳しく説明します。

④納品条件を決めます。希望納期、既存データの移行方法、操作研修の有無、稼働後の保守・運用体制まで含めて書き出します。⑤最後に①〜④を1つの文書にまとめ、提案の手続きと評価の観点を添えて複数社へ送ります。中小企業の業務システムであれば、A4で数ページにまとまれば発注準備として十分に機能します。

提案の質を左右する要求機能一覧の作り方

RFPの中で提案と見積もりの精度を最も左右するのが要求機能一覧です。業務を大項目・中項目に分解し、それぞれに「業務内容」「業務量」「必要な機能」「優先度」を付けて表にします。例えばスタッフ管理なら、大項目「スタッフ管理」、中項目「スタッフ登録」、業務内容「氏名・連絡先・シフト希望の登録」という粒度です。

業務量（月間の処理件数や作業時間）を書いておくと、開発会社が処理の規模を見積もりやすくなり、提案の精度が上がります。優先度は「必須」と「あれば望ましい」の2段階で十分です。見積もりが予算を超えたときに、優先度の低い機能から削るという判断がその場でできるようになります。

機能一覧を作る前に、対象業務の流れを順番に書き出しておくと機能の抜けが減ります。誰が・どんな情報を受け取り・何に記録し・誰に渡すか、という業務の棚卸しが済んでいれば、要求機能一覧はその写しに近い作業になります。

RFPを送った後はどう進める？提案の比較と選定

RFPを送った後の対応にもコツがあります。提案期間中には各社から質問が届きますが、1社から受けた質問とその回答は、全社に同じ内容で共有してください。特定の会社だけが多くの情報を持つ状態になると提案の前提が揃わなくなり、せっかく条件を統一した意味が薄れてしまいます。

提案書が集まったら、あらかじめ決めておいた評価の観点で採点します。観点は、要求機能をどれだけ満たすか、開発体制と類似案件の実績、稼働後の保守・運用、金額の4つが基本です。最安値の提案が最良とは限りません。要求機能一覧への回答が具体的な会社ほど、こちらの業務を理解して見積もっていると判断できます。

2〜3社に絞り込んだ段階で、画面イメージのデモや追加説明を依頼するのも有効です。文書だけでは分からない担当者との相性や回答の速さは、開発が始まってからの進めやすさに直結します。選定した会社とは、RFPと提案書を土台にそのまま要件定義へ進めるため、RFP作成にかけた時間はここで回収できます。

中小企業がつまずくポイントと対処

実際の支援現場でよくあるのは、完璧なRFPを作ろうとして発注準備そのものが止まってしまうケースです。IT専任の担当者がいない会社では、専門用語で書こうとせず、業務の言葉のまま「誰が・何を・どれくらいの量・どう困っているか」を書いてください。それを要件に翻訳するのは提案側の仕事です。

予算を書かないのも失敗のもとです。予算を伏せると各社の提案の前提がばらばらになり、比較のしようがなくなります。1点で書きにくければ「◯◯万円以内」と上限や幅で示せば、その範囲で現実的な構成の提案が集まります。開発費用の相場観は、規模や作り方で大きく変わるため関連記事で確認してください。

当社（UniGain）の業務アプリ・システム開発は80万円からで、RFPが未整備の段階でも業務の棚卸しと要求整理から一緒に進めています。支援した業務システム構築では工数60%削減・対応速度2.5倍という結果が出ており、詳細は事例ページで紹介しています。要求が文書になっているだけで、どの会社に発注する場合でも提案の質は大きく変わります。