大手企業向けのシステム開発を発注するとき、その成否の8割を決めると言っても過言ではないのが、RFP（提案依頼書）と要件定義の質です。大手のシステムは、関わる部門・拠点・既存システムが多く、利用者数も数千〜数万人に及ぶため、要件が曖昧なままベンダーに丸投げすると、提案各社の見積もりがバラバラになり、開発が始まってからも認識のズレと仕様変更が止まらなくなります。一次データでは、要件が曖昧なまま進んだプロジェクトは工数が当初の1.3〜1.5倍に膨張するとされ、大手の大規模案件ではこれが数千万円単位の超過に直結します。
本記事は、大手企業向けのシステムのRFP・要件定義書・提案依頼書を、発注企業の視点から「要件定義特化」で実務的に解説します。RFPに書くべき項目とその粒度、機能要件と非機能要件の固め方、複数ベンダーから妥当な提案を引き出す比較設計、そしてAI生成コードが当たり前になった時代の検収基準まで、一次データとあわせて掘り下げます。読み終えるころには、自社のRFPと要件定義のドラフトに着手できる具体的な道筋が見えるはずです。なお、大手企業向けシステムの全体像をまだ把握していない方は、まず大手企業向けのシステムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・大手企業向けのシステムの完全ガイド
大手のRFP（提案依頼書）に書くべき項目
RFP（Request for Proposal＝提案依頼書）は、ベンダーに「こういうシステムを作ってほしい」という要望を伝え、それに対する提案と見積もりを引き出すための文書です。大手企業の場合、RFPの完成度がそのまま提案各社のアウトプットの質を決めます。RFPが曖昧だと、各社が自社の都合のいい前提で提案を作り、出てきた見積もりを横並びで比較できなくなります。まずは何を盛り込むべきかの全体像を押さえましょう。
背景・目的・課題を最初に明文化する
RFPの冒頭で最も重要なのが、プロジェクトの背景・目的・解決したい課題の明文化です。「なぜ今このシステムを作るのか」「現状の何が問題で、刷新後にどうなりたいのか」を言語化することで、ベンダーは単なる機能の実装者ではなく、課題解決のパートナーとして提案を組み立てられます。大手では、レガシー基幹の老朽化や2025年の崖への対応、部門サイロの解消といった背景があるはずで、これを具体的に書くほど提案の精度が上がります。
背景と並んで、現状（AsIs）の業務フローと、あるべき姿（ToBe）の方向性も示します。完璧な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を使った開発（いわゆるVibe Coding）が広がる中、ベンダーがAIに生成させたコードをそのまま納品するケースも増えており、その品質・セキュリティ・権利関係をどう検収するかが、大手の発注者にとって新たな論点になっています。従来の検収基準だけでは、AI特有のリスクを見落とすおそれがあります。
AI生成コードの脆弱性と責任範囲を要件化する
AIに丸投げで生成させたコードには、表面上は動くものの、セキュリティ上の脆弱性や保守困難な構造が潜んでいることがあります。要件定義の段階で、「AI生成コードであっても人による設計レビューとセキュリティ検査を経ること」「生成コードの著作権やライセンス上の問題がないことを保証すること」「バグが見つかった場合の責任の所在」を契約・検収条件として明記しておくと安心です。AIを使うこと自体は問題ではなく、その品質を誰がどう担保するかを曖昧にしないことが肝心です。
とくにLLM（大規模言語モデル）を組み込んだシステムを開発する場合は、AIが事実と異なる回答を生成するハルシネーションをどこまで許容するか、その検収基準を要件に盛り込む必要があります。「AIの出力をそのまま正としない」「重要な判断には人のチェックを挟む」といった運用前提を要件化しておかないと、稼働後にAIの誤った出力が業務トラブルを引き起こします。大手のAI活用システムは、機能要件だけでなく「AIの誤りをどう扱うか」までを検収基準に含めるべき時代になっています。
検収基準とテスト範囲を要件定義で先に決める
AIに限らず、大手の検収では「何をもって完成とみなすか」を要件定義の段階で具体的に決めておくことが重要です。検収基準が曖昧だと、納品後に「これは要件を満たしていない」「いや満たしている」という水掛け論になり、検収が長期化します。機能ごとの受け入れ条件、性能テストの合格ライン、移行データの整合性チェック、負荷テストの実施範囲などを、要件定義書のなかで明文化しておきましょう。
検収を見据えると、要件定義書は単なる開発の指示書ではなく、「完成を判定する物差し」でもあることが分かります。曖昧な要件は曖昧な検収しか生まず、結果として品質の保証されないシステムが本番に乗ってしまいます。逆に、機能要件・非機能要件・検収基準が明確であれば、ベンダーも明確なゴールに向かって開発でき、発注者も自信を持って検収できます。要件定義は、開発の入口であると同時に検収の出口を定める作業だと捉え、最初の数値と基準を妥協なく固めることが、大手システム成功の土台になります。
まとめ
大手企業向けのシステムのRFP・要件定義を整理すると、その要諦は「課題と目的を起点に、機能要件と非機能要件を数値の解像度で固め、比較可能な提案を引き出し、検収基準まで先に決めておく」ことに集約されます。RFPには背景・目的・予算・納期・スコープ・前提を明記し、機能要件は現場ヒアリングから優先度づけし、非機能要件は性能・セキュリティ・可用性を数値で定義します。見積もりは人月単価で妥当性を検証し、契約形態と権利・SLAを要件の性質に合わせて選び、AI時代には生成コードの品質と検収基準まで要件化する。これらの積み上げが、工数1.3〜1.5倍膨張という曖昧さの代償を防ぎます。
要件定義で大切なのは、見える機能だけでなく、性能・セキュリティ・契約・検収という「曖昧にすると後で高くつく領域」を妥協なく明文化することです。自社の組織・既存システム・事業特性に照らし、現場と情報システム部門を巻き込んで要件を固めてください。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を創業。