フレームワーク活用ガイドひとことで言うと#
組織内のデータ資産（テーブル・カラム・パイプライン・ダッシュボード）にメタデータを付与し、誰でも検索・理解・評価できる状態にするための設計手法。図書館の蔵書目録のように、「どこに・どんなデータがあり・誰が管理し・どれくらい信頼できるか」を一元管理する。
押さえておきたい用語#
- メタデータ（Metadata）
- データに関するデータ。テーブル名、カラムの説明、更新頻度、オーナー情報などが含まれる。
- テクニカルメタデータ（Technical Metadata）
- スキーマ定義、データ型、パーティション、行数などシステムから自動取得できる情報。
- ビジネスメタデータ（Business Metadata）
- カラムの業務的な意味、計算ロジック、利用上の注意点など人間が記述する情報。
- データリネージ（Data Lineage）
- データがどこから来てどこへ流れるかの系譜。上流の変更が下流にどう影響するかを追跡できる。
- データオーナー（Data Owner）
- 特定のデータセットの品質・定義・アクセス管理に責任を持つ人。カタログに明記することで問い合わせ先が明確になる。
データカタログ設計の全体像#
こんな悩みに効く#
- 「このデータどこにあるの？」という質問が毎週のように飛び交う
- 同じ意味のカラムが複数テーブルにあり、どれが正解か分からない
- データの定義やロジックが特定の人の頭の中にしかない
- 新しく入ったメンバーがデータ構造を理解するのに何週間もかかる
基本の使い方#
全データ資産を一度にカタログ化しようとすると頓挫する。まず最も利用頻度が高いデータに絞る。
- 社内で最も参照されているダッシュボードが依存するテーブルを洗い出す
- 全テーブルの上位20%（利用頻度ベース）に絞ると、分析者の体験が大きく改善する
- Tier 1（ビジネスクリティカル）から着手し、Tier 2・3 は運用が安定してから追加
手作業に依存すると最初から鮮度が落ちる。ツールで自動取得できる情報は自動化する。
- データウェアハウス（BigQuery・Snowflake等）からスキーマ・データ型・行数・更新日時を自動取得
- dbt の
schema.ymlやmanifest.jsonからカラム説明・テスト定義を連携 - BIツール（Looker・Tableau等）からダッシュボードとテーブルの依存関係を取得
自動取得できない情報は人間が書く。ただし負担を最小化する工夫が要る。
- 各テーブルにデータオーナーを1名アサインし、記述責任を持たせる
- 記述テンプレートを用意: 「このテーブルは何のためのデータか」「主要カラムの業務上の意味」「利用上の注意点」の3項目に絞る
- PR レビューの一環としてメタデータ更新を組み込む（dbt の
schema.ymlをコードと一緒にレビュー）
作っただけでは使われない。利用者の動線に組み込む。
- Slack で「データの質問」が来たら、カタログのURLで返す文化を作る
- 新入社員のオンボーディングにカタログの使い方ガイドを組み込む
- 月次で「カタログ利用率」と「Slack でのデータ質問数」を計測し、効果を可視化する
具体例#
従業員120名のEC企業。データウェアハウスに350テーブルがあるが、ドキュメントは散在するスプレッドシートとConfluenceページのみ。分析チーム8名にアンケートを取ったところ、業務時間の**平均22%**を「正しいデータを探す」ことに費やしていた。
カタログ構築のスコープ:
- BIダッシュボードの利用ログから、最も参照される上位60テーブル（全体の17%）を初期対象に選定
- ツール: DataHub（OSS）を選択。BigQueryコネクタで自動連携
メタデータの整備:
- テクニカルメタデータ: BigQueryから自動取得（スキーマ・行数・更新日時）
- ビジネスメタデータ: 各テーブルのオーナー（分析チーム8名で分担）が3項目テンプレートで記述。1テーブルあたり平均20分で完了
- リネージ: dbtのmanifest.jsonからテーブル間の依存関係を自動生成
3か月後の成果:
- 分析チームの「データ探し時間」: 業務時間の**22% → 11%**に半減
- Slackでの「このデータどこ？」質問: 週12件 → 週3件
- 新メンバーのオンボーディング期間: 3週間 → 1.5週間
- カタログの週間アクティブユーザー: 42名（分析チーム以外の事業部メンバーも利用）
従業員300名のA社が80名のB社を買収。両社のデータウェアハウスを統合する必要があるが、B社のデータ資産の全体像を誰も把握していなかった。
カタログによるデータ棚卸し:
- B社のSnowflakeアカウントにカタログツールを接続し、180テーブルを自動検出
- 各テーブルの最終更新日・行数・参照頻度を一覧化
- B社のデータエンジニア2名にビジネスメタデータの記述を依頼（2週間で完了）
発見された問題:
- 42テーブルが6か月以上更新されておらず、廃止候補と判明
- A社とB社で「顧客」の定義が異なる（A社は契約ベース、B社はアカウントベース）
- 同じ指標名「MRR」の計算ロジックが2社で異なっていた
カタログを使った統合計画:
- 廃止候補42テーブルをアーカイブし、統合対象を138テーブルに絞った
- 「顧客」「MRR」などの重要ビジネス用語の定義を統一し、カタログ上のグロッサリーに登録
- 統合後のリネージを描き、どちらのパイプラインを残すか判断
結果:
- カタログなしで見積もった統合期間: 6か月
- カタログを使った実際の統合期間: 3.5か月（約40%短縮）
- 統合後のデータ不整合に起因するインシデント: ゼロ（カタログ上で事前に定義を統一したため）
従業員600名の金融サービス企業。データウェアハウスに800テーブル、BIダッシュボードが120枚ある。ある朝、外部APIからの取込みパイプラインが障害を起こしたが、「どのダッシュボードが影響を受けるか」を特定するのに4時間かかった。
リネージの構築:
- dbt のモデル定義から自動生成した上流→下流の依存グラフをカタログに統合
- BIツール（Looker）のAPIからダッシュボード→テーブルの参照関係を取得し、リネージの末端に接続
- 各テーブルにTierタグを付与（Tier 1: 規制報告・課金、Tier 2: KPIダッシュボード、Tier 3: 探索用）
障害発生時の活用: 3か月後、同じ外部APIの障害が再発。今回はカタログのリネージを検索し、影響範囲を15分で特定した。
- 影響テーブル: 12テーブル
- 影響ダッシュボード: 5枚（うちTier 1は1枚）
- 即座に利用部門に「このダッシュボードは本日○時まで更新が遅延します」と通知
成果:
- 影響範囲の特定時間: 4時間 → 15分
- 利用部門への通知: 障害発生から20分以内に完了（以前は数時間後）
- 誤ったデータに基づく意思決定のリスク: 事前通知により回避
やりがちな失敗パターン#
- 全テーブルを一気にカタログ化しようとする — 350テーブルの説明を一度に書くのは現実的でない。利用頻度の高い上位20%から始め、成功体験を作ってから拡大する
- テクニカルメタデータだけで満足する — スキーマ情報だけのカタログは「中身が空の図書館目録」と同じ。ビジネスメタデータ（このテーブルは何のためのデータか）がなければ利用者は使わない
- カタログを作って放置する — メタデータは時間とともに腐る。四半期に1回のオーナーレビューと、PRレビューへの組み込みで鮮度を維持する仕組みが必要
- ツール選定に時間をかけすぎる — DataHub、Atlan、Amundsen、dbt Docs など選択肢は多いが、完璧なツールはない。まず1つ選んで小さく始め、フィードバックを得てから乗り換えを検討する
まとめ#
データカタログは、組織のデータ資産に「目録」を付けることで、誰でもデータを発見・理解・信頼できる状態を作る基盤である。成功の鍵は小さく始めて利用者の体験を早期に改善すること。テクニカルメタデータの自動収集で初速を出し、ビジネスメタデータの記述でカタログに魂を入れ、オーナー制度と定期レビューで鮮度を保つ。この3つのサイクルが回れば、カタログは「作ったけど使われないツール」ではなく、組織のデータ文化の中心になる。