1. 概要
提案依頼書（RFP：Request For Proposal）および見積依頼書（RFQ：Request For Quotation）は、システム調達における重要な文書です。これらは、発注者がベンダー企業に対して調達対象システム、提案依頼事項、調達条件などを明確に示し、具体的な提案書や見積書の提出を依頼するために使用されます。特に情報システムの調達においては、要件の曖昧さによる認識のズレを防ぎ、適切なベンダー選定を行うための基盤となるため、非常に重要な役割を担っています。
flowchart TD
A[調達計画策定] --> B[要件定義]
B --> C[RFP作成]
C --> D[RFP配布]
D --> E[ベンダー説明会]
E --> F[質疑応答]
F --> G[RFQ配布]
G --> H[提案書・見積書受領]
H --> I[評価・選定]
I --> J[契約交渉]
J --> K[契約締結]
style C fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#f9f,stroke:#333,stroke-width:2px
style G fill:#ccf,stroke:#333,stroke-width:2px
style H fill:#ccf,stroke:#333,stroke-width:2px
図1: システム調達プロセスにおけるRFP・RFQの位置づけ
2. 詳細説明
2.1. 提案依頼書（RFP）の定義と目的
RFPとは、システム調達を行う際に発注者がベンダー企業に対して発行する文書であり、調達するシステムの要件や条件を明確にして、それに対する提案を依頼するものです。RFPの主な目的は以下の通りです。
- 発注者の要求を明確に伝える
- ベンダー間の公平な競争環境を提供する
- 提案内容の比較評価を容易にする
- プロジェクトの範囲と期待を明確にする
2.2. 見積依頼書（RFQ）の定義と目的
RFQは、特定の製品やサービスに対する価格や納期などの見積もりを依頼するための文書です。RFPが提案内容も含めた依頼であるのに対し、RFQはより具体的な価格や納期に焦点を当てています。
| 項目 | RFP（提案依頼書） | RFQ（見積依頼書） |
|---|---|---|
| 主な目的 | ソリューション提案の依頼 | 価格・納期等の見積もり依頼 |
| 依頼内容の詳細度 | 要件の概要レベル | 具体的な仕様レベル |
| 発行タイミング | 調達プロセスの初期〜中期 | RFP評価後または単独で |
| ベンダーに求める回答 | 技術提案、実施方法、体制、実績、概算費用など | 詳細な費用、納期、保守条件など |
| 評価の焦点 | 技術力、実績、提案内容の適合性など | 主に価格と納期 |
表1: RFPとRFQの比較表
flowchart TD
A[要件整理] --> B[RFP作成]
B --> C[ベンダー選定]
C --> D[RFP配布]
D --> E[説明会開催]
E --> F[質疑応答]
F --> G[提案書受領]
G --> H[一次評価]
H --> I[プレゼンテーション]
I --> J[最終評価]
J --> K[ベンダー選定]
style B fill:#f9f,stroke:#333,stroke-width:2px
style G fill:#ccf,stroke:#333,stroke-width:2px
style J fill:#cfc,stroke:#333,stroke-width:2px
style K fill:#cfc,stroke:#333,stroke-width:2px
図2: RFP作成・評価プロセスフロー
2.3. RFPの主要構成要素
効果的なRFPには、以下の要素が含まれています。
2.3.1. 対象範囲
調達するシステムの範囲を明確に定義します。どのビジネスプロセスやシステム機能が含まれるか、また含まれないかを明示することで、誤解を防ぎます。
2.3.2. システムモデル
理想とするシステムの概要や構成モデルを示します。現行システムとの関係や、全体アーキテクチャにおける位置づけなども含めると良いでしょう。
2.3.3. サービス要件
システムに求められる機能要件、非機能要件（性能、セキュリティ、可用性など）を詳細に記述します。これはベンダーが提案するソリューションの基盤となります。
2.3.4. 目標スケジュール
プロジェクトの開始時期、主要マイルストーン、完了予定日などの時間的制約を明示します。これにより、ベンダーは実現可能なプロジェクト計画を立てることができます。
2.3.5. 契約条件
支払い条件、知的財産権の帰属、保守サポート条件、SLA（Service Level Agreement）などの契約上の条件を記載します。
2.4. ベンダー評価基準
2.4.1. ベンダーの経営要件
財務状況、企業規模、事業継続性など、ベンダー企業としての安定性や信頼性に関する要件を示します。長期的なシステム運用を考慮する場合、特に重要な評価項目となります。
2.4.2. ベンダーのプロジェクト体制要件
プロジェクトマネージャーの経験、技術者のスキルレベル、要員数、バックアップ体制などのプロジェクト実施体制に関する要件を記載します。
2.4.3. ベンダーの技術及び実績評価
類似プロジェクトの実績、特定技術の専門性、認証取得状況などを評価基準として示します。これにより、ベンダーの技術的な信頼性や適合性を判断することができます。
| 評価項目 | 評価基準 | ウェイト |
|---|---|---|
| 提案内容の適合性 | 要件への対応度、実現可能性 | 30% |
| コスト | 初期費用、運用費用、TCO | 25% |
| ベンダーの実績 | 類似案件の実績、業界知識 | 15% |
| 技術力 | 採用技術の適切さ、先進性 | 15% |
| プロジェクト体制 | PM経験、要員スキル、バックアップ体制 | 10% |
| 企業の安定性 | 財務状況、事業継続性 | 5% |
表2: ベンダー評価基準の例とウェイト付け
3. 応用例
3.1. 業界別のRFP・RFQ活用事例
3.1.1. 金融業界
金融機関では、セキュリティや可用性に関する厳格な要件を持つシステムの調達が多く、RFPにはこれらの要件が詳細に記載されます。例えば、インターネットバンキングシステムの調達では、不正アクセス対策や24時間365日の安定稼働に関する要件が重視されます。
3.1.2. 製造業界
製造業では、生産管理システムやSCM（Supply Chain Management）システムの調達において、既存の生産設備との連携や、国際的なサプライチェーンに対応するためのグローバル対応などが重要視されます。
3.1.3. 公共部門
政府機関や地方自治体では、透明性と公平性を確保するために、より形式的で詳細なRFPが作成されることが多いです。また、法令遵守や情報公開に関する要件も重要な位置を占めます。
3.2. RFP・RFQプロセスの最新トレンド
3.2.1. クラウドサービス調達
近年はオンプレミスのシステム構築だけでなく、SaaS（Software as a Service）などのクラウドサービス調達におけるRFPも増加しています。この場合、データの所在やセキュリティ、SLAなどの条件が特に重要になります。
3.2.2. アジャイル開発対応
従来の一括発注型のRFPだけでなく、アジャイル開発手法に適応したRFPの形式も登場しています。要件の詳細度や柔軟性、反復的な開発サイクルに対応した契約形態などが考慮されます。
| RFP目次構成例 | ||
|---|---|---|
| 1. はじめに | 1.1. 本書の目的 | |
| 1.2. 背景・経緯 | ||
| 1.3. スケジュール | ||
| 2. 調達の概要 | 2.1. 対象システム | |
| 2.2. 対象範囲 | ||
| 2.3. システムモデル | ||
| 3. 要件 | 3.1. 業務要件 | |
| 3.2. 機能要件 | ||
| 3.3. 非機能要件 | ||
| 4. 提案依頼事項 | 4.1. サービス要件 | |
| 4.2. 実施体制 | ||
| 4.3. プロジェクト管理方法 | ||
| 4.4. 納品物 | ||
| 5. 評価基準 | 5.1. 技術評価 | |
| 5.2. コスト評価 | ||
| 5.3. 実績評価 | ||
| 6. 契約条件 | 6.1. 契約形態 | |
| 6.2. 支払条件 | ||
| 6.3. SLA | ||
| 7. 提案書作成要領 | 7.1. 提出方法 | |
| 7.2. 提案書の構成 | ||
| 7.3. 質問受付方法 | ||
表3: RFP目次構成例（テンプレート）
4. 例題
例題1
ある企業が新しい顧客管理システムの調達を計画しています。RFPに含めるべき「対象範囲」と「サービス要件」について、具体的に記述してください。
【対象範囲】
- 顧客基本情報管理（個人・法人）
- 商談・案件管理
- 顧客対応履歴管理
- マーケティングキャンペーン管理
- 既存会計システムとの連携
- モバイルデバイスからのアクセス ※社内在庫管理システムとの連携は対象外
【サービス要件】
- 5,000社、20,000人の顧客データを管理可能であること
- 同時アクセスユーザー数100名に対応可能であること
- レスポンスタイムは画面遷移時3秒以内であること
- 顧客データの暗号化保存に対応していること
- 権限管理機能により、部門ごとのアクセス制御が可能であること
- スマートフォン・タブレット対応のレスポンシブWebデザインであること
- 顧客分析レポート機能を有すること
例題2
ベンダー選定において、「ベンダーの技術及び実績評価」と「ベンダーのプロジェクト体制要件」に関して重要な評価基準を3つずつ挙げ、その理由を説明してください。
【ベンダーの技術及び実績評価】
- 同業種における類似システム開発の実績：業界特有の業務知識やシステム要件を理解している可能性が高く、スムーズなプロジェクト進行が期待できる。
- 採用予定の技術スタックに関する専門性：採用する技術に関する深い知識と経験があれば、技術的な問題解決力が高く、品質の高いシステム構築が可能。
- セキュリティ関連の認証取得状況（ISO27001など）：組織としてのセキュリティ管理体制が整っていることを示し、情報漏洩などのリスク低減につながる。
【ベンダーのプロジェクト体制要件】
- 専任プロジェクトマネージャーの経験と資格：PMPなどの資格や類似規模のプロジェクト経験があるPMがいることで、プロジェクト管理の質が向上する。
- 主要技術者のスキルレベルと継続性：核となる技術者のスキルと、プロジェクト期間中の継続的な参画保証は、技術的な一貫性と品質を確保する。
- バックアップ体制の整備：主要メンバーの不在時や突発的な問題発生時に対応できる体制があることで、プロジェクトの遅延リスクを軽減できる。
例題3
以下はあるRFPの一部です。この記述における問題点を指摘し、改善案を示してください。
「当社の業務に適したシステムを構築すること。使いやすいインターフェースを持ち、高速で処理できること。また、将来の拡張にも対応可能であること。納期は相談の上決定する。」
【問題点】
- 「当社の業務に適した」という表現が抽象的で、具体的な業務内容や要件が明示されていない。
- 「使いやすい」「高速」といった主観的・相対的な表現が使われており、明確な基準がない。
- 「将来の拡張」の内容が具体化されていない。
- 納期が明確に設定されておらず、目標スケジュールが不明確。
【改善案】
「当社の営業部門における顧客管理業務（訪問履歴管理、商談管理、売上実績管理）に対応したシステムを構築すること。インターフェースは、既存の顧客管理台帳の項目配置・操作感を踏襲し、新規入力画面の入力項目は10項目以内とすること。データベース検索のレスポンスタイムは3秒以内を目標とすること。また、将来的な海外拠点（アジア3拠点を予定）への展開を考慮し、多言語対応が可能な設計とすること。納期は契約締結後6か月以内とする。」
例題4（選択式）
以下のRFPに関する記述のうち、最も適切なものはどれか。
- RFPは調達プロセスの最終段階で作成され、契約条件のみを記載する文書である。
- RFPとRFQは同一文書の異なる名称であり、機能的な違いはない。
- RFPには、ベンダーの技術及び実績評価の基準を明確に示す必要がある。
- RFPの評価は、コスト面のみを考慮して行うべきである。
- RFPでは対象範囲を曖昧にしておき、ベンダーの創造性を引き出すことが重要である。
正解は3。
RFPには、選定基準を明確に示す必要があり、ベンダーの技術力や過去の実績をどのように評価するかという基準を含めることで、ベンダー側も自社の強みを適切にアピールでした提案が可能になる。また、発注者側にとっても客観的な評価が可能となる。
それ以外の選択肢については、1はRFPは調達プロセスの初期〜中期に作成され契約条件以外の要素も含む、2はRFPとRFQは異なる目的・内容の文書である、4は技術面や実績なども含めた総合評価を行うべき、5は対象範囲は明確に定義すべきであることから、いずれも不適切である。
5. まとめ
提案依頼書（RFP）と見積依頼書（RFQ）は、システム調達において発注者とベンダー企業の間の明確なコミュニケーションを確立するための重要なツールです。効果的なRFPには、対象範囲、システムモデル、サービス要件、目標スケジュール、契約条件などが明確に記載されているとともに、ベンダーの経営要件、プロジェクト体制要件、技術及び実績評価などの選定基準も含まれています。
RFPの質はシステム調達の成功に直結するため、曖昧な表現を避け、具体的かつ測定可能な要件を記述することが重要です。評価基準にはウェイト付けを行い、どの要素を重視するかを明確にすることで、ベンダー選定の透明性と客観性を高めることができます。また、業界や開発手法の特性に応じた適切なRFP作成も求められます。
情報処理技術者として、クライアント側・ベンダー側のどちらの立場であっても、効果的なRFP・RFQの作成や対応は、成功するITプロジェクトのための重要なスキルの一つといえるでしょう。