データ整備ガイド

まえがき

  • 本ガイドの目的と背景
  • 想定読者

第一部　データ整備とは何か、なぜ重要か

本書の目的と読み方

データ整備の定義と位置づけ

なぜデータ整備が必要なのか

  • 整備を怠った場合のリスクと影響
  • 失敗例・損失事例

データ整備に取り掛かる前に知っておくべき限界

  • いくらデータ整備をしても分析の能力は高まらない
  • 分析リテラシーは別に育てる必要がある

第二部　データ整備の仕事

データ整備の4つの仕事の定義と概要

  • データ整備の仕事
  • 「抽出・整理・品質管理・記録」の4分類にした理由
  • 各仕事の関係性

抽出

  • どのようなデータが必要なのかを決める
  • アウトプットの形を決める
  • 抽出のためのSQL
  • 過度なドキュメンテーションに注意する
  • いらないデータやダッシュボードを作らない
  • 時間やコストに見合うのかを考える
  • 全て自分で完結させようとしない
  • 依頼を行う、受ける際の注意点
  • 依頼を管理する

整理

  • データを使いやすくするとはどういうことか
  • 整理で行うこと１・値レベルの整理（データの中身の標準化）
  • 整理で行うこと２・構造レベルの整理（構造・設計の最適化）
  • 整理の事例
    • 年齢・年代の整理
    • 日付・時間の整理
    • 地域の統合・分類
    • 商品やカテゴリの再定義
    • 集計済サマリデータの作成
    • 共通売上テーブルの作成
    • 使われていないデータの棚卸
  • 整理のためのSQL
  • 整理対象の優先順位付け
  • 分析やBIでの利用を見据えたDWH・データマートの設計
  • スキーマや仕様変更は早く掴む
  • マスターデータ管理との関わり方
  • 生データを残す
  • BIツールでデータの整理はしない
  • 特定のツールへの依存リスクはできるだけ回避する
  • 整理する前の段階での解決を試みる
  • 整理そのものが目的化していないか注意する
  • 整理側から品質管理へのフィードバック
  • エンジニアとのコミュミケーション

品質管理

  • 品質レベルはすべて利用を基準に考える
  • 各チェック項目に「閾値（許容値）」を定義する
  • 異常発見時の対応ルール（修正・通知・差し戻し）を決めておく
  • 自動チェックが基本、人力は例外対応
  • 過剰品質になっていないかに注意する
  • 業務フローや入力ルールの変更に関与する
  • 共通的に必要な設計・運用
    • 各チェック項目に「閾値（許容値）」を定義する
    • 異常発見時の対応ルール（修正・通知・差し戻し）
    • 自動チェック＋ログ記録が基本、人力は例外対応
    • チェック内容のバージョン管理（過去チェックとの比較）
    • チェック自体の整備漏れ・陳腐化にも注意
  • 入力時点の品質チェック項目
    • データの異常を早期発見し、以降の工程にゴミを流さない
    • レコード数の期待値との乖離
    • ファイル・バッチ単位の欠損（特定ソース未着）
    • 文字化け・エンコード不備（UTF-8/Shift-JISなど）
    • 必須項目のNULL（ID、日付など）
    • 形式不備（メール、電話番号、日付など正規表現で確認）
    • 重複レコード（複合キーでの一意性確認）
    • タイムスタンプのずれ（未来日、1970年、UTC/JST混在）
    • 半角・全角・全角スペース・特殊文字・改行の混在
    • 文字列長制限違反（VARCHARの制限超過）
    • サロゲートペア／非表示文字（絵文字、ゼロ幅スペース）
    • ダミー値（例：9999-12-31、9999999999 など）
    • バッチ重複（同一キーの多重取り込み）
    • トランザクションログ・アラート通知の設計
  • 整理後の品質チェック項目
    • 加工・変換処理で壊していないかを確認する
    • NULLや異常値の増加（JOINや集約による欠損発生）
    • JOIN後の件数増減（意図しない多重化／脱落）
    • コード変換ミス／マスタ未定義コードの出現
    • マスタ結合の未成立（JOIN KEY未マッチ）
    • 値の分布異常（カテゴリ比率の急変）
    • 横断キーの不足・非一意キーの混入
    • 比率の不一致（合計100%を超過／不足）
    • 桁丸め・四捨五入誤差（数値型の精度喪失）
    • マスタの時点ズレ（データ：4月、マスタ：6月）
    • 正規化／非正規化後の構造破損（親子不整合）
    • フィルタ処理漏れ（不要行の混入）
    • 空文字とNULLの混在（SQLで意図とズレる）
    • 一意キーの喪失（加工後にユニーク性消滅）
    • 計算ロジックの逆演算不能（非可逆な関数使用）
    • ハッシュ化・マスキングの不可逆処理ミス
    • 履歴構造の整合（最新行の重複、履歴の連続性）
    • ETL／変換パイプラインのバージョン管理とログ保守
  • 出力時点の品質チェック項目
    • 最終的な出力が破綻していないか確認する
    • 指標異常（売上0円、人数マイナス、累計減少など）
    • データ更新遅延（updatedAt が古いまま）
    • 件数0件（WHERE句ミスやJOIN落ちによる空データ）
    • 集計ロジック異常（平均、率、合計の計算間違い）
    • 単位やラベルの不一致（「千円」表記に対する実値誤り）
    • 出力フォーマット異常（CSV改行、JSONエスケープ、Excel崩れ）
    • カラム順序の変化（仕様書との不一致）
    • 日付フォーマットのブレ（YYYY-MM-DD vs YYYY/MM/DD）
    • 0と欠損の混同（意味的に違う）
    • 表示制限によるサンプル数の欠損（BI件数上限）
    • グラフスケールの不整合（縦軸固定による錯誤）
    • 並び順ミス（ソート漏れ、ランキング順位逆転）
    • 表記ずれ（項目名「商品名」→「アイテム名」など）
    • 外部リンク切れ／画像参照崩壊
    • スナップショット保存と差分比較の実施
    • BIロジックとDWHロジックの整合性確認
    • ユーザーからの誤値報告ルートの確保

記録

  • メタデータとは何か
  • メタデータの例
    • 基本情報（テーブル名、カラム名、データ型）
    • 内容の意味・構造（カラムの定義、単位、粒度）
    • 技術属性・物理情報（保存場所、ファイル形式、エンコード）
    • 運用・管理情報（更新頻度、データ提供元、データオーナー）
    • セキュリティ・制限（利用権限、機密区分、マスキング有無）
    • 品質・統計情報（件数、欠損率、ユニーク数）
    • 関連・依存関係（外部キー、派生元テーブル、関連ダッシュボード）
    • 利用者・アクセス状況（利用部門、主要ユーザー、最終利用日時）
    • バージョン・変更履歴（スキーマ変更日、変更内容、旧カラム名）
    • モデル・分析適性（時系列可否、目的変数、リーケージの有無）
    • 表示・ラベル情報（BI上の項目名、略称、表示順）
    • 自動化・連携設定（ETL処理名、更新トリガー、DAG名）
    • データ鮮度・タイムライン（最新更新日時、遅延時間、SLA）
    • 利用文脈・意図（利用目的、想定シナリオ、ユーザー層）
    • 利用支援・ガイド（注意点、FAQ、可視化の推奨、トレーニング資料）
  • メタデータを書く意味を明確にする
  • 書くべきメタデータ項目を押さえる
  • メタデータを記録する優先順位をつける
  • 書く場所・書き方を決める（ツール／フォーマット）
  • 書く人と、責任の所在を明確にする
  • 書くタイミングと更新ルールを決める
  • どこまで書くかの線引きをする（最低限の必須項目）
  • 管理基盤を選ぶ
  • 属人化を防ぐ
  • テンプレートや運用ルールを整備する
  • 自動取得と手入力をどう使い分けるか
  • 形骸化を防ぐ仕組みを持つ
  • 組織としての活動にすることの重要性
  • 活用してもらえるメタデータとは
    • 使う人の視点で整理されている（分析者・業務ユーザーが見てわかる）
    • 動作が軽い
    • 探しやすい（検索性／分類／依存関係の整理）
    • 情報が古くない（更新日記載／スナップショット比較）
    • フォーマットが統一されている（表現ブレ・表記ゆれがない）
    • 活用事例が添えられている（この定義は〇〇レポートで使われている）

第三部　データ整備の実践

データ整備と密接にかかわる仕事の知識を得る

  • 生成
  • 獲得
  • 評価
  • 集約
  • 分析
  • 法務
  • セキュリティ

データ整備におけるルール作りと合意形成

  • 命名規則や保存場所のルール
  • 更新権限とレビュー体制
  • データ変更の合意プロセス
  • 運用を定着させるために必要なこと

データ整備プロジェクトの立ち上げ方

  • 小さく始める（1チーム・1指標）
  • 成果の見える化
  • 他部門への展開と抵抗への対応 ‐ 経営層の理解を得る
  • 整備の効果をどう可視化するか

データ整備のアンチパターン

  • 気にしない
  • 誰も使わない
  • 属人化 ‐ ブラックボックス化
  • みんなでSQL
  • 若手に押し付け
  • 現場任せ
  • 外注に丸投げ
  • 内製化にこだわる

第四部　組織の中でのデータ整備

データ整備を分担する

  • データ整備の役割分担
  • データ整備をする人の呼称
  • データ整備をする人の位置づけ
  • エンジニアとの分担における課題
  • 分析する人との分担における課題
  • ビジネス部門との連携における課題
  • データの民主化について考える
  • データの民主化をせざるを得ないときの折り合いのつけ方

データ整備を関係者に説明する

  • 経営者
  • ビジネス部門
  • 分析者
  • エンジニア
  • データ整備担当

データ整備人材を内製化する

  • 採用
  • 育成
  • キャリア
  • 評価
  • 内製化が難しい理由と対策

データ整備を外注する

  • 外注する対象の判断基準（整備全体か一部か）
  • 外注時の注意点（属人化／仕様伝達／品質保証）
  • 委託先との契約・SLA設計
  • 内製とのハイブリッド体制

データ整備の価値を現場に浸透させる

  • 整備の価値を現場に定着させる
  • 整備の成果を現場が実感できる形にする
  • 整備内容の共有・教育・フォロー体制を設ける
  • 経営層が後押しする

データ整備の投資と説明責任

  • 整備コストはどこまで許容されるのか
  • 投資対効果の説明方法
  • 無駄な整備の見極め方

第五部　データ整備のいままでとこれから

  • データ整備の現状
  • データ整備のこれから
  • 生成AIとデータ整備

補章　実務で役立つ参考情報

  • 整理・品質チェックSQLテンプレ集
  • メタデータ記録用スプレッドシート雛形
  • 抽出仕様書テンプレート
  • 整備対象の棚卸フォーマット
  • 整備スプリントのWBS

あとがき

  • 参考文献