システム開発の成否は、コードを書き始める前の「要件定義」と「RFP（提案依頼書）」でほぼ決まる、と言っても過言ではありません。やりたいことをベンダーに正確に伝えられないまま開発に進むと、出来上がったものが思っていたのと違う、追加費用が次々に発生する、といったトラブルが避けられないからです。実際、要件定義が曖昧なまま進めると工数が当初見積もりの1.3〜1.5倍に膨張するという指摘もあり、ここでの手抜きは後で何倍にもなって返ってきます。
本記事は、システム開発の要件定義書・RFP・提案依頼書を、発注企業がどう作り、どう使うべきかを「要件定義特化」の視点で解説します。RFPに記載すべき項目、見落とされがちな非機能要件の固め方、複数ベンダーの見積もりを公平に比較するための工夫、そしてAI時代に新しく求められる検収基準まで、実務に直結する形で整理します。読み終えるころには、自社のプロジェクトで「何を、どの粒度で書けば、ベンダーに正しく伝わるか」の感覚がつかめるはずです。なお、システム開発の全体像をまだ把握していない方は、まずシステム開発の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・システム開発の完全ガイド
RFP・提案依頼書に記載すべき項目
RFP（Request for Proposal＝提案依頼書）は、発注企業がベンダーに「こういうシステムを作りたいので、提案と見積もりをください」と依頼するための文書です。RFPの質が、集まる提案の質を決めます。曖昧な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を出して複数の見積もりが集まったら、次はその妥当性を見極める段階です。ここで「一番安い会社」を選ぶのは危険な発想です。安すぎる見積もりには、後から追加請求される、品質が低い、必要な工程が抜けている、といったリスクが潜んでいます。見積もりの妥当性を正しく判断できるよう、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の利用に伴うリスクと、それを検収でどう確認するかを、発注側が意識的に要件に組み込む必要があります。これは競合の解説でも手薄な、これからの発注に欠かせない視点です。
生成AIコードの品質と著作権を検収で確認する
生成AIを使った開発（いわゆるVibe Codingのような手法）では、AIが生成したコードをそのまま採用するケースが増えています。スピードは上がりますが、生成コードには見えにくい脆弱性が潜んでいたり、品質にばらつきがあったりするリスクがあります。発注側としては、「AIが生成したコードであっても、人間によるレビューとテストを経て品質を担保すること」を要件に明記し、検収時にその裏付けを確認する姿勢が求められます。スピードと引き換えに品質が犠牲になっていないかを問う基準を持つことが大切です。
もう一つの論点が、生成コードの著作権やライセンスです。AIが学習データから生成したコードが、第三者の権利を侵害していないか、利用規約上問題がないかを確認する必要があります。万一、生成コードに起因する不具合や権利侵害が起きたとき、その責任をどう分担するかも、契約で取り決めておくべき新しい論点です。AI活用は便利な一方、責任の所在が曖昧になりやすいため、要件と契約で明確にしておくことがトラブル回避の鍵になります。
LLM搭載システムのハルシネーション許容範囲を定める
AIそのものを機能として組み込むシステム、たとえばLLM（大規模言語モデル）を使った問い合わせ対応や文書生成では、ハルシネーション（AIがもっともらしい誤情報を生成する現象）への対応が避けて通れません。従来のシステムは「正しい入力には正しい出力を返す」ことが前提でしたが、AIは確率的に振る舞うため、常に100%正確とはかぎりません。要件定義では、「どの程度の誤りまでを許容するか」「誤った出力をどう検知し、どう人間が補正するか」を品質要件として定める必要があります。
この許容範囲をあらかじめ決めておかないと、検収の段階で「AIがたまに間違えるが、これは不具合なのか仕様なのか」という不毛な議論が起きます。発注側とベンダーが、AIの特性を理解したうえで、許容できる精度の水準と、誤りが起きたときの運用上の歯止めを合意しておくことが重要です。AIを組み込むシステムは、従来の「動くか動かないか」という検収基準では測れません。確率的な振る舞いを前提とした新しい品質要件と検収基準を、要件定義の段階で設計することが、AI時代の発注の要諦だと言えます。
まとめ
システム開発の要件定義とRFPは、プロジェクトの成否を左右する最重要工程です。RFPには背景・目的・課題・予算・納期・対象範囲を明記し、見落とされがちな性能・セキュリティ・SLAといった非機能要件を数値で固める。見積もりは内訳・人月・工程ごとに出してもらい、契約形態・著作権譲渡・保守範囲まで含めて妥当性を検証する。そして、AI時代には生成コードの品質・著作権、LLMのハルシネーション許容範囲といった新しい検収基準も求められます。要件定義が曖昧だと工数が1.3〜1.5倍に膨張するという事実が、ここでの丁寧さの価値を物語っています。
要件定義で大切なのは、機能の羅列ではなく「何のために、どの品質で作るか」を発注側が言語化することです。完璧な要件を一人で書き上げる必要はありません。たたき台を用意し、信頼できるベンダーと対話しながら精度を高めていくのが現実的です。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を創業。