受託開発を成功させられるかどうかは、開発そのものの技術力よりも、発注前にどれだけ精度の高いRFP（提案依頼書）と要件定義書を用意できるかにかかっています。発注側がやりたいことを曖昧なまま投げ、あとはベンダー任せにする「丸投げ」は、見積もりのばらつき、認識のズレ、仕様変更の多発という、受託開発の失敗の典型的なパターンを引き起こします。一次データでも、要件が曖昧だと工数が1.3〜1.5倍に膨張すると指摘されており、要件定義の質はそのまま費用と成否に直結します。
本記事は、受託開発におけるRFP・要件定義書・提案依頼書の作り方に特化して、発注企業が自力で精度を高めるための実務を解説します。RFPに最低限盛り込むべき記載項目、見落とされがちな非機能要件の解像度の上げ方、提示された見積もりの妥当性をチェックする観点、そしてAI時代に必要になった新しい検収基準まで、一次データを交えて具体的に掘り下げます。受託開発全体の進め方や費用構造をまだ把握していない方は、まず受託開発でおすすめの完全ガイドをあわせてご覧ください。読み終えるころには、自社のRFPに何が足りないかが具体的に見えてくるはずです。
▼全体ガイドの記事
・受託開発でおすすめの完全ガイド
RFPに盛り込むべき記載項目
RFP（提案依頼書）は、発注側がベンダーに「こういうものを作りたいので提案してください」と依頼するための文書です。これが充実しているほど、各社から比較可能で精度の高い提案が集まります。逆にRFPが薄いと、ベンダーは前提を想像で埋めるしかなく、提案も見積もりもばらつき、後で「言った言わない」のトラブルになります。まずは、RFPに最低限盛り込むべき記載項目を押さえましょう。
目的・背景・予算・スケジュールの記載
RFPの冒頭には、まず「なぜこのシステムを作るのか」という目的と背景を書きます。現状のどんな課題を解決したいのか、それによって何を実現したいのかを言語化することで、ベンダーは枝葉ではなく本質に沿った提案ができます。あわせて、想定予算とスケジュールの幅を示すことも重要です。予算を一切示さないと、各社が異なる前提で見積もるため比較できなくなります。規模感の目安として、小規模なら300万〜800万円・1〜3ヶ月、中規模なら800万〜2,500万円・3〜6ヶ月といった相場を踏まえて、現実的な幅を提示しましょう。
予算を示すと足元を見られると心配する声もありますが、実際には逆です。予算が分かれば、ベンダーはその範囲で実現可能な最適案を考えてくれますし、予算に対して要件が過大なら早めに指摘してくれます。スケジュールも同様で、いつまでに何が必要かを示すことで、フェーズ分割の提案を引き出せます。目的・背景・予算・スケジュールという土台の記載が、提案の質を大きく左右します。
機能要件と対象業務範囲の記載
RFPの中核は、機能要件と対象業務範囲です。どの業務をシステム化するのか、その業務で何ができる必要があるのかを、できるだけ具体的に書きます。たとえば「受発注を管理したい」だけでなく、「得意先ごとの単価で受注を登録し、在庫を引き当て、納期を回答し、請求データを出力したい」というレベルまで噛み砕くと、ベンダーは抜け漏れなく工数を見積もれます。ここが曖昧だと、後から「その機能は要件に入っていなかった」という追加費用の温床になります。
同時に、対象範囲の「外」も明記しておくと、認識のズレを防げます。「今回は受注管理までを対象とし、会計連携は次フェーズとする」というように、スコープの境界を引いておくのです。これはスコープクリープ（範囲がなし崩しに膨らむ現象）を防ぐうえで効果的です。完璧な要件を最初から書く必要はありませんが、「何を作り、何を作らないか」の輪郭をRFPで示すことが、見積もりの比較可能性と後のトラブル防止につながります。
非機能要件の解像度を上げる
RFPと要件定義書でもっとも見落とされやすいのが、非機能要件です。機能要件が「何ができるか」を定めるのに対し、非機能要件は「どれだけ速く、安全に、大量に扱えるか」という品質・性能を定めます。リサーチでも、この非機能要件の解像度が競合の重要論点として挙げられています。ここが曖昧なまま発注すると、「機能は揃っているのに遅くて使い物にならない」「セキュリティが甘く事故が起きた」という事態を招きます。
セキュリティ・データ量・レスポンスの定義
非機能要件の代表が、セキュリティ・想定データ量・レスポンス速度の三つです。セキュリティでは、扱う情報の機微度に応じて、暗号化の範囲、アクセス権限の設計、ログの取得方針などを定めます。個人情報や決済情報を扱うなら、求められる水準は格段に上がります。データ量では、現在のデータ規模だけでなく、数年後に何倍になるかを見込んで設計する必要があります。ここを小さく見積もると、データが増えたときにシステムが急に遅くなります。
レスポンス速度は、「この検索は何秒以内に結果を返す」「同時に何人が使っても耐える」といった目標値で定めます。これらは数値で書くことが肝心です。「速く」「安全に」という曖昧な言葉では、ベンダーごとに解釈が分かれ、見積もりもばらつきます。非機能要件の解像度を上げるとは、こうした品質の目標を、検証可能な数値の言葉に翻訳することです。RFPの段階で完璧に書けなくても、「ここは重視する」という優先順位を示すだけで、提案の精度は大きく変わります。
運用・保守・SLAを要件に織り込む
非機能要件には、リリース後の運用・保守やSLAも含めて考えるべきです。作ることばかりに気を取られ、運用フェーズの要件をRFPに書かないと、保守費が後出しで膨らみます。保守費は年で開発費の15〜25%が相場であり、最初から「保守はどこまで含むか」を要件として提示しておくと、各社の提案を保守込みで比較できます。これを後回しにすると、初期費用だけ安い提案を選んでしまい、結局トータルで高くつくことがあります。
SLAの要件としては、障害時の初動時間、サポート時間帯、復旧目標、そして法改正・OSアップデート・脆弱性対応が保守範囲内か別料金かを明示するよう求めます。これらをRFPで問うておけば、運用の手厚さでベンダーを比較できます。非機能要件を「作るとき」だけでなく「使い続けるとき」まで広げて定義することが、総保有コストを見据えた発注の第一歩です。要件定義は機能の一覧表ではなく、システムの一生を見通す設計図だと捉えてください。
見積もりの妥当性をチェックする観点
精度の高いRFPを出すと、各社から見積もりが返ってきます。次に発注側がやるべきは、その見積もりの妥当性をチェックすることです。総額の安さだけで選ぶと、後で追加請求や品質低下に苦しみます。リサーチでも、安すぎる見積もりが追加請求や品質低下のリスクをはらむことが繰り返し指摘されています。ここでは、見積書を読み解くための具体的な観点を解説します。
人月単価と工数の内訳を分解して見る
見積もりチェックの第一歩は、総額を「人月単価×工数」に分解して見ることです。一式◯◯万円としか書かれていない見積もりは要注意です。誰が（PMかSEかPGか）、何人月かかわるのかが分からなければ、妥当性を判断できません。相場として、PMは110万〜150万円、SEは65万〜90万円、PGは50万〜70万円、テスターは45万〜60万円が目安です。内訳が開示されていれば、各工程の工数が過大でも過少でもないかをチェックできます。
体制によっても単価は変わります。フリーランスで50万〜80万円、中小開発会社で80万〜120万円、大手SIerで150万〜200万円が目安です。同じ機能でも、どの体制に頼むかで総額は倍以上違ってきます。重要なのは、安い体制が常に正解ではないことです。要件が複雑で品質保証が必要な開発を最安の体制に任せると、かえって手戻りで高くつくこともあります。見積もりは、単価の高低だけでなく、その体制が自社の要件に見合っているかという観点で読み解いてください。
安すぎる見積もりを警戒する
見積もりチェックで意外に重要なのが、「安すぎる提案を警戒する」という観点です。複数社の見積もりの中に、突出して安いものがあったら、まず理由を確認すべきです。請負契約には人月計算に1.3〜1.5倍の係数と、全体の10〜20%のリスクバッファが乗るのが一般的です。これらが一切ない見積もりは、想定が少しでも外れると赤字になり、その皺寄せが品質低下や追加請求、最悪は途中放棄として発注側に跳ね返ります。
安さの裏には、テスト工程の省略、ドキュメントの未整備、保守を別料金にしている、といったからくりが隠れていることがあります。見積もりを比較するときは、各社が同じスコープ・同じ品質水準で見積もっているかを揃えてから比べる必要があります。RFPで要件をしっかり示しておけば、この「土俵を揃えた比較」ができます。見積もりの妥当性チェックとは、最安を選ぶことではなく、「適正なバッファと品質保証が含まれた、信頼できる見積もり」を見極めることなのです。
AI時代に必要な新しい検収基準
近年、要件定義と検収の場面に、AI時代特有の新しい論点が加わっています。生成AIによるコード生成が普及し、開発のスピードが上がる一方で、品質と責任の所在が新たな課題になっているのです。RFPと要件定義書には、こうしたAI起因のリスクを踏まえた検収基準を盛り込むことが、これからの発注に欠かせなくなっています。ここでは、その具体的な観点を解説します。
生成コードの脆弱性と責任を定める基準
AIが生成したコードを丸ごと組み込む、いわゆるVibe Codingには、脆弱性が紛れ込みやすいという落とし穴があります。動いているように見えても、セキュリティホールやエッジケースの考慮漏れが残っていることがあるのです。RFPと要件定義書には、生成コードであっても人間によるレビューとセキュリティ検証を経ることを、検収の条件として明記しておくべきです。「動けば合格」ではなく、「安全に動くことが確認できて合格」という基準に引き上げる必要があります。
あわせて、生成コードのバグ責任と著作権の所在も、契約と要件で整理しておくことが重要です。AIが生成したコードに起因する不具合の責任を誰が負うのか、生成コードの著作権上の扱いはどうなるのか、といった論点は、まだ実務上もグレーな部分が残ります。だからこそ、発注側から「生成コードを使う場合の品質保証と責任の扱い」を要件定義の段階で問い、合意しておくことが、後のトラブルを防ぎます。AI活用は歓迎すべきですが、検収基準を伴わない丸投げは新たなリスクになります。
LLM機能のハルシネーション許容範囲を決める
システムにLLM（大規模言語モデル）を組み込む場合、ハルシネーション（もっともらしい誤答）をどこまで許容するかという、従来にない検収基準が必要になります。LLMは確率的に出力を生成するため、常に正しい答えを返すとは限りません。要件定義では、「どの業務でLLMを使い、誤答が出たときに業務にどんな影響があるか」を整理し、許容できる誤答率や、誤答を人間が確認する仕組みを定める必要があります。
たとえば、社内向けの参考情報を提示する用途なら多少の誤答も許容できますが、契約金額の計算や法的判断に直結する用途では、人間の確認を必須にするなど、用途ごとに基準を変えるべきです。この「ハルシネーション許容範囲」を要件で定めておかないと、検収のときに「思っていたより精度が低い」と揉めることになります。riplaはフルスクラッチ受託の立場から、AIを使う場合も、用途に応じた検収基準を発注側と一緒に定めることを重視しています。AI時代の要件定義は、機能の定義に加えて、不確実性をどう扱うかの合意までを含むのです。
まとめ
受託開発のRFP・要件定義書を整理すると、目的・背景・予算・スケジュール・機能要件・対象範囲という土台に加え、セキュリティ・データ量・レスポンス・運用保守といった非機能要件の解像度、人月単価×工数を分解した見積もりの妥当性チェック、そしてAI時代の生成コード検収・ハルシネーション許容範囲という新しい基準までを盛り込むことが、失敗を防ぐ要件定義の全体像です。要件が曖昧だと工数が1.3〜1.5倍に膨張するという数字が示すとおり、ここに時間をかけることが、結局はもっとも費用対効果の高い投資になります。
RFPは完璧でなくてかまいません。大切なのは、「何を作り、何を作らないか」「どんな品質を求めるか」「どこで合格とするか」を、発注側の言葉で示すことです。それさえあれば、各社の提案を同じ土俵で比較でき、安すぎる提案の危うさも見抜けます。riplaはフルスクラッチ受託と国内開発の立場から、要件定義の段階から発注側に伴走し、非機能要件やAI時代の検収基準まで一緒に固めることを重視しています。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。