データ分析を始めようとすると、欠損値、表記揺れ、異常値、重複、商品コードや顧客コードの不整合など、さまざまな問題が見つかります。
そこで「まずデータをきれいにしてから分析しよう」と考え、すべての欠損や表記揺れを修正し始めると、データクレンジングだけで多くの工数を使ってしまうことがあります。
一方、品質問題を確認せず分析へ進めば、同じ商品が別商品として集計されたり、重要なKPIが欠損したりして、判断そのものを誤る可能性があります。
重要なのは、データを完全にきれいにすることではなく、「何を判断するためのデータなのか」から逆算し、その判断に必要な品質水準を決めることです。
データ品質は単なる正確さだけでなく、利用する文脈やタスクとの適合性を含めて考える必要があります（Wang and Strong, 1996; Strong et al., 1997）。
データ品質は「高いほど良い」とは限らない
データ品質が高いこと自体は望ましい状態です。しかし、企業が利用できる時間・人員・予算には限りがあります。
例えば、商品別売上を分析したい場合、商品コードが正しく対応していることは重要です。一方、今回の分析で利用しない備考欄に全角・半角の表記揺れが大量にあっても、同じ優先度で修正する必要性は低いかもしれません。
データ品質を評価する際には、すべての項目を一律に高品質へするのではなく、利用目的に対して十分な品質を確保する「Fit for Purpose」という考え方が有効です。
Decision
データ分析で確認したい6つの品質観点
Data Qualityには複数の整理方法があります。唯一の分類があるわけではありませんが、実務では次の6つが代表的な観点として利用されています。
| 品質観点 | 意味 | 業務データでの確認例 |
|---|---|---|
| Accuracy / 正確性 | 現実を正しく表しているか | 売上額や数量が原票と一致しているか |
| Completeness / 完全性 | 必要な値・レコードが存在するか | 分析対象商品の売上額が欠けていないか |
| Consistency / 一貫性 | データ間で矛盾がないか | 同じ商品がシステムごとに異なるコードになっていないか |
| Timeliness / 適時性 | 必要な時点で利用できるか | 月次会議までに必要データが確定するか |
| Validity / 妥当性 | 定義・型・範囲等のルールに従うか | 商品コードが許容された形式になっているか |
| Uniqueness / 一意性 | 不要な重複がないか | 同一取引が二重登録されていないか |
どのDimensionを重視するかは利用目的によって変わります。データ品質指標を画一的に適用するのではなく、タスクに応じた評価指標を設計する必要があります（Pipino et al., 2002）。
データクレンジングに工数を使い切る理由
クレンジングが終わらなくなる大きな理由の一つは、「何を直せば完了なのか」が決まっていないことです。
例えば100列あるデータについて、すべての欠損、表記揺れ、異常値を同じ重要度で調査すると、分析に利用しない項目まで修正対象になります。
まず確認したいのは、今回の意思決定に必要なCritical Data Elementです。
例えば「どの商品カテゴリへ営業・在庫資源を重点配分するか」を判断するなら、商品ID、対象期間、売上、数量、在庫等は重要です。一方、その判断に利用しない自由記述欄の表記統一は後回しにできる場合があります。
つまり品質問題の優先順位は、単に「汚れているか」ではなく、その問題によって今回の判断が変わる可能性があるかで決めます。
旧・新の商品コードが混在している架空例
説明用の架空企業で、過去3年間の商品別売上を分析し、「どの商品カテゴリへ営業・在庫資源を重点配分するか」を判断するとします。
ところが、分析対象期間の途中で商品コード体系が変更されていました。
旧コードは「PROD-A01」、新コードは「ITEM-101」で、どちらも製品Aを示しているとします。
この2つを別の商品として集計すれば、製品Aの売上推移が途中で分断され、商品ランキングや成長率の判断も変わる可能性があります。
今回の分析では商品別集計が意思決定に直接関係するため、商品コードの整合性は優先して確認すべき品質問題です。
ただし、旧コードをすべて新コードへ文字列置換すればよいとは限りません。商品仕様、容量、Pack、価格体系の変更や、商品統合・分割が行われている可能性があるためです。
実務ではRaw Dataを直接上書きせず、旧新コードと分析用のCanonical IDを対応付けるMapping Tableを用意すると、元データを保持しながら分析条件を変更できます。
例えばsource_code、canonical_product_id、product_name、valid_from、valid_to、mapping_status、mapping_reason、source_system等を持たせます。
分析前にデータ品質を判断する6つのステップ
Step 1：何を判断したいか決める
「データを分析したい」ではなく、「分析結果を使って何を決めるのか」を明確にします。
Step 2：判断に必要な項目を特定する
売上、商品ID、顧客ID、日付等、判断結果に直接関係するCritical Data Elementを特定します。
Step 3：Data Profilingで品質問題を把握する
Data Profilingとは、欠損、値の分布、重複、型、Code、範囲等を確認し、データの状態を把握する作業です。
この段階では、見つけた問題をすべて直すのではなく、まず一覧化します。
Step 4：意思決定への影響度で優先順位を付ける
「この項目が間違っていると、今回の判断が変わるか」を確認します。
商品別売上を判断するのに商品IDが不整合なら影響は大きい一方、利用しない備考欄の表記揺れなら初期分析への影響は小さい可能性があります。
Step 5：必要水準まで修正し、残存課題を記録する
品質問題を修正したら、「未解決の問題が何か」「分析結果へどのような影響があり得るか」も残します。
すべてを解消できない場合でも、制約を明確にした上で分析を行うことで、結果を過度に一般化することを避けられます。
Step 6：分析開始後も品質問題を監視する
データ品質改善は一度だけの作業ではありません。分析を進めることで、新たな不整合や欠損パターンが分かる場合もあります。
Criticalな問題を解消した後は、分析、品質問題の追加確認、必要部分の改善、再分析というIterationで進める方法もあります。
欠損・表記揺れ・異常値はどう扱うか
欠損値は、すべて同じ意味とは限りません。
未入力、不明、対象外、測定不能、システム移行時の欠落など、空欄になる理由によって扱いが変わります。そのため、欠損値を一律に0や平均値へ置き換える前に、欠損理由を確認します。
表記揺れも同様です。「株式会社SCI」と「SCI（株）」が同一企業であることを確認できれば正規化できますが、似た名称というだけで同一視すると誤った名寄せにつながります。
異常値についても、検出と削除は別です。極端に高い売上額が入力ミスの場合もあれば、実際に発生した大型案件の場合もあります。
まず原票・業務イベント・単位等を確認し、その値が何を意味するかを判断します。
どこまで直せば分析を開始してよいか
「欠損率○%以下」「品質スコア○点以上」のような一律の線引きは、本記事では推奨しません。
分析開始条件は、利用目的ごとに決めます。
- 分析に必要な主要項目が利用できる
- Join Keyや集計Keyの重大な不整合が解消されている
- KPIを変えてしまう既知の問題が対処されている
- 残っている品質問題と影響範囲を説明できる
- Raw Dataと修正ルールを追跡できる
この状態になれば、必要に応じて分析を開始し、その過程で追加の品質改善を進めることができます。
分析に使う列を一覧化し、その横に「この項目が間違っていると今回の判断が変わるか」という列を一つ追加してみてください。Yesとなる項目から品質確認を始めるだけでも、すべての列を同じ優先度で修正する状態を避けやすくなります。
同じ品質問題を再発させない
毎月同じ商品コードを手作業で変換しているなら、分析担当者のクレンジングだけで問題を閉じないことも重要です。
繰り返し発生するCritical Issueは、データ入力、Master管理、ETL、システム連携等、可能な範囲で発生源に近い場所へ対策を移します。
例えば商品コード変更時のMapping Table更新責任者を決める、入力時のValidity Checkを行う、重要項目の欠損を定期的に監視するといった方法があります。
Data Qualityは一度のクレンジング作業ではなく、継続的な測定と改善として扱う必要があります（Pipino et al., 2002）。
データ品質チェックリスト
| 確認項目 | 確認内容 |
|---|---|
| Business Question | 分析結果で何を判断するか決まっているか |
| Critical Data | 判断に必要な項目を絞れているか |
| Completeness | 必要項目・期間の欠損を確認したか |
| Consistency | 部署・期間・システム間の不整合を確認したか |
| Master | 旧新コードや対応関係を確認したか |
| Missing Reason | 未入力・不明・対象外等を区別したか |
| Outlier | 異常値を自動削除せず意味を確認したか |
| Duplicate | 重複と正当な複数レコードを区別したか |
| Raw Data | 修正前データを保持しているか |
| Mapping / Rule | 修正方法・理由を記録しているか |
| Remaining Risk | 残存する品質問題を説明できるか |
| Monitoring | 重要な問題の再発を継続監視しているか |
まとめ
データ分析の前に、欠損・表記揺れ・異常値・重複・Master不整合を確認することは重要です。
しかし、すべてのデータ項目を完全にきれいにしてからでなければ分析できないわけではありません。
まず何を判断したいのかを明確にし、その判断に必要なCritical Data Elementを特定します。そして、品質問題が意思決定へ与える影響を基準に優先順位を付けます。
特に商品コードや顧客コード等のKeyが不整合で、集計結果そのものが変わる場合は優先的な対応が必要です。一方、今回利用しない列の軽微な表記揺れは後回しにできる場合があります。
Fit for Purposeとは「品質が低くてもよい」という意味ではありません。利用目的に必要な品質要件を明確にし、重要な問題へ限られた改善資源を配分する考え方です。
SCI総合研究所株式会社のRASHINRAでは、データをきれいにすること自体を目的とせず、まず何を判断したいのかを整理し、その判断に必要なデータと品質水準を確認します。
「欠損・表記揺れの修正だけで分析が進まない」「商品コードや顧客コードが途中で変わっている」「どこまでデータを整備すれば分析へ進んでよいか分からない」といった段階から、データ整備と分析の優先順位を整理できます。
参考文献
- Wang, R. Y. and Strong, D. M. 1996. Beyond Accuracy: What Data Quality Means to Data Consumers. Journal of Management Information Systems. Vol. 12. Issue 4. pp. 5-33. DOI: 10.1080/07421222.1996.11518099.
- Strong, D. M. et al. 1997. Data Quality in Context. Communications of the ACM. Vol. 40. Issue 5. pp. 103-110. DOI: 10.1145/253769.253804.
- Pipino, L. L. et al. 2002. Data Quality Assessment. Communications of the ACM. Vol. 45. Issue 4. pp. 211-218. DOI: 10.1145/505248.506010.