RFPでデータ基盤プロジェクトが失敗する原因は、「技術要件」が過剰で「ビジネス要件」が不足していることにあります。100ページのRFPに延々と続く画面仕様、テーブル定義、非機能要件の羅列。その一方で、「このプロジェクトで達成したい業務KPI」「ビジネス上の意思決定の変化」といった上流の定義は1ページだけ、という構造は珍しくありません。ベンダーはその構造に合わせて、技術要件のチェックリストに答える「提案」を提出し、その結果、プロジェクトは期待した成果から大きく乖離します。本記事では、RFPが的外れになる構造的原因と、良いRFPの書き方を整理します。

データ基盤RFPの典型的な失敗パターン

データ基盤プロジェクトのRFPは、担当者が「過去のRFPテンプレートを流用」するところから始まります。前回の案件が基幹システムのリプレイスだった場合、そのテンプレートは機能要件中心の構造であり、データ基盤という性質にはそぐいません。結果、RFPには業務画面の数や処理速度のSLAは詳細に書かれる一方で、「どんな意思決定をしたいのか」「どんなデータ分析をしたいのか」は曖昧なまま。ベンダーは「書かれている要件」に答えるしかなく、発注側が本当に欲しかったものとは異なる提案が返ってきます。

問題原因結果
ビジネスゴール不在経営層の関与不足成果指標が計測不能
技術仕様の過剰記述過去RFPテンプレの流用ベンダーの提案余地なし
価格偏重の評価調達プロセスの硬直化品質より安さ優先
PoCフェーズなし「まず本番構築」の発想初期のつまずきで大規模見直し
評価基準の重み不明調達部門と技術部門の分離評価結果への不満

RFPが的外れになる3つの構造的原因

ビジネスゴールが不明確なまま技術仕様を書く

多くのRFPは、「データ基盤を構築する」という手段を目的として書かれています。本来記されるべきは「この基盤で何を実現したいか」であり、たとえば「顧客LTV分析を可能にし、解約予兆を早期に検知する」「月次の経営レポート作成時間を80%削減する」といったビジネス成果です。これらが冒頭に書かれていれば、ベンダーは自然にその成果から逆算した技術提案を行えます。逆にビジネスゴールがなければ、どれだけ技術仕様が精緻でも的外れな提案しか返ってきません。

評価基準が「価格」に偏重

調達プロセスが価格中心で設計されていると、ベンダーは「価格で勝つ提案」を出さざるを得ません。結果、技術的な選定はすべて「最も安価な選択肢」に流れ、ナレッジトランスファーや長期保守への配慮は薄くなります。データ基盤は5〜10年使うものであり、初期コストよりライフサイクル全体のコストで評価すべきですが、RFPの評価基準がそれを許容していないケースが大半です。

ベンダーの提案の自由度を奪う過剰な仕様記述

「○○というDWHを使用すること」「××というETLツールを前提とする」といった技術選定までRFPに書き込んでしまうと、ベンダーは独自の知見を活かす余地を失います。ベンダーから見れば「この顧客は既に答えを決めているので、その通りに構築するだけ」となり、品質の高い提案は期待できません。技術選定こそベンダーの専門性を発揮すべき領域であり、発注側が事前に固めるべき事項ではありません。

【失敗するRFPと成功するRFPの構造の違い】

失敗するRFP                        成功するRFP
-----------                        -----------
(1ページ) プロジェクト概要         (10ページ) ビジネスゴール
(5ページ)  現行システム            (5ページ) 期待成果とKPI
(80ページ) 機能要件                (5ページ) 利用シーン
(20ページ) 技術仕様                (15ページ) 必須制約(セキュリティ等)
(2ページ)  評価基準                (10ページ) 評価基準と重み付け
(0ページ)  ビジネスゴール          (5ページ) PoCフェーズの設計
                                    (ベンダー提案余地を確保)

[結果]                             [結果]
技術要件への回答のみ              ビジネス成果への提案競争
価格最安値で選定                  総合評価での最適選定
期待乖離で炎上                    成果達成で継続発展

※ RFPの構造が、返ってくる提案の質を決める

良いRFPの書き方

RFPに書くべきこと書かないほうがよいこと
ビジネスゴール・期待成果特定のDWH・ETLツール指定
定量的な成功指標細かな画面仕様
既存システム連携の必須要件既存の担当者の方法論
セキュリティ・コンプライアンス制約「XX社の事例通りに」という指示
PoC・パイロットのフェーズ設計内部政治を反映した部門調整事項
評価基準と重み付けベンダーごとの個別条件
ナレッジトランスファー要件「御社の標準アプローチで」

ビジネスゴールと期待する成果を先に書く

RFPの第1章で、プロジェクトのビジネスゴールを定量的に記述します。「売上1%向上」「意思決定リードタイム50%短縮」「月次決算5営業日短縮」など、測定可能な成果です。技術要件は第4章あたりに、必要最低限の制約として書きます。

技術制約ではなく評価基準を明示する

「何をどう作れ」ではなく、「何を評価するか」を明示します。ビジネス理解度30%、技術提案品質30%、体制・人材20%、価格20%、といった重み付けを事前公開することで、ベンダーは自社の強みを活かした提案を設計できます。

PoC/パイロットのフェーズを組み込む

いきなり本番構築ではなく、3ヶ月程度のPoCフェーズをRFPに明記します。PoCで実装能力・コミュニケーション品質・成果物の品質を確認してから本番フェーズへ進む段階設計は、大規模な失敗を避けるための保険です。

ベンダーの提案余地を残す

技術選定、アーキテクチャ、チーム編成などは、ベンダーが自由に提案できる余地を残します。発注側が事前に決めるのは「制約条件」であり、「解決策」は提案競争で引き出すべきです。自由度のあるRFPほど、ベンダーの知見が活きた提案が返ってきます。

【効果的なRFPの構成テンプレート】

Section 1: ビジネスコンテキスト
  | 1.1 プロジェクトの背景
  | 1.2 ビジネスゴールとKPI
  | 1.3 期待成果の定量目標

Section 2: 利用シーンと要件
  | 2.1 主要ユーザーと使用目的
  | 2.2 重要な分析・意思決定シーン
  | 2.3 既存システムとの連携

Section 3: 必須制約
  | 3.1 セキュリティ・コンプライアンス
  | 3.2 性能・可用性の下限
  | 3.3 予算レンジ

Section 4: 提案要件
  | 4.1 技術アプローチの提案
  | 4.2 体制・人材の提案
  | 4.3 スケジュール・フェーズ設計

Section 5: 評価基準
  | 5.1 評価軸と重み付け
  | 5.2 評価プロセス
  | 5.3 PoCフェーズの設計

※ 技術選定はベンダーの提案領域に残す

RFP改善で成功したプロジェクトの事例

事例A:製造業のRFP再構成
ある製造業は、当初作成したRFPが100ページの技術仕様中心で、ベンダー5社からの提案がいずれも「言われた通りに作る」レベルでした。外部アドバイザーの助言でRFPを30ページに圧縮し、冒頭にビジネスゴール（生産ライン予知保全による年間15%のコスト削減）を明記。評価基準もビジネス理解度重視に変更しました。再発行したRFPに対し、ベンダーからは業界特化の独自提案が返り、最終的に選定した提案は当初想定より20%低コストかつ成果目標を達成しました。

事例B:金融機関のPoCフェーズ組み込み
ある信用金庫は、データ基盤の選定で価格最安値のベンダーを選んだ結果、6ヶ月後に「要件の認識違い」で大幅な作り直しとなる経験をしていました。次回のRFPでは、「3ヶ月のPoCフェーズで実装品質・コミュニケーション品質を評価し、合格後に本番フェーズへ進む」という二段階契約を明記。PoCの結果で当初選定を変更する条項も設けました。結果、PoCで品質を確認した上で本契約に進めたため、本番フェーズで大きなトラブルは発生しませんでした。

まとめ

良いRFPは、発注側の意図を伝え、ベンダーの知見を引き出すための対話設計です。100ページの技術要件ではなく、30ページのビジネスゴール・制約・評価基準の方が、結果的に良い提案を引き出します。

  • RFPはビジネスゴールから書き始める
  • 技術選定はベンダーの提案領域に残す
  • 評価基準と重み付けを事前公開する
  • PoCフェーズを契約に組み込む
  • ナレッジトランスファー要件を明記する

DE-STKでは、RFP作成支援、評価基準の設計、ベンダー提案の評価まで伴走しています。関連記事としてSIerに丸投げしたデータ基盤がブラックボックスに、データ基盤のRFPに書くべきこと・書いてはいけないこと、コンサル会社の美しい資料に騙されないためのチェックポイントもご覧ください。

よくある質問

Q1. データ基盤のRFPで最も重要な要素は何ですか？

技術仕様よりもビジネスゴールと期待する成果の明記が最重要です。何を達成したいか（業務KPIの改善目標等）を明確にすることで、ベンダーから最適な技術提案を引き出せます。

Q2. RFPの評価基準はどう設計すべきですか？

価格だけでなく、技術提案の品質（アーキテクチャ設計力）、チーム体制、ナレッジトランスファー計画、運用移行計画を含む多面的な評価基準を設定します。重み付けは事前に合意しておくことが重要です。

Q3. RFPに技術仕様をどこまで書くべきですか？

必須要件（既存システムとの連携、セキュリティ基準等）は明記しますが、アーキテクチャや具体的なツール選定はベンダーの提案に委ねる方が良い結果を得られます。過剰な仕様記述はベンダーの創造性を制限します。