RFP（提案依頼書）と要件定義書は、目的・品質・範囲から見積もりと検収までを先に定めておくと、認識のずれや追加費用を抑えやすくなります。
RFPには背景・目的・課題を冒頭に、予算・納期・対象範囲を添えて書きます。見積もりは内訳で確かめます。全体像はシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
RFP・提案依頼書に記載すべき項目
RFP（Request for Proposal＝提案依頼書）は、発注企業がベンダーに提案と見積もりを依頼する文書です。また、要件定義が曖昧なまま進むと、工数が当初見積もりの1.3〜1.5倍に膨張するとの指摘もあります。
曖昧なRFPでは、提案や見積もりの根拠を比べにくくなります。逆に要点をそろえておけば、各社を同じ土俵で比較できます。
RFPの冒頭に置く背景・目的・課題
RFPでは機能より先に、なぜシステムを作るのか、その背景・目的・現状の課題を記します。
- 現状：業務で発生している工数やミスの内容
- 目的：改善後に実現したい状態
- 優先順位：開発中に増えた要望の選び方（当初目的への貢献を基準）
多くの発注者は機能一覧から書き始めます。しかし、目的が伝わらないと、ベンダーは指示された機能だけを作り、代替案を提案しにくくなります。
目的が曖昧なまま要望を追加すると、仕様が際限なく広がるスコープクリープに陥るおそれがあります。だからこそ、RFPの背景と目的は、プロジェクト全体を判断する軸になります。
予算・納期・対象範囲と前提条件
RFPには機能要件に加えて、予算感・希望納期・業務範囲・前提条件も必ず記載します。予算帯が示されていないと、提案内容にばらつきが出て、比較しにくくなります。
- 小規模：300万〜800万円
- 中規模：800万〜2,500万円
- 大規模：2,500万〜5,000万円以上
この相場を踏まえて、おおよその予算レンジを示すと、現実的で精度の高い提案を得られます。
希望納期は、理由とあわせて伝えます。たとえば「来年4月の組織変更に間に合わせたい」と伝えれば、ベンダーは逆算してフェーズ分けを提案できます。
また、対象範囲は、今回作る部分、将来拡張する部分、今回は対象外の部分に分けて示します。さらに、連携する既存システムや希望する技術も前提条件に含めておくと、初期段階の認識のずれを抑えられます。
見落とされがちな非機能要件の固め方
非機能要件は、性能・セキュリティ・可用性・データ量など、システムがどの品質で動くかを定めるものです。リリース後の満足度やトラブルの有無は、機能要件に加えて、非機能要件をどこまで固めたかで左右されます。この領域は、発注側が意識して踏み込む必要があります。
性能・レスポンス・データ量の数値定義
性能やデータ量は、「速いシステム」といった曖昧な表現を避け、できるかぎり具体的な数値で定義します。
- 画面表示：主要画面は3秒以内
- 同時アクセス：100人分の同時処理
- データ量：年間50万件の蓄積を想定
数値がないと、過剰なスペックか楽観的な見積もりになり、稼働後に性能不足を招く可能性があります。数値を決めきれない場合は、現在の取引件数や利用者数、データの増加ペースから、3年後・5年後の規模を推定します。
将来を見越して余裕を持たせすぎると費用が膨らみます。一方で、現状に合わせすぎると、数年で性能の限界に達します。
成長規模はベンダーと相談して決めます。RFPには現状の数値と想定する成長率を示し、議論の土台にします。
セキュリティ水準とSLAの必須条項
セキュリティ水準は、扱うデータの機密性に応じて定めます。特に、個人情報や決済情報を扱う場合は、対策を明示しておく必要があります。
- 対策：暗号化・アクセス制御・脆弱性対策
- 準拠基準：従うべきガイドラインがある場合の記載
水準が高いほど費用も上がるため、守るべきものを起点に、過不足なく定義します。曖昧なままだと、各社の想定する水準がずれ、見積もりを比べられなくなります。
稼働後を見据えて、SLA（サービス品質保証）の必須条項もRFPの段階で決めておきます。たとえば、障害時に何分以内に初動するか、稼働率を何%保証するかを明記します。
OS更新や脆弱性、法改正への対応が保守の範囲内か別料金かも決めておく必要があります。曖昧なままだと、保守対象外として追加費用を請求され、トラブルにつながりかねません。SLAで運用・保守の範囲を決めておけば、関連コストを見通しやすくなります。
見積もりの妥当性をチェックする要件の書き方
複数社の見積もりを比べたとき、一番安い会社を選ぶのは危険です。追加請求や品質低下、工程漏れのリスクも確かめる必要があります。そこで、見積もりの妥当性を判断できるように、RFPの段階で見積もりの出し方を指定しておきます。
内訳・人月・工程ごとの記載
妥当性を判断する第一歩は、内訳を細かく出してもらうことです。「一式300万円」では、費用の中身が分かりません。
- 工程：要件定義・設計・実装・テスト・導入
- 担当：PM・SE・PGそれぞれの人月
- 単価目安：PMは110万〜150万円、SEは65万〜110万円、PGは50万〜90万円
開発費は基本的に人月単価×工数で決まります。そのため、内訳が分かれば相場と比べて妥当性を検証できます。
工数比では、要件定義が全体の約20%、設計からテストが約80%を占めるのが一般的とされます（出典：IPAのソフトウェア開発データ白書）。テスト工程がほとんど計上されていない場合は、品質確保の工程が省かれている疑いがあります。
請負契約では、リスクバッファとして全体の10〜20%を上乗せするのが一般的です。人月計算に1.3〜1.5倍の係数をかけることもあります。だからこそ、内訳を求めることが、安すぎる見積もりの危険を見抜く最も有効な手段です。
契約形態・著作権・保守範囲の要件
見積もりと合わせて、契約形態と権利関係をRFPで明確にし、稼働後の保守範囲も整理します。
- 請負契約：完成責任を負う契約で、要件が固まった案件向け
- 準委任契約：善管注意義務を負う契約で、探索的な要件定義向け
- 工程別契約：要件定義は準委任、開発・実装は請負に分ける方法
- 著作権：原則は受託者に帰属。自由な改修・移管には譲渡を明記し、著作権法27条・28条の権利も含める
- 保守範囲：保守に含む作業と別料金の作業を、契約前に確定させて稼働後のトラブルを防ぐ
著作権の譲渡を怠ると、後でベンダーを切り替えたいときに、自社で改修できない場合があります。
AI時代に求められる検収基準と品質要件
生成AIを使う開発や、AIを組み込んだシステムが急速に広がり、従来の要件定義や検収では捉えにくい論点が生まれています。発注側は、生成AIのリスクと、検収での確認方法を要件に含める必要があります。競合の解説では手薄ですが、今後の発注に欠かせない視点です。
生成AIコードの品質と著作権の検収確認
Vibe CodingなどAIを使う開発では、生成コードをそのまま採用する例も増えています。速さの一方で、脆弱性や品質のばらつきが懸念されます。
- 品質確認：人間によるレビューとテストを要件に含める
- 著作権・ライセンス：第三者の権利侵害や利用規約上の問題の有無
- 責任分担：不具合や権利侵害が起きた際の、契約上の責任の所在
検収時には、レビューとテストの裏付けを確認します。そのうえで、スピードと引き換えに品質が損なわれていないかを判断します。
AI活用では責任の所在が曖昧になりやすいため、要件と契約で明確にしておくことが、トラブルの回避につながります。
LLM搭載システムのハルシネーション許容範囲
LLM（大規模言語モデル）を使う問い合わせ対応や文書生成では、ハルシネーション（AIがもっともらしい誤情報を生成する現象）への備えが必要です。従来のシステムは、正しい入力に正しい出力を返す前提です。一方で、AIは確率的で、常に100%正確とはかぎりません。
- 許容範囲：どの程度の誤りを許容するかという精度の水準を、発注側とベンダーで合意する
- 誤りへの対応：誤出力の検知基準と、人が出力を補正する方法
- 検収基準：動作の確認に加えて、運用上の歯止めも含む品質要件で評価する
許容範囲を先に決めておかないと、検収時にAIの誤りが不具合か仕様かを巡る議論になります。このため、確率的な振る舞いを踏まえた新たな品質要件と検収基準は、要件定義の段階で設計しておきます。
まとめ
要件定義とRFPは、プロジェクトの成否を左右する重要な工程です。背景・目的・課題、予算・納期・対象範囲を記したうえで、性能・セキュリティ・SLAを数値で固めます。
見積もりは、内訳・人月・工程ごとに求めます。次に、契約形態や著作権譲渡、保守範囲まで含めて妥当性を検証します。
AI開発では、コード品質・著作権・ハルシネーションの基準も決めておく必要があります。曖昧な要件定義では、工数が当初見積もりの1.3〜1.5倍に膨張するとの指摘もあります。
発注側が「何のために、どの品質で作るか」を言葉にすると、ベンダーとの対話で要件を具体化できます。完璧な要件を一人で書く必要はありません。そこで、たたき台を用意し、信頼できるベンダーと一緒に精度を高めます。
riplaはフルスクラッチ受託と国内開発の立場から、業務に沿った要件整理や非機能要件、AI時代の検収基準の設計を支援します。
全体像をあらためて確かめたいときは、完全ガイドもご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。