発注の進め方　／　更新：2026年8月12日

システム開発のRFP（提案依頼書）の書き方

要件が固まっていなくても書けます。曖昧なところを曖昧なまま書くのがコツです。

RFP（提案依頼書）は、開発会社に「こういうものを作りたいので提案してください」と伝える資料です。上手なRFPは、良い提案を引き出すだけでなく、見積もりの精度を上げて総額を下げます。

情報が足りない案件には、開発会社はリスク分を上乗せして見積もるからです。

RFP に書く項目

項目	書く内容	省くとどうなるか
1. 背景・目的	なぜ作るのか。解決したい課題	機能の言われたとおりの実装になり、目的からずれる
2. 現状の業務	いまのやり方、使っているツール、担当部署	ヒアリングが長引き、要件定義の費用が上がる
3. 課題	時間がかかる、ミスが出る、属人化しているなど具体的に	提案が一般論になる
4. 実現したいこと	機能の一覧と、優先度（必須／あれば良い）	全部必須と解釈され、金額が膨らむ
5. 対象範囲	どの部署・どの業務まで。今回やらない範囲も書く	範囲の認識がずれ、後で揉める
6. 利用者	人数、役割、同時に使う人数	性能要件が読めず、過剰または過少な構成になる
7. 既存システム	連携が必要なシステム名、API の有無	連携工数が見積もりから漏れる（最大の追加要因）
8. 非機能要件	稼働時間、止められる時間、データ量、セキュリティ	後から要件が増え、設計のやり直しになる
9. スケジュール	いつまでに稼働したいか、その理由	体制の提案ができない
10. 予算	幅でよいので提示する	各社バラバラの規模で提案し、比較できない
11. 提案してほしいこと	決めきれていない部分を明示	各社が勝手に前提を置く
12. 選定の進め方	提出期限、質問方法、選定基準、決定時期	提案の質と熱量が下がる

最も価値があるのは「2. 現状の業務」

機能一覧よりも、いまの業務の流れを書いたページのほうが良い提案を生みます。「誰が」「何をきっかけに」「どの順で」「何を使って」作業しているかを、箇条書きでよいので書いてください。ここが具体的だと、開発会社は改善案まで提案できます。

非機能要件の書き方

忘れられがちですが、金額に最も効くのがここです。分からない場合は「分からないので提案してほしい」と書けば構いません。

観点	書き方の例
稼働時間	平日 8〜20時。夜間は停止してよい／24時間365日
停止の許容	半日止まっても業務は回る／1時間で業務が滞る
同時利用者	登録 200名、同時 30名程度。月初は倍になる
データ量	年 10万件、5年分を保持したい
アクセス元	社内のみ／外出先からも／取引先も利用する
取り扱う情報	個人情報を含む／決済情報は扱わない
バックアップ	日次。1日分の消失までは許容できる

優先度は3段階で書く

全機能を「必須」にすると、予算内に収まらないときに削る議論ができません。

必須：これが無いと業務が回らない
重要：初回リリースに入れたいが、次段階でも可
希望：予算が許せば

この分類があると、開発会社は「必須のみ 800万円、重要まで含めて 1,200万円」といった段階的な提案ができます。予算の組み方はシステム開発の予算取りの方法を参照してください。

やってはいけない書き方

・「既存システムと同等の機能」…既存を知らない会社には見積もれません
・「使いやすい画面」…判断基準がないので提案も評価もできません
・「将来的な拡張に対応」…何を拡張するのか書かないと、過剰な設計を招きます
・「詳細は打ち合わせで」…提案時点で見積もれず、リスク分が上乗せされます

提出から選定までの進め方

RFP を配布（2〜3社。多くても4社まで）
質問期間を設ける（1週間程度）。質問と回答は全社に共有すると公平です
提案期間（2〜3週間）。1週間だと形式的な提案しか来ません
提案会（各社60〜90分）。実際に担当する人の同席を条件にします
評価：価格だけでなく、理解度・体制・保守まで含めて比較（システム開発会社の選び方）

そのまま使える構成

RFP の目次テンプレート

1. はじめに（会社概要・依頼の背景）
2. プロジェクトの目的
3. 現状の業務とその課題
4. 実現したいこと（機能一覧・優先度つき）
5. 対象範囲（今回やらない範囲も明記）
6. 利用者と利用形態
7. 既存システムとの連携
8. 非機能要件
9. スケジュール
10. 予算
11. 提案してほしい事項
12. 提案書の提出要領・選定基準・スケジュール
13. 問い合わせ窓口

よくある質問

RFP は必ず必要ですか？

数百万円規模までなら、課題と業務の流れをまとめた資料でも足ります。1,000万円を超える案件や、3社以上を比較する場合は RFP を作ってください。同じ前提で提案を受けられるので、比較の精度が上がります。

要件が固まっていなくても書けますか？

書けます。むしろ<strong>固まっていないことを固まっていないと書く</strong>のが重要です。「この部分は提案してほしい」と明示すれば、各社の考え方の違いが見えます。無理に決めて書くと、良い提案の芽を潰します。

RFP はどれくらいのボリュームが必要ですか？

10〜30ページが一般的です。ページ数より、①現状の業務 ②困っていること ③実現したい状態 ④制約条件の4点が具体的に書かれているかが重要です。

予算は書くべきですか？

書いてください。伏せると各社バラバラの規模で提案してくるため比較できません。「1,000万〜1,500万円」のように幅で示せば十分です。予算に合わせて機能の優先度を提案してもらうほうが、建設的な議論になります。

まとめ

RFP の目的は「同じ前提で提案を受ける」こと。情報不足はリスク上乗せとして金額に跳ね返る。
機能一覧より 現状の業務の流れ のほうが価値がある。
非機能要件（稼働時間・停止許容・データ量）は必ず触れる。
予算は幅で提示し、機能は3段階の優先度で書く。

この記事の金額について

掲載している金額は、一般的な発注で見かける水準をもとにした目安です。実際の費用は要件・地域・体制によって変わります。必ず複数社から見積もりを取り、「何が含まれていて、何が含まれていないか」を比べたうえでご判断ください。