RFPの書き方完全ガイド｜システム開発を成功に導く9項目

システム開発を外部に依頼するとき、最初の関門になるのがRFP（提案依頼書）の作成です。

とはいえ、「何をどこまで書けばよいのかわからない」「テンプレートの項目は埋めたものの、適切な提案を受けられる内容なのか判断できない」といった声は多く聞かれます。

RFPの内容は、提案の質と見積もりの精度を左右します。記載が曖昧なままだと、開発会社が要望や条件を正しく把握できず、自社の意図に沿った提案を受けにくくなります。

本記事では、RFPに記載したい必須9項目と作成手順に加え、自社の要望を開発会社へ正確に伝え、適切な提案や見積もりを受けるためのポイントを解説します。

記事の最後には提出前に使えるチェックリストもまとめていますので、これからRFPを作成する方はぜひ最後までご覧ください。

RFP（提案依頼書）とは？作成する3つのメリット

RFPとは「Request For Proposal」の略で、日本語では提案依頼書と訳されます。

システム開発やツール導入を外部に委託する際、発注候補となる開発会社に自社の要求を伝え、具体的な提案を依頼するための文書です。

RFPは仕様を指示する文書というよりも、より良い提案を引き出すための依頼文書という位置づけになります。

RFPを作成する3つのメリット

RFPの作成は義務ではありませんが、用意しておくことで次のようなメリットがあります。

1. 各社の提案を同じ条件で比較でき、金額の妥当性を判断しやすくなる
2. 見積もりの精度が上がり、想定外の追加費用を抑えられる
3. 社内の要望と優先順位が整理され、発注後の認識のずれを防げる

1つ目は、特に効果を実感しやすい部分です。

口頭やメールだけで依頼すると、A社は開発費用のみ、B社は運用保守を含めた金額を提示するといった状況が起こり、金額の大小では判断できなくなります。

2つ目については、開発会社が前提を推測して見積もる必要がなくなるため、リスク分の上乗せが起こりにくくなります。

RFPを丁寧に作り込むことは、結果として発注側のコスト面にもプラスに働きます。

3つ目は社内向けの効果で、作成の過程で現場と経営層の期待のずれが表面化し、その調整を発注前に済ませられます。

システム開発全体の進め方については、【【初心者でも安心】システム開発の手順を徹底解説！プロが教える成功する7つの工程】もあわせてご確認ください。

RFI・要件定義書との違い

RFPと混同されやすい文書に、RFIと要件定義書があります。

最も大きな違いは、RFPの段階では「何を実現したいか」を書き、要件定義書の段階で「どう実現するか」を決めるという役割分担にあります。

RFPに細かい画面仕様やデータベース構造まで書き込むと、開発会社は指定された方法をなぞる形になり、費用を抑えた代替案が提案されにくくなります。

RFIは情報収集のための文書なので、候補が多い場合の絞り込みに使い、3社から5社に絞ってからRFPを提示する流れが一般的です。

規模の小さいプロジェクトであれば、RFIを省略しても問題ありません。

RFPに記載する必須9項目

RFPに決まった書式はありませんが、提案を引き出すために必要な項目はおおむね共通しています。

項目	記載する内容
1. プロジェクトの背景	なぜ今このプロジェクトを実施するのか
2. 目的とゴール	導入によって達成したい状態と評価の指標
3. 現状の課題と業務内容	現在の業務の流れと発生している問題
4. 対象範囲	対象となる業務・部門・システムの範囲
5. 機能要求	システムに求める機能と優先順位
6. 非機能要求	性能・セキュリティ・可用性・保守に関する要求
7. 予算	想定している費用の範囲と支払条件
8. スケジュール	提案提出から稼働開始までの想定日程
9. 提案依頼事項と選定基準	提案書に含めてほしい内容と評価の観点

これらの9項目を整理しておくことで、開発会社がプロジェクトの目的や条件を理解しやすくなり、より具体的な提案を受けやすくなります。

すべてを最初から確定する必要はありません。未定の項目は「未定」「提案を希望」「調査が必要」などと明記し、現時点での状況を共有することが大切です。

1. プロジェクトの背景

背景には、なぜ今このタイミングで取り組むのかを記載します。

たとえば「現行システムのサポート期限が来年3月に終了する」「受注件数が3年で2倍になり、手作業での管理が追いつかなくなった」といった内容です。

背景が書かれていると、開発会社は優先すべきことを判断しやすくなります。

サポート期限が理由であれば期日を守ることが最優先となり、業務量の増加が理由であれば処理性能や拡張性を重視した構成が検討されます。

過去に同じ課題へ取り組んで途中で止まった経緯がある場合は、その事情も簡潔に書いておくと、同じつまずき方を避ける進め方を提案してもらいやすくなります。

2. 目的とゴール

目的には、システムを導入した後にどのような状態になっていたいかを書きます。このとき、可能な範囲で数値を入れておくことをおすすめします。

• 月末の締め作業にかかる時間を、20時間から5時間程度に短縮する
• 受注データの二重入力をなくし、入力ミスを月10件から数件以内に減らす
• 拠点をまたいだ在庫状況を、リアルタイムで確認できるようにする

数値の目安があると提案の方向性が定まりやすくなり、導入後の効果測定もしやすくなります。

一方で、目的が「システムを刷新する」といった手段のまま書かれていると、提案は全体を広く押さえた内容になりがちです。

手段ではなく、解決したい業務上の状態を書くことが、具体的な提案を受け取るための近道になります。

3. 現状の課題と業務内容

現状の業務の流れと、その中で発生している課題を記載します。「どの部署の誰が、どのタイミングで、何を使って作業しているか」という粒度で書くと、実態が伝わりやすくなります。

現行システムがある場合は、次の情報も添えておくと提案の精度が上がります。

• システム名と導入時期、開発した会社
• 利用しているサーバー環境やデータベースの種類
• 登録されているデータ件数と、1日あたりの処理件数
• 連携している他システムの有無と、その連携方法

これらは移行作業の工数に直結する情報です。

社内で把握しきれていない項目については、「不明」と記載しておくだけでも十分な情報になります。

4. 対象範囲

対象範囲では、今回のプロジェクトに含む業務と含まない業務を明確にします。

含まないものを明記しておくことが、範囲の曖昧さを防ぐうえで効果的です。

たとえば「今回は受注管理と在庫管理を対象とし、会計処理は既存の会計ソフトを継続して利用する」といった書き方になります。対象とする拠点や部門、利用者の人数もあわせて記載しておきましょう。

将来的に対象を広げる構想がある場合は、その見通しも書いておくと、拡張を見越した設計で提案してもらえます。

範囲があいまいなまま進むと、開発途中で「これも対象だと思っていた」という認識の違いが生まれやすくなります。

5. 機能要求

機能要求は、システムに求める機能を一覧にしたうえで、優先度を付けて記載します。

優先度を付ける利点は、予算内に収まらなかった場合の調整がしやすくなることです。

現場から集めた要望をすべて必須として提示すると、開発会社は全機能を含む見積もりしか出せず、予算を超えた時点で調整の余地がなくなります。

必須とする項目は、「これがなければ導入する意味がない」と言えるものに絞っておくと、提案の幅が広がります。

6. 非機能要求

非機能要求とは、機能そのものではなく、システムの品質や運用条件に関する要求です。

• 同時に利用する人数と、想定するデータ量
• 画面表示や検索処理にかかる応答時間の目安
• 稼働する時間帯と、停止が許容される時間
• アクセス権限の管理方法とログの保存期間
• バックアップの頻度と、障害時の復旧目標時間
• 稼働後の保守サポート体制と対応時間帯

非機能要求は専門的に見えるため省略されがちですが、見積もり金額に影響しやすい項目でもあります。

すべてを自社で判断する必要はなく、「平日9時から19時まで利用し、応答時間は月末のみ22時まで」といった実態を書くだけでも十分です。

保守や機能追加を将来的に他社へ依頼する可能性がある場合は、その点も記載しておきましょう。

特定の開発会社に依存する状態を避けたい方は、【ベンダーロックインとは？自社が陥っているか判断する5つの兆候】もあわせてご覧ください。

7. 予算

予算は、可能な範囲で具体的な金額の幅を提示することをおすすめします。

想定規模がわからないと標準的な構成で見積もることが多くなり、自社に合った提案を受けにくくなるためです。

正確な金額が決まっていない段階であれば、次のような書き方でも構いません。

• 初期費用は800万円から1,200万円の範囲を想定している
• 月額の運用費用は10万円以内を上限として考えている
• 予算を超える場合は、機能を分割した段階的な導入も検討できる

3つ目のように調整の余地を示しておくと、複数のプランを比較する形の提案を受けやすくなります。

8. スケジュール

スケジュールには、提案提出の締切から稼働開始までの想定日程を記載します。

工程	時期の記載例
RFP提示・質疑応答	4月上旬から4月中旬
提案書・見積書の提出期限	5月10日
プレゼンテーション	5月中旬
発注先の決定・契約	5月末
稼働開始の希望時期	翌年1月

提案書の作成には、規模にもよりますが2週間から3週間程度かかることが一般的です。

提出期限が短すぎると、提案を見送る会社が出たり、精査しきれていない見積もりが集まったりする場合があります。

3週間程度の期間を確保しておくと、具体的で精度の高い提案を受けやすくなります。

9. 提案依頼事項と選定基準

最後に、提案書に含めてほしい内容と、どのような観点で評価するかを記載します。

• 提案するシステムの全体構成と、採用する技術
• プロジェクトの進め方と、想定する開発期間
• 参画するメンバーの体制と役割
• 類似案件の実績
• 稼働後の保守サポートの内容
• 費用の内訳と、追加費用が発生する条件

提案書の様式や枚数の上限を指定しておくと、各社の提案を横並びで比較しやすくなります。

選定基準を明示しておくことも、双方にとって有益です。価格、実績、開発体制、提案内容、保守・運用体制など、重視する項目を伝えることで、評価の観点に沿った提案を受けやすくなり、各社を比較する際の判断基準も明確になります。

あわせて、質問の受付方法と回答期限、提出先の連絡先も記載しておきましょう。

RFP作成の進め方5ステップ

RFPは、いきなり文書を書き始めると手が止まりやすくなります。

次の5つのステップで進めると、社内の合意を取りながらまとめやすくなります。

1. 現場の課題と要望を洗い出す
2. 目的と優先順位を決める
3. 予算とスケジュールの枠を決める
4. 必須9項目に沿って文書に落とし込む
5. 社内レビューを受けて提示する

最初のヒアリングでは、要望をそのまま機能の形で聞き取るのではなく、どのような場面で困っているのかを聞き出すことが大切です。

集めた内容は課題と要望に分けて一覧にしておくと、そのままRFPの下書きとして使えます。

次に、すべての要望を盛り込むと予算も期間も膨らみやすくなるため、優先順位を付けます。この判断は現場だけでは難しい場合が多く、経営層を含めて合意を取っておくことをおすすめします。

3つ目のステップでは、予算の範囲と稼働させたい時期に加えて、決裁に必要な手続きと期間も把握しておきましょう。

提案を受けてから決裁の流れを検討し始めると、契約までに想定以上の時間がかかる場合があります。

最後のレビューは、情報システム部門だけで完結させず、現場と経営層の双方に依頼します。

提示後に質疑応答の期間を1週間程度設けておくと、認識のずれを早い段階で解消できます。

RFP提出後の流れと提案の比較方法

RFPを提示した後は、質疑応答、提案の受領、比較検討、発注先の決定という流れで進みます。ここでは、提案が集まった後の進め方を解説します。

評価表を作って比較する

提案を比較する際は、あらかじめ評価項目と配点を決めておきます。

評価表を用意しておくと、社内で意見が分かれた際にも根拠を示して説明できます。

配点はプロジェクトの性質に応じて調整して構いませんが、費用の配点を高くしすぎると、金額の安さが判断を左右しやすくなる点には注意が必要です。

評価は担当者ひとりで行わず、現場と決裁者を含めた複数名で点数を付けると偏りを防げます。

見積もりの前提条件を確認する

金額を比較する際は、見積もりの前提条件を必ず確認してください。

特に次の点は、会社によって扱いが分かれます。

• データ移行の作業が含まれているか
• 稼働後の保守費用が別途必要か
• サーバーやライセンスの費用が含まれているか
• 要件定義の工程が含まれているか
• 仕様変更が発生した場合の追加費用の考え方

これらの条件が異なれば、提示金額の差は範囲の違いによるものであり、割高か割安かの判断材料にはなりません。

特に追加費用の考え方は、開発が始まってからのやり取りに影響する部分です。

まとめ｜提出前のチェックリスト

RFPは、開発会社から良い提案を引き出すための土台となる文書です。

提出前の確認用として、次のチェックリストをご活用ください。

確認項目	チェックの観点
背景と目的	手段ではなく、解決したい業務課題として書けているか
現状の情報	現行システムやデータ量を記載し、不明な点は不明と書いているか
対象範囲	含む業務と含まない業務の両方を書けているか
機能要求	すべてを必須とせず、優先度を分けているか
非機能要求	利用人数、稼働時間、保守体制を書けているか
予算	金額の幅または上限を提示しているか
スケジュール	提案期間を3週間程度確保できているか
選定基準	何を重視して評価するかを明示しているか
質疑応答	質問の受付方法と回答期限を書いているか

RFPの段階では「どう実現するか」まで書き込まず、開発会社の提案に委ねる余地を残しておくことも大切です。

完璧な文書を目指す必要はありません。現時点でわかっていることを整理し、不明な点は不明と記載して提示することが、結果として精度の高い提案につながります。

RFP作成やベンダー選定でお悩みなら株式会社アレグビット

RFPの作成は、自社の課題を整理し、優先順位を決めていく作業でもあります。

そのため、「何から手を付ければよいかわからない」「この内容で開発会社に伝わるのか判断できない」といったご相談を多くいただきます。

株式会社アレグビットでは、システム開発の実績をもとに、RFP作成前の課題整理や進め方についても無料でご相談いただけます。

提案を受け取る側の視点から、記載しておいたほうがよい情報や、優先順位の付け方についてもお伝えできます。

システム導入をご検討中の方は、お気軽に株式会社アレグビットまでお問い合わせください。