民主化が進むと 「この数字の正しさは誰が保証するの？」 という問いが必ず出ます。これに答えられない組織では、指標の定義争い・データ品質の押し付け合い・誰も改善しない放置テーブルが増えていきます。データオーナー制度は、ドメインごとに「正しさを保証する人」を明示する設計です。
オーナーが見るべき 3 つの責任
| 責任 | 中身 |
|---|---|
| 定義の正本 | 「売上」「顧客」「離反」のドメイン用語の意味を最終決定 |
| データ品質の保証 | 鮮度 / 完全性 / 正確性の を設定し、監視し、改善する |
| 変更の承認 | 上流のスキーマ変更・指標変更を承認し、影響を関係者に通知 |
誰がオーナーになるべきか
ドメインに最も近い人 ≠ 技術者
オーナーは ビジネスドメインで最終判断できる人。例: 「売上」のオーナーは経理マネージャ、「顧客」は CRM プロダクト責任者、「在庫」は SCM マネージャ。データエンジニアではない。エンジニアは オーナーをサポートするインフラ提供側。
| ドメイン | オーナー候補 | サポート |
|---|---|---|
| 売上 / 注文 | 経理マネージャ / コマースリード | エンジニア |
| 顧客 / アカウント | CRMプロダクトマネージャ | アナリスト |
| 広告効果 | マーケディレクター | アナリティクス担当 |
| 在庫 / 発注 | SCMマネージャ | オペレーション IT |
| 人事系 | HR ディレクター | 情報システム |
SLO（サービスレベル目標）を決める
「データが正しい」は曖昧。SLO で具体化することで、オーナーの責任範囲が見えるようになる。
| SLO 項目 | 売上 (例) | 顧客 (例) |
|---|---|---|
| 鮮度 | 確定売上は翌営業日 09:00 まで | 顧客マスタは 1 時間以内 |
| 完全性 | 全注文の 99.9% が に到達 | アクティブ顧客の 100% が反映 |
| 正確性 | DWH と経理元帳の差異 0.1% 以内 | 重複顧客 0.5% 以下 |
| 変更承認 | 重要指標の定義変更は 1 週間前告知 | 列の追加は法務承認必須 |
運用フロー：「変更承認」を仕組み化する
オーナーが 「事故の後で初めて気づく」 状態を避けるため、変更を承認フローに乗せる。 での実装パターン:
dbt のモデル meta にオーナーと承認者を埋め込み
YAML
models: - name: orders config: meta: owner: "team:commerce@hukuhuku.co.jp" approvers: ["accounting-lead@", "commerce-pm@"] sla: freshness_hours: 6 completeness_pct: 99.9 change_policy: "1week_notice"github Actions で「重要モデル変更時に owner にレビュー依頼」
YAML
# .github/workflows/dbt-review-routing.ymlon: pull_request: paths: ["models/marts/**"]
jobs: request-owner-review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Find changed models and their owners id: owners run: | # 変更ファイルからモデル名を抽出 → schema.yml から owner を引いて # PR にレビュアー追加 ./scripts/route-to-owners.sh - uses: actions/github-script@v7 with: script: | github.rest.pulls.requestReviewers({ ...context.repo, pull_number: context.issue.number, reviewers: ${{ steps.owners.outputs.reviewers }}, });嫌がられない移譲の段取り
「急にオーナー指名されても困る」が起きやすい。3 段階で段取りすると受け入れられやすい:
- 1Phase 1（説明）: なぜこの制度が必要か、データ事故事例を交えて経営層と合意
- 2Phase 2（兼務オーナー）: 既存業務の延長として、月 2-3 時間のコミットで開始。エンジニア側でほぼ全自動の SLO ダッシュボードを提供
- 3Phase 3（明文化）: 1 ヶ月運用してから、目標管理（ / MBO）にデータオーナー責務を組込み
オーナーの負荷を軽くするツール
- Freshness 自動監視: dbt source freshness、 等
- 変更影響分析の自動化: DataHub の Lineage、dbt のモデル依存可視化
- SLO ダッシュボード: オーナー向けに 1 画面で「自ドメインの状態」を見せる
- 事故時の自動 1 次報告: pager化、Slack channel 自動通知
次の話
EP.13 では、 測定と失敗事例集。民主化の効果を経営層にどう報告するか、過去の崩壊事例から何を学ぶか。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。