A社は「まずデータレイクから」、B社は「BIツールだけ入れましょう」、C社は「500万円で」「1,800万円で」。3社にお願いしたら、返ってきた提案の中身も金額もバラバラ。RFPの相談は、こういう状況からご連絡をいただくことが多い印象です。
正直に言うと、これは各社が悪いというより、そもそも渡した条件がそろっていないことに原因があります。同じ土俵に提案を並べるために使う道具、それがRFP（提案依頼書：Request for Proposal）です。
一般的なシステム開発のRFPとの違い、データ基盤ならではの必須項目、そして同じRFPでも集まる提案の質が変わる書き方のコツを、そのまま下敷きに使える形でまとめました。
費用の相場観をまだつかんでいない方は、先にデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説を読んでおくと、RFPに書く予算感がイメージしやすくなります。どんなタイプの会社に依頼すべきか迷っている方は、データ基盤構築の会社の選び方・比較｜失敗しない発注先で発注先のタイプと選定軸を先に整理しておくと、RFPを渡す相手を絞り込めます。
「口頭で要望を伝えれば、ベンダーが見積もってくれるのでは」と思うかもしれません。実際、それでも見積もりは出てきます。問題は、その見積もりを横並びで比較できないことです。
A社には「広告データを見たい」、B社には「売上も見たい」と、伝えた内容が少しずつ違えば、各社は別々の前提で提案します。スコープが違う見積もりを金額だけで比べても、安いほうが本当に得かは分かりません。
RFPを1枚そろえて全社に同じものを渡すと、次の効果があります。
逆に、RFPを作らずベンダー任せにすると、発注側が受け身になり、後から要件の認識違いでトラブルになりがちです。これはデータ基盤に限らず、システム導入が失敗する典型パターンとして知られています。
1社に絞って発注する場合でも、RFPを作る価値はあります。要件を書き出す過程で、自社の目的とデータの現状が整理されるからです。
RFPの話をすると、RFIや要件定義書との違いが分かりにくい、とよく聞かれます。図のように、これらは使うタイミングが違います。
一般的には、RFI → RFP → RFQ の順に進みます。候補が最初から数社に絞れているなら、RFIを省いてRFPから始めても構いません。
要件定義書とも混同されがちですが、こちらは発注先が決まった後に、システムの仕様を詳細に固める成果物です。RFPが「何を実現したいか」を扱うのに対し、要件定義書は「どう作るか」を扱います。順番としては、RFPのほうが先です。
RFPに決まった様式はありませんが、データ基盤構築では図のように3つのブロックで組み立てると、漏れなく整理できます。
ベンダーが提案の方向性を決めるための、土台になる情報です。
提案と見積もりの精度を左右する、RFPの中心です。データ基盤特有の項目が多いため、次のセクションで詳しく扱います。
意外と抜けやすいのが、このブロックです。評価基準と配点を先に明記することで、提案を公平に比較でき、社内での選定理由も説明しやすくなります。提案の提出方法・様式、選定スケジュール、想定する契約形態（請負か準委任か）もここに書きます。
一般的なシステム開発のRFPと、データ基盤構築のRFPの一番の違いは、「データそのもの」の情報をどれだけ具体的に書けるかです。ここが薄いと、提案も見積もりも精度が出ません。最低限おさえたい項目を挙げます。
どのシステムのデータを扱うのかを、表で具体的に示します。これがRFPの肝です。
| 書く項目 | 例 |
|---|---|
| システム名 | Salesforce、会計ソフト、各広告媒体 |
| データ量・件数 | 月◯万件、累計◯GB |
| 更新頻度 | リアルタイム／日次／月次 |
| 連携方法 | API有無、CSVエクスポート、DB直結 |
データ連携の費用はデータソースの数に比例しやすく、ソースの実態（API があるか、権限を取れるか）が分かると、ベンダーは現実的な工数を見積もれます。Evastの現場でも、RFP段階でデータ量と更新頻度が書かれていないと、見積もりが提案社ごとに2〜3倍ぶれることがあります。
機能要件（何ができるか）だけでなく、性能や運用などの非機能要件も書きます。何を書けばいいか迷ったら、IPA（情報処理推進機構）が公開している非機能要求グレードの6分類が参考になります。
すでに使っているDWHやBIツール、クラウド環境があれば明記します。「BigQueryを使っている」「Tableauの資産を活かしたい」といった制約は、提案の前提を大きく変えます。ツール選定をゼロから相談したい場合は、その旨を書けば各社が選定理由ごと提案してくれます。ツール選びの観点はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較も参考になります。
いきなり全社展開ではなく、まず一部で試したいなら、PoC（試験導入）やスモールスタートを許容する旨を書いておきます。段階的な進め方を前提にすると、初期費用を抑えた現実的な提案が集まりやすくなります。PoCの進め方や成功基準の決め方はデータ基盤のPoCの進め方｜5ステップと成功基準・費用の目安にまとめています。
ここまでの項目を、章立てに落とすと次のようになります。Wordやスプレッドシートにこの見出しをそのまま並べ、各章を埋めていけば、データ基盤構築のRFPの骨格ができます。
1. はじめに
1-1. 提案依頼の背景・現状の課題
1-2. プロジェクトの目的・達成したい状態
1-3. 対象業務・利用部門
2. プロジェクト概要
2-1. スコープ（対象範囲・対象外）
2-2. 想定予算レンジ
2-3. スケジュール（提案・選定・構築・稼働）
3. 提案依頼内容
3-1. 対象データソース一覧（システム名・データ量・更新頻度・連携方法）
3-2. 機能要件
3-3. 非機能要件（可用性・性能・運用保守・移行・セキュリティ）
3-4. 既存資産・利用中のツール／制約
3-5. PoC・スモールスタートの可否
3-6. 成果物・体制・運用保守の範囲
4. 選定について
4-1. 評価基準と配点
4-2. 契約形態（請負／準委任）の想定
4-3. 質疑応答の窓口・締切
5. 提出要領
5-1. 提出期限・様式・宛先
5-2. 提案プレゼンの有無すべての項目を完璧に埋める必要はありません。特に 3-1の対象データソース一覧と 4-1の評価基準の2つが埋まっていれば、提案の質は大きく変わります。逆にこの2つが空欄だと、どれだけ他を作り込んでも提案がぶれます。
提案を集めてから「さて、どう選ぼう」では遅すぎます。評価基準は、RFPを出す前に決めておくのが鉄則です。基準を先に決めておくと、各社に同じ観点を伝えられ、選定後に社内へ理由を説明するときにも役立ちます。
データ基盤構築でよく使う評価軸は次のとおりです。
それぞれに配点をつけ、価格点と技術点のバランスを決めておきます。配点の例を挙げます。
| 評価軸 | 配点 | 見るポイント |
|---|---|---|
| 実績 | 25点 | 同業種・同規模のデータ基盤構築の経験 |
| 技術・提案内容 | 30点 | 要件に対する構成の妥当性 |
| コスト・TCO | 25点 | 3〜5年の総額で見た妥当性 |
| 運用・保守体制 | 20点 | 稼働後の伴走体制 |
配点に正解はありませんが、価格だけで決めると安かろう悪かろうの提案を選びがちなので、技術点の比重を価格点と同等以上にしておくと失敗しにくくなります。見積もりの読み解き方はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説でも詳しく解説しています。
評価基準とあわせて決めておきたいのが、契約形態です。データ基盤構築では主に2つあります。
データ基盤は、作りながら要件が見えてくる場面が多いため、PoCや初期は準委任、要件が固まった本構築は請負、とフェーズで使い分けるのが現実的です。どちらを想定しているかをRFPに書いておくと、提案の前提がそろいます。
RFPでつまずく原因は、両極端のどちらかに寄ることです。図のように、目的が曖昧な「丸投げRFP」と、手段まで縛りすぎたRFPは、どちらも良い提案を遠ざけます。
ありがちな失敗を、具体的に挙げます。
避け方はシンプルです。What（何を実現したいか）と制約（既存資産・予算・セキュリティ）は具体的に、How（どう作るか）はベンダーに委ねる。この線引きができると、各社の知恵を引き出しつつ、同じ土俵で比較できるRFPになります。RFPの作り込み以外にも発注前に確認すべき落とし穴はデータ基盤構築でよくある失敗と発注前チェックリストにまとめています。
最後に、RFPを作る現実的なステップを順に挙げます。規模にもよりますが、棚卸しから完成まで2〜4週間ほどを見ておくと無理がありません。
最後の質疑応答は、運用ルールを決めておくと公平に進められます。質問の締切を設け、特定の1社にだけ答えるのではなく、回答は全社に共有するのが原則です。一部の社だけが有利な情報を持つと、提案の前提が食い違ってしまいます。
要件の棚卸しや評価基準づくりは、社内だけだと手が止まりがちな工程です。私たちEvastも、ツール選定やRFP作成の前段となる現状整理から相談を受けることが少なくありません。データ活用の戦略立案から伴走するデータ戦略策定サービスのような形で、第三者の視点を入れる選択肢もあります。
データ基盤構築のRFPについて、要点を整理します。
RFPは、立派な分厚い文書を作ることが目的ではないと思います。自社が何を実現したいかを言葉にし、それを各社に同じ形で伝えられれば、役割は十分に果たせるのではないでしょうか。まずは目的の1行と、データの棚卸しから手をつけてみてください。
株式会社Evastでは、データ戦略の立案からデータ基盤の設計・構築、運用定着まで を一貫して支援しています。
RFP作成の前段となる現状整理や、ベンダー提案の評価からでも構いません。自社に合った進め方を知りたい方は、データ活用の無料診断もご利用ください。
データ基盤構築にどのくらいの期間がかかるのかを、発注の現場目線でまとめました。スモールスタートから大規模までの規模別の期間レンジ、要件定義・設計・構築・テスト・移行という工程ごとの配分、問い合わせから着手までのリードタイム、期間を左右する要因、よくある遅延の原因、最初の成果を3か月で出す段階リリースの進め方まで解説。費用とあわせて発注計画を立てたいマネージャー向けの実務記事です。
データ基盤構築をどの会社に頼むかで、プロジェクトの成否は大きく変わります。大手SIer・データ専業ベンダー・クラウド認定パートナー・フリーランス・BI導入支援の5タイプを、費用・カバー範囲・内製化のしやすさ・ロックインリスクで比較。さらに「失敗しない発注先」を見極める7つのチェック軸、請負と準委任の使い分け、発注先選びでよくある5つの失敗まで、発注前に立ち止まって確認したいことを実務目線で整理しました。費用相場やRFPの書き方は関連記事に譲り、本記事は「どこに頼むか」の判断に絞って解説します。
データ基盤構築は、作っても「使われない」「途中で頓挫する」失敗が後を絶ちません。目的・体制・データ・運用の4カテゴリでよくある失敗パターンと注意点を整理し、なぜ起きるのか・どう防ぐのかを実務目線で解説します。内製と外注の判断、PoC疲れの回避、対象データの棚卸し、頓挫した場合の立て直しまでカバーし、発注前にそのまま使えるチェックリストつき。これからデータ基盤を発注するマネージャーが、契約前に立ち止まって確認するための実務記事です。
データ基盤を内製で作るか、外注するか。発注の分かれ道になるこの判断を、発注の現場目線で整理します。外注と内製それぞれのメリット・デメリット、スピード・ノウハウ・採用・コストという判断軸、データ人材の採用が難しい現実、そして設計は外注・運用は内製に寄せるハイブリッドの役割分担まで解説。どちらで進めるか迷っているマネージャー向けの実務記事です。