昨日まで正しかったデータが、今日から間違っている
—物流データ品質を保ち続ける仕組み
・データ品質が「収集時の課題」から「運用の課題」に変わる理由
・欠損・遅延・異常値・マスタ不整合という4つの監視観点
・データが止まったことに気づく仕組みと、誰が異常を受け取るのか
データ基盤が動き始めて数か月。KPIは毎朝更新され、ダッシュボードには数字が並んでいます。特に不具合の報告もありません。
ある日、現場の担当者が言います。「この数字、ちょっと低すぎませんか」。調べてみると、3週間前からB拠点のデータが1件も入っていませんでした。
誰もエラーを見ていなかったわけではありません。むしろ、エラーは出ていませんでした。取り込む対象がなければ、処理は何事もなく完了します。集計も正常に終わります。数字も表示されます。ただ、その数字がB拠点を含んでいなかっただけです。
これがデータ品質の運用がもっとも難しい点です。データが間違っているとき、システムはたいてい正常に動いています。
1. 「収集時の品質」と「運用の品質」は別のもの
8月の「物流データ収集入門」では、欠損・重複・遅延をどう防ぐか、システム間の時刻をどうそろえるかを扱いました。これらは収集の設計の話です。設計が正しければ、その時点では品質は確保されます。
しかし、その先があります。
| 観点 | 収集時の品質（8月シリーズ） | 運用の品質（本記事） |
|---|---|---|
| 問い | 正しく取れる設計になっているか | 正しく取れている状態が続いているか |
| 時点 | 導入・設計時 | 稼働開始後、毎日 |
| 対処 | 設計を見直す | 異常を検知し、対応する |
| 失敗の形 | 最初から測れていない | ある日から測れなくなっている |
設計をどれだけ丁寧に行っても、後者は防げません。センサーは故障し、通信は途切れ、WMSのバージョンアップで項目名が変わり、拠点が追加され、マスタの更新が漏れます。現場が動いている限り、データ品質を維持するための対応が必要になります。
したがって運用フェーズでのデータ品質は、監視の指標と、異常時の対応の流れをどう設計するかという話になります。
2. 何を監視するのか——4つの監視観点
「データ品質を監視する」と言っても、すべてを見ることはできません。実務で見るべきものは、大きく4つに整理できます。
もっとも頻度が高く、もっとも気づきにくい異常です。冒頭のB拠点の例がこれに当たります。
見るのは「エラーが出たか」ではなく「いつもと同じだけ来ているか」です。拠点別・データ種別ごとの件数を前日や前週と比べると、ゼロになった系統がすぐに分かります。
データは届いているものの、想定していた時刻までに揃っていない状態です。朝8時に見るはずのKPIが、実は前日23時までのデータしか含んでいない、というずれが起きます。
問題は、遅延したデータで集計しても数字は出てしまうことです。「不完全なまま集計された」という事実が表示されなければ、見た人は完全な数字だと受け取ります。
1件のピッキングに8時間かかっている、庫内温度が-40℃になっている、1日の出荷数が通常の10倍になっている。機器の不調や設定変更で起きます。
ここで注意したいのは、異常値を自動で除外すると本当の異常が見えなくなることです。実際に設備が長時間停止していた場合、その記録は異常値ではなく事実です。除外ではなく、まず「通常と違う値が出ている」と知らせることが優先されます。
第4回で扱った、対応表に載っていないコードが現れる状態です。これも黙って集計から落ちるため、数字だけを見ていると気づけません。
見るのは、対応先が見つからなかった件数です。この件数が普段よりも増えていれば、マスタの更新が追いついていないことになります。
だから、意図して見に行かないと気づけません。
3. 「止まったことに気づく」のがいちばん難しい
4つの中でも、欠損——とくにデータが完全に止まったケースは、仕組みの作り方に工夫が必要です。
理由は単純です。ほとんどの監視は「何かが起きたら知らせる」形をとりますが、データが止まった場合は何も起きません。処理は走らず、エラーも出ず、通知もされません。静かに何もない状態が続きます。
つまり、「来ていないこと」を異常として扱うには、その前に「いつ、どこから、どれくらい来るはずか」を定義しておく必要があります。この定義がなければ、来ていないという判断そのものが成立しません。
「毎日ちょうど1,200件」のような正確な期待値は必要ありません。実務的には「平日の午前中に、A拠点から数百件規模で届く」程度の粒度でも、ゼロや極端な減少は十分に検知できます。
最初から精密な閾値を設計しようとすると、かえって着手できません。まずゼロを検知できる状態を作り、そこから調整していく方が現実的です。
4. データ品質にも当番が要る
監視の指標を決め、異常を検知できるようにした。ここでもう一つ、決めなければならないことがあります。その異常を、誰が受け取るのかです。
通知の宛先が決まっていない仕組みは、しばらくすると機能しなくなります。全員に通知が飛ぶ設定は、結局誰も見ません。特定の担当者だけに飛ぶ設定は、その人が休むと止まります。
実務では、毎朝決まったタイミングでの確認と、異常時の連絡先が決まっていれば、専任の監視担当者を置かずに運用できるケースもあります。必要なのは人員の増強ではなく、役割の明示です。
決めておくべきことは、それほど多くありません。
最後の2つは、見落とされやすいものの重要です。「データが3週間欠けていた」と分かったとき、その3週間のKPIをどう扱うかを決めていないと、報告済みの数字と再集計後の数字が食い違います。
「異常を検知する仕組みを作ったが、通知が多すぎて誰も見なくなった」という状態は、監視がない状態とほとんど変わりません。むしろ「監視しているから大丈夫」という前提が生まれるため、より危険です。通知は、対応する人が対応できる量に絞る必要があります。
5. 「気づけている」ことを、どう確かめるか
もう一段進んだ論点があります。監視の仕組みそのものが動いているかどうかは、どうやって分かるのでしょうか。
監視が止まっていても、通知は来ません。データが正常なときも通知は来ません。どちらも「通知が来ない」という同じ見え方になります。
そのため、異常時だけでなく正常時にも状態が見える形にしておくと確実です。毎朝「昨日のデータは4拠点すべて揃っています」という確認ができれば、通知が来ないことと監視が止まっていることを区別できます。
監視の仕組みが動いているか、処理が止まっていないか、拠点追加に追いついているか——これらはデータの品質というより、基盤そのものを維持するという論点です。第8回で改めて扱います。
整理すると、本記事（第5回）はデータの品質を維持する話、第8回は基盤自体を維持する話という関係になります。
6. データ品質は、自動的には保証されない
ここまでの内容を一言にすると、次のようになります。
保証してくれるものではありません。
基盤を導入すれば品質が担保される、という理解は誤りです。基盤ができることは、異常を見えるようにすることです。見て、判断して、対応するのは人です。
そしてこの「見て、判断して、対応する」という流れが設計されていない基盤は、時間の経過とともに静かに信頼を失います。数字は出続けるので、誰も止まっていることに気づきません。気づいたときには、現場が「あの数字は当てにならない」と判断しています。
現場が数字を信用しなくなる原因は、たいてい大きな障害ではありません。「一度、明らかに変な数字が出ていたのに、誰も説明できなかった」という小さな出来事の積み重ねです。逆に、異常が出たときに「これはB拠点のデータが3日欠けていたためです」と説明できれば、信頼は保たれます。
まとめ：品質を保つのは、仕組みと運用の両方
データ品質は、収集の設計で一度確保すれば終わるものではありません。稼働後に起きる劣化——欠損、遅延、異常値、マスタ不整合——は、エラーを出さずに進行します。だから、意図して見に行く仕組みが必要になります。
そして仕組みだけでは足りません。誰が見て、誰が対応し、その間の数字をどう扱うか。この運用が決まってはじめて、品質は保たれ続けます。
システムはたいてい正常に動いています。
ここまでは、データを正しく揃えることを扱ってきました。次回からは処理の話に入ります。8月のシリーズでは「データを何秒ごとに取得するか」を考えましたが、次に考えるのは、そのデータをいつ分析可能な状態にするかです。1秒ごとに取得していても、日次処理ならリアルタイム分析にはなりません。用途から処理タイミングを決める考え方を扱います。
何を監視すべきか、どの粒度で異常と判断するか、誰が受け取り誰が対応するか——データ品質の維持は、仕組みと運用の両方を決める作業です。まず「止まったことに気づける状態」を作るところからご一緒できます。
「ダッシュボードの数字が正しいか自信がない」という段階からでもご相談いただけます。
お問い合わせはこちら