大規模システムの発注は、目的と範囲を定め、非機能要件を数値にし、見積もりと検収基準を確認する順に進めます。この順にすると、品質と費用の妥当性につながります。
RFP（提案依頼書）・要件定義書の作り方を、発注企業の視点から解説します。全体像は完全ガイドもご覧ください。
▼全体ガイドの記事
・大規模システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
大規模システムのRFPに盛り込む記載項目
RFP（提案依頼書）は、発注企業がベンダーに実現したいことを伝える文書で、各社から精度の高い提案と見積もりを引き出す役割を担います。記載が曖昧だと、各社の提案や見積もりの前提がそろわず、比較して適切に選ぶことができません。そのため、まず盛り込む基本項目を明確にします。
大規模システムの投資額は数千万円から1億円規模に達します。要件が曖昧なまま発注すると、後工程の手戻りが連鎖します。その結果、工数が当初見積もりの1.3〜1.5倍に膨らむことも珍しくありません。
IPAのソフトウェア開発データ白書では、要件定義は工数比で約20%、工期比で約25%を占めます。この工程の質が、設計・開発・テストの精度を左右します。
目的・背景・スコープの書き方
RFPでは、プロジェクトの目的・背景・スコープ（範囲）を冒頭に記載します。導入理由、解決したい現状の課題、今回の開発で対象とする範囲を、文章にして書き出します。
- 対象範囲：今回の開発で実施する内容を示します。
- 対象外：開発の対象にしないことを明記します。
目的が曖昧だと、ベンダーは「とりあえず全部入り」の提案をしがちで、見積もりも膨らみます。
範囲の線引きは、スコープクリープ（範囲のなし崩し的な拡大）を防ぐのに役立ちます。開発中は「あの機能も欲しい」という要望が続き、当初の範囲を超えることがあるためです。
追加要望が出ても、対象外と明記してあれば「スコープ外なので別見積もり」と整理できます。費用と納期の膨張を抑えるには、目的・背景・範囲を丁寧に書いておくことが大切です。
予算・納期・前提条件と評価基準の提示
予算・希望納期・前提条件・評価基準も、RFPに含めます。予算の提示に抵抗を感じる担当者もいます。ただ、幅を示せば、ベンダーはその範囲で実現できる現実的な提案を出しやすくなります。
- 予算・納期：予算の目安と希望納期を示します。
- 段階リリース：段階的な公開を実施できるかどうかを伝えます。
- 評価基準：価格、同業界・同規模の実績、保守の一貫対応などを観点とします。
大規模システムの開発期間は6ヶ月以上で、規模によっては2年以上に及びます。そのため、希望納期と段階リリースの可否を伝えておくと、提案の幅が広がります。
価格だけでなく、品質や実績とのバランスも評価基準に含めます。たとえば、安すぎる見積もりは、追加請求や品質低下のリスクをはらみます。
RFPは、発注側の意図を整理して伝える設計図です。評価基準を示せば、ベンダーはその観点に沿って提案をまとめられます。
大規模だからこそ詰めるべき非機能要件
発注側が見落としやすいのが非機能要件です。機能要件は議論されやすい一方で、処理速度やデータ量、停止せずに処理する水準は曖昧になりがちです。特に大規模システムでは、非機能要件が性能と安定性を決め、費用の大半を左右します。
レスポンス・データ量・同時接続数の数値定義
非機能要件は、数値で定義しておきます。数値があると、ベンダーは構成を設計でき、精度の高い見積もりを出せます。
- 画面表示：「速く動く」を、3秒以内という数値で示します。
- データ量：「大量データ」の中身は、商品マスタ100万件・年間取引500万件です。
- 同時接続：「多くの人」は、ピーク時500ユーザーと示します。
数値には、現在の実績だけでなく、数年後の成長見込みも含めます。導入時点のデータ量だけで設計すると、事業が伸びた後に性能が頭打ちになり、早期の作り直しを迫られます。
反対に、過大な想定では不要な性能に費用を払うことになります。そこで、業務量の推移を分析し、現実的なピーク値と将来値を見定めます。レスポンス・データ量・同時接続数を数値で詰めることが、性能要件を適切な水準にする鍵です。
セキュリティ・可用性・SLAの水準の定め方
性能と並んで重要なのが、セキュリティ・可用性・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生成コードをそのまま採用すると、動いていても脆弱性や保守しにくい構造が潜むことがあります。「とりあえず動く」だけのコードは、将来の改修や障害対応で負債になります。
- 品質：人がコードをレビューし、基準を満たすことを検収条件にします。
- 責任：生成コードのバグや脆弱性を、誰が負うかを契約で示します。
- 著作権：権利の扱いと必要な譲渡を契約に定めます。
納品物の著作権は、原則として受託者に帰属します。ただし、発注側が自由に改修・流用するなら、著作権法27条・28条の権利も含む譲渡を契約に明記します。
AIが介在しても、最終的な品質と責任はベンダーが負う構造を、検収基準に落とし込みます。これが、AI時代の発注条件です。
要件段階で定める検収テストの合格基準
検収で何をもって合格とするかは、要件定義の段階で定めておきます。完成後に決めると、発注側とベンダーの認識がずれ、完成をめぐる対立につながります。
- 機能：要件どおりに動くことを確かめます。
- 性能：非機能要件の数値を満たすかどうかを見ます。
- 処理：想定したデータ量で正常に処理できることです。
大規模システムでは、本番に近いデータ量やアクセス量での負荷テストも、検収項目に含めます。少量データでは動いても、本番規模では性能が破綻するリスクがあります。
非機能要件で定めたレスポンスや同時接続数を、検収テストの合格基準に明記しておけば、性能を客観的に判定できます。
要件定義・RFP・見積もり・検収基準は、一本の線でつながっています。だからこそ、最初のRFPと要件定義を丁寧に作ることが、最後まで品質を担保します。
まとめ
大規模システムのRFPでは、目的・背景・スコープ、予算・納期・評価基準を文章で示し、精度の高い提案を引き出します。
レスポンス・データ量・同時接続数に加えて、セキュリティ・可用性・SLAも数値で詰めます。非機能要件が、品質と費用を左右します。
見積もりでは、人月単価と工数の内訳を確かめて妥当性を判断します。初期費用だけでなく、5年のTCOで維持費も比べます。
隠れたランニングコストを把握することが、費用対効果の判断で最も重要です。要件が曖昧だと工数が1.3〜1.5倍に膨らむこともあり、工程の質が全体を左右します。
AI生成コードの品質・責任・著作権を検収基準に含め、本番規模の負荷テストも要件段階で定めます。RFPから検収まで一貫させるには、まず自社の目的と非機能要件を言葉にすることから始めます。
RFPと要件定義は、最後の検収まで一本の線でつながる設計図です。
riplaはフルスクラッチ受託と国内開発の立場から、要件定義、RFP作成、見積もり評価、検収基準の設計を一貫して支援します。
▼全体ガイドの記事
・大規模システムの完全ガイド
▼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を創業。