データのライフサイクル：生成から廃棄まで

Stage 1 — 第3章 | データマネジメント入門 推定学習時間：35〜45分 | 難易度：★★☆☆☆

この章で学ぶこと

データマネジメントは、ダッシュボードや SQL の話だけではありません。 データには 生まれてから消えるまで の流れがあり、各段階で守るべきことが変わります。

さくら商事では、分析用データは増え続けました。 一方で 退職者の個人コピー、テスト注文の残存、使われなくなった CSV が残り、信頼を少しずつ削っていきました。

この章では、データライフサイクル（Data Lifecycle）を全体像として押さえ、Stage 2 以降の用語（品質、メタデータ、ガバナンス）が どの段階の話か を見分けられるようにします。

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

• 生成・保存・加工・活用・廃棄の各段階で起きやすい問題を説明できる
• 「分析前」だけでなく 取込時・保存時・公開時・廃棄時 に確認すべきことを挙げられる
• テストデータや個人コピーが残ると何が危ないか説明できる
• 次章の DAMA-DMBOK（DAMA Data Management Body of Knowledge）地図を読む準備ができる

1. ライフサイクルは「データの一生」

データマネジメントの文献や行政ガイドラインでは、データを 一度作って終わり ではなく、業務とともに変化する資産として扱います。

ざっくり次の 5 段階で考えると、現場の議論が整理しやすくなります。

次の図は、以降のカリキュラム全体の“背骨”になります。 新しい用語が出てきたら、まずどの段階の話かを当てはめてください。

特に見落とされやすいのが 廃棄 です。 増やすことばかり考えると、古い定義・個人コピー・テストデータが残り続けます。

2. 生成：最初の 1 行に未来が宿る

2.1 生成段階で決まること

データは 最初に記録された形 によって、後工程の苦労が大きく変わります。

さくら商事では、EC 改版時に 旧ステータス paid と新ステータス completed が混在 しました。 鈴木さんは SQL で両方を 完了扱い に寄せましたが、生成時点の設計変更記録 がなく、半年後に誰も説明できなくなりました。

-- 暫定対応の例（説明責任は別途必要）
          SELECT
            CASE
              WHEN status IN ('completed', 'paid') THEN 'completed'
              ELSE status
            END AS normalized_status,
            total_amount
          FROM orders;
          

現場メモ

「SQL でなんとかなる」は 加工段階の応急処置 です。 生成段階で ステータス一覧と意味 が文書化されていれば、暫定 CASE 式は不要に近づきます。

2.2 外部 SaaS からの取込

広告、物流、決済、CS ツールなど、生成元が社外にあるデータも増えています。

取込は 生成の延長 です。ここを無視すると、Stage 4 の品質問題につながります。

3. 保存：増やすほど“正本”が必要

3.1 保存場所が増えると SSOT が崩れる

前章までの「売上 3 通り」は、保存段階の問題でもあります。

SSOT（Single Source of Truth）は 保存戦略 です。 「どこに正本があるか」を決めない限り、加工段階でいくら整えても複数の“正”が残ります。

3.2 バックアップと分析用コピーの違い

よくある勘違い

「バックアップがあるからデータは大丈夫」≠「会議で使う数字が説明できる」。 さくら商事の経営会議に必要なのは 復旧可能 ではなく 定義可能 な保存です。

4. 加工：信頼はここで作られるが、ここだけでは足りない

加工段階は、アナリティクスエンジニアリング（Analytics Engineering）の中心です。 data-analytics-fundamentals で学ぶ SQL 集計、マート、品質チェックの多くはこの段階です。

さくら商事で返品反映を忘れた SQL があると、加工段階のバグ として売上がズレます。 ただし、そもそも「返品を含めるか」が未決なら、加工以前の 定義・オーナー 問題です（前章）。

-- 返品テーブルがある場合のイメージ（定義合意後）
          SELECT
            o.order_id,
            o.total_amount - COALESCE(r.refund_amount, 0) AS net_sales
          FROM orders AS o
          LEFT JOIN refunds AS r
            ON o.order_id = r.order_id
          WHERE o.status = 'completed';
          

加工段階の鉄則:

1. 入力の定義 が決まっている
2. 変換ルール が文書化されている
3. 出力が SSOT 候補か が明示されている

5. 活用：数字が“意思決定”に触れる瞬間

活用段階で初めて、データは 組織の行動 に影響します。

5.1 活用段階の典型事故

公開してから「定義が違う」と気づく

経営会議で公式売上を発表した翌日、経理から「返品の扱いが違う」と指摘。 活用の前にオーナー合意がなかった 典型例です。

古い数字を見続ける

Looker ダッシュボードがキャッシュされ、パイプライン修正後も 3 日間古い数字が表示。 鮮度（Timeliness） は活用段階で初めて問題化します（Stage 4 で詳述）。

現場メモ

木村さんは「数字を出す」ことと「数字で決める」ことを同時にやろうとして、会議が混乱しました。 活用段階では “使ってよい状態”のチェックリスト があると安全です（Stage 4 の分析前チェックリストへ）。

6. 廃棄：最も軽視され、最も長く害を出す

6.1 廃棄しないと何が起きるか

さくら商事では、半年前有識者が退職した際、個人 Google Drive に顧客 CSV が残っていることが監査で判明しました。 ファイル自体は「使っていない」ものの、廃棄設計がなかった ことが問題視されました。

6.2 廃棄設計で決めること

廃棄は 悲しい話 ではなく、信頼を守る話 です。 古い定義や不要データが残るほど、SSOT は薄れます。

7. ライフサイクル × ロール（Stage 1 総まとめ）

前 2 章と合わせて、さくら商事の論点を配置し直します。

Stage 1 の到達点:
          「SQL が書ける」→「データの一生のどこに問題があるか言える」
          

8. Stage 2 への扉

Stage 1 では 症状・ロール・ライフサイクル を押さえました。 Stage 2 からは、用語の地図（DAMA-DMBOK）、SSOT、オントロジー（Ontology）、メタデータ（Metadata）と、より 設計判断 に入ります。

その前に確認しておきたいのは、次の一文です。

データマネジメントは、ダッシュボードを 1 枚直す作業 ではなく、 データの一生を通じて信頼を維持する作業 である。

さくら商事の物語は Stage 2 以降も続きます。

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

📚 途中チェックポイント

Stage 1 を終えた時点で、次の 3 点を自分の言葉で説明できるか確認してください。

• さくら商事の「売上不一致」を、定義・SSOT・責任 のどれが主因か切り分けられるか
• DE / AE / スチュワード / オーナーの 最低 4 ロール の違いを、具体例付きで言えるか
• 返品欠損や退職者 CSV など、困りごとがライフサイクルの どの段階 に属するか指せるか

まとめ

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

分析 SQL は 加工段階 の話です。 売上が揃わない、説明できない、危ない——これらは生成・保存・活用・廃棄のどこか、または複数にまたがる問題として見る必要があります。

次に読む

• 前章: 誰が何を担うか
• Stage 2 第1章: DAMA-DMBOK 簡易地図
• 関連: データ品質チェック — 加工段階の SQL チェック

確認問題

問題 1

さくら商事で旧ステータス paid と新ステータス completed が混在し、半年後に説明できなくなった。 この問題をライフサイクルで言うと 主にどの段階 の話か。

A. 廃棄
B. 生成
C. 活用
D. 加工のみで完結する

正解: B

解説: ステータスコードとその意味は 業務システムが記録する生成段階 で決まります。加工 SQL で寄せるのは応急処置であり、生成時の定義管理が本筋です。

問題 2

退職者の Google Drive に顧客 CSV が残っていた。 データマネジメント上 最も関連が深い テーマはどれですか。

A. 廃棄とアクセス管理の設計不足
B. 回帰分析のモデル選択
C. ウィンドウ関数の書き方
D. 確率分布の形状

正解: A

解説: 使われていないように見えても、個人保管データは 廃棄・アカウント停止・利用規程 の問題です。漏えいリスクと SSOT 崩壊の両方につながります。

問題 3

「バックアップがあるから、経営会議の数字は大丈夫」と言う主張について、最も適切な評価 はどれですか。

A. 正しい。バックアップがあれば SSOT も自動的に満たされる
B. 不十分。バックアップは復旧用で、会議数字には定義・鮮度・正本の設計が別途必要
C. 誤り。バックアップは不要
D. 関係ない。統計検定 2 級の知識があれば十分

正解: B

解説: 復旧可能性と 説明可能な公式数字 は別です。保存段階では、何を正本とし、どの定義で配布するかを決める必要があります。

用語メモ（この章）