メタデータとリネージ：「このカラム何？」を終わらせる

Stage 2 — 第4章 | データマネジメント入門 推定学習時間：40〜50分 | 難易度：★★★☆☆

この章で学ぶこと

正本（SSOT）と意味（オントロジー）が決まっても、現場では毎日こう聞かれます。

「attributed_revenue って何？ 返品入ってる？ 広告費引いてる？」

これは メタデータ（Metadata、データについてのデータ） と リネージ（Lineage、データの来歴・加工経路） の問題です。 DAMA 地図では メタデータ管理 の箱に入ります。

この章を終えると、こんなことができるようになります：

• 技術メタデータとビジネスメタデータの違いを説明できる
• リネージで 追跡できること・できないこと を説明できる
• 広告経由売上のような 多段加工 を来歴で説明できる
• データカタログ（Data Catalog）が現場で何を解決するか説明できる

1. 山田さんの定番質問

さくら商事の DWH に、マーケ向けマート mart_marketing_daily があります。 列は 30 以上。説明はほぼありません。

山田（新人）: @鈴木 attributed_revenue って返品前ですか？
鈴木: うーん、田中さん作ったビュー経由で… 3 年前の SQL 見るね
田中: その列、私も使ってないかも。広告 CSV 足したやつ？
佐藤（経理）: 経理の売上と一致しませんが。

3 日後、まだ答えが出ていません。 値は入っているのに、使えない —— メタデータ不在の典型です。

2. メタデータの 2 層

2.1 最低限付けるべき 5 項目

さくら商事で「主要列」に求める最低ライン:

これが データディクショナリ の核です。 スプレッドシートでも、カタログツールでも構いません。

3. リネージで分かること

リネージ（Lineage） は、データが どこから来て、どんな変換を経て、どこへ流れたか の系譜です。

3.1 広告経由売上の来歴

さくら商事の attributed_revenue は、ざっくり次の経路です。

Google Ads CSV ──┐
                           ├──> staging_ads ──> int_orders_ads_join ──> mart_marketing_daily
          Shopify 注文 ────┘         │                    │
                                     │                    └── 返品はここで除外（2024-03 変更）
          Meta Ads API ──────────────┘
          

次の図は、さくら商事のマーケ売上が どの原材料から来ているか の簡略版です。

2024 年 3 月に「返品除外」を int_orders_ads_join に追加した——この 1 行の変更 が、経理数字との差の説明になります。

3.2 リネージが答える問い

リネージは 説明責任の地図 であり、品質保証そのものではありません。

4. データカタログ：探す・理解する・信頼する

データカタログ（Data Catalog） は、メタデータとリネージを 検索可能 にしたハブです。 製品例: Alation, Atlan, DataHub, BigQuery Dataplex 等（本トラックでは製品比較しません）。

現場メモ

カタログを入れても 中身が空 なら、高機能な電話帳です。 まず 公式売上・主要マート 10 列 からビジネスメタを埋めるのが現実的です。

5. 来歴がないと起きる事故

鈴木さんは、次の 変更管理の最小ルール を導入しました。

1. 公式マートの SQL 変更は Git PR 必須
2. PR に 定義変更があるか チェックボックス
3. 定義変更時はスチュワード承認 + カタログ更新

6. メタデータ × リネージ × SSOT

3 つは別レイヤですが、現場ではセットで効きます。

SSOT（どこが公式か）
              ↓
          メタデータ（その列は何か）
              ↓
          リネージ（どう作られたか）
          

7. 手で始める：カタログ前の「1 枚シート」

ツール導入前でも、次の形式で 10 行 埋めるだけで Slack が静かになります。

これを後からカタログに インポート すればよいのです。

体系コラム：カリキュラム上の位置づけ

コラム：analytics との線引き

データアナリティクス入門 では、CTE や JOIN でマートを作り、SQL コメントに指標定義を書きます。本トラックのメタデータ・リネージは、その 組織版の裏付け です。

山田さんが書く ad hoc SQL にも、最低限 入力テーブル名と定義リンク を残す——これは analytics でも DM でも共通の習慣です。違いは、そのリンクが 誰の公式定義か を指しているかどうかです。

まとめ

この章のキーメッセージ：

「このカラム何？」は、怠惰の問題ではなく 設計の穴 です。 ビジネスメタデータとリネージを揃えると、SQL の前に 使っていいか・説明できるか が分かります。

次に読む

• 前章: オントロジーと ER の違い
• 次章: 指標の正本を一箇所に
• 関連: データ品質チェック（analytics）

確認問題

問題 1

attributed_revenue の型と NULL 率は分かるが、返品が含まれるか分からない。 足りないメタデータ は主にどれですか。

A. 技術メタデータ
B. ビジネスメタデータ（定義・除外ルール）
C. ネットワークメタデータ
D. 物理ディスクの RAID 構成

正解: B

解説: 型・NULL 率は技術メタです。「返品を含むか」は 業務定義 です。C/D は論点外です。

問題 2

2024 年 3 月の SQL 変更でマーケ売上が経理とさらに離れた。 最初に確認すべき 情報源の組み合わせとして最も適切なのはどれですか。

A. リネージ + 変更履歴（Git） + 用語集の更新有無
B. 社内便の配送スケジュール
C. 競合他社の決算短信
D. 統計検定の公式問題集

正解: A

解説: 数字の変化説明には 来歴と変更記録 が必要です。定義変更が用語集に反映されたかもセットで見ます。

問題 3

データカタログを導入したが、定義欄がほぼ空で利用率が低い。 最も効果的な次の一手 はどれですか。

A. 全テーブル全列を一週間で埋める巨大プロジェクト
B. 公式売上など 会議で使う 10 列 からビジネスメタを埋め、オーナーを明示する
C. カタログを削除し、口頭のみに戻す
D. リネージ機能だけ OFF にする

正解: B

解説: カタログは 中身の密度 が命です。会議数字から始めると ROI が見え、横展開しやすいです。A は燃え尽き、C/D は後退です。

用語メモ（この章）