DWH移行で失敗しない要件定義チェックリスト｜期間・費用の現実と進め方

数千万円から億単位の予算がつくデータ基盤刷新やDWH（データウェアハウス：分析用にデータを集約する基盤）の移行を任された。けれど、何をどこまで決めれば失敗しないのか、全体像も期間も読めない——。
中堅〜大企業の情報システム部門やデータ部門で、いま静かに増えている悩みです。前任者が作った「高価なのに使われない基盤」を引き継いでいる方も少なくありません。

この記事では、DWH移行・データ基盤刷新を失敗させないための要件定義の勘所を、現実的な期間・費用の感覚と、そのまま使えるチェックリストつきで整理します。ツールの比較や用語解説ではなく、稟議を通し、投資を回収できる基盤にするための「上流の判断軸」に絞ります。

Index
• 1DWH移行・データ基盤刷新はなぜ失敗するのか
• - 失敗の多くは技術ではなく要件定義で起きる
• 2まず「期間と費用の現実感」を持つ
• - RFP策定だけで数か月、通算2〜3年
• 3要件定義は3層で決めきる
• - ビジネス要件・データ要件・システム要件
• 4「使われる設計」から逆算する
• - 貯めるためでなく、使われるために作る
• 5失敗しないための要件定義チェックリスト
• - 設問形式で漏れを潰す
• 6移行の進め方とRFP・ベンダー選定
• - 段階移行と、RFPに「活用の要件」を書く

DWH移行・データ基盤刷新はなぜ失敗するのか

データ基盤刷新の失敗は、ツール選定のミスよりも、要件定義の段階で「何のために・誰が使うか」を決めきれないことから起きます。目的が曖昧なまま構築が進み、完成しても使われない基盤になります。

失敗の多くは技術ではなく要件定義で起きる

大規模ITプロジェクトの難しさは、数字にも表れています。マッキンゼーとオックスフォード大学が5,400件超の大規模ITプロジェクトを調べた調査では、平均で予算を45%超過し、当初見込んだ価値を56%下回ったと報告されています（2012年 マッキンゼー／オックスフォード大）。データ基盤のような大規模ITでは、この傾向が特に出やすい領域です。
国内の実務でも、失敗要因は共通しています。分析目的やKPIが曖昧なまま作って「作っても使われない」、データ品質・鮮度・履歴の要件を技術選定より後回しにして手戻りする、旧・新システムで担当ベンダーが分かれ連携仕様の引き継ぎが抜けて移行が頓挫する——といったパターンです（2025年 NTTデータ等の公開知見）。いずれも上流の設計で防げるものです。
見落とされがちなのは、技術要因の手前にある「意思決定の失敗」です。経営が投資回収を測る指標を持たないまま着手し、現場は「言われたから作る」で目的を握れていない。この上流のズレが、後工程のすべての手戻りの源になります。要件定義とは、技術仕様を決める前に、この意思決定の土台を固める工程だと捉えるのが正解です。

まず「期間と費用の現実感」を持つ

中堅〜大企業のデータ基盤刷新は、RFP（提案依頼書）策定から構築まで2〜3年のスパンになるのが実態です。最初のRFP策定だけでも数か月かかります。この現実感を最初に持つことが、稟議とスケジュールの土台になります。

RFP策定だけで数か月、通算2〜3年

「まず要件定義から」と語る記事は多いのですが、実際にどれくらいの時間がかかるかを示すものは多くありません。
当社が支援してきた大企業のデータレイク・DWH・データマートの刷新やBI移行では、RFP策定からベンダー選定、構築まで通算で2〜3年のスパンになるのが実態です。最初のRFP策定フェーズだけでも数か月を要します。ここを「半年で終わる」と軽く見積もると、後で炎上します。
逆に言えば、この時間軸を経営に正直に共有できるかが、プロジェクトを最後まで走らせられるかの分かれ目です。国内のデータプラットフォーム市場は2025年に約7,000億円規模、年平均7.7%ほどで拡大が見込まれており（2025年 IDC Japan）、刷新に取り組む企業は今後も増えます。だからこそ、拙速ではなく現実的な計画で臨む価値があります。

要件定義は3層で決めきる

データ基盤の要件定義は、ビジネス要件・データ要件・システム要件の3層で決めきります。この順番が重要で、技術（システム要件）から入ると、目的とデータの前提がずれたまま構築が進みます。

ビジネス要件・データ要件・システム要件

ビジネス要件では、分析の目的と、成果を測るKPIを定義します。「データ参照量」「クエリ実行数」「分析者の満足度」など、"使われているか"を測る指標まで決めるのがコツです。
データ要件では、データソース・量・形式・更新頻度を棚卸しし、データ品質・鮮度・履歴保持の要件を技術選定より先に合意します。ここが後戻り最大の地雷です。システム要件では、想定データ量に見合う処理能力・ストレージ・セキュリティと、スケール時の長期運用コスト（TCO）を比較します。性能を意識したETL・ELT（データを集めて変換する処理）の設計も、初期から織り込みます。

「使われる設計」から逆算する

データ基盤は「貯める」ことを目的にすると使われず、「使われる場面」から逆算して設計すると投資を回収できます。誰の、どの意思決定を変えるためのデータかを、要件定義の段階で言語化することが起点です。

貯めるためでなく、使われるために作る

高価な基盤を作ったのに現場で使われない——この失敗は、要件定義で「使われ方」を描けていないことから生まれます。
当社は、データを貯める設計ではなく、利用シーン・利用者の意思決定単位・活用KPIから逆算して要件を立てる進め方を取っています。たとえば「予算策定のときに過去の類似案件を即座に参照したい」という具体的な利用シーンがあれば、そこから必要なデータ・更新頻度・見せ方が決まります。分析を単発のレポートで終わらせず、現場の意思決定に組み込まれる仕組みに落として初めて、基盤投資は回収されます。RFPや要件定義書に「活用の要件」を書き込めているか——これが「貯めるだけの基盤」と「使われる基盤」を分けます。

失敗しないための要件定義チェックリスト

要件定義の抜け漏れは、次の設問に「はい」と答えられるかで点検できます。ひとつでも曖昧なら、構築に進む前にそこを埋めるのが、手戻りを防ぐ最短路です。

設問形式で漏れを潰す

• - このデータは、誰の・どの意思決定を変えるか、具体的に答えられるか
• - 「使われているか」を測る活用KPI（参照量・クエリ数・利用率など）を定義したか
• - データ品質・鮮度・履歴保持の要件を、技術選定より先に合意したか
• - 全ジョブ・レポート・DWHを直接参照するアプリの棚卸し（インベントリ）を作ったか
• - 移行後の運用（監視・改善）を誰が回すか決めたか
• - 利用が増えたときの長期運用コスト（TCO）を見積もったか
• - 部門ごとの権限の出し分け・ガバナンス・監査の要件を定義したか
• - 重要度の低いデータから始める段階移行の順序を決めたか
• - RFPに「活用の要件」と、PoC（概念実証）の合格条件を書き込んだか
• - この投資をどのKPIで回収したとみなすか、経営と合意したか

特に最初と最後の設問——「誰のどの意思決定を変えるか」「どのKPIで回収するか」——に即答できないまま着手した基盤は、高い確率で「作ったが使われない」に着地します。

移行の進め方とRFP・ベンダー選定

移行は一括ではなく、重要度の低いデータセットから段階的に進めます。RFPには技術スペックだけでなく「活用の要件」を書き込み、ベンダー選定の主導権を自社が握ることが、後悔しないための条件です。

段階移行と、RFPに「活用の要件」を書く

移行前には、全ジョブ・レポート・直接参照アプリ・連携点の完全なインベントリを作ります。ひとつの見落としが、切り替え後の本番停止に直結するためです。実務では、移行時間の約半分を「発見・影響分析」に充てた組織が成功しやすい、という知見があります。
クラウドDWH（Snowflake・BigQuery・Databricks等）へ移す場合、旧環境で効いた性能チューニングはそのまま通用せず、クエリの書き直しが前提になります。利用量に応じて課金が膨らむため、FinOps（コスト管理）とアラートを早期に入れることも欠かせません。
ベンダー選定では、自社が主導権を握れるかが分かれ目です。要件定義書とRFPに「活用の要件」まで自社の言葉で書けていれば、提案の良し悪しと見積もりの妥当性を自分たちで判断できます。逆に、要件が曖昧なままだとベンダー提案の土俵に乗るだけになり、旧・新システムで担当が分かれた際の連携仕様の抜けにも気づけません。要件定義は、ベンダーに委ねる前に自社で握るべき最上流の資産です。
おおよその期間感は次の通りです。RFP策定に「活用の要件」を書けているかが、ベンダー任せにせず投資を回収するための分岐点になります。

出典：当社実績（匿名・複数案件のレンジ）

まとめ

DWH移行・データ基盤刷新の成否は、ツール選定ではなく上流の要件定義で決まります。現実的な期間（RFP数か月・通算2〜3年）を経営と共有し、3層で要件を決めきり、「使われる設計」から逆算する。この3つがそろえば、「作ったが使われない」を避けられます。
基盤は貯めるためではなく、現場の意思決定に使われるために作る。要件定義の段階でそこまで描けているかが、投資を回収できるかどうかを分けます。

データの整理や分析基盤の構築について、何から手をつければよいかわからない場合や、自社の状況を整理したい場合は、お気軽にご相談ください。

よくある質問

Q. データ基盤刷新・DWH移行はどのくらいの期間がかかりますか？
A. 中堅〜大企業では、RFP策定からベンダー選定、構築まで通算で約2〜3年が実態です。最初のRFP策定だけでも数か月、要件定義に約3か月が目安です。

Q. 要件定義で最初に決めるべきことは何ですか？
A. 分析の目的と、成果を測る活用KPIです。あわせて、データ品質・鮮度・履歴保持の要件を技術選定より先に合意しておくと、後戻りを防げます。「誰のどの意思決定を変えるか」を言語化するのが起点です。

Q. 「作ったが使われない基盤」を避けるには？
A. 貯めることを目的にせず、利用シーン・意思決定単位・活用KPIから逆算して要件を立てることです。RFPや要件定義書に「活用の要件」を書き込み、どのKPIで投資を回収するかを経営と合意しておきます。