データ基盤構築は「何を買うか」より「何を判断するか」から始める
データ基盤の構築が止まる典型は、DWHやETL、BIの比較から始め、要件が増え続けるケースです。 先に決めるべきなのは製品ではなく、誰が、どの判断を、どのデータで、いつまでに行うかです。
取込・蓄積・整形・提供という技術レイヤーの役割や選択肢はデータ基盤の組み方ガイドで整理しています。本記事では、その構成を実際のプロジェクトとしてどう進め、どの成果物を残すかに集中します。
データ基盤構築ロードマップの全体像
| 段階 | 決めること | 主な成果物 | 次へ進む条件 |
|---|---|---|---|
| 1. 要件 | 対象判断・利用者・非機能要件 | プロジェクト憲章、ユースケース、成功指標 | 事業責任者が優先順位を承認 |
| 2. 棚卸し | ソース・定義・品質・権限 | データ台帳、用語集、品質・権限一覧 | PoCに必要なデータの取得可否が判明 |
| 3. 設計 | 責務分離・データモデル・運用 | 構成図、モデル、ADR、テスト・監視設計 | セキュリティと運用担当が承認 |
| 4. PoC | 価値・品質・費用・運用可能性 | 縦切り実装、検証記録、Go/No-Go判断 | 成功条件と本番化課題が確認済み |
| 5. 本番・運用 | SLO・変更・障害・費用管理 | Runbook、RACI、ダッシュボード、移管記録 | 運用者が単独で検知・復旧できる |
各段階を文書の完成待ちにするのではなく、判断に必要な最小成果物を作って次へ進みます。 ただし、責任者と終了条件が曖昧なまま実装だけを先行させないことが重要です。
Step 1：要件と成功条件を決める
最初の会議で、次の質問に答えます。
- 意思決定者は誰で、現在どの資料・画面・集計を使っているか
- どの判断に時間がかかり、何が分からないために止まっているか
- 必要な粒度、対象期間、更新頻度、許容できる遅延は何か
- 個人情報・契約情報など、利用や移動を制限すべきデータは何か
- 基盤構築後に、利用・品質・業務成果をどう確認するか
成果物
- プロジェクト憲章：背景、対象、対象外、意思決定者、予算責任、主要リスク
- ユースケース記述：利用者、質問、必要データ、出力、利用頻度、誤った場合の影響
- 非機能要件：鮮度、可用性、セキュリティ、監査、データ保持、費用上限
- 成功指標：納品物の数ではなく、利用・品質・判断プロセスの変化を測る指標
「全社データを統合する」は範囲ではありません。最初のリリースで扱う判断、部門、データソース、期間を明記します。
Step 2：データと業務を棚卸しする
棚卸しではシステム名だけでなく、データの責任と意味まで確認します。APIがあるかどうかだけでは、業務に使えるか判断できません。
データ台帳に必要な列
- ソース名、業務オーナー、技術担当、取得方法、認証方式
- 主要エンティティ、粒度、主キー、更新方式、履歴の有無
- 更新頻度、タイムゾーン、遅延、欠損・重複など既知の品質問題
- 機密区分、個人情報、保存期間、利用可能な地域、アクセス承認者
- 下流のレポート、ファイル、手作業、データ障害時の影響
同時に作る業務用語集
売上、顧客、契約、解約など、重要な言葉には定義、計算式、除外条件、対象期間、オーナーを付けます。 部署ごとに定義が違う場合は、無理に1つへ潰すのではなく、用途と名前を分けます。 棚卸しの終了時点で、PoCに必要な項目を取得できるか、誰の承認が必要か、何が欠けているかが説明できる状態にします。
Step 3：最小アーキテクチャを設計する
設計は製品の箱を並べる作業ではありません。取込、保存、変換、提供、監視、権限の責務を分け、障害と変更がどこまで波及するかを明確にします。
設計で決めること
- 取込：全件・増分・イベントのどれで運ぶか。再実行時の重複をどう防ぐか
- 保存：生データ、標準化データ、業務向けデータをどう分離し、保持するか
- 変換：staging、intermediate、martsなどの責務と命名・テスト規約
- 提供：BI、ファイル、API、AIの各利用者へ、どの粒度と権限で渡すか
- 運用：鮮度、品質、ジョブ、費用、権限変更を誰が監視するか
成果物
- 論理・物理構成図とデータフロー
- 主要エンティティ、粒度、キー、履歴方式を示すデータモデル
- IAM、行列制御、マスキング、サービスアカウントの権限表
- 品質テスト、鮮度SLO、アラート、バックフィル、災害復旧の設計
- 重要な選択と却下案を残すADR（Architecture Decision Record）
構成は最初のユースケースに必要な最小限にします。ただし、セキュリティ、監視、再実行、変更管理を「本番化の後」に回してはいけません。
Step 4：1つの業務判断を端から端までPoCする
PoCでは一部の技術だけを試すのではなく、ソース取得から利用者への提供までを縦に通します。 たとえば売上の週次判断なら、注文データの取込、定義に沿った整形、品質テスト、権限制御、レポートまたはAI回答、障害通知まで含めます。
PoCで検証する4点
- 価値：利用者は出力を理解し、実際の判断に使えるか
- 正しさ：既存の信頼できる集計と差分を説明できるか
- 運用：失敗を検知し、担当者が再実行・復旧できるか
- 費用：保存、処理、転送、ライセンス、監視、運用工数を観測できるか
Go / No-Go記録
成功・失敗の二択ではなく、要件ごとに「本番化」「追加検証」「範囲外」を記録します。 想定と違った品質、取得制約、利用者の反応、費用を残し、本番設計を更新します。 デモが動いたことだけを成功条件にしないことが重要です。
Step 5：本番化と運用移管を同時に進める
本番化では対象データを増やす前に、再現可能なデプロイと日常運用を整えます。構築者しか復旧できない状態は、リリースではなく作業途中です。
本番化チェック
- 開発・検証・本番を分離し、コードレビューとCI/CDで変更する
- 秘密情報をコードや個人端末に置かず、専用の保管・ローテーション手順を使う
- 品質、鮮度、ジョブ失敗、費用、権限変更を監視する
- バックフィル、障害復旧、上流スキーマ変更、権限申請のRunbookを試す
- 定義、リネージ、問い合わせ先、既知の制約を利用者へ公開する
運用指標
稼働率だけでなく、鮮度違反、品質違反、復旧時間、利用状況、問い合わせ、クエリ費用、定義変更のリードタイムを見ます。 指標が悪化したときに、誰が何を止め、どこへ連絡するかまで決めます。
RACIで「誰かがやる」をなくす
Rは実行責任、Aは最終説明責任、Cは相談先、Iは共有先です。Aは原則1つの役割に絞ります。
| 作業 | 事業責任者 | 業務オーナー | データ担当 | セキュリティ | 利用者代表 |
|---|---|---|---|---|---|
| 対象と成功条件 | A | R | C | C | C |
| KPI・業務定義 | I | A/R | C | I | C |
| 基盤・モデル実装 | I | C | A/R | C | I |
| 権限・機密区分 | I | R | R | A | I |
| 受入・利用判断 | I | A | C | C | R |
| 運用・障害対応 | I | C | A/R | C | I |
組織によって役職名は変わります。重要なのは、KPIの意味をデータ担当だけに決めさせず、セキュリティ判断を実装者の自己判断にせず、運用のAをリリース前に決めることです。
よくある失敗と回避策
- 全社統合を最初のスコープにする：判断を1つ選び、必要なデータだけで縦に通す
- BI画面から設計する：ソース、業務定義、粒度、品質を決めてから提供方法を選ぶ
- 既存レポートとの数字違いを無視する：差分を不具合・定義差・対象期間差に分解し、承認を残す
- PoC用の手作業を本番へ持ち込む：認証、再実行、監視、テストを含めて本番化を再設計する
- 権限を最後に付ける：棚卸しで機密区分と承認者を確認し、PoCから本番相当の境界を試す
- 完成後に運用担当へ渡す：設計段階からRACIとRunbookを作り、担当者自身が復旧演習する
判断基準にした一次情報
- Microsoft Cloud Adoption Framework — Strategy、Plan、Ready、Adopt、Govern、Secure、Manageを連続した活動として扱う枠組み
- Microsoft: Document your cloud adoption plan — 役割、運用モデル、アーキテクチャ、計画を単一の参照点として残す考え方
- Google Cloud Architecture Center: Enterprise data management and analytics platform — データ取得、処理、ガバナンスを分離した参照アーキテクチャ
- dbt Labs: How we structure our dbt projects — staging、intermediate、martsの責務分離
- Google Cloud: Use IAM securely — 最小権限とサービスアカウント運用
- Google Cloud: Auto data quality overview — 品質ルール、実行、監視、アラートの実装要素
まとめ：構築の完了条件は、継続して使い直せること
- 要件、棚卸し、設計、PoC、本番・運用の順で進める
- 各段階に成果物と終了条件を置き、ツール導入を進捗の代わりにしない
- PoCは1つの業務判断を端から端まで通し、価値・正しさ・運用・費用を検証する
- RACI、監視、Runbook、変更管理を設計時から含める