大手企業向けシステムのRFPと要件定義書は、目的を起点に要件を固め、提案を比べ、検収基準を決めると、認識のずれを抑えられます。
発注企業の立場から、両者の書き方を実務に沿って解説し、自社のドラフト作成に着手する道筋を示します。全体像は大手企業向けのシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・大手企業向けのシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
大手のRFP（提案依頼書）に書くべき項目
RFP（Request for Proposal＝提案依頼書）は、要望を伝えて提案と見積もりを募る文書です。大手企業では、その完成度が各社の提案の質を左右します。
記載が曖昧なままだと、各社は異なる前提で提案を組み立ててしまい、見積もりを横並びで比べられなくなります。まず、RFPに盛り込む項目を整理します。
背景・目的・課題の明文化
RFPには、なぜシステムを作るのか、今どんな問題があるのか、刷新後にどうなりたいのかを文章で示します。これがあると、ベンダーは機能を並べるだけでなく、課題を解決する方向で提案を組み立てられます。
大手企業では、レガシーな基幹システムの老朽化や2025年の崖への対応、部門サイロの解消などが背景になり得ます。事情を具体的に示すほど、提案の精度が上がります。
現状（AsIs）の業務フローと、あるべき姿（ToBe）の方向性も、あわせて示します。ただし、最初から完全なToBeを描く必要はありません。
- 背景・目的：刷新の理由と、解決したい課題
- 業務の現状：AsIsの業務の流れと、改善したい業務
- 目指す姿：ToBeの方向性
機能の一覧だけを渡すと、現場の実態に合わない提案が返ってくるおそれがあります。だからこそ、課題と目的の流れに沿ってRFPを書くことが、良い提案を引き出す第一歩になります。
予算・納期・対象範囲・前提条件の明記
RFPには、想定予算と希望納期を書き、対象範囲（スコープ）と前提条件も示します。予算と範囲を示しておくと、各社の提案を同じ条件で比べられます。
予算の目安を示さずに提案を募ると、各社が想定する規模がばらばらになり、500万円の提案と5,000万円の提案が並んでしまって、比べられません。たとえば、費用相場の一つの目安は、大規模システムで2,500万〜5,000万円以上、基幹刷新クラスで5,000万〜1億円以上です。
自社が想定する金額の範囲を伝えておくと、各社は同じ前提で見積もりを作れます。さらに、対象範囲では、今回作るものと作らないものを分けて示します。
- 開発対象：連携する既存システム、移行データ、対象の部門と拠点
- 対象外：フェーズ2以降に回す機能
- 前提条件：認証基盤、クラウドかオンプレか、セキュリティ基準
範囲や前提が曖昧だと、提案後に対象外とされた作業の追加費用が発生します。そのため、RFPの段階でこれらを固めておくことが、後のトラブルを防ぐ備えになります。
機能要件と非機能要件の固め方
大手の案件で特に重要なのは、非機能要件をどこまで具体的に決めるかです。機能要件は画面や処理を定め、非機能要件は性能やセキュリティ、可用性といった品質を定めます。運用に関する項目も、非機能要件に含まれます。
大手システムでは非機能要件が見落とされやすく、その決め方が成否を左右します。一次データでは、工数の約20%が要件定義、約80%が設計からテストにかかるとされ、上流の精度は後工程にも響きます。
現場ヒアリングによる機能要件の具体化
機能要件は、現場の業務ヒアリングをもとに整理します。大手企業では、複数の部門の担当者から、業務の内容や順番、使う情報を聞き取ります。
- 画面：業務で必要な画面の洗い出し
- 処理：業務の流れに沿った処理の整理
- 帳票：現場で使う帳票の確認
机上の理想ではなく、実務に根ざした要件が、リリース後に使われるシステムにつながります。一方、現場を無視した要件では、誰にも使われず廃止されるリスクがあります。
要望は膨大になりやすいため、各機能に「必須」「推奨」「任意」の優先度を付けておきます。そうしておけば、予算の制約に直面したときに、残す機能と後回しにする機能を判断できます。
優先順位づけには、後から対象範囲が膨らむ（スコープクリープ）のを防ぐ役割もあります。まずは現場の実態から要件を積み上げ、そのうえで優先度で整理します。
非機能要件の数値による具体化
非機能要件では、セキュリティ、レスポンス、データ量、可用性などを数値で定めます。抽象的な表現のままにせず、項目ごとに水準を決めておきます。
- レスポンス：主要画面は3秒以内
- データ量：年間で増えるレコード数の想定
- 可用性：稼働率99.9%以上、障害時の初動は◯分以内
水準が曖昧だと、ベンダーが品質を低く見積もり、後から性能向上の追加費用が必要とされるおそれがあります。現場ユーザーは機能には詳しくても、性能やセキュリティの水準までは答えられません。そのため、情報システム、セキュリティ、インフラの各担当者を、要件定義の初期から巻き込みます。
経済産業省やIPAが整理した非機能要求の項目を参照し、自社の事業に応じた水準を設定します。項目には可用性、性能、運用などがあり、セキュリティや移行も含まれます。
非機能要件は目立ちにくいものの、大手システムの安定稼働を左右します。
複数ベンダーから妥当な提案を引き出す比較設計
大手システムの発注では、複数のベンダーから提案を募り、比べて選ぶのが一般的です。だからこそ、RFPの段階で評価条件をそろえておくことが重要です。条件がそろわないと、安さや見栄えに引きずられて、自社に合うベンダーを見落とすことがあります。
人月単価による見積もりの妥当性の検証
見積もりは「人月単価×工数」の観点で確認します。一次データでは、人月単価は職種や体制によって幅があります。
- 職種別：PMは110万〜150万円、SEは65万〜110万円、PGは50万〜90万円程度
- 体制別：中小開発会社は80万〜120万円、大手SIerは150万〜200万円
提案書の工数（人月）に単価を当てはめると、金額の内訳を大づかみに検証できます。
特に警戒すべきなのは、極端に安い見積もりです。必要な工数を削っていたり、後から追加請求する前提になっていたりすることがあり、品質低下や追加費用のリスクを伴います。
請負契約では、人月計算に1.3〜1.5倍の係数を見込み、全体の10〜20%をリスクバッファとして確保するのが一般的です。
価格の安さに加えて、金額の根拠と内訳の透明性、同規模・同業界の実績も評価します。
要件に合わせた請負と準委任の契約形態の選択
大手の発注では、契約形態の選択も要件定義と密接に関わります。要件が固まっている開発には、成果物の完成に責任を負う請負契約が向きます。
- 請負契約：成果物の完成を約束する契約で、要件が固まった開発向け
- 準委任契約：善管注意義務に基づいて作業を遂行する契約で、上流工程やアジャイル開発向け
一方で、要件が固まりきらない上流の要件定義や、アジャイル的に進める開発には、準委任契約が適しています。また、要件定義は準委任、開発は請負と、工程ごとに使い分ける方法もあります。
著作権は原則として、制作した受託者に帰属します。発注者が成果物の権利を持つ場合は、著作権法第27条・第28条の権利を含めて譲渡する旨を、契約に明記します。
権利が曖昧なままだと、後の改修や流用の場面で制約に直面します。さらに、SLAや保守範囲も契約前に定めておくと、稼働後のトラブルを防げます。
riplaは、フルスクラッチ受託の立場から、契約形態や権利、保守条件を要件の性質に合わせて整理するところまで伴走することを重視しています。
AI時代の検収基準と品質担保の要件
近年の要件定義では、AI生成コードが一般化した時代の検収基準が新たな論点になっています。ベンダーが生成コードを納品するケースも増えており、その品質やセキュリティ、権利関係の確認が必要です。また、従来の検収基準のままでは、AI特有のリスクを見落とすおそれがあります。
AI生成コードの脆弱性と責任範囲の要件化
AI生成コードは動いていても、脆弱性や保守しにくい構造を含むことがあります。そのため、品質を誰がどう担保するのかを、要件定義の段階で明らかにしておきます。
- レビュー・検査：人による設計レビューとセキュリティ検査
- 権利・ライセンス：生成コードに問題がないことの保証
- 責任範囲：バグ発見時の責任の所在
これらは、契約や検収条件に記載しておきます。AIの利用そのものより、品質の担保方法を曖昧にしないことが重要です。
LLM（大規模言語モデル）を組み込む場合は、事実と異なる回答（ハルシネーション）をどこまで許容するかを、発注側が要件で定めます。
重要な判断には人の確認を挟むなど、AIの出力をどう運用するかも要件に含めます。曖昧なままでは、誤った出力が稼働後の業務トラブルにつながります。
大手のAI活用システムでは、機能だけでなく、AIの誤りの扱いも検収基準に含めます。
要件定義で決める検収基準とテスト範囲
検収では、何をもって完成とするかを要件定義の段階で決めておきます。基準が曖昧だと、納品後に要件を満たすかどうかの議論が続き、検収が長引きます。
- 機能：機能ごとの受け入れ条件の明文化
- 性能：性能テストの合格ライン
- 移行・負荷：移行データの整合性と、負荷テストの範囲
検収条件は要件定義書に記載します。同書は、開発の指示書であると同時に、完成を判定するための基準にもなります。一方、曖昧な要件では検収も曖昧になり、品質が保証されないシステムが本番稼働するおそれがあります。
機能要件、非機能要件、検収基準を明確にしておけば、ベンダーは目標がはっきりした状態で開発でき、発注者も自信を持って検収できます。
要件定義は開発の入口で、検収の出口を定める作業でもあります。最初に数値と基準を固めることが、大手システムの成功の土台になります。
まとめ
大手システムの要件定義では、課題と目的を起点に、機能要件と非機能要件を具体化します。そのうえで、比べられる提案を募り、検収基準まで先に定めておきます。
RFPでは、背景と目的を示したうえで、予算や納期、範囲を記します。前提条件も併せて書きます。機能は現場ヒアリングと優先順位で整理し、非機能要件は性能やセキュリティ、可用性を数値で定めます。
見積もりは人月単価から妥当性を確認し、契約形態や権利、SLAは要件に合わせて決めます。AI生成コードの品質と検収基準も要件に含めます。また、請負契約では人月計算に1.3〜1.5倍の係数を見込みます。
性能やセキュリティ、契約や検収は、曖昧なままだと後の負担につながる領域です。発注側は、自社の組織や既存システム、事業特性を踏まえ、現場と情報システム部門を交えて要件を固めます。
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を創業。