要件定義が不十分なRFPの典型例と改善策

システム開発やIT導入プロジェクトにおいて、RFP（提案依頼書）は成功への重要な第一歩となります。

しかし、要件定義が不十分なRFPを発行してしまうと、ベンダー選定に失敗し、期待した成果が得られないばかりか、予算超過やスケジュール遅延といった深刻な問題を招くリスクがあります。

本記事では、要件定義後にRFPを発行する場合において、要件定義が不十分な典型例を5つ取り上げ、それぞれの問題点と具体的な改善策を解説します。

RFPと要件定義の基本的な関係性

RFP（Request for Proposal：提案依頼書）は、システム開発やIT導入プロジェクトにおいてベンダーに提案を依頼するための文書であり、その中核をなすのが要件定義です。

要件定義が明確に記載されているRFPは、ベンダーから適切な提案を引き出し、プロジェクトの成功確率を大幅に高める効果があります。

ここでは、RFPにおける要件定義の重要性と、不十分な場合に発生する問題について解説します。

RFPにおける要件定義の役割

RFPにおける要件定義は、発注側が実現したい目的や解決したい課題を具体的に示し、ベンダーに対して「何を求めているのか」を明確に伝える役割を担います。

要件定義には、機能要件（システムに求める具体的な機能）と非機能要件（性能、セキュリティ、可用性など）の両方が含まれます。

明確な要件定義があることで、ベンダーは提案内容を具体化でき、発注側は複数のベンダーからの提案を公平に比較・評価することが可能になります。

また、要件定義はプロジェクト全体のスコープを定義し、後工程での認識齟齬や仕様変更を防ぐ基準としても機能します。

このように、RFPにおける要件定義は単なる希望事項の羅列ではなく、プロジェクト成功のための設計図といえるでしょう。

要件定義が不十分なRFPがもたらす問題

要件定義が不十分なRFPを発行すると、様々な問題が連鎖的に発生します。

まず、ベンダー側は発注側が何を求めているのか正確に理解できず、的外れな提案や過剰な見積もりを提出する可能性が高まります。

その結果、発注側は本当に必要な機能や解決策を含む提案を選定できず、ベンダー選定そのものが失敗に終わるリスクがあります。

さらに、要件定義の曖昧さは開発フェーズでの度重なる仕様変更を招き、スケジュール遅延や予算超過の原因となります。

発注側とベンダー間での認識齟齬から生じる対立や信頼関係の悪化も、要件定義が不十分なRFPの典型的な問題です。

また、完成したシステムが当初の期待や業務課題の解決に貢献せず、投資対効果が著しく低下するケースも少なくありません。

要件定義の不備は、プロジェクト全体の品質とコストに直接的な影響を及ぼす重大な要因なのです。

要件定義が不十分なRFPの典型例5選

実際のプロジェクトにおいて、要件定義の不備が原因でベンダー選定に失敗したり、開発段階で深刻な問題が発生したりする事例は数多く存在します。

ここでは、要件定義が不十分なRFPの代表的な5つの典型例を取り上げ、それぞれの問題点と改善策を具体的に解説します。

自社のRFP作成時にこれらの典型例を避けることで、より質の高い提案依頼書を作成できるでしょう。

典型例①プロジェクトの目的と課題が曖昧

要件定義が不十分なRFPの中でも特に多いのが、プロジェクトの目的と解決すべき課題が曖昧にしか記載されていないケースです。

「業務効率化のため」「システムを刷新したい」といった抽象的な表現だけでは、ベンダーは何を優先して提案すればよいのか判断できません。

典型的な問題点

目的が曖昧なRFPでは、「現行システムの老朽化対策」や「業務の効率化」といった漠然とした記述にとどまり、具体的に何が課題なのか、どのような状態を目指すのかが不明確です。

たとえば、「営業部門の業務を効率化したい」という目的だけでは、受注処理の時間短縮が目的なのか、顧客情報の一元管理が目的なのか、あるいは売上予測の精度向上が目的なのかがわかりません。

このような曖昧さは、ベンダーに過剰な機能を提案させる原因となり、結果的にコスト増や不要な機能の実装につながります。

また、プロジェクト完了後の成功基準も定義されていないため、「期待した効果が得られなかった」という不満が発生しやすくなります。

改善策と具体的な記載例

プロジェクトの目的を明確にするには、「なぜこのシステムが必要なのか」「現状のどのような課題を解決したいのか」「プロジェクト完了後にどのような状態を実現したいのか」を具体的に記載する必要があります。

目的を記載する際は、以下のような具体的な情報を盛り込みましょう。

項目	例
現状の業務フローと課題	受注から納品までに平均5営業日かかっており、競合他社と比較して2日遅い
解決したい具体的な問題	手作業によるデータ入力ミスが月平均15件発生し、顧客クレームの原因となっている
プロジェクト完了後の目標状態	受注から納品までの期間を3営業日以内に短縮し、入力ミスをゼロにする
期待する効果の定量的な指標	年間の人的コストを20%削減、顧客満足度スコアを85点に向上

このように具体的に記載することで、ベンダーは発注側の真のニーズを理解し、課題解決に最適な提案を行うことができます。

典型例②機能要件の粒度が粗すぎる

機能要件の記載において、「顧客管理機能が必要」「在庫管理ができること」といった大まかな記述のみで、具体的な機能の詳細が不足しているRFPも典型的な問題例です。

粒度が粗すぎる機能要件は、ベンダーによって解釈が大きく異なり、提案内容のばらつきを招きます。

典型的な問題点

機能要件の粒度が粗いRFPでは、「顧客管理機能」という一言だけで済まされ、具体的にどのような情報を管理するのか、どのような操作が必要なのかが記載されていません。

たとえば、顧客管理機能といっても、基本的な顧客情報の登録・検索だけなのか、商談履歴や購買履歴の管理も含むのか、複数の担当者による共同編集が必要なのかによって、システムの規模や構築方法は大きく異なります。

このような粒度の粗さは、ベンダーが過剰スペックの提案をするリスクや、逆に必要な機能が不足した提案になるリスクを高めます。

また、開発段階で「この機能も必要だったのか」という追加要望が頻発し、スケジュール遅延や追加費用の発生につながります。

改善策と具体的な記載例

機能要件は、実際の業務フローや操作シーンを想定しながら、できるだけ具体的に記載することが重要です。

機能要件を記載する際は、以下のような情報を含めましょう。

• 機能の目的（なぜその機能が必要なのか）
• 具体的な操作内容（誰が、どのような場面で、何をするのか）
• 扱うデータの種類と項目（例：顧客情報には企業名、担当者名、連絡先、取引履歴を含む）
• 必須機能と優先度の高い任意機能の区別
• 想定される利用者数や同時アクセス数

たとえば、顧客管理機能の場合、以下のように具体的に記載します。

• 営業担当者（約50名）が顧客企業の基本情報（企業名、所在地、業種、従業員規模）を登録・検索・更新できる機能
• 担当者情報（氏名、部署、役職、連絡先）
• 商談履歴（日時、内容、次回アクション）を登録・検索・更新できる機能
• 複数の営業担当者が同一顧客情報を共有し、最新の活動状況を確認できる機能
• 顧客情報は既存の販売管理システムと連携し、受注実績も表示できることが望ましい

このレベルの具体性があれば、ベンダーは適切な規模とスコープで提案を作成できます。

典型例③非機能要件の記載が不足または欠落

機能要件は比較的詳しく記載されていても、非機能要件（性能、セキュリティ、可用性、拡張性など）の記載が不足しているか、完全に欠落しているRFPも多く見られます。

非機能要件は、システムの品質や運用安定性を左右する重要な要素であり、不足すると重大な問題を引き起こします。

典型的な問題点

非機能要件が不足しているRFPでは、システムの応答速度やセキュリティレベル、障害発生時の対応方針などが明示されていません。

たとえば、ECサイトを構築する場合、セール時に同時アクセスが急増することが想定されますが、「同時アクセス数1000件でも3秒以内に画面表示すること」といった性能要件が記載されていなければ、ベンダーは最小限のインフラで提案する可能性があります。

その結果、本稼働後にアクセス集中でシステムダウンし、機会損失や顧客信頼の低下を招きます。

また、個人情報を扱うシステムにもかかわらずセキュリティ要件が曖昧だと、必要な暗号化やアクセス制御が実装されず、情報漏洩のリスクが高まります。

非機能要件の欠落は、システムの品質問題や運用コストの増大に直結する深刻な問題です。

改善策と具体的な記載例

非機能要件は、システムの品質を保証するための重要な要素として、RFPに必ず含めるべき項目です。

以下のような非機能要件カテゴリについて、具体的な基準を記載しましょう。

非機能要件カテゴリ	記載すべき具体的内容
性能・拡張性応答時間、処理速度、同時接続数、将来的なユーザー増加への対応可否
可用性・信頼性	稼働率（例：99.9%以上）、障害復旧時間、バックアップ頻度
セキュリティ	暗号化方式、アクセス制御、個人情報保護対策、準拠すべき規格
運用・保守性	ログ管理、監視機能、データ移行方法、マニュアル整備
移行性・互換性	既存システムとのデータ移行方法、他システムとの連携仕様

たとえば、性能要件の記載例としては以下のようになります。

1. 通常時の同時アクセス数は約200件、繁忙期（月初の3営業日）には最大1000件を想定
2. 画面表示の応答時間は通常時3秒以内、繁忙期でも5秒以内を維持すること
3. 将来的に利用部門が現在の5部門から10部門に拡大する可能性があるため、ユーザー数の増加に対応できる拡張性を持つこと

セキュリティ要件の記載例としては以下のようになります。

1. 個人情報保護法に準拠し、個人情報は暗号化して保存すること
2. アクセスログを最低1年間保存し、不正アクセスを検知できる仕組みを導入すること
3. 利用者の権限管理機能を実装し、部門ごとにアクセス可能なデータを制限できること

このように非機能要件を具体的に記載することで、システムの品質と安定性が確保されます。

典型例④スケジュールと体制に関する記載が曖昧

プロジェクトのスケジュールや発注側・ベンダー側の体制に関する記載が曖昧なRFPも、要件定義が不十分な典型例の一つです。

スケジュールや体制が明確でないと、プロジェクト計画そのものが不安定になり、遅延や責任の所在の不明確化といった問題が発生します。

典型的な問題点

スケジュールに関する記載が「2026年度内に稼働開始」といった大まかな記述のみで、要件定義・設計・開発・テストといった各フェーズの期限が示されていないRFPでは、ベンダーは現実的なスケジュールを組めません。

また、発注側がどの程度プロジェクトに関与できるのか、意思決定の体制がどうなっているのかが不明確だと、ベンダーは作業の前提条件を正確に把握できず、無理のあるスケジュール提案をしてしまうリスクがあります。

たとえば、発注側の確認・承認に時間がかかる体制であるにもかかわらず、その点が明示されていないと、ベンダーは短期間での開発を前提とした提案を行い、後に大幅な遅延が発生します。

さらに、発注側の担当者が複数プロジェクトを兼務しており十分な時間を割けない状況が伝わっていないと、ベンダーの期待と現実の間にギャップが生じます。

改善策と具体的な記載例

スケジュールと体制については、以下の情報を明確に記載することが重要です。

• プロジェクト全体のスケジュール（主要マイルストーンと各フェーズの期限）
• 稼働開始の希望時期とその理由（業務サイクルやイベントとの関連）
• 発注側の体制（プロジェクト責任者、担当者、意思決定プロセス）
• 発注側が対応可能な作業範囲（要件定義への参加度合い、テストへの関与など）
• 定例会議や報告の頻度

たとえば、スケジュールの記載例としては以下のようになります。

1. 2026年9月末までに稼働開始することを希望します。
2. 理由は、10月が当社の下期開始月であり、新システムでの業務開始に最適なタイミングであるためです。
3. 主要マイルストーンとして、6月末までに要件定義完了、7月末までに基本設計完了、8月末までに開発・テスト完了を想定していますが、実現可能性を含めた提案をお願いします。

体制に関する記載例としては以下のようになります。

1. 発注側の体制は、プロジェクトオーナー（情報システム部長）、プロジェクトマネージャー（情報システム部担当者1名）、業務側担当者（営業部・経理部から各1名）で構成します。
2. 意思決定は週次のプロジェクト会議で行い、重要事項は経営会議（月1回）での承認が必要です。
3. 要件定義フェーズでは業務側担当者が週2日程度参加可能ですが、それ以降のフェーズでは週1日程度の関与となる見込みです。

このように具体的に記載することで、ベンダーは現実的なスケジュールと体制を考慮した提案ができます。

典型例⑤予算や契約条件の記載がない

予算や契約条件に関する記載が全くないか、極めて曖昧なRFPも、要件定義が不十分な典型例です。

予算の上限や契約形態が不明確だと、ベンダーは提案の方向性を定められず、発注側の期待と大きく乖離した見積もりが提出される可能性があります。

典型的な問題点

予算に関する記載が一切ないRFPでは、ベンダーは「できる限り多機能なシステムを提案しよう」と考え、発注側の想定を大幅に超える高額な見積もりを提出するケースがあります。

逆に、極端に低い予算を想定しているベンダーは、必要最小限の機能だけを提案し、発注側が期待する成果を実現できない提案になることもあります。

また、契約形態（一括請負か準委任か）、支払条件、納品物の範囲、保守契約の有無などが明示されていないと、後の契約交渉で大きなトラブルの原因となります。

たとえば、発注側は運用保守も含めた価格を想定していたのに、ベンダーは開発費のみで見積もっており、稼働後の保守費用が別途必要と判明して予算不足に陥るケースがあります。

改善策と具体的な記載例

予算や契約条件については、以下の情報を可能な限り明示することが望ましいです。

• 予算の上限または想定範囲（公開可能な範囲で）
• 契約形態の希望（一括請負、準委任、段階的契約など）
• 支払条件（一括払い、分割払い、成果に応じた支払いなど）
• 納品物の範囲（システム本体、マニュアル、ソースコード、設計書など）
• 運用保守の考え方（開発ベンダーへの委託希望、自社対応など）
• 知的財産権の帰属

たとえば、予算の記載例としては以下のようになります。

1. 本プロジェクトの予算上限は2000万円（税抜）を想定しています。
2. 内訳として、システム開発費1500万円、運用保守費（初年度）200万円、その他（教育・移行支援等）300万円を想定していますが、提案内容に応じて柔軟に検討します。

契約条件の記載例としては以下のようになります。

1. 契約形態は一括請負契約を希望します。
2. 支払条件は、契約時30%、基本設計完了時30%、納品・検収完了時40%を想定しています。
3. 納品物には、システム本体、ソースコード、設計書、操作マニュアル、運用マニュアルを含めることとします。
4. 知的財産権は発注側に帰属することを希望します。
5. 運用保守については、稼働後1年間は開発ベンダーに委託する契約を別途締結したいと考えています」

このように明示することで、ベンダーは現実的な見積もりと提案を作成でき、後のトラブルも防げます。

ベンダー選定を成功させる！記載項目チェックリスト

要件定義が不十分なRFPの典型例を踏まえて、ベンダー選定を成功させるためには、RFPに必要な記載項目を網羅的にチェックすることが重要です。

ここでは、RFP作成時に確認すべき記載項目をカテゴリ別に整理し、チェックリストとして提示します。

このチェックリストを活用することで、記載漏れや曖昧な表現を防ぎ、質の高いRFPを作成できるでしょう。

プロジェクト背景・目的に関する記載項目

プロジェクト背景と目的に関しては、以下の項目を明確に記載することが必要です。

• 自社の事業内容と組織概要
• プロジェクト実施の背景（現状の課題や問題点）
• プロジェクトの目的（何を実現したいのか）
• 期待する効果（定量的な目標を含む）
• プロジェクトの優先順位と重要度
• ステークホルダー（経営層、利用部門など）の期待

これらの項目が具体的に記載されていることで、ベンダーは発注側のビジネス状況を理解し、最適な解決策を提案できます。

特に、定量的な目標（コスト削減率、処理時間短縮率、エラー削減件数など）を明示することで、提案内容の評価基準も明確になります。

機能要件・非機能要件に関する記載項目

機能要件と非機能要件については、以下のような項目を具体的に記載しましょう。

機能要件の記載項目

• 必須機能と任意機能の区別
• 各機能の詳細な仕様（操作フロー、入出力データ、画面イメージなど）
• 想定利用者数と利用部門
• 既存システムとの連携要件
• データ移行の範囲と方法

非機能要件の記載項目

• 性能要件（応答時間、処理速度、同時アクセス数）
• 可用性要件（稼働率、復旧時間目標）
• セキュリティ要件（認証、暗号化、アクセス制御、準拠規格）
• 運用・保守性要件（ログ管理、監視、バックアップ）
• 拡張性要件（将来的なユーザー増加やデータ量増加への対応）
• ユーザビリティ要件（操作性、アクセシビリティ）

これらの要件を具体的に記載することで、ベンダーは技術的に実現可能な提案を行い、後工程での仕様変更を最小化できます。

スケジュール・体制・契約条件に関する記載項目

スケジュール、体制、契約条件については、以下の項目を明示しましょう。

スケジュール関連

• プロジェクト全体のスケジュール（主要マイルストーン）
• 各フェーズの期限（要件定義、設計、開発、テスト、移行）
• 稼働開始希望時期とその理由
• スケジュールの制約条件（繁忙期、決算期など）

体制関連

• 発注側の体制（責任者、担当者、役割分担）
• 意思決定プロセスと承認フロー
• 発注側の対応可能範囲と工数
• 定例会議や報告の頻度

契約条件関連

• 予算の上限または想定範囲
• 契約形態（一括請負、準委任など）
• 支払条件（支払時期、支払割合）
• 納品物の範囲
• 知的財産権の帰属
• 運用保守の考え方
• 瑕疵担保責任や損害賠償の範囲

これらの項目を明確にすることで、ベンダーは実現可能性を判断し、適切な提案を行うことができます。

提案依頼内容と評価基準に関する記載項目

ベンダーに何を提案してほしいのか、どのような基準で評価するのかを明示することも重要です。

提案依頼内容

• 提案してほしい項目（システム構成、開発方法、体制、スケジュール、費用など）
• 提案書の構成と記載内容
• 提案書の提出期限と提出方法
• 質問受付期間と質問方法
• プレゼンテーションやデモの有無

評価基準

• 評価項目（機能適合性、技術力、実績、価格、サポート体制など）
• 各評価項目の配点または重み付け
• 選定スケジュール（評価期間、結果通知時期）
• 選定方法（書類審査、プレゼンテーション、参考事例の確認など）

評価基準を事前に明示することで、ベンダーは発注側が重視するポイントを理解し、それに沿った提案を作成できます。

また、発注側も客観的で公平な評価が可能になります。

まとめ

要件定義が不十分なRFPは、ベンダー選定の失敗やプロジェクトの遅延・予算超過を招く大きな原因となります。

本記事で解説した5つの典型例を避け、目的・課題、機能要件、非機能要件、スケジュール・体制、予算・契約条件を具体的に記載することで、質の高いRFPが作成できます。

チェックリストを活用し、ベンダーから最適な提案を引き出しましょう。

合わせて読みたい

監修者プロフィール

岩井 知洋

株式会社クロスオーバー
取締役 ITコンサルティング事業部 事業部長

大手SI事業者にて、大規模開発のPMを経験後、日本能率協会コンサルティング（JMAC）に入社し、金融から物流、自治体まで幅広くシステムグランドデザインやシステム化企画、業務分析・改善等の支援に従事。
近年は、JMACのグループ会社であるクロスオーバーにて、メガバンク、政令市、大手アパレル、製造業等におけるシステム再構築やインフラアウトソーシングの案件等のシステム化企画やユーザー側のPMOを中心に支援している。