IPA「ソフトウェア開発データ白書」によると、システム開発プロジェクトの約30%がスケジュール超過、約25%が予算超過に陥っている。その最大の原因の一つが「要件の不明確さ」であり、RFP（Request for Proposal：提案依頼書）の品質がプロジェクトの成否を大きく左右する。

しかし「RFPをどう書けばよいか分からない」「テンプレートが欲しい」という声は、特にRFP作成経験の少ない中小企業から多く寄せられる。本記事では、システム開発のRFPの書き方を、テンプレート構成とともに実践的に解説する。

目次

  1. RFPとは何か・なぜ必要か
  2. RFPの基本構成（テンプレート）
  3. 各セクションの書き方と記載例
  4. ベンダーに伝えるべき情報チェックリスト
  5. 良いRFP・悪いRFPの具体例
  6. RFP作成から提案評価までのプロセス
  7. よくある失敗パターンと対策
  8. まとめ
  9. FAQ

1. RFPとは何か・なぜ必要か

RFPの定義と目的

RFP（Request for Proposal：提案依頼書）とは、システム開発を外部のベンダー（開発会社）に依頼する際に、要件や条件をまとめた文書だ。以下の3つの目的がある。

目的内容
要件の明確化自社が「何を実現したいか」を整理し、言語化する
提案の比較複数ベンダーから同条件で提案を受け、客観的に比較する
認識の一致発注者とベンダーの間で認識のズレを防ぐ

RFPなしで発注した場合のリスク

リスク発生確率影響度
見積もり金額のばらつきが大きく比較できない高中
開発途中で要件の追加・変更が頻発し、費用が膨らむ高大
ベンダーの提案が的外れになる中大
プロジェクト開始後に「言った・言わない」の問題が発生高大
システム開発の要件定義テンプレートについては業務システム要件定義テンプレートも参照されたい。

セクションまとめ：RFPは「提案を比較可能にする」ための文書。RFPなしの発注は、見積もりのばらつき、要件変更の頻発、認識のズレといったリスクを大幅に高める。

2. RFPの基本構成（テンプレート）

全体構成

#セクションページ数目安必須/任意
1会社概要・プロジェクト背景1〜2ページ必須
2プロジェクトの目的・ゴール1ページ必須
3現状のシステム構成1〜3ページ必須
4機能要件3〜10ページ必須
5非機能要件1〜3ページ必須
6スケジュール・マイルストーン1ページ必須
7予算1ページ推奨
8提案の評価基準1ページ推奨
9提案のフォーマット・提出期限1ページ必須
10契約条件・制約事項1〜2ページ推奨
合計12〜25ページ

ページ数の目安

プロジェクト規模RFPのページ数作成期間
小規模（500万円以下）5〜10ページ1〜2週間
中規模（500〜3,000万円）10〜20ページ2〜4週間
大規模（3,000万円以上）20〜50ページ1〜2ヶ月
セクションまとめ：RFPは10セクションで構成し、中規模プロジェクトなら10〜20ページ、作成期間は2〜4週間が目安だ。

3. 各セクションの書き方と記載例

1. 会社概要・プロジェクト背景

記載すべき内容：

  • 会社の事業内容、従業員数、年商
  • プロジェクトの発端となった課題・背景
  • 関連する社内の意思決定状況

良い記載例：「当社は従業員150名の製造業。現在の受注管理はExcelで行っており、月間約500件の受注を3名で処理している。入力ミスが月平均15件発生し、顧客クレームにつながっている。受注管理システムの導入により、入力ミスの削減と処理時間の短縮を目指す。」

悪い記載例：「業務効率化のためにシステムを導入したい。」

2. 機能要件の書き方

機能カテゴリ機能名優先度説明
受注管理受注登録必須顧客名、商品、数量、納期を登録。CSVインポート対応
受注管理受注一覧・検索必須顧客名、日付、ステータスで検索。CSV出力対応
受注管理ステータス管理必須受注→製造→出荷→完了のステータス遷移
在庫管理在庫照会高商品別の在庫数をリアルタイム表示
レポート月次売上レポート中顧客別、商品別の売上集計を自動生成

3. 非機能要件の書き方

カテゴリ要件具体的な指標
性能レスポンス時間画面表示が3秒以内
可用性稼働率99.5%以上（月間ダウンタイム3.6時間以内）
セキュリティ認証ID/パスワード＋二要素認証
セキュリティデータ暗号化通信はTLS 1.3以上、保存データはAES-256
拡張性ユーザー数現在50名、3年後100名を想定
運用バックアップ日次バックアップ、30日保持
セクションまとめ：機能要件は「優先度」を明記し、非機能要件は「具体的な数値」で記載する。曖昧な表現（「速い」「安全」等）は避ける。

4. ベンダーに伝えるべき情報チェックリスト

#チェック項目記載の目的
1プロジェクトの背景と目的ベンダーが「なぜこのシステムが必要か」を理解する
2現行システムの構成図連携が必要なシステムの把握
3利用ユーザーの属性と人数画面設計・性能設計の前提条件
4業務フロー（現状 As-Is）現在の業務の流れとペインポイント
5業務フロー（理想 To-Be）システム導入後に実現したい業務の流れ
6機能一覧と優先度提案範囲と見積もりの基準
7非機能要件性能・セキュリティ・可用性の前提条件
8予算の概算または上限提案内容の現実性を担保
9スケジュールの希望納期の制約条件
10提案の評価基準ベンダーが何を重視して提案すべきか
11契約条件（瑕疵担保、知財等）後のトラブル防止
12提出フォーマットと期限提案内容の比較をしやすくする

5. 良いRFP・悪いRFPの具体例

比較表

項目良いRFP悪いRFP
背景「月500件の受注を3名で処理、入力ミス月15件」「業務効率化したい」
機能要件「受注登録：顧客名/商品/数量/納期、CSV取込対応」「受注管理ができること」
非機能要件「レスポンス3秒以内、稼働率99.5%以上」「速くて安定していること」
予算「初期費用1,000万円以内、ランニング月額30万円以内」「なるべく安く」
評価基準「技術力40%、費用30%、実績20%、提案力10%」記載なし

6. RFP作成から提案評価までのプロセス

ステップ内容期間目安
1. 社内ヒアリング業務部門の課題・要望を収集1〜2週間
2. RFP作成要件整理、ドキュメント作成2〜4週間
3. ベンダー候補の選定3〜5社に絞り込み1週間
4. RFP配布・説明会ベンダーへのRFP送付、質疑応答1週間
5. 提案受領ベンダーからの提案書受領2〜4週間
6. 提案評価・選定スコアリング、プレゼン評価1〜2週間
7. 契約交渉条件の調整、契約締結1〜2週間
合計8〜15週間

7. よくある失敗パターンと対策

失敗パターン原因対策
要件が曖昧で見積もりがバラバラ機能要件の粒度が粗い画面一覧、帳票一覧まで落とし込む
重要な非機能要件が漏れるセキュリティ・性能要件の検討不足チェックリストを使って網羅的に確認
予算を書かず的外れな提案が来る予算の開示をためらう概算予算または上限額を記載する
提案の比較ができないベンダーごとに提案の粒度が異なる提案フォーマットを統一し、比較表を用意
社内の合意形成不足業務部門の要望をIT部門だけで判断業務部門のキーパーソンをRFP作成に巻き込む

8. まとめ

RFP作成の成功ポイントは以下の3つだ。

  1. 背景と目的を具体的に書く：数字で現状の課題を示す
  2. 機能要件は優先度付きで詳細に：曖昧な表現を排除し、画面・帳票レベルまで記載する
  3. 非機能要件と予算を明示する：具体的な数値目標と予算感を伝えることで、提案の精度が上がる

要件定義のテンプレートについては業務システム要件定義テンプレートも参照されたい。

RFP作成・システム開発のご相談はお問い合わせフォームよりお気軽にどうぞ。

9. FAQ

Q1. RFPは必ず作成しなければいけませんか？

法的な義務はないが、500万円以上のプロジェクトでは作成を強く推奨する。RFPがないと、ベンダーごとに前提条件が異なり、見積もりの比較が困難になる。少なくとも「プロジェクト概要」「機能一覧」「予算」「スケジュール」の4点は書面で伝えるべきだ。

Q2. 予算をRFPに書くとベンダーに上限まで見積もられませんか？

その懸念はもっともだが、予算を書かないデメリットの方が大きい。予算を書かないと、1,000万円の予算に対して5,000万円の提案が来るような「的外れ」が発生する。「予算上限1,000万円」と書くことで、その範囲内での最適な提案を引き出せる。

Q3. RFP作成を外部に依頼できますか？

ITコンサルティング会社やPMO専門会社にRFP作成を依頼することは可能だ。費用は50〜200万円程度。自社にIT企画の経験者がいない場合は、投資に見合う価値がある。ただし、業務要件は社内でしか定義できないため、外部に丸投げすると質が低下する。

Q4. RFPの配布先は何社が適切ですか？

3〜5社が適切だ。2社では比較の母数が少なく、6社以上では評価に時間がかかりすぎる。事前にWebサイトや口コミで候補を絞り込み、RFP配布前に各社の概要を確認しておくとよい。

Q5. RFPに書く機能要件はどこまで詳細にすべきですか？

画面一覧（各画面の入出力項目）と帳票一覧（出力帳票の種類・項目）まで落とし込めるのが理想だ。ただし、初めてRFPを作成する場合は「やりたいこと」を箇条書きでまとめるだけでも、口頭で依頼するよりはるかに精度の高い提案を受けられる。

追加の一次情報・確認観点

この記事の内容を社内で検討する場合は、一般論だけで判断せず、次の一次情報と自社データを照合してください。特に、稟議・RFP・ベンダー選定では「何を実装するか」よりも「どのリスクをどの水準まで下げるか」を先に決めると、見積もり比較のブレを抑えられます。

確認領域参照先自社で確認すること
デジタル調達デジタル庁要件定義、調達、プロジェクト管理の標準観点を確認する
Webアプリ品質OWASP ASVS認証、認可、入力検証、ログ、セッション管理を確認する
DX推進経済産業省 DXレガシー刷新、経営課題、IT投資判断の前提を確認する
DX推進IPA デジタル基盤センターDX推進指標、IT人材、デジタル基盤の観点で現状を確認する
個人情報個人情報保護委員会個人情報・委託先管理・利用目的・安全管理措置を確認する

稟議・RFPで使う数値設計

投資判断では、導入前後で測れる指標を3から5個に絞ります。下表のように、現状値・目標値・測定方法・責任者をセットにしておくと、PoC後に本番化するかどうかを判断しやすくなります。

指標現状確認目標の置き方失敗しやすい例
対象業務数現状の対象業務を棚卸し初期は1から3業務に限定対象を広げすぎて要件が固まらない
月間処理件数件数、担当者、例外率を確認上位20%の高頻度業務から改善件数が少ない業務を先に自動化する
例外対応率手戻り、確認待ち、属人判断を計測例外の分類と承認ルールを定義例外をAIやシステムだけで吸収しようとする
追加要件率過去案件の変更件数を確認要件凍結ラインを設定見積後に仕様が増え続ける
障害・手戻り件数問い合わせ、障害、改修履歴を確認受入基準とテスト観点を定義テストをベンダー任せにする

よくある失敗と回避策

失敗パターン起きる理由回避策
目的が曖昧なままツール選定に入る比較軸が価格や機能数に寄る経営課題、業務課題、測定KPIを先に固定する
現場確認が不足する例外処理や非公式運用が見落とされる担当者ヒアリングと実データ確認を必ず行う
運用責任者が決まっていない導入後の改善が止まる業務側とIT側の責任分界をRACIで定義する
RFPが抽象的で見積が比較できない業務フロー、データ、非機能要件が不足見積前に要件定義と受入条件を固める

GXOに相談する前に整理しておく情報

初回相談では、次の情報があると診断と提案の精度が上がります。すべて揃っていなくても問題ありませんが、分かる範囲で用意しておくと、概算費用・期間・体制の見立てを早く出せます。

  • 対象業務の現行フロー、利用中システム、Excel・紙・チャット運用の一覧
  • 月間件数、担当人数、手戻り件数、確認待ち時間などの概算
  • 個人情報、機密情報、外部委託、権限管理に関する制約
  • 希望開始時期、予算レンジ、社内承認者、決裁までの流れ
  • 既存システム構成、画面・帳票・データ項目、外部連携、現行ベンダー契約

GXOでは、現状整理、要件定義、RFP作成、ベンダー比較、PoC設計、本番移行計画まで一気通貫で支援できます。記事の内容を自社に当てはめたい場合は、まずは現在の課題と制約を共有してください。