フレームワーク活用ガイドひとことで言うと#
データプロダクトをソフトウェア製品と同様に、企画→構築→運用→成熟→廃止のライフサイクルで管理するフレームワーク。「作って終わり」ではなく、利用状況のモニタリング・品質改善・廃止判断までを体系化し、データ資産の価値を持続させる。
押さえておきたい用語#
- データプロダクト（Data Product）
- 特定のユーザーの意思決定を支援するために設計・運用・改善されるデータの提供単位。テーブル、API、ダッシュボードなど形態はさまざま。
- データプロダクトマネージャー（Data Product Manager）
- データプロダクトのユーザー価値・品質・ロードマップに責任を持つ役割。ソフトウェアのPMのデータ版。
- ヘルスメトリクス（Health Metrics）
- データプロダクトの健全性を測る指標。利用頻度・ユーザー数・品質スコア・鮮度・コストなど。
- データ廃止（Data Deprecation）
- 利用されなくなったデータプロダクトを段階的に停止・削除するプロセス。依存関係を確認し、利用者に移行猶予を与えて安全に廃止する。
- データ契約（Data Contract）
- データの提供者と利用者の間で合意するスキーマ・品質・SLAの取り決め。変更時の通知ルールも含む。
データプロダクト・ライフサイクルの全体像#
こんな悩みに効く#
- DWHに誰も使っていないテーブルが大量にあるが、消していいかわからない
- データプロダクトを作ったが、リリース後に放置されて品質が劣化している
- 新しいデータプロダクトの企画基準がなく、思いつきで作られる
- データ基盤のコストが膨らんでいるが、何にいくらかかっているか見えない
基本の使い方#
ソフトウェアプロダクトと同じく、作る前に「作るべきか」を検証する。
- データプロダクトキャンバスでユーザー・課題・提供方法を整理する
- 既存のデータプロダクトで代替できないか確認する（重複防止）
- ROIを概算する（開発工数 + 運用コスト vs 削減される分析工数 or 意思決定の改善効果）
- ゲート基準: ユーザーが3名以上特定でき、課題が明確で、ROIがプラス
完璧を目指さず、最小限のモデルで早く価値を出す。
- 最初は主要なユースケース1〜2個をカバーするMVPを作る
- データ契約（スキーマ・SLA・品質基準）を定義する
- 品質テスト・ドキュメント・データカタログ登録をリリース要件に含める
- ゲート基準: 品質テスト合格、ドキュメント完備、オーナー明記
リリース後が本番。使われ続けているか・品質は保たれているかを監視する。
- ヘルスメトリクス: 週次アクティブユーザー数、クエリ実行回数、品質スコア（欠損率・遅延率）、運用コスト
- 月次でヘルスレビューを実施し、改善アクションを決める
- ユーザーからのフィードバックを収集し、スキーマの進化やSLAの見直しに反映
- 利用が減少し始めたら成熟フェーズへの移行を検討
すべてのデータプロダクトには寿命がある。
- 廃止の判断基準: 30日以上アクティブユーザーがゼロ、代替プロダクトが存在、運用コストが価値を上回る
- 廃止プロセス: (1) 利用者に通知（30日前）→ (2) 代替先への移行支援 → (3) 読み取り専用化 → (4) アーカイブ → (5) 削除
- 依存関係（下流パイプライン・ダッシュボード）を必ず確認してから廃止する
具体例#
ARR 20億円のSaaS企業。データエンジニアリングチーム8名が3年間で作ったデータプロダクト（dbtモデル）が420個に膨れ上がっていた。BigQueryの月額コストは180万円。しかし利用状況を調べると、直近30日でクエリされたモデルはわずか165個（39%）。残りの255個は誰にも使われていなかった。
ライフサイクル管理を導入:
Step 1: 全420モデルの棚卸し
- 利用頻度（クエリログから自動集計）
- オーナーの有無
- ドキュメントの有無
- 下流の依存関係
結果の分類:
- アクティブ: 165個（週1回以上クエリあり）→ 運用フェーズ
- 低利用: 80個（月1回未満）→ 成熟フェーズ、オーナーに進化 or 廃止を判断させる
- 未利用: 175個（30日以上ゼロ）→ 廃止候補
Step 2: 廃止プロセスの実行
- 未利用175個のオーナーに通知（オーナー不明は全社Slack告知）
- 30日の猶予期間後、異議なしの152個を廃止
- 23個は「稀に使うが必要」と判明し、ドキュメントを追加して運用継続
Step 3: 新規作成にゲートを設置
- 企画フェーズ必須: データプロダクトキャンバスの記入 + レビュー
- 構築フェーズ: 品質テスト・ドキュメント・カタログ登録がないとマージ不可
6か月後: モデル数が420個→280個に整理。BigQueryコストは180万円→115万円に削減（月65万円、年780万円の削減）。新規モデルの品質も向上し、リリース後のバグ報告が月8件→2件に減少。
地方銀行のデータ分析部門12名が、融資審査・リスク管理・顧客分析のデータプロダクト35個を運用していた。問題は、リリース時は品質が高いが、半年〜1年で劣化すること。ソースシステムの仕様変更に追従できず、気づいたときには欠損率が5%を超えるテーブルが複数あった。
ヘルスメトリクスによる運用体制:
各データプロダクトに以下のヘルスメトリクスを設定:
| メトリクス | 基準 | 監視頻度 |
|---|---|---|
| 鮮度（最終更新からの経過時間） | SLA内 | 日次 |
| 完全性（欠損率） | 1%以下 | 日次 |
| 正確性（バリデーションテスト合格率） | 100% | 日次 |
| 利用状況（週次ユニークユーザー数） | 1名以上 | 週次 |
| コスト（月次BigQuery処理量） | 前月比150%以下 | 月次 |
自動化:
- Great Expectationsで品質テストを日次実行
- 閾値超過時にSlackアラート + PagerDuty（重大なもの）
- 月次ヘルスレポートを自動生成し、各オーナーに配信
1年後: 品質インシデント（欠損率5%超え）が年12件→1件に激減。ソースシステムの仕様変更を平均2日以内に検知し対応できるようになった。監査からの品質関連指摘もゼロに。
EC プラットフォーム企業のDWHに、5年間で蓄積された1,200テーブルがあった。データエンジニアが退職するたびにオーナー不明のテーブルが増え、「消したいが怖くて消せない」状態が続いていた。Snowflakeの月額コストは350万円。
段階的廃止プロセスの設計:
Phase 1: 依存関係の可視化（2週間）
- Snowflakeのクエリログ + dbtのリネージュグラフで全テーブルの依存関係をマッピング
- 1,200テーブルのうち、下流依存がゼロ かつ 90日間クエリゼロの380テーブルを廃止候補に
Phase 2: 段階的廃止の実行（3か月）
- Week 1: 廃止候補リストを全社に公開。Slackで「このテーブルが必要な人は申告を」と告知
- Week 4: 異議なしの340テーブルに
_deprecatedサフィックスを付与、テーブルコメントに「廃止予定。代替先は○○。削除予定日: YYYY-MM-DD」を記載 - Week 8:
_deprecatedテーブルへのアクセスを読み取り専用に変更 - Week 12: アーカイブ（GCSにParquetで退避）→ テーブル削除
Phase 3: 再発防止（継続）
- 新規テーブル作成時にオーナー・有効期限（デフォルト1年）の設定を必須化
- 有効期限の30日前に自動リマインド。延長するかオーナーが判断
- 四半期ごとに「未利用テーブル棚卸し」を自動レポート
成果: テーブル数が1,200→780に削減。Snowflakeコストは350万円→220万円（月130万円削減）。40テーブルが廃止後に「やっぱり必要」と判明したが、アーカイブから数時間で復旧でき、業務影響はなかった。
やりがちな失敗パターン#
- 企画なしに作り始める — 「とりあえずテーブルを作る」を繰り返すと、DWHが不要データの墓場になる。最低限、ユーザーと課題を確認してから構築する
- リリースしたら運用を放置する — データは時間とともに劣化する。ソースの仕様変更、ビジネス定義の変化、利用者の離脱を定期的にチェックしないと、気づいたときには使い物にならない
- 廃止を先送りにする — 「誰か使っているかもしれない」で残し続けると、コストとメンテナンス負担が膨らむ一方。利用状況データに基づいて合理的に判断する
- ヘルスメトリクスを設定しない — 「問題が起きてから対応する」のリアクティブ運用では、品質劣化に気づくのがいつも遅い。プロアクティブな監視体制が不可欠
まとめ#
データプロダクト・ライフサイクルは、データ資産を企画→構築→運用→成熟→廃止の5フェーズで管理するフレームワークである。ソフトウェアプロダクトと同じく、データにも「作る判断」「育てる運用」「閉じる勇気」が必要。各フェーズにゲート基準とヘルスメトリクスを設定し、作りっぱなしを許さない仕組みを組み込むことで、データ基盤のコストと品質を持続的にコントロールできる。