RFPの品質が提案の品質を決める。書くべきことを書き、書いてはいけないことを省くことで、ベンダーから最適な提案を引き出せる。逆に、情報不足のRFPには的外れな提案が、仕様を縛りすぎたRFPには金太郎飴のような提案が集まる。RFPはベンダーへの指示書ではなく、協力を引き出すための「問いかけ」だ。
RFPに書くべき10項目
以下の10項目が揃っているRFPは、ベンダーが本質的な提案を作れる。
| 番号 | 記載項目 | 書くべき内容 | 記載量目安 |
|---|---|---|---|
| 1 | プロジェクトの背景と目的 | なぜこのプロジェクトが必要か。現状の課題と解決したい問題 | 200〜400字 |
| 2 | ビジネスゴールと成功基準 | 「何が達成されたら成功か」を数値で定義（KPI） | 200〜300字 |
| 3 | 現行環境の概要 | 既存システム・データ基盤・ツールの概要と課題点 | 300〜500字 |
| 4 | データソースとデータ量 | 接続が必要なシステム・データの種類・件数・更新頻度 | 表形式で整理 |
| 5 | ユーザー数と利用パターン | 想定ユーザー数・ピーク時アクセス・利用シーン | 100〜200字 |
| 6 | セキュリティ・コンプライアンス要件 | 個人情報・機密データの取り扱い・認証要件・監査対応 | 300〜500字 |
| 7 | 評価基準と選定プロセス | 評価軸・重み・選定スケジュール・参加条件 | 200〜300字 |
| 8 | スケジュール要件 | 本番稼働希望日とその根拠・マイルストーン | 100〜200字 |
| 9 | 予算レンジ | 最低〜最大の予算範囲（初期+3年運用の合計） | 100字以内 |
| 10 | ナレッジトランスファー要件 | プロジェクト終了後の社内担当者への引き渡し条件 | 200〜300字 |
特に重要なのは「ビジネスゴールと成功基準」と「ナレッジトランスファー要件」だ。前者がないと技術的には優れていても事業価値を出せない提案が集まる。後者がないとコンサル・SIer依存が継続する提案を引き寄せる。
RFPに書いてはいけない5項目
過剰な仕様指定や曖昧な要件は、良い提案の芽を摘む。
| 書いてはいけない記載例 | 問題点 | 代替案 |
|---|---|---|
| 「Snowflakeを使ったデータ基盤を構築すること」 | 特定製品の指定でベンダーの創意工夫を封じる | 「クラウドDWHを用いた分析基盤。製品はベンダーが提案すること」 |
| 「パーティショニング戦略はパーティションキーにdate_idを使うこと」 | 過剰な技術仕様指定が最適設計を妨げる | 「クエリパフォーマンスとコストを最適化した設計を提案すること」 |
| 「RFP受領から2週間で本番稼働すること」 | 非現実的スケジュールは真剣な提案者を遠ざける | 「○月○日の本番稼働を希望。スケジュールの実現可能性を含めて提案すること」 |
| 「最新技術を活用した革新的なデータ基盤を構築すること」 | 「最新技術」「革新的」は要件ではなく希望・造語 | 「スケーラビリティと運用コストを重視した持続可能なデータ基盤を構築すること」 |
| 「提案書は300ページ以上で詳細に記載すること」 | ページ数の過度な指定はベンダーの参加意欲を下げる | 「提案の要点を25ページ以内に整理すること。詳細は別添資料で補足可」 |
【良いRFPと悪いRFPの構成比較】
良いRFP: 悪いRFP:
背景・目的 (10%) 仕様書の羅列 (70%)
ビジネスゴール (15%) 曖昧な要件 (20%)
現行環境 (15%) ページ数稼ぎ (10%)
データ概要 (15%)
要件（非機能含む） (20%)
評価基準・プロセス (15%)
予算・スケジュール (10%)
良いRFPはベンダーに「問い」を投げかける
悪いRFPはベンダーに「答え」を押しつけるRFPの構成テンプレート
【データ基盤RFPの理想的なセクション構成】
表紙・概要（1ページ）
・プロジェクト名、発注者、提出期限
1. プロジェクト概要（2〜3ページ）
・背景・目的
・ビジネスゴールと成功基準（KPI）
・スコープ（対象外も明示）
2. 現行環境（2〜3ページ）
・既存システム構成図
・現行の課題・ボトルネック
・移行が必要なデータの概要
3. 要件定義（3〜5ページ）
・機能要件
・非機能要件（性能・可用性・セキュリティ）
・データソース一覧（表形式）
4. 制約条件・前提（1〜2ページ）
・予算レンジ
・スケジュール要件
・使用可能なクラウド環境
5. ナレッジトランスファー要件（1ページ）
・引き渡し対象・期間・方法
6. 評価基準（1〜2ページ）
・評価軸と重み付け
・選定スケジュール
7. 提案書フォーマット（1ページ）
・提案書の章立て・記載要件・ページ数上限
合計: 12〜18ページ（添付資料は別途）RFP回答の評価方法
| 評価軸 | 重み | 評価基準 | 配点 |
|---|---|---|---|
| 技術力・提案の質 | 30% | 課題理解の深さ、設計の合理性、技術選定の妥当性 | 30点 |
| 実績・経験 | 20% | 類似規模・業種でのデータ基盤構築実績 | 20点 |
| コスト（TCO） | 20% | 初期費用+3年間運用コストの合計（値上げ考慮） | 20点 |
| スケジュール実現性 | 10% | 要求スケジュールへの対応と根拠の妥当性 | 10点 |
| ナレッジトランスファー | 10% | 社内への知識移転の具体性・継続性の設計 | 10点 |
| サポート・運用体制 | 10% | 問題発生時の対応速度・エスカレーション体制 | 10点 |
評価マトリクスはRFP提出時にベンダーに開示することを推奨する。「どう評価されるか」を明確にすることで、ベンダーが評価軸に対応した提案を作れるようになり、比較評価が容易になる。
成功・失敗事例
事例1（失敗）: 「Snowflakeで構築すること」と書いたRFP
情シス担当者が社内で事前調査を行い、Snowflakeが良いという結論に達し、RFPに「Snowflakeを用いたデータ基盤を構築すること」と明記した。集まった提案はいずれも「Snowflakeを使った設計」であり、本当はBigQueryの方が自社のGoogleWorkspace環境に適合していたという視点は誰からも提示されなかった。特定製品を指定したことでベンダーの専門的な助言が封じられた。
事例2（成功）: 評価基準を開示したRFPで最適な提案を引き出した企業
データ基盤刷新プロジェクトで、RFPに評価基準（技術力30%・実績20%・TCO20%・ナレッジトランスファー10%・他）を明示した。ベンダー5社からの提案を評価した結果、知名度は低いが自社と同規模の事例を持つ専門ベンダーが高得点を獲得した。ナレッジトランスファーの配点を10%設定したことで、全提案に「社内担当者への研修計画」が含まれ、比較がしやすくなった。最終的に選定したベンダーはプロジェクト終了後も社内チームが自律運用できる体制を構築し、外部依存が最小化された。
まとめ――RFPは「問い」の質で提案の質が決まる
データ基盤RFPのポイントを整理する。
- 書くべき10項目（特にビジネスゴールとナレッジトランスファー要件）を必ず含める
- 特定製品の指定・過剰な技術仕様・曖昧な要件の3つは書かない
- 評価基準をRFPに開示し、ベンダーが評価軸に対応した提案を作れるようにする
- RFPは10〜25ページ以内に要点を絞って記述する
DE-STKでは、データ基盤RFPの作成支援からベンダー評価・選定まで一貫してサポートしている。初めてRFPを作成する企業や、過去のRFPがうまくいかなかった企業はぜひご相談いただきたい。
よくある質問
Q. データ基盤のRFPにはどんな情報を書くべきですか?
ビジネスゴールと成功基準、現行環境の概要、データソースとデータ量、セキュリティ要件、評価基準、ナレッジトランスファー要件が必須です。技術仕様よりも「何を達成したいか」を重点的に記述してください。
Q. RFPに予算は書くべきですか?
予算レンジ（最低〜最大）の記載を推奨します。予算を伏せるとベンダーが的外れな提案をするリスクが高まります。ただし、正確な金額ではなく範囲を示すことで、ベンダーの創意工夫の余地を残します。
Q. RFPの適切なページ数は?
10〜25ページが目安です。短すぎると情報不足で的外れな提案が来やすく、長すぎるとベンダーの負担が増えて参加を見送るケースがあります。要点を絞った簡潔な記述が最も効果的です。