このポストについて
DMBOK2 を読み進めていくシリーズ。
今回は第13章「データ品質」について。
これまで業務で「データ品質」という言葉が使われることがあったが、意味が限定的だったり人によって定義が違ったりしていた。
そのあたりクリアにできるとよい。
内容紹介
データ品質の定義
データ品質の簡潔な定義は「目的に適合している」。
データ品質管理の定義は「データを収集し扱うための技法を適用し、企業や地域のデータ利用者の、ニーズや利用に適したデータとすることを保証する活動を計画し、実施し、管理する」。
データ基盤担当の仕事柄、データ品質というとどちらかというと上流であるデータソース側の定義が重要だと思っていたが、そうではなく下流であるデータ利用においての観点が起点になるというのが気づきだった。(でも考えてみれば当たり前)
ビジネス上の意義
- ステークホルダーの体験と組織の評判を高める
- ex. データが正しいことを顧客が信頼し、組織との取引に自信を持てる
- 組織がより有効な成果を出せるようにする
- ex. ビジネスチャンスの特定と効果的な請求により売上を獲得できる
- 低品質なデータによるリスクとコストを削減する
- ex. データが正しいかどうかをスタッフが見極める時間が減る
- ex. 誤ったデータによる誤った意思決定
- 組織の効率と生産性を向上する
- ex. カスタマーサービスにかかってくる電話が減り、問い合わせを解決できるようになる
- ex. カスタマーサービスにかかってくる電話が減り、問い合わせを解決できるようになる
重要なデータ
データ品質管理における第一の原則は、組織とその顧客にとって最も重要なデータに改善努力を集中させること。
- ex.
- 顧客のメールアドレス欄のデータが不完全であれば、顧客にメールで商品情報を送ることができず、潜在的な売上を失う
- 1通のメールを送るごとに100円の収益が得られることが知られている
- → データ品質の改善に明確な価値があると言える
重要なデータは組織や業界によって異なるが、以下のような用途で使用されることが多い。
- 規制、財務、経営報告
- 事業運営上のニーズ
- 製品の品質と顧客満足度の測定
- 事業戦略、特に競争上の差別化への取り組み
データ品質評価軸
データ品質評価軸は、測定可能なデータの特徴または特性。
一般的な評価軸は次のとおり。
| No. | 評価軸 | 説明 | 例 |
|---|---|---|---|
| 1 | 有効性Validity | データの値が定義された領域の値と一致しているかどうか。 | - 数値、日付などのデータ範囲- 電話番号などの書式 |
| 2 | 完全性Completeness | 必要なデータがすべて存在するかどうか。カラム, レコード, データセットのレベルがある。 | - カラム: 必須カラムにデータが入っているか？- データセット: 都道府県マスタに47都道府県の情報はあるか？ |
| 3 | 一貫性Consistency | データ値が同じアプローチ、評価、価値基準を用いてコード化されていることを保証すること。レコード内、レコード間、経時的な一貫性などがある。 | - すべての顧客企業の住所は本社住所となっているか？- 生徒の成績評価は時を経ても同じか？ |
| 4 | 整合性Integrity | データに非一貫性や破綻した関係性がないこと。 | - 顧客住所の国がカナダの場合、州としてカナダの州が記載されているか？ |
| 5 | 適時性Timeliness | データの取得または更新後、ユーザーがデータにアクセスできるようになるまでの時間を指す。 | - 電力会社は電力需要データを数秒以内に利用して需給調整する必要がある- 政府機関が四半期末の2ヶ月後に GDP 報告書を作成 |
| 6 | 最新性Currency | データが最後に更新されてから現在までの期間と、それがまだ正しいという可能性。データセットによって期待される最新性は異なる。 | - 国コードは比較的静的- 銀行口座残高は変動的 |
| 7 | 妥当性Reasonableness | データパターンが期待に合致しているかどうか。 | - 先週のクリック数と比較して今日のクリック数は普通か否か？ |
| 8 | 一意性/重複排除Uniqueness/Deduplication | 現実世界の実体がデータセット内に2つ以上存在しないこと。 | - ユーザー ID は重複していないか？- ユーザー ID は異なるが、同一の人物を表していないか？ |
| 9 | 正確性Accuracy | データが「現実の」実体を正しく表している程度。 | - ユーザー名は現実世界の個人の名前なのか？- 顧客は実際にそのメールアドレスを使用しているのか？ |
ここでようやく「データ品質」が具体的なものとして見えてきた。
測定が比較的容易なものもあれば困難なものもある。
効果的なデータ品質尺度
完全性の例
| 業務ルール | 内容 | 例 |
|---|---|---|
| 業務ルール | フィールドの入力は必須 | 郵便番号は住所テーブルに100%入力されていなければならない。 |
| 測定 | データが入力されたレコードの数を数え、レコードの総数と比較する | 入力数: 700,000未入力数: 300,000合計: 1,000,000 |
| 評価基準 | データが入力されたレコードの割合をパーセンテージで算出 | 正の測定: 700,000 / 1,000,000 = 70% |
| 判定指標 | 業務ルールが満たされていれば可。そうでなければ受け入れ不可。 | 許容できない。未入力の郵便番号がある。 |
| |
データ品質 業務ルール
業務ルールは、組織内の有用で使用可能なデータはどうあるべきかを記述する。
データ品質評価軸と整合しており、データ品質要件を記述するために使用される。
- ex. 州や県を管理するための業務ルール
- 有効性: すべての州や県は、参照テーブルの値でなければならない
- 完全性: 国が州や県に分割されている場合、すべての住所は州や県を持たなければならない
- 整合性: すべての州や県の名前は、国名にリンクされた値を持たなければならない
- etc.
評価軸に基づき、データ品質をより具体的に規定するのが業務ルール。
データ品質問題のよくある原因
- 監督の欠如による問題
- 指導者やスタッフの認識不足
- 優先順位の欠如
- 業務ガバナンスの欠如
- etc.
- データ入力プロセスに起因する問題
- ユーザーエンゲージメントの不足
- ユーザートレーニング
- 使い勝手の悪さ
- etc.
- データ処理機能に起因する問題
- 下流を考慮しない
- 一貫性のないプロセスの実行
- 業務プロセスの変更
- etc.
- システム設計に起因する問題
- 参照整合性
- 一意性制約
- 処理エラーとギャップ
- etc.
- 問題の修正によって引き起こされる問題
- 不十分なリカバリ機能
- 参照データの頻繁な変更
システムで対応できるものもあれば組織的な課題となるものもある。
データ処理機能に起因する問題のある程度は data contract で解決できそう。
アクティビティ
- データ品質フレームワークの定義
- 高品質データの定義
- 品質評価軸と関連する業務ルールの特定
- 最初のデータ品質アセスメントの実施
- 潜在的な改善点の特定と優先順位付け
- データ品質改善のゴールの策定
- データ品質オペレーションの開発と展開
- データ品質ルールの管理
- データ品質の測定と監視
- データ問題の管理手順の策定
- データ品質 SLA の確立
- データ品質への対応 (利用者への報告)
データ品質およびその他の知識領域
データ品質と「データモデリング」
高品質なデータを得るためのデータモデリング段階のポイント
- データ品質値を保持する
- 業務ルールを関連付ける
データ品質と「メタデータ管理」
データ品質プロセス中にメタデータが作成される。
- ex. 顧客住所がプロセスによって有効とマークされた場合、住所とともにメタデータとして維持されるべき
データ品質メタデータがないとユーザーはそのデータを信用せず、チェックや検証に労力を費やすことになる。
データ品質と「マスターデータ・参照データ管理」
データを検証するために利用される。
データ品質低下の主な原因はマスターデータ管理の弱さにある。
未熟なマスターデータ管理は信頼性の低いデータソースを選択することにつながり、データ品質の問題を発見することが困難になる。
データ品質と「データ統合と相互運用性」
データの移動がデータ処理プロセスにおけるエラーの一般的な原因となるため、データ品質に影響する。
データ品質をテストする重要な場所でもある。
データ品質と「データガバナンス」
データ品質機能がデータガバナンスプログラムの一環として行われれば、より効果的。
逆にデータ品質の問題が企業全体のデータガバナンスを確立する動機ともなる。
所感
プロダクト開発におけるコード品質と類似点が多いと感じた。
- 組織としてデータ品質に投資する合意を得るのは簡単でなさそう
- データ品質改善に取り組めたとして、うまくいってるときに評価されにくい問題
- 水道からはきれいな水が出て当たり前
データ基盤においてこれらの品質を整えていくのは長い道のりになりそう。
だがやるしかない。