データの棚卸しから、活用目的の整理、品質や統合、ガバナンス、運用体制まで検討を重ねたら、いよいよ開発会社への発注が見えてくる。ここで多くの企業がつまずくのが、「何をどう依頼すればよいか分からない」ことである。要件が曖昧なまま相見積もりを取ると、各社の提案がバラバラで比べられず、安さだけで選んで後悔する、ということが起きやすい。
本記事は、データ基盤の発注に向けた要件のまとめ方と開発会社選びを、発注者の視点で整理する。あわせて、本連載で扱ってきた論点を振り返り、それぞれがRFP（提案依頼書）のどこに効くかをつなぐ。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当である。専門用語を完璧に使いこなす必要はなく、これまで整理してきたことを依頼の形にまとめられれば十分である。
結論：目的を軸にRFPを作り、比べられる形で依頼する
データ基盤の発注を成功させる鍵は、要件を整理し、各社を同じ土俵で比べられるようにすることである。GXOがRFPと開発会社選びで重視するのは、次の3点である。
- 何のためのデータ基盤かという目的を、RFPの軸に置く
- 各社が同じ条件で提案できるよう、前提を揃えて依頼する
- 安さだけでなく、運用まで含めた進め方で開発会社を見極める
RFPは、立派な書類を作ることが目的ではない。発注者が考えを整理し、開発会社が的確に提案できるようにするための道具である。これまでの検討をまとめれば、その材料はすでに揃っている。
連載で整理してきたことを振り返る
本連載では、データ基盤の検討に必要な論点を順に扱ってきた。RFPは、これらの整理の集大成にあたる。
| テーマ | 整理したこと | 参照 |
|---|---|---|
| 棚卸しと目的 | どんなデータがあり、何のために使うか | データの棚卸し |
| 統合とガバナンス | 部門をまたいでつなぎ、安全に保つ | データガバナンスと権限 |
| 始め方と運用 | 小さく始め、使い続ける体制を作る | 運用体制とデータ人材 |
これらは独立した話ではなく、一つの基盤づくりの異なる側面である。RFPでは、これらを「目的のために、何を、どう作り、どう運用するか」という一つの依頼にまとめていく。各テーマの詳細は、それぞれの回を参照されたい。
RFPに入れるべき項目
RFPには、開発会社が提案を組み立てるために必要な情報を、漏れなく書く。最低限、次の項目を押さえたい。
| 項目 | 書く内容 | なぜ必要か |
|---|---|---|
| 目的・背景 | 何のためのデータ基盤か | 提案の軸が定まる |
| 対象データ | どのデータを扱うか | 範囲が共有される |
| 使い方 | 誰がどう使うか、見たい問い | 出口が明確になる |
| 権限・個人情報 | アクセスの方針、機微なデータ | 安全要件が伝わる |
| 運用 | 更新や保守をどうするか | 運用前提で提案される |
| 段階・予算 | 小さく始めるか、予算の感覚 | 現実的な提案になる |
これらが書かれていれば、開発会社は的を射た提案ができる。逆に、目的や使い方が曖昧だと、各社が前提を勝手に補い、提案が比べられなくなる。まずは目的と使い方を明確にすることが、よいRFPの出発点である。
すべての項目を最初から精緻に書く必要はない。決めきれない部分は「ここは相談しながら詰めたい」と正直に書いておけばよい。むしろ、分からないことを分かっているふりで埋めるより、未確定の論点を明示するほうが、開発会社からの提案も実のあるものになる。RFPは発注者の知識を試す書類ではなく、双方が同じ前提に立つための土台である。
ベンダー選定で見るべき点
複数の開発会社から提案を受けたら、何を基準に選ぶかが問題になる。価格は分かりやすいが、それだけで選ぶと後で困りやすい。
- 目的を理解しているか：自社の目的を踏まえた提案か、汎用的な売り込みかを見る。
- 小さく始める提案か：いきなり全体を作る提案より、段階的な進め方を示せるかを見る。
- 運用まで考えているか：作って終わりでなく、使い続ける体制まで提案に含まれているかを見る。
- 説明が分かるか：専門用語で煙に巻かず、発注者に分かる言葉で説明できるかを見る。
価格が安くても、目的を外した提案や、運用を考えていない提案は、結局やり直しになりやすい。総額の安さより、目的に届くかと、運用まで見据えているかを重視したい。開発費の見方はダッシュボード可視化開発の費用も参考になる。
見積もりを比べるときは、金額だけでなく内訳を見たい。何にいくらかかるのかが示されていれば、各社の提案範囲の違いが見えてくる。同じ総額でも、片方は運用支援を含み、片方は構築だけ、ということもある。内訳が曖昧で総額だけ示される見積もりは、後から追加費用が発生しやすい。安さの理由が、範囲を削ったことによるものでないかを確かめておきたい。
ありがちな失敗を避ける
データ基盤の発注では、次のような失敗が起きやすい。連載で整理してきたことを依頼に反映すれば、多くは避けられる。
- 目的が曖昧なまま発注する：何のための基盤か決まらないまま作り、できたものが使われない。
- 全部を一度に作ろうとする：範囲が膨らみ、完成が遠のく。小さく始める発想が要る。
- 運用を発注に含めない：作った後の更新や保守を考えず、放置されて古くなる。
- 安さだけで選ぶ：目的や運用を軽視した安い提案を選び、やり直しになる。
これらは、ツールの選び方そのものより、発注前の整理で防げる部分が大きい。比較のための材料はデータ分析・BIツール比較も参考になる。
発注は、開発会社に丸投げして終わりにするものではない。発注者が目的と使い方を握っているからこそ、提案の良し悪しを判断でき、できあがったものが役に立つ。本連載で一つずつ整理してきたことは、まさにこの「握っておくべきこと」である。整理が進んでいれば、開発会社との対話も噛み合い、回り道が減る。逆に、整理を飛ばして発注を急ぐと、後から戻って考え直すことになりやすい。
導入前チェックリスト
- 何のためのデータ基盤か、目的を一文で書けるか
- 扱うデータの範囲を整理したか
- 誰がどう使うか、見たい問いを書き出したか
- 権限や個人情報の方針をRFPに含めたか
- 運用（更新・保守）の前提をRFPに含めたか
- 小さく始める前提を提案依頼に書いたか
- 各社を同じ条件で比べられるよう前提を揃えたか
- 価格以外の選定基準（目的理解・運用）を決めたか
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| 私たちの目的をどう理解しましたか | 目的の理解度 |
| 小さく始める進め方を提案できますか | 段階的な導入 |
| 運用や保守はどこまで含まれますか | 発注後の体制 |
| 後から拡張するとき作り直しになりませんか | 拡張のしやすさ |
| 専門用語を使わず説明してもらえますか | 説明の分かりやすさ |
| 見積もりの内訳を示してもらえますか | 費用の透明性 |
「お任せください、全部やります」という説明だけで、目的の理解や進め方が見えない提案には注意したい。何を、なぜ、どう作るかを、発注者の言葉で語れるかが見極めの分かれ目になる。
相談前に整理しておくとよい情報
- 何のためにデータ基盤を作りたいか（目的）
- 扱いたいデータと、見たい問い
- 権限や個人情報で気をつけたいこと
- 運用に割ける社内の人手
- 予算の感覚と、最初にかけられる範囲
これらが整理されていなくても相談は可能である。本連載で扱ってきた論点を一つずつ振り返れば、RFPの材料は見えてくる。整理しきれない部分は、相談しながら一緒にまとめていける。
関連記事
よくある質問
Q1. RFPは必ず作らないといけませんか
立派な書類は必須ではない。ただ、目的・使い方・運用の前提を整理して各社に同じ条件で伝えないと、提案が比べられず、選びにくくなる。簡単な依頼書でも、要点を揃えておく価値は大きい。
Q2. 開発会社は価格で選んでよいですか
価格は大事だが、それだけで選ぶと後で困りやすい。目的を理解しているか、小さく始められるか、運用まで考えているかを合わせて見たい。安い提案がやり直しになれば、結局高くつく。
Q3. 要件が固まっていなくても相談してよいですか
問題ない。むしろ要件が固まる前の段階から相談し、目的や使い方を一緒に整理していくほうが、的を射た基盤になりやすい。整理を手伝うところから関わる開発会社を選びたい。
データ基盤の要件整理と開発会社選びを一緒に進めませんか
GXOでは、データ基盤の発注に向けて、目的の整理、RFPに入れる項目の洗い出し、運用まで見据えた進め方を一緒にまとめます。本連載で扱ってきた論点を踏まえ、小さく始めて育てる現実的な計画づくりをご支援します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。