大規模システムの導入で成否を分ける最大の工程が、要件定義とRFP（提案依頼書）の作成です。大規模システムは投資額が数千万円から1億円規模に達するため、要件が曖昧なまま発注すると、後工程での手戻りが連鎖し、工数が当初見積もりの1.3〜1.5倍に膨張することも珍しくありません。IPAのソフトウェア開発データ白書でも、工数比で要件定義が約20%、工期比では約25%を占めるとされ、最初のこの工程の質が、その後の設計・開発・テストすべての精度を決めます。
本記事は、大規模システムのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から実務的に掘り下げる「要件定義特化」の解説です。RFPに盛り込むべき記載項目、大規模だからこそ解像度を上げるべき非機能要件、見積もり妥当性のチェック方法、そしてAI生成コードが普及した時代ならではの検収基準まで、一次データとあわせて具体的に解説します。なお、費用相場や事例を含めた全体像をまだ把握していない方は、まず大規模システムの完全ガイドから読むことをおすすめします。読み終えるころには、自社のRFPに何を書くべきかが具体的に見えてくるはずです。
▼全体ガイドの記事
・大規模システムの完全ガイド
大規模システムのRFPに盛り込む記載項目
RFP（提案依頼書）は、発注企業がベンダーに「何を実現したいか」を伝え、各社から精度の高い提案と見積もりを引き出すための文書です。大規模システムでは、このRFPの記載が曖昧だと、各社の提案がバラバラになって比較できず、見積もりの前提も揃わないため、適正な選定ができません。まずは、盛り込むべき基本項目を押さえることが出発点です。
目的・背景・スコープを明確に書く
RFPの冒頭で最も重要なのが、プロジェクトの目的・背景・スコープ（範囲）です。なぜこの大規模システムを導入するのか、現状のどんな課題を解決したいのか、そして今回の開発でどこまでをやり、どこからを対象外とするのかを明文化します。目的が曖昧なままだと、ベンダーは「とりあえず全部入り」の過大な提案をしがちで、見積もりも膨らみます。
スコープの定義は、後のスコープクリープ（範囲のなし崩し的な拡大）を防ぐ防波堤にもなります。大規模システムでは、開発中に「あの機能も欲しい」という要望が次々に出て、気づけば当初の範囲を大きく超えてしまうことがよくあります。RFPの段階で対象範囲と対象外を明確に線引きしておけば、後から追加要望が出ても「それはスコープ外なので別見積もり」と整理でき、費用と納期の膨張を抑えられます。目的・背景・スコープは、RFPの土台として最も丁寧に書くべき項目です。
予算・納期・前提条件と評価基準を提示する
RFPには、予算感・希望納期・前提条件・評価基準も盛り込みます。予算をある程度提示することに抵抗を感じる担当者もいますが、予算の幅を示したほうが、ベンダーはその範囲で実現可能な現実的な提案をしてくれます。大規模システムの開発期間は6ヶ月以上、規模によっては2年以上に及ぶため、希望納期とともに段階リリースの可否も伝えておくと、提案の幅が広がります。
あわせて、提案をどう評価するかの基準を明示することも大切です。価格だけで選ぶのか、同業界・同規模の実績を重視するのか、保守までの一貫対応を求めるのかを伝えておけば、ベンダーはその観点に沿って提案をまとめます。なお、安さだけで選ぶのは大規模システムでは特に危険です。安すぎる見積もりは、後からの追加請求や品質低下のリスクをはらむため、価格と品質・実績のバランスを評価基準に組み込むことをおすすめします。RFPは、発注側の意図を構造化してベンダーに伝える設計図だと考えてください。
大規模だからこそ詰めるべき非機能要件
大規模システムの要件定義で、発注側が最も見落としやすいのが非機能要件です。「どんな機能を作るか」という機能要件は議論されやすい一方、「どれだけの速さで・どれだけのデータ量を・どれだけ止まらずに処理するか」という非機能要件は曖昧なまま放置されがちです。しかし大規模システムでは、この非機能要件こそが性能と安定性を決め、費用の大半を左右します。
レスポンス・データ量・同時接続数を数値で定義する
非機能要件は、感覚ではなく数値で定義することが鉄則です。「速く動くこと」ではなく「画面表示は3秒以内」、「大量データに対応」ではなく「商品マスタ100万件・年間取引500万件を想定」、「多くの人が使う」ではなく「ピーク時の同時接続500ユーザー」というように、具体的な数値で要件を書きます。これがあって初めて、ベンダーは適切な構成を設計し、精度の高い見積もりを出せます。
これらの数値は、現在の実績だけでなく、数年後の成長見込みまで含めて設定することが重要です。導入時点のデータ量で設計すると、事業が伸びたときに性能が頭打ちになり、早期の作り直しを迫られます。逆に過大に見積もりすぎれば、不要な性能に費用を払うことになります。自社の業務量の推移を分析し、現実的なピーク値と将来値を見定めて数値化することが、大規模システムの性能要件を適正化する鍵です。レスポンス・データ量・同時接続数の三点は、非機能要件の中核として必ず数値で詰めてください。
セキュリティ・可用性・SLAの水準を要件に書く
性能と並んで重要な非機能要件が、セキュリティ・可用性・SLA（サービス品質保証）の水準です。どこまでの暗号化や認証強度を求めるか、システムが止まってよいのは年間何時間までか、障害時に何分以内に初動するかを、要件定義の段階で明確にします。これらを後回しにすると、運用が始まってから「想定していた水準と違う」というトラブルになります。
特にSLAは、契約前に具体的に詰めておくべき項目です。止まったとき何分で初動するか、法改正やOSのアップデート、脆弱性への対応は保守範囲内か別料金か、といった条項を明確にしておかないと、いざというときに「それは契約に含まれていない」と追加費用を請求されかねません。保守費用は年間で開発費の15〜25%が一つの目安ですが、その範囲に何が含まれるかをSLAとして定義することが、大規模システムを安心して運用する前提になります。非機能要件は、機能要件以上に大規模の品質を左右する、と肝に銘じてください。
見積もりの妥当性をチェックする方法
RFPを出してベンダーから見積もりが返ってきたら、その妥当性をどう判断するかが次の関門です。大規模システムの見積もりは数千万円規模になるため、その金額が適正なのか、安すぎ・高すぎではないかを発注側が見極められないと、後の追加請求や品質トラブルにつながります。見積もりの構造を理解し、妥当性をチェックする視点を持つことが重要です。
人月単価と工数の内訳を確認する
システム開発の費用は、基本的に「人月単価×工数」で決まります。人月単価は職種や体制によって幅があり、PM（プロジェクトマネージャー）が110万〜150万円、SE（設計）が65万〜110万円、PG（実装）が50万〜90万円程度が一つの目安です。体制で見ると、フリーランスが50万〜80万円、中小開発会社が80万〜120万円、大手SIerが150万〜200万円と大きく異なります。
見積もりの妥当性をチェックするには、総額だけでなく、この人月単価と工数の内訳が示されているかを確認します。誰が（どの職種が）何人月かかる前提か、その単価は相場の範囲内かを見れば、見積もりの根拠が分かります。内訳が示されず「一式◯◯万円」とだけ書かれた見積もりは、後から「想定外だった」として追加請求される温床になります。請負契約では人月計算に1.3〜1.5倍の係数をかけ、全体の10〜20%程度のリスクバッファを見込むのが一般的なので、その分が織り込まれているかも確認のポイントです。内訳の透明性こそ、信頼できるベンダーを見分ける指標になります。
初期費用に隠れたランニングコストを見抜く
大規模システムの見積もりで見落としやすいのが、初期開発費の裏に隠れたランニングコストです。クラウドのサーバー利用料、外部APIの利用料、保守費用、ライセンス料といった毎月・毎年かかる費用は、初期費用とは別に積み上がっていきます。保守費用だけでも年間で開発費の15〜25%（月額では初期開発費の5〜15%程度）が目安とされ、数千万円の開発費なら年数百万円規模の保守費が継続的に発生します。
見積もりを評価するときは、初期費用だけでなく、5年程度の総保有コスト（TCO）で比較することをおすすめします。初期費用が安く見えても、ランニングコストが高ければ、数年で総額は逆転します。RFPの段階で「運用後の月額・年額の維持費も提示してほしい」と求めておけば、各社のランニングコストを横並びで比較でき、隠れコストの罠を避けられます。発注検討企業の約4〜5割が「費用対効果が分からない」を課題に挙げているという調査もあり、この見えにくいコストの把握こそ、大規模投資の判断で最も注意すべき点です。riplaは国内開発の立場から、こうした隠れコストまで含めた見積もりの透明化を重視しています。
AI時代の要件定義と検収基準
近年、AIによるコード生成が普及し、大規模システムの開発現場でも生成AIが使われるようになりました。これは開発効率を高める一方で、発注側が要件定義と検収の段階で新たに注意すべき論点を生んでいます。AI時代の要件定義では、従来の項目に加えて、生成コードの品質や責任の所在をどう担保するかを織り込む必要があります。
AI生成コードの品質と責任を検収基準に組み込む
AIが生成したコードを丸ごと採用すると、表面的には動いていても、内部にセキュリティ上の脆弱性や保守しづらい構造が潜んでいることがあります。いわゆる「とりあえず動く」状態のコードをそのまま納品されると、大規模システムでは将来の改修や障害対応で大きな負債になります。要件定義の段階で、生成コードであっても人がレビューし、品質基準を満たすことを検収条件として明記しておくことが重要です。
あわせて、生成コードのバグや脆弱性の責任、著作権の扱いも契約で明確にしておく必要があります。納品物の著作権は、原則として受託者に帰属するため、発注側が自由に改修・流用したいなら、著作権を譲渡する旨を契約に明記すること（著作権法27条・28条の権利も含めて）が欠かせません。AIが介在しても、最終的な品質と責任はベンダーが負う、という構造を検収基準に落とし込むことが、AI時代の大規模システムを安全に発注する条件になります。
検収テストの合格基準を要件段階で定める
大規模システムの検収では、「何をもって合格とするか」を要件定義の段階であらかじめ定めておくことが鉄則です。完成してから合格基準を決めようとすると、発注側とベンダーの認識がずれ、「これで完成と言えるのか」という不毛な対立に陥ります。機能が要件どおり動くこと、性能要件の数値を満たすこと、想定したデータ量で正常に処理できることなどを、検収のチェック項目として事前に文書化します。
特に大規模システムでは、本番に近いデータ量・アクセス量での負荷テストを検収項目に含めることが重要です。少量のデータでは問題なく動いても、本番規模になると性能が破綻する、という事態は大規模特有のリスクです。前述の非機能要件で定めた数値（レスポンス・同時接続数など）を、検収テストの合格基準として明文化しておけば、性能面の品質を客観的に判定できます。要件定義・RFP・見積もり・検収基準は一本の線でつながっており、最初のRFPと要件定義を丁寧に作ることが、最後の検収まで一貫した品質を担保します。
まとめ
大規模システムのRFP・要件定義書・提案依頼書を整理すると、まず目的・背景・スコープと予算・納期・評価基準を明文化してベンダーから精度の高い提案を引き出し、次にレスポンス・データ量・同時接続数やセキュリティ・可用性・SLAといった非機能要件を数値で詰めることが、品質と費用を左右すると分かります。見積もりは人月単価と工数の内訳の透明性で妥当性を判断し、初期費用に隠れたランニングコストを5年のTCOで見抜くことが、費用対効果の判断で最も重要です。要件が曖昧だと工数が1.3〜1.5倍に膨張するというデータが示すとおり、この工程の質がプロジェクト全体を決めます。
さらにAIによるコード生成が普及した今、生成コードの品質・責任・著作権を検収基準に組み込み、本番規模の負荷テストの合格基準を要件段階で定めておくことが、新たな必須事項になっています。RFPと要件定義は、最後の検収まで一本の線でつながる設計図です。自社の目的と非機能要件を解像度高く言語化することから始めてください。riplaはフルスクラッチ受託と国内開発の立場から、要件定義からRFP作成、見積もりの妥当性評価、検収基準の設計までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。