データ品質・分析準備

予測モデルの前に確認したいデータ品質――粒度・欠損・更新頻度の点検表

データが蓄積されていても、分析に必要な項目が揃っているとは限りません。目的に合った粒度、欠損や重複、定義変更、更新遅延をどのように調べるかを、業務データの準備段階に沿ってまとめます。

8分で読めます

予測対象と、実際に判断する単位をそろえる

最初に決めたいのは、どんなデータが手元にあるかではなく、誰が何を判断するために予測を使うのかです。予測の対象、データの一行が表す単位、判断を行う単位を並べて確認します。注文、商品、店舗、工程など、同じ業務でも記録の粒度は異なります。

たとえば店舗ごとの補充量を考えたいのに、売上データが全店舗の合計しか残っていなければ、店舗間の違いを捉える根拠が不足します。反対に、細かい記録があっても、最終判断が週単位なら、時間単位の変動をそのまま使う必要があるとは限りません。店舗別の在庫を判断するのか、全体の仕入れ量を決めるのかで、必要なデータのまとめ方は変わります。

粒度を確かめるための問い

予測したい対象は何か。商品、店舗、注文、設備、工程のどれか。
一つの記録は何を表し、期間や集計方法はどう定義されているか。
現場が判断する単位と、データを集計している単位は一致しているか。
予測を使う時点で、その単位のデータを必要な期間分確認できるか。

ここで必要な粒度を一律に細かくするのではなく、判断の違いを見分けられるかを基準にします。分析単位が判断単位と異なる場合は、集計や結合で補えるのか、追加の記録が必要なのかを分けて考えます。

欠損・重複・異常値は、理由を調べてから扱う

値が空欄、同じ記録が複数、通常と大きく異なる値――これらはデータ品質の問題に見えますが、すぐ削除や補完を決めるのは早計です。欠損が特定の店舗、曜日、作業状況に偏っているなら、記録されなかったこと自体が業務上の条件を示している可能性があります。

たとえば、ある工程が停止した日に稼働時間が記録されない仕組みなら、空欄を平均値で埋めると、停止の情報を消してしまいます。異常に見える値も、入力ミスとは限らず、繁忙期や設備の切替など実際の出来事かもしれません。発生元の記録や担当者の運用を確認し、問題の理由と分析上の影響を一緒に記録します。

欠損：どの項目・期間・業務条件で発生し、記録されない理由は何か。
重複：同じ出来事の再送なのか、別の明細なのか。識別子や時刻で判別できるか。
異常値：単位や入力を誤ったのか、実際の例外や業務変化なのか。

対処方法は、除外、修正、補完、別の区分として保持するなど、原因と用途によって異なります。何を変更したかを残し、加工前後で判断や評価がどう変わるか確認できるようにしておくと、後から検証しやすくなります。

項目の定義と更新の遅れを、業務の時間軸で見る

同じ項目名でも、部門や時期によって意味が違うことがあります。「完了」が作業終了なのか承認済みなのか、「数量」が受注数なのか出荷数なのかを確認しましょう。コード体系、単位、項目名、集計ルールが変更された時期も、データの期間と照らして整理します。定義変更を見落とすと、業務が変わった影響を予測モデルが学習上の傾向と取り違えるおそれがあります。

更新頻度は、単に「毎日更新」といった設定だけでなく、実際にいつ利用可能になるかが重要です。前日の実績が翌朝に届く業務と、数分ごとに状況が変わる業務では、許容できる遅れが異なります。ライブの判断に使うなら、データ発生時刻、連携時刻、利用可能時刻を区別し、遅延や未着をどう見分けるかも確認します。

まず対象期間の変更履歴と更新の実態を確認し、判断の締切までに間に合わないデータがどれくらいあるかを調べます。更新が遅いから直ちに使えないと決めつけず、より長い計画期間の予測には使えるのか、速報値と確定値を分けるべきかなど、利用目的に照らして判断します。

目的・項目・アクセス権を一緒に整理する

データ準備は、形式や欠損を直す作業だけではありません。どの判断のために何を使うかを定め、その目的に必要な項目に絞れているか、誰が確認・利用できるかも整理します。個人情報や機密性のある業務データを含む場合は、技術的に取得できることと、利用の目的や権限が適切に整理されていることを分けて確認してください。

たとえば予測の評価に必要な項目と、担当者が結果を確認するために必要な項目は同じとは限りません。目的に直接必要のない識別情報を分析に含めない方法や、アクセスを業務上必要な担当者に限る方法を検討します。具体的な取り扱いはデータの種類や利用環境によって異なるため、関係する責任者と確認することが大切です。

すべてを直すのではなく、検証に必要な問題から着手する

点検で課題が見つかっても、分析を始める前にデータ基盤全体を作り直す必要があるとは限りません。目的に照らして、予測対象を定義できない問題、評価結果を歪める問題、運用の判断時刻に間に合わない問題など、検証を妨げるものから優先します。後から改善できる項目や、今回の判断に使わない項目は、理由とともに保留できます。

点検結果は、次のような形でまとめると、分析や業務側との相談に使いやすくなります。

目的と判断単位：誰が、いつ、何を決めるために使うのか。
対象データ：項目、記録単位、期間、定義、更新の実態。
見つかった課題：欠損や遅延の範囲、発生理由、判断への影響。
対応の優先度：検証前に解決する課題、検証と並行して調べる課題、後で見直す課題。
管理上の確認：利用目的、担当者、アクセス権、変更や確認の記録。