受託開発でおすすめのRFP/要件定義書/提案依頼書について

受託開発では、発注前の要件整理が成否を左右します。なかでも、RFP(提案依頼書)と要件定義書の精度が、提案と見積もりの比較のしやすさを決めます。比べる観点は、RFPの記載項目、非機能要件、見積もりの見方、AI時代の検収基準の4つです。

要件が曖昧だと、見積もりのばらつきや仕様変更が起きやすくなり、工数が1.3〜1.5倍に膨らむという一次データもあります。全体像や費用は受託開発でおすすめの完全ガイドもご覧ください。

  • RFPの記載項目
  • 非機能要件
  • 見積もりの見方
  • AI時代の検収基準

▼全体ガイドの記事
・受託開発でおすすめの完全ガイド

RFPに盛り込むべき記載項目

RFPの記載項目を、目的・背景、予算・スケジュール、機能要件、対象外の業務に分けた図解。
依頼内容の輪郭を、目的から対象範囲まで順に整えられます。

RFP(提案依頼書)は、発注側が開発内容を示し、ベンダーに提案を求める文書です。情報が揃うほど、各社の提案を並べて比べられます。

記載が少ないと、ベンダーは前提を推測して提案します。その結果、見積もりに差が出たり、後から認識の違いが表面化したりします。そのため、まず目的や範囲といった比較の前提を揃えておくことが必要です。

目的・背景・予算・スケジュールの記載

RFPには、システムを作る目的と背景を記します。解決したい課題と実現したい状態が分かれば、ベンダーは本質に沿って提案できます。

想定予算とスケジュールは、幅を持たせて示します。予算がないと、各社が異なる前提で見積もり、比較しにくくなります。記事で示す規模の目安は、小規模が300万〜800万円・1〜3ヶ月、中規模が800万〜2,500万円・3〜6ヶ月で、自社の条件に合わせて現実的な幅を示します。

予算を伝えると、その範囲で実現する案や、要件が予算を超える場合の指摘を得やすくなります。期限と必要な成果を示せば、段階的な開発案も比べられます。目的・背景・予算・スケジュールを先に揃えることが、提案の質と比較のしやすさにつながります。

機能要件と対象業務範囲の記載

機能要件では、対象業務と必要な操作を具体的に書きます。「受発注を管理する」とだけ書くと、見積もりに必要な範囲が伝わりません。

たとえば、得意先ごとの単価で受注を登録し、在庫を引き当て、納期を回答し、請求データを出力する、と業務の流れに沿って示します。曖昧なままだと、後から機能を追加することになり、費用も発生するおそれがあります。また、対象外の業務も書いて、スコープの境界を決めます。

対象外の例としては、受注管理を今回の対象とし、会計連携を次の段階に回す形があります。範囲がなし崩しに広がるスコープクリープを防ぐには、「何を作り、何を作らないか」を示すことが有効です。最初から完璧な要件を揃えなくても、輪郭があれば比較と合意が進みます。

ポイント

RFPには、目的、予算、スケジュールに加えて、対象業務と対象外の範囲を書きます。前提を揃えておけば、各社の提案と見積もりを同じ条件で比べられます。

非機能要件の解像度

非機能要件は、速度や安全性など、機能以外の品質を定める項目です。調査でも、要件の具体性が競合上の論点として挙げられています。

基準が曖昧だと、機能が揃っていても遅くて使いにくくなったり、セキュリティ上の問題が起きたりするおそれがあります。そのため、利用状況に応じて目標を具体化します。

セキュリティ・データ量・レスポンスの定義

代表的な非機能要件は、セキュリティ、想定データ量、応答速度です。扱う情報に合わせて、暗号化、権限、ログの方針を定めます。

個人情報や決済情報を扱う場合は、求める安全性を具体化します。データ量は、現在の規模だけでなく、数年後の増加も見込みます。応答速度は「検索結果を何秒以内に返すか」、利用規模は「同時に何人が使うか」のように定めます。

「速く」「安全に」だけでは、各社の解釈が分かれます。数値があれば、後から検証もできます。数値化が難しい項目も、重視する品質の優先順位を示せば、提案を比べやすくなります。

運用・保守・SLAの要件への織り込み

運用・保守とSLAも、RFPに含めます。記事では、保守費の目安を年間で開発費の15〜25%としています。

保守の範囲を最初に示せば、各社の費用を保守込みで揃えて比べられます。後から要件に加えると、初期費用が低くても総額が膨らむ場合があります。要件定義では、開発時だけでなく、使い続ける期間の費用と品質も見通します。

SLAでは、障害時の初動、サポート時間、復旧目標を明記します。法改正やOS更新、脆弱性への対応が保守の範囲内か別料金かも、あわせて示します。こうした条件があれば、運用支援の違いも比較できます。

ポイント

非機能要件は、セキュリティやデータ量、応答速度を数値で示せるかどうかが判断の目安になります。数値にできない項目も、重視する品質の優先順位を示しておくと、提案を比べられます。

見積もりの妥当性を見る観点

見積もりの妥当性を見る観点として、総額、人月単価、工数、役割ごとの体制を並べた図解。
金額の背景にある作業量と担当体制にも目を配れます。

見積もりは、総額だけで判断せず、前提と内訳を確かめます。安さだけで選ぶと、追加請求や品質低下につながるおそれがあります。

調査でも、安すぎる見積もりにはこうしたリスクが伴うと指摘されています。まずは、各社が同じ範囲を見積もっているかを確かめます。

人月単価と工数の内訳

「一式」とだけ書かれた見積もりは、妥当性を判断しにくいものです。そのため、総額を人月単価と工数に分け、役割ごとの体制を確認します。

記事に記載された単価の目安は、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時代に必要な新しい検収基準

RFPを中心に、人によるレビュー、安全性の確認、不具合の責任、許容する誤答率、人が確認する手順を結んだ図解。
品質確認と責任の整理を、検収条件としてひとつに結びます。

生成AIで開発は速くなる一方、品質と責任の所在が課題になります。そのため、RFPと要件定義書に、AI利用を踏まえた検収基準を含めます。

生成コードの脆弱性と責任を定める基準

生成コードは、動作していても脆弱性や例外条件の考慮漏れが残る場合があります。そのため、人によるレビューと安全性の確認を検収条件にします。

合格の条件は、動くことだけでなく、安全に動くと確認できる基準にします。その確認内容は、RFPと要件定義書に明記します。生成コードに起因する不具合の責任や著作権上の扱いも、契約と要件で整理します。

こうした責任の扱いには実務上の論点が残るため、発注側から確認します。品質保証と責任の分担を開発側と合意すれば、後の行き違いを防げます。特に、AIを使う場合も検収条件をあわせて取り決めます。

LLM機能のハルシネーション許容範囲

LLM(大規模言語モデル)は、常に正しい回答を返すとは限りません。そのため、使う業務と、誤答が与える影響を要件定義で整理します。用途に応じて、許容する誤答率や人が確認する手順も定めます。

誤答の影響が大きい業務ほど、検収条件を具体化します。社内向けの参考情報なら一定の誤答を許容できても、契約金額や法的判断に関わる用途では人の確認が必要です。用途別に基準を変えます。

許容範囲を決めておかないと、検収時に期待した精度との食い違いが起きます。なお、riplaは、用途に応じた基準を発注側と定めることを重視しています。

ポイント

生成コードの品質責任と、LLM機能の誤答をどこまで許容するかを検収条件に含めるかが判断の目安です。社内の参考用途か、契約や法的判断に関わるかで基準は変わります。

まとめ

RFPには、目的・予算・範囲に加えて、品質や運用の条件を記します。見積もりの内訳とAI機能の検収基準も、あわせて確認します。

記事中のデータが示すとおり、要件が曖昧だと工数は1.3〜1.5倍に膨らみます。そのため、発注前の整理に時間をかけ、比較と合意を進めることが欠かせません。

RFPは完璧でなくても構いません。「作るもの」「求める品質」「合格の条件」を、発注側の言葉で示すことが大切です。

発注側とベンダーが前提を共有していれば、提案を比較しやすくなります。また、riplaは要件定義から発注側に伴走し、非機能要件やAI時代の検収基準を一緒に固めます。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。