不正値は全部きれいにしたいけれどもそれは無理
不正値を検知することができたら次はその不正値をどうするか。
全ての不正値を修正してデータを完璧な状態にすることが理想だ。しかし、現実的にはそんな時間もなければ、費やすリソースに見合うだけの恩恵は得られない。
それどころかほんのわずかなずれを修正するために膨大な時間を費やして他の仕事を止めてしまってはむしろ損失になってしまう。
なのでどこかで折り合いをつけることになる。今回は不正値を検知したらどうするかを考える。
不正値を検知したらまずやること
どうするかを決める前にやっておきたいことが２つある。
不正値の内容を把握し、原因を調査する
まずは何が起きているかを知る必要がある。あるべき値に対していつどのような不正値がどれぐらい発生しているかを把握する。
併せて起きた原因を探る。限界はあるがある程度でも絞れておけばこのあとエンジニアが調査する際の手助けになる。
エンジニアに連絡する
不正値は「システムではエラーにならないが利用するには正しくない値」とも表現できる。なのでエンジニア側では気づいていないかもしれないので連絡する。
原因が解明ないしは推測できているのであれば一緒に知らせておくといい。いきなり「値がおかしい」だけ伝えたところで言われた側も困る。
この段階ではまだ修正の要求はしない。理由は後述するが、検知した全ての不正値の発生を止めるのは現実的ではないからだ。
不正値をどう扱うかを決める
ここからが本番。検知した不正値の扱い方にはいくつか選択肢がある。限られたリソースの中で優先順位を付けて対応していくことになる。なのでどれが正しいかは決められない。状況に合わせて選んでいくことになる。
その選択肢は大きく分けて次の３つに分かれる。
- 不正値が発生する仕組みを修正する
- 不正値の発生はそのままにして整理する
- 不正値のまま放置する
不正値が発生する仕組みを修正する
最初の選択肢は、仕組みを修正して不正値の発生を止めることだ。不正値が発生しないようにできるならばそれに越したことは無い。しかしそのためにどれぐらいの労力が必要なのかが問題になる。
ユーザーがフォームに入力する際に制限が掛かっていないのが原因であれば簡単に修正可能かもしれない。システムのどこかで起きているらしいが原因すらすぐにはわからないかもしれない。
修正するにしても整備側がエンジニアに依頼だけして負担を全部担わせるのはおかしい。
なので、以下の場合のどれかに当てはまらないなら仕組みを直すことを考えるより先に別の選択肢を検討した方がいいだろう。
- 修正しないと重要なデータが正しく取れない
- 開発中なので修正がしやすい
- リリース済みでも修正が簡単
また、仕組みを修正した場合、修正前後でデータの仕様や傾向が変わってしまう。なので「修正前にできた不正値はどうするのか」も併せて考える必要がある。
過去のデータを全て正しく修正できるのであればそれでよい。しかしほとんどの場合はその後の整理の段階で帳尻を合わせることになるだろう。修正する前までは処理1、それ以降は処理2を別々に施してUNIONする。
頻繁に指標や修正が入るプロダクトや機能のリリース直後であれば安定する以前は切り捨ててもいいだろう。中途半端に残すとしばらく経って「この時期だけおかしいけれど何があった？」と間違い探し大会が始まる。残すならメタデータとして記述しておくこと。
不正値の発生はそのままにして整理する
すでにリリースされて時間が経っているシステムのどこで不正値が発生しているのかわからないと修正するにしても影響の調査と関係者との調整に時間と人が取られる。作られて時間が経っていれば詳細を把握している人もいないかもしれない。
なので仕組みが修正することだけでなく、整理する際に吸収できるか検討しよう。メリットは仕組みの修正に比べるとコストがかからない。整備側だけで完結できるならばなお良い。
例えば、年齢に不正値があっても範囲を決めてそれ以外は全て「その他」でまとめてしまえばどんな値が入ってきても対応できる。ただしその他に含まれるのが1割2割と出てくるようならこれはそのまま放置するわけにはいかないので限度はある。
不正値のまま放置する
不正値が発生するのがごくわずかで影響が軽微であるから無視できる、あるいは滅多に使わないデータである場合はあえて放置することも選択肢の１つだ。
デメリットはそのデータを利用する際に整理を行うならクエリが長くなること。なのでそのデータの利用頻度次第。
この場合も何が起きているかはメタデータとして記録しておいた方がいい。
修正や整理は完璧にはすることは前提にしない
不正値をどうするかで重要な点を１つ。修正や整理を行う際に、全ての不正値を取り除くことには固執しない方がいい。そのほんのわずかな事のために膨大なリソースを費やすならば他のことに使った方がいい。
ただし、どこまで許容するかを決めるのは整備する側ではなく分析に利用する側だ。「1%の誤差を許容すればすぐに使えるが完全なデータが必要ならば当分使えない。整理するなら時間がかかるがどうするか」と状況を正確に伝え、希望を聞いて実現方法を一緒に考えよう。
あとはやるだけ
やることが決まったら最後に必要なのはどうやるか。仕組みを修正するのはエンジニアの領域なので触れない（わからないので触れられない）。整理についてはいくらか経験があるので次に書こう。
