1 データ品質の基本
1.1 データ品質の定義
データ品質とは、データが定められた利用目的に照らして、必要な属性をどの程度満たしているかを表す概念である。一般に、正確性・完全性・一貫性・適時性・妥当性などの性質として整理される。品質は主観的な印象ではなく、測定可能な指標と評価手順によって、客観的に捉えることができる。
1.2 データ品質が重要となる理由
1.2.1 意思決定への影響
品質の低下は、集計結果や分析モデルの前提が崩れる原因となり、意思決定の判断材料を歪める。たとえば、誤った顧客情報は施策の対象を誤らせ、欠損や重複は統計的な偏りを生む。適時性が欠けると、意思決定のタイミングが遅れ、競争上の不利につながる。
1.2.2 業務・システムへの影響
データは業務処理の入力であり、品質が不足していると例外処理の増加、手作業の発生、システム障害の誘発などが起こりやすい。さらに、品質問題が長期化すると、参照データの信頼性低下により複数部門で追加確認が常態化し、運用コストが増大する。
1.3 データ品質の評価観点
1.3.1 品質次元（正確性・完全性など）
評価は複数の側面から行うのが一般的である。正確性は実世界や正しい定義への近さを示す。完全性は必要情報が欠けずに揃っている度合いを表す。一貫性は同一概念に対する値や整合が保たれているかを測る。適時性は更新の遅れがどの程度許容範囲に収まっているか、妥当性は定義・形式・範囲・標準に照らした正しさをそれぞれ扱う。
1.3.2 目的適合性（用途との関係）
品質は「良いか悪いか」だけでなく、用途との関係で判断される。たとえば、探索的分析では欠損を補完して運用する前提が成り立つ場合がある一方、規制対応や請求処理では欠損や誤差が許されないことが多い。同じ指標でも、利用場面に応じた合格基準（しきい値）が異なる。
2 データ品質の主要な指標
2.1 正確性（Accuracy）
正確性は、データ値が正しい根拠にどれだけ近いかを示す。参照可能な正解データや検証ルールがある場合は、それとの一致率や差分の分布で評価できる。参照が困難な場合でも、信頼できる情報源との照合や段階的な検証によって近似的に把握する。
2.2 完全性（Completeness）
完全性は、期待されるレコードや属性が欠けずに存在しているかを表す。欠損が多いほど復元コストが増え、モデルや集計の前提が変わりやすい。評価では「何が必須か」を先に定義し、その要件に基づいて測定する。
2.2.1 欠損率
欠損率は、特定属性において欠けている割合を示す。欠損は null、空文字、ダミー値など複数の形で現れるため、定義の統一が重要である。属性ごとの欠損率を並べることで、重点改善領域を特定できる。
2.2.2 必須項目の充足度
必須項目の充足度は、定められた必須属性が同時に揃っている比率である。欠損率が低くても、必須項目の組合せが欠けているケースはあり得るため、単一項目の指標だけに依存しない設計が望ましい。
2.3 一貫性（Consistency）
一貫性は、同一概念について値が食い違わないこと、また関連する情報同士が矛盾しないことを指す。システム間のデータ統合や更新頻度の違いがある環境では、不整合が発生しやすい。一貫性は誤差の累積を防ぎ、利用者の解釈を安定させる。
2.3.1 重複・同一性の問題
重複は同一対象が複数レコードとして存在することで、集計や分析を過大評価する要因になる。同一性（マッチング）の精度は、氏名・住所・識別子などのキーに依存するため、キー設計と標準化の成否が直結する。重複は「量」だけでなく「重複の解消難度」も評価対象となる。
2.3.2 参照整合性
参照整合性は、外部キーや参照先が成立している状態を指す。たとえば、存在しないマスタコードを参照していると、後続処理が不可能になる、または不正な扱いを誘発する。評価では、参照先の有無と参照関係の正しさを機械的に検査する。
2.4 適時性（Timeliness）
適時性は、データが必要な時点に利用可能であることを示す。計測では、更新から利用開始までの遅延（遅延時間）、最終更新時刻からの経過、処理完了までの所要時間などを用いる。遅延は可用性の問題だけでなく、意思決定の鮮度にも関わるため、業務要件に対応した測定が必要である。
2.5 妥当性（Validity）と標準準拠
2.5.1 形式・範囲・辞書の適合
妥当性は、値が定義・形式・範囲・用語辞書に適合しているかで評価される。たとえば日付形式、数値の桁や単位、許容範囲、コード体系などが該当する。辞書にない値は無効として扱う設計が一般的であり、例外が必要な場合はルールとして明文化しなければならない。
2.6 一貫した解釈（解釈可能性）
2.6.1 用語・コード体系の揺れ
解釈可能性は、利用者が同じ意味として理解できる状態を指す。用語の揺れ（表記ゆれ）やコード体系の変更、同一コードの意味変更などがあると、分析結果が再現しにくくなる。評価では、メタデータの整備状況、変換規約の存在、過去バージョンとの互換性なども確認する。
3 データ品質の評価プロセス
3.1 品質要件の定義
3.1.1 利用目的の整理
最初に、どの業務または分析でデータを使うのかを明確化する。次に、意思決定の粒度、更新頻度、許容される誤差や欠損の影響範囲を整理する。目的が曖昧なまま指標を決めると、改善の優先順位がずれやすい。
3.1.2 合格基準（しきい値）の設定
品質要件は定量化されるべきである。合格基準（しきい値）は、各品質次元について許容範囲を定め、合否や運用アクションを連動させる。しきい値は現状だけでなく、将来の利用拡大や改善余地も考慮して設計する。
3.2 データプロファイリング
3.2.1 分布・パターンの把握
プロファイリングは、データの実態を統計的に俯瞰する作業である。値の分布、頻度、欠損の偏り、文字列長、単位の傾向などを確認すると、異常の芽が見えやすい。これにより、評価指標や検査ルールの設定が現実に即して行える。
3.2.2 外れ値の探索
外れ値の探索は、期待される範囲から大きく逸脱するレコードや、急増・急減するパターンを特定する。単発の入力ミスだけでなく、手順変更やシステム移行の影響を示す場合もあるため、時系列の観察と合わせて判断する。
3.3 品質測定とレポーティング
3.3.1 ダッシュボードと指標可視化
指標は利用者が理解しやすい形で可視化する。ダッシュボードでは、対象範囲（データセット、期間、システム）、指標値、基準との差分、推移を示すと効果的である。可視化の目的は「見た目の正しさ」ではなく、改善の意思決定につなげることにある。
3.3.2 監査ログと履歴管理
測定結果とともに、ルール変更やデータ更新の履歴を残す。監査ログにより、問題発生時にいつ何が変わったかを追跡できる。履歴がない場合、評価の再現性が失われ、原因分析が困難になる。
3.4 ルールベース検査と機械的判定
3.4.1 妥当性チェック
妥当性チェックでは、形式、範囲、辞書、整合条件などをルールとして実装する。たとえば、数値が想定単位であるか、コードが許容リストに含まれるか、日付が論理的順序を満たすかを検査する。合否判定は処理フローに組み込み、例外は分類して扱う。
3.4.2 一貫性チェック
一貫性チェックは、関連するデータ間の矛盾を対象にする。重複判定、参照整合性、整合のためのキー照合などが含まれる。検査の結果は、修正可能なものと修正が難しいものを分けて運用設計に反映する。
3.5 原因分析と改善サイクル
3.5.1 事象の切り分け
原因分析では、どの時点で品質が劣化したか、影響を受ける範囲はどこかを切り分ける。入力工程、変換処理、格納後の更新、利用側の解釈など複数段階を視野に入れる。測定データと履歴を突き合わせることで、推定の精度を高める。
3.5.2 再発防止策
改善策は場当たり的な修正ではなく、再発を防ぐ仕組みへ落とし込む。具体例としては、検査ルールの強化、変換ロジックの見直し、マスタ管理の統一、入力支援（選択式フォームや検証）などがある。効果は次サイクルの指標で検証し、必要に応じて要件や基準を調整する。
4 データ品質の改善と運用
4.1 データクレンジング（修正・標準化）
4.1.1 欠損処理
欠損への対応は、補完、削除、推定、別扱いなどの選択肢に分かれる。補完する場合は前提条件と不確実性の扱いを明確にし、推定値には識別子を付けることで誤用を避ける。削除は情報損失を伴うため、影響分析と基準整備が必要である。
4.1.2 重複排除
重複排除では、マッチング条件と統合方法を定める。どの項目を優先し、衝突した値をどう扱うかを決めないと、統合後の品質が下がる可能性がある。人手レビューが必要なケースをあらかじめ設けると、全体の安定性が高まる。
4.1.3 フォーマット統一
フォーマット統一は、日付・数値・文字列の表記などを整える作業である。全体で同一の規則に従うことで、機械判定や集計の再現性が向上する。単位やタイムゾーンの扱いは特に注意が必要で、暗黙の変換がある場合はドキュメント化する。
4.2 データガバナンスと責任分界
4.2.1 データオーナーと管理者
データガバナンスでは、誰が品質に責任を持つかを明確にする。データオーナーは用途と要件を定め、管理者は運用とルール実装を担う。責任が曖昧だと、問題が発生しても判断と対応が遅れ、改善が停滞しやすい。
4.2.2 変更管理（改訂・承認）
品質はルールや定義の変更によって変動するため、改訂と承認のプロセスが重要である。変更の影響範囲、互換性、移行計画、テスト結果を記録し、利用者へ周知する。特にコード体系や必須項目の変更は、下流処理への波及を慎重に扱う。
4.3 ETL・ELTにおける品質統制
4.3.1 検証の組み込み
ETL・ELTの各段階に検証を組み込むと、問題の早期検出が可能になる。取り込み前の形式確認、変換後の整合性チェック、格納後の再検査など、段階ごとに役割を分ける。検査は計算コストと運用性を考慮し、必要な粒度で設計する。
4.3.2 取り込み時の品質ゲート
品質ゲートは、合格しないデータをそのまま流さずに制御する仕組みである。拒否、隔離、修正して再投入、警告のみ発行などの選択肢を用意し、例外時の運用を決める。ゲートがない場合、問題が下流へ伝播し、後で回収するコストが増える。
4.4 継続的モニタリング
4.4.1 異常検知とアラート
定期またはリアルタイムに品質を監視し、急な変化を異常として検知する。欠損率の急増、分布の崩れ、参照整合性の悪化などはアラート対象となる。アラートには優先度と対応手順を紐づけ、担当者が迷わない設計が必要である。
4.4.2 定期レビュー
モニタリングの結果は定期的にレビューし、指標やルールの妥当性を再評価する。利用要件の変化やシステム更新によって基準が不適切になることがあるため、固定的に運用しない。レビューでは、改善の進捗と再発状況を同時に確認する。
4.5 ユーザー活用と“データの納得感”
4.5.1 品質メタデータの提供
利用者が品質を理解するには、測定値だけでなく背景情報が必要である。評価日時、対象範囲、欠損の定義、補完の有無、既知の制約などをメタデータとして提示することで、解釈の前提が揃う。結果として、二度手間の確認が減り、信頼が醸成される。
4.5.2 フィードバックによる改善
利用者からの指摘は品質改善の重要な入力となる。異常に気づいた箇所、利用上の誤解が生じたポイント、想定外のケースなどを整理し、ルールの改善や要件の見直しにつなげる。フィードバックの反映状況を可視化すると、継続的な協力が得られやすい。
4.6 ありがちな失敗と対策
4.6.1 指標だけ追って原因を見ない
指標が悪化した事実は把握できても、背景を特定しないまま対処を重ねると、根本の再発防止にならない。対策として、履歴と工程単位の切り分け、関連データセットの比較、変更点の追跡を実施する。改善のゴールは「数値の回復」ではなく「再発しない状態の確立」である。
4.6.2 要件定義不足による手戻り
品質要件が曖昧だと、測定方法やしきい値が利用現場と合わず、修正が繰り返される。対策として、利用目的から逆算して必須項目と許容範囲を明確化し、検証ルールを合意形成する。最初の設計に時間をかけるほど、後工程のやり直しを抑えられる。