データ品質管理体制の作り方
守るべき値と責任境界を先に決める
品質は「誰が・何を・どこまで守るか」を先に決めないと運用化できません。重要データ資産（例：受注ファクト、顧客ディメンション、費用仕訳）ごとにオーナーを明確化し、データ契約とSLOを設定します。契約には少なくとも次を含めます。
- スキーマと意味論：例）order_idは不変のUUID、statusは{new, paid, shipped, canceled}に限定
- 鮮度：営業日D+0 06:00 JSTまでに99.5%到着、遅延時は07:00までにアラート
- 完全性・唯一性：当日分の受注行の到着率99.9%以上、order_idの重複率0%
- 整合性：支払済み(order.status=paid)は必ずpayment_idが非NULL
責任境界は「生成側（プロダクト/ETL）」「統合側（DWH/モデリング）」「提供側（BI/データ製品）」で切り、RACIを定義します。例：生成側はスキーマ変更の事前通知義務、統合側は変更に対する互換レイヤー提供、提供側は下流利用者への変更告知とリリースノート配布。可観測性（鮮度・欠損・重複・分布変化）のメトリクスは全資産で共通化し、ダッシュボードで可視化します。
検証と自動化：アラートが“使える”レベルに落とす
抽象的な「品質向上」ではなく、具体的な検証と運用手順に落とし込みます。基本は「スキーマ検証」「値検証」「関係検証」「分布ドリフト検出」の4層です。
- スキーマ検証：型・必須カラム・許容値。例）emailは正規表現に合致、priceは非負、timestampは過去365日以内。
- 値検証：欠損率/外れ値率の閾値。例）daily_ordersのNULL率<0.5%、金額のP95/P50が前週比±15%以内。
- 関係検証：外部キー、重複排除。例）(customer_id, order_date)の複合唯一制約。
- 分布ドリフト：KS検定や人口比の乖離で検知。例）チャネル比率が前月比で20pt以上変化。
検証はパイプラインの各段（取り込み→ステージ→統合→マート）で実行し、重大度を3段階にします。
- L3（致命）：契約違反。消費停止、最後に良かったパーティションへフェイルバック。
- L2（重要）：統計異常。オーナーへのページ、原因切り分けの標準手順に従う。
- L1（注意）：軽微な変化。日次レビューで監視し傾向管理。
アラートには「対象データセット/影響範囲/最終正常時刻/推奨アクション」を必ず含め、5分以内のトリアージをSLO化します。検証クエリの雛形作成や事象サマリにはChatGPTやClaudeを補助的に使うと初動が速くなります。コードのテスト補完やPRレビューはCopilot、アラートの自然言語要約や週次レポート草案はGeminiが役立ちます。ただし、最終判断はオーナーが行い、生成物は必ずレビューします。
監視ダッシュボードとエラーバジェット
鮮度SLOの達成率、欠損・重複・ドリフトの件数、インシデントMTTRを可視化し、月次で「エラーバジェット」を評価します。バジェット超過時は新規開発より品質改善を優先する運用ルールを明文化します。
変更管理とライフサイクルを仕組みにする
壊れるのは変更時です。スキーマ方針は「原則アディティブ」を基本に、互換性を壊す変更はバージョン付けで並走させます。例）customers_v1に新しい正規化設計を導入する場合はcustomers_v2を作成、30日間は両方を更新し、下流移行完了後にv1を凍結→廃止。変更はカレンダーで事前告知し、四半期決算前はフリーズ期間を設けます。
バックフィルは「範囲・再計算コスト・検証方法・リスクとロールバック条件」を運転計画に記載し、実行前に承認を得ます。PIIの保持期間・マスキング方針・削除要求への応答もライフサイクルに含めます。生成側・統合側で「契約破りを検知したら即時に互換レイヤーで吸収し、24時間以内に恒久対応案を提示する」など、合意済みのエスカレーションパスを定義すると混乱が減ります。
身近な企業活用例：ECスタートアップのやり直し
週次の広告ROASで意思決定していましたが、CRM移行の影響でcustomer_idが重複し、返品の遅延反映も相まってROASが20%過大評価。広告費を積み増した結果、在庫回転が悪化しました。
やり直しでは、データ資産を「受注」「顧客」「広告費」に区分しオーナーを設定。SLOは「D+0 07:00までに99.5%」「受注の重複率0%」「返品は発生日+1で反映」。検証として、(email, phone)の複合キーで疑似IDを生成し、決定論的ルール→確率的スコアで重複排除。返品は支払い・在庫と三者突合を必須化。変更はcustomers_v2を並走させ、30日間で移行。初期導入はパイプラインの各段に自動テストを配置、L3発生時は「広告マート更新を停止し、最後の正常日付で固定」するフェイルバックを実装しました。
運用面では、当番制オンコールと5分トリアージ、日次の鮮度レビューを定着。検証SQLの雛形をChatGPTで生成し、事故報告の時系列要約をClaudeで草案化、PRのテスト補完はCopilot、週次品質レポートのドラフトはGeminiで作成。最終レビューはオーナーが行い、ルールはリポジトリに保存。結果、ROASの過大評価は解消、広告配分の見直しで無駄コストを月次で6%削減、在庫回転日数は12%改善、データ関連のMTTRは平均42分から18分に短縮しました。
品質は「一度きれいにする」ではなく「壊れない仕組み」を回し続ける営みです。データ解析プラットフォーム事業では、この仕組みを土台（契約・検証・監視・変更管理）として標準装備し、各プロダクトが自律的に品質を守れるようにすることが価値になります。プラットフォームがSLOと可観測性を共通言語にし、現場の改善速度を落とさずリスクを下げることが、最終的に意思決定の質を上げます。
