LESSON 30分

ストーリー

田中VPoE
データ戦略の第一歩は「何があるか知る」ことだ。うちのデータ資産、全体像を把握している人は何人いると思う?
あなた
正直、各チームが自分の範囲しか知らないと思います。全体を把握している人はいないのでは
田中VPoE
その通りだ。これが最大の問題だ。営業のCRMデータ、プロダクトのユーザー行動データ、マーケティングのキャンペーンデータ、経理の財務データ — すべてが別々のシステムに散在している。まずは全体を見える化するための棚卸しが必要だ
あなた
どこから手を付ければいいですか?
田中VPoE
3つのアプローチを組み合わせる。「自動ディスカバリ」「ステークホルダーヒアリング」「システム横断分析」だ

データ資産棚卸しの全体像

棚卸しの目的

目的説明具体的な成果物
可視化どこに何のデータがあるかを全体像として把握するデータ資産カタログ
分類データの種類・重要度・機密度を体系的に整理するデータ分類体系
関係性の把握データ間の依存関係やフローを明らかにするデータリネージマップ
課題の特定重複、欠損、品質問題、セキュリティリスクを洗い出す課題一覧と優先度

棚卸しの3つのアプローチ

データ資産棚卸しの3層アプローチ:

Layer 1: 自動ディスカバリ(ボトムアップ)
  ├── データベーススキーマの自動収集
  ├── データパイプラインのトレース
  ├── API仕様書からのデータモデル抽出
  └── クラウドサービスのストレージ一覧

Layer 2: ステークホルダーヒアリング(トップダウン)
  ├── 各部門のデータ利用状況
  ├── 意思決定に使っているデータ
  ├── 「あれば欲しい」データの要望
  └── データに関する課題・不満

Layer 3: システム横断分析(クロスカット)
  ├── データフローの全体マッピング
  ├── 重複データの特定
  ├── マスターデータの識別
  └── データリネージの構築

Layer 1: 自動ディスカバリ

データソースの種類と発見手法

データソース発見手法取得できる情報
RDBMSスキーマクロール、Information Schemaテーブル構造、カラム名、型、制約、レコード数
NoSQLコレクション/テーブル一覧、サンプルドキュメント分析データモデル、フィールド名、ネスト構造
データウェアハウスメタデータカタログAPIテーブル一覧、パーティション、利用頻度
オブジェクトストレージバケット/プレフィックス一覧ファイル数、サイズ、更新頻度、フォーマット
SaaSAPI仕様書、Webhook定義エンティティモデル、利用可能フィールド
ログログフォーマット分析イベント種別、フィールド、ボリューム

自動ディスカバリで使えるツール

ツールカテゴリ代表的ツール特徴
データカタログApache Atlas, DataHub, AmundsenOSS、メタデータ収集・管理
クラウドネイティブAWS Glue Data Catalog, Google Data Catalogクラウドサービスとの統合
商用製品Collibra, Alation, Informatica豊富な機能、エンタープライズ向け
軽量ツールdbt docs, Great Expectations特定領域に特化、導入が容易

Layer 2: ステークホルダーヒアリング

ヒアリング対象と観点

ステークホルダーヒアリング観点典型的な回答例
経営層意思決定に使うデータ、KPI「月次の顧客LTVが見たいが、算出に2週間かかる」
プロダクトマネージャーユーザー行動分析、A/Bテスト「ファネル分析をしたいが、イベントデータが不完全」
営業顧客情報、パイプライン分析「CRMとプロダクトデータが繋がっていない」
マーケティングキャンペーン効果、アトリビューション「広告効果の測定が手作業で、リアルタイムに見えない」
カスタマーサクセス解約予測、ヘルススコア「解約の兆候を早期に検知したいがデータが散在」
エンジニアリングシステムメトリクス、品質指標「各サービスの依存関係が可視化されていない」

ヒアリングテンプレート

質問カテゴリ具体的な質問
データ利用日常業務でどのようなデータを使っていますか?
データソースそのデータはどのシステムから取得していますか?
加工プロセスデータの取得から活用までにどのような加工をしていますか?
課題データに関して最も困っていることは何ですか?
要望「こんなデータがあれば」と思うものはありますか?
頻度データを確認・分析する頻度はどのくらいですか?
意思決定データに基づいて下している重要な意思決定は何ですか?

Layer 3: システム横断分析

データフローマッピング

組織全体のデータの流れを可視化します。

データフローの全体像(例):

[データソース]
  CRM(Salesforce) ──→ ETL ──→ DWH(Redshift)
  プロダクトDB(PostgreSQL) ──→ CDC ──→ DWH(Redshift)
  広告(Google Ads) ──→ API連携 ──→ DWH(Redshift)
  ログ(CloudWatch) ──→ Kinesis ──→ S3 ──→ DWH(Redshift)

[データ加工]
  DWH(Redshift) ──→ dbt ──→ マート層
                              ├── 顧客マート
                              ├── 売上マート
                              └── プロダクトマート

[データ消費]
  マート層 ──→ BIツール(Tableau) ──→ 経営ダッシュボード
  マート層 ──→ Jupyter ──→ データサイエンスチーム
  マート層 ──→ API ──→ プロダクト内レコメンド

データリネージの構築

要素説明重要性
ソースデータの発生元品質問題のトレースに必須
変換ETL/ELTでの加工内容ビジネスロジックの把握
消費先データを利用するシステム・レポート影響範囲の把握
鮮度データの更新頻度とレイテンシSLAの設計に必要
責任者各段階のデータオーナー問題発生時の連絡先

データ分類体系の設計

4軸での分類

分類軸レベル説明
機密度Public / Internal / Confidential / Restrictedデータへのアクセス制御に直結
重要度Critical / High / Medium / Low障害時の優先復旧順序に使用
鮮度要件Real-time / Near-real-time / Daily / Weekly / Monthlyデータパイプラインの設計に反映
保持期間永久 / 7年 / 3年 / 1年 / 90日ストレージコストとコンプライアンスに影響

機密度分類の具体例

分類該当データ例アクセス制御
Restricted個人情報(PII)、決済情報、パスワードハッシュ最小権限原則、暗号化必須、アクセスログ監査
Confidential売上データ、顧客リスト、契約情報部門限定、NDA対象
Internal社内Wiki、プロジェクト計画、技術ドキュメント社員アクセス可能
Public公開API仕様、ブログ記事、プレスリリース制限なし

データカタログの設計

データカタログに含めるべき情報

カテゴリ項目
基本情報名前、説明、オーナー「顧客マスター」, 営業部
技術情報所在地、フォーマット、スキーマPostgreSQL / customers テーブル
品質情報完全性、正確性、鮮度完全性98%、日次更新
利用情報主な利用者、利用目的、アクセス頻度営業チーム、週次レポート
ガバナンス機密度、保持期間、アクセス制御Confidential、7年、営業部+CS部
リネージソース、変換処理、依存先CRMからETL経由、BIダッシュボードに利用

「データカタログは”データの図書館の目録”だ。目録がなければ、誰も必要な本を見つけられない。逆に目録がよく整備されていれば、誰でも必要なデータを自力で見つけられる」 — 田中VPoE


まとめ

ポイント内容
3層アプローチ自動ディスカバリ、ステークホルダーヒアリング、システム横断分析
データ分類の4軸機密度、重要度、鮮度要件、保持期間
データリネージソースから消費先までの全経路を可視化
データカタログ基本・技術・品質・利用・ガバナンス・リネージを一元管理

チェックリスト

  • データ資産棚卸しの3層アプローチを理解した
  • 自動ディスカバリで取得できる情報とツールを把握した
  • ステークホルダーヒアリングの対象と観点を理解した
  • データ分類体系の4軸を理解した
  • データカタログに含めるべき情報を把握した

次のステップへ

次は「データ成熟度モデル」を学びます。組織のデータ活用レベルを客観的に評価し、目指すべきゴールを設定する方法を身につけましょう。


推定読了時間: 30分