データが使い道に合う質か、集めてから処分するまで確かめ続ける

## データの使い道から、必要な質の基準を決める 品質は、データが特定の意思決定、サービス、分析、義務をどの程度支えられるかで捉える。形式が整ったデータセットでも、特定の用途には適さない場合がある。そのため、データが「良い」という一般的な約束ではなく、利用の前提から検討を始める。 - 想定するユーザー、意思決定、成果物、誤りがもたらす結果を明示する。 - その用途で重要となる各品質特性について、最低限許容できる基準値を記録する。 - 観測可能な証拠と、適合性に関する仮定を分ける。 - 目的、ユーザー、運用環境が変わったら、適合性を再評価する。 ## データと直す作業ごとに担当者を決める 品質を、明確な意思決定権を伴う共通の運用責任にする。上級責任者は作業に資金を割り当てて優先順位を決め、説明責任を持つ所有者は残余リスクを引き受ける。専門家は管理策を設計し、データを作成または取り扱う人は日々の実務でそれを適用する。 - 重要なデータセット、管理策、問題、是正措置ごとに、担当者を明確にする。 - 例外を承認できる人と、通知を受ける必要がある人を定める。 - 担当者に、その役割に関係する基準と確認方法を教育する。 - 能力の不足、繰り返す不具合、期限を過ぎた対応を定期的に見直す。 ## データが実際にどう使われているかを聞き、直す順番を決める 作成者が想定する使われ方だけでなく、データが実際にどう利用されているかを示す証拠を集める。ユーザーによって、鮮度、詳細度、網羅性、精度に求める水準は異なる。一つの改善が、ある用途には役立つ一方で、別の用途を弱める場合もある。 - 代表的な作成者、処理担当者、分析者、運用担当者、受領者に聞き取りを行う。 - 用途ごとに、意思決定、依存関係、不具合の影響、不確実性への許容度を対応付ける。 - ユーザー価値、回避できる損害、影響範囲、実装コストに基づいて改善の優先順位を決める。 - 需要が変化した場合や、影響の大きい新たな用途が生じた場合は、優先順位を見直す。 ## 計画から処分までの各段階で、確かめる事を決める ライフサイクルを、計画、取得、準備と保守、利用、共有、保持または廃棄へとつながる循環として捉える。早い段階で入り込んだ不具合は、後の意思決定や公開まで隠れたままになる場合があるため、品質管理は各段階を通じてデータを追跡しなければならない。 - 各段階について、開始条件、完了条件、検証、証拠、責任者を定める。 - 重要な項目を、発生元から変換処理を経て最終成果物まで追跡する。 - 問題を、その原因を取り除ける最も早い段階へ戻す。 - レビュー担当者が経緯を再構成できるよう、十分な来歴と意思決定の履歴を残す。 ## データを集める時点で、おかしな値を止める 取得時点で回避可能な不具合を防ぐ。収集ルールは、期待する値を入力しやすくし、正当な例外を隠さずに不可能な値を拒否できるものにする。さらに、各レコードの出所と意味を説明できる十分な背景情報を保持する。 - 必須項目、形式、範囲、識別子、参照値を検証する。 - 欠損、重複、矛盾、予想外の変更があるレコードを検出する。 - 来歴、収集時刻、定義、既知の変換処理を記録する。 - 下流のユーザーが発生元の責任者へ不具合を報告できるフィードバック経路を設ける。 ## データを加工する前後で、件数と合計を照らし合わせる データを標準化、結合、変換、移行、更新する間も、その意味を保護する。安定した確認は実用的な範囲で自動化する一方、曖昧な関係、重大な異常、解釈を変え得る変更については、人によるレビューを残す。 - 文書化されたルールと代表的な境界事例に照らして変換処理をテストする。 - 処理の前後で、件数、合計値、キー、重要な属性を照合する。 - ドリフト、古いレコード、スキーマ変更、切れたリンク、理由を説明できない件数変動を監視する。 - 定義と管理策を、それを実装するシステムと一緒に版管理する。 ## 使う前・渡す前に、データがその用途に合うか確かめる 分析、業務への投入、外部共有の前に、そのデータが対象の用途に引き続き適しているかを確認する。技術的に有効なデータでも、背景情報や保護策が欠けていれば損害を招く場合があるため、アクセス、プライバシー、開示、品質の各管理策を一体として適用する。 - 重要な成果物を、発生元の証拠と既知の制約に照らしてレビューする。 - 定義、来歴、品質評価の結果、許可された用途を、データと一緒に公開または引き渡す。 - 不具合によって以前の結論が変わる場合は、訂正を記録して影響を受ける受領者へ通知する。 - 保持または廃棄の際は、必要な期間にわたり、完全性、監査証拠、不可欠な知識を保全する。 ## データの問題を1つの点数にまとめず、種類ごとに測る 異なる不具合の種類を一つのスコアにまとめず、それぞれ個別の指標で測る。最低限、必須値が存在するか、各実体が一度だけ表現されているか、複数の発生元で値が一致するか、データが必要な鮮度を保っているか、値が定めたルールを満たすか、レコードが現実を反映しているかを検討する。 - 各指標について、対象母集団、分子、分母、除外条件、期間を定義する。 - 一律の目標値を流用せず、用途とリスクに応じて基準値を設定する。 - ルールへの適合と、現実に対する正しさを区別する。 - 意思決定が基本的な評価軸では扱えない特性に依存する場合は、専門的な評価軸を追加する。 ## 何を確かめ、何を確かめていないかを、使う人に伝える ユーザー自身が適合性を判断できるだけの情報を提供する。品質報告には、検証したこと、検証していないこと、その結果、業務への影響、未解決の不確実性、次の対応の責任者と時期を記載する。 - 再現に必要な定義を保ちながら、平易な言葉を使う。 - 現在の状態と変化の方向の両方を報告する。 - 網羅性が低い段階で早く公開するか、より強い保証を得るまで待つかといったトレードオフを説明する。 - 確認済みの不具合、疑われるリスク、承認済みの例外、不明点を区別する。 ## くり返す誤りを根本の原因から直し、効いた証拠で閉じる 繰り返す不具合を、個別の修正作業ではなく、弱いプロセスを示す兆候として扱う。差し迫った損害を抑え、不具合がどのように入り込み、なぜ検出をすり抜けたかを調べる。そのうえで、最も早い段階にある有効な管理策を変更し、変更が継続して機能することを確認する。 - 問題について、重大度、影響を受ける用途、証拠、責任者、期限、状態を記録する。 - インシデント、段階、発生元、管理策にまたがる傾向を分析する。 - 結果を基準値や以前の期間と比較し、悪化または改善を特定する。 - 根本原因が管理され、下流に重大な影響が残っていないことを証拠で示してから、対応を完了とする。