データ分析のためのSQL】データ更新1つだけでも結構な問題だったことに気づいたデータ分析プロセスにおける収集フェーズはいかにしてデータを集めてくるかが主題だが、データエンジニアがそのためのデータをしっかり作ってくれる恵まれた環境にいる人は少なそうだ。いうことは分析者側が多かれ少なかれデータがどのように作られ、保管されているかを知り、改善のために関わらざるを得ない場合が多いということでもある。そこでデータアナリストというかアナリティクスディレクターの目線でデータマネジメントについて考えていた一環でデータ更新をする際におきることを考えていたところ、日常の風景なので簡単かと思ったら結構な問題だったことに気づいたので記事としてまとめることにした。知らない間にマスタデータが更新されているのに周知されない大分前に更新されたことは記憶にあっても記録が残っていないので何かが起きたことしかわからない更新されるべきデータを誰がどう管理しているのか誰もしらないといったことに出くわしたことはないだろうか。週ごとに売り上げを集計しようとしたところ開店日のデータがきちんと取れず、さてはエラーかと大騒ぎ。半日かけて調査したところ、間違えていたので担当者が自分で1日直してましたというオチ。新規開店した店舗が登録されておらず集計したくても集計できないので追加を依頼しようとしたら、あのへんの部署なのだけれど誰に聞けばいいかわからないで右往左往。してこんなことになるのだろうか。データ更新における確認と周知ルールを決めようエンジニアからするともっと技術的な問題はあるのだろうが、利用者する立場からするとデータ更新では更新そのものよりも知らないところで行われて知るべき人が知らないということが問題になるほうが多く、大半のことは事前の確認と周知があれば防げるのではないか、というのが実感だ。確認と周知がされないかというと話は簡単で、確認と周知が必要なことが周知されていないからということだ。やるかやらないかを個人任せにすると、うまくやってくれる人がいればいいがその人がいなくなったら途端に動きがとまる、では心もとない。更新するときに確認や周知するべきことをルール化した方がいいのでは、ということで主に「店舗マスタの更新」を例として何をルール化するのがよさそうかをまとめる。変更が必要かまずは、変更の理由だ。根本的には「正しいデータ」を持っておくことはあるのだがそれは前提として、今回の変更はなぜ行うのかの周知は”あったほうがよい”。「なぜ変更が必要か」は知らされなくてもこれ以降に実際に変更されるデータについてさえわかってさえいれば作業自体はできる。「店舗の開店日が1日おかしいから」のたったそれだけを言わないがために混乱し、知らない人が時間を無駄にし、無用な対立を生んでいるケースは実に多い。何がどのように変更されるか新規店舗があるから追加するとテーブルが更新されることは知らされても中身がどうなっているかは知らされないでは困る。具体的に何がどのように変更されるのかも周知される必要がある。それはどれぐらいの量があるのか、特殊な例はないのかといったことはもちろんで、今までなかったカラムや値が登場するならなおさらだ。新規開店でレコードが増えたりすれば見れば気づくが、突然カラムが増えた場合は増えたことはわかってもどのようなデータが入っているのかはすぐにはわからない。したがって、どのような定義でどういったデータが入っているかは作った当人に明確に提示してもらう必要がある。これは作られたその時が一番良い。後で聞いても作った本人が忘れていたりする。自分で調べればいいというのはデータの量が多ければ多いほどナンセンスで、区分であればマスタがどこにあるのか、数値であればどんな範囲に収まればよいのか、今はなくても将来入る予定のデータはないか、Nullなのは正しいのかエラーなのかなど聞けばわかる話を探らなければならないのは時間の無駄であるからだ。第一、何が正しい状態なのかがわからない。店舗マスタ以外でも行動ログで今まで収集していなかったデータを増やしたり逆にやめたりしたのを大分後になっておかしいことに気づくとか、POSデータで商品カテゴリの名称を途中で変えたりしたためにidは同じなのに違う値が入っているとか、もっと極端なのは商品コードを別の商品で使いまわしているから時期によって全く違う商品になっているとか、システム的にはエラーが起きないからと放置されてしまうと使う時になって大惨事を引き起こしかねない。周知がされていれば気を付けることができるし、早めに確認できれば変更を止めることもできる(かもしれない)。何が起きたら更新するか何が起きたら更新するかも確認と周知が必要な項目だ。店舗マスタなら新規開店時のレコード追加、閉店時の削除またはフラグの更新、店舗名の変更はもちろん定休日や臨時休業、店長の交代などなど大手チェーンなどは非常に頻繁な更新があるのは想像がつく。記入ミスの修正も更新だ。これがあいまいだと忘れたり更新されていなければいけない時に更新されない。「新規店舗が開店したので売上どうなっている?」と聞かれて「マスタに入っていなかったからわかりません」と答えた経験が無い人は少ないだろう。更新の責任がデータを利用する側にないと直接の影響が出ないため忙しいからと先延ばしにされたりする。いつ更新されるか変更が必要であってもそれは重要度や緊急度で判断すべきで、必ずしも即時に直さなければならないわけでもない。トランザクションのデータは早く直さないと間違えが蓄積されてしまうので早めに対応するのが望ましいとはいえ、重要でない項目であれば後回しになるかもしれないし、閉店フラグは閉店が決まった時ではなく実際に閉店してから立てるべきだ。それも閉店翌日にやらねばならないわけでもなく、使い方によるが1週間に1度でも困ることはさほどないだろう。「新規開店の場合は〇日前までにレコードを追加する」といったことは決めておいた方がよさそうだ。いつなのかわかっていれば「このデータはいつ更新されるのか」なんていちいち問い合わせする必要もない。誰が変更を行うのか部署でも人でもいいが誰がやるのかは明確にし、周知しておきたい。マスタなどエンジニア以外が更新に関与するときは特に放置されやすい。誰が変更を行うのかの周知は意外と盲点になっていて、一応担当が決まっているけれどもそれを当人以外はしらないのでは意味がない。店舗や商品マスタのように営業が更新を担当している場合、忙しいことを言い訳に後回しになり忘れらされるのでエンジニアや分析者が責任を持つことは選択肢にあってもよいのだが、では全部をやるべきかというとそうでもない気がする。追加変更の依頼を誰にどのように行えばよいのかおかしなデータを見つけたので問い合わせをしたり、追加で登録をしたかったりしたときに、速やかに担当者に伝えないと忘れるし精神衛生上もよろしくない。このデータの場合は誰にどう聞く、とどこかに書いておけば済む話なのだが、なぜか実践しているところは少ない。いつ誰がどこにどのように変更を周知するのか変更する人は決まっていても確認と周知については忘れ去られていることが多い。事前に周知がされない。データごとにその都度決めようとしてもあとでうやむやになるので、タイミングとして一番良いのは変更の”可能性”が決まったその時だろう。知らないところで勝手に変えて「もう作ってしまったからしょうがない」を防ぐには、作る前に介入する以外にない(権力で強制する場合を除く)。ルール化しないと変更担当者は変更したことで自分の責任ではないと言い、ユーザー側は知らされないことで問題視することで仲が悪くなるですめばまだよいが、ひどいとコミュニケーションすら取らなくなる。事前事後に周知することまで含めて変更の仕事であると考えるのがよいのではないだろうか。一緒に変更されるべきデータは何か時間もないからとりあえず一番重要そうなデータだけ追加しておけばいいや、でやっているとあとで大体困る。他のデータとの整合がとれなくなるからだ。店舗マスタに新規店舗を登録したけれども、店舗idと支店idを対応させるテーブルにデータが追加されないからnullになってたりする。使う側が気づいた時に変更していないだけなのかエラーなのかもわからないから調べることになり無駄に時間がかかる。どのデータが一緒に変更されなければならないかを事前に確認しておき、その条件が満たされていなければ変更を許可するべきではない。変更された項目が他のテーブルや既存のデータにどのように影響するか1つだけも値を変えたらそのレコードでのJOINがうまく行かなくなり、nullになることでエラーになってしまうといったことを避けるには、正しく変更するだけでなくその影響も考えないといけない。新規店舗を追加したからそれでいいでしょ、と考えるのは理解できなくもないが、これもきちんと確認と周知をしないと後々非常な面倒になる。店舗マスタで店舗名を変えたがトランザクションデータの値はそのまま、別のマートは最新のマスタが更新されるので全部変更といった違いは集計を行うと変更直後だとみんな覚えているからよいのだが、ここ数年の店舗別で集計なんてことをするとずれが起き、当時のことなど忘れていたり詳しい人がもういなかったりで調べるのも大変だ。いった影響があるかを考え、場合によってはいっそ全て入れ替える、影響が大きすぎればいったん更新を止めるといった選択もありえる。早い段階で介入が必要なのだ。変更後に問題が起きないかどうかを確認するためにはどうなっていることが必要か「データの変更で想定されていたところは正しく実現できているか」をあらかじめ確認しておくことも重要だ。店舗を追加したはずなのにダッシュボートに出てこないのは実はもう1つ別のカラムが影響していてそちらが正しく入力されていなかったとかはこれでかなり防げるだろう。だれがどこにどのように記録するのかそして忘れてならないのは、これらの記録は残しておくべきだということだ。人の記憶は曖昧だし、一度作ってエラーが出ずに動いていれば細かいことなどすぐに記憶から消去される。どんなに細かくても記録しておくのが望ましい。書くことはたくさんあるが、書く時間に比べれば書いておかないことで失われる時間は比較にならないほど長い。理想はあらゆるデータの変更であらゆる確認と周知を行うこと以上、確認と周知をすべきことについて列挙してみた。理想はあらゆるデータの変更であらゆる確認と周知を行うことであるが、これには膨大な人的リソースが必要になるのは明白で、そこまでデータマネジメントに金を投資しようという企業は少ないだろうし、すべてを同様に行うべきかというと多分そうでもない。何をどうやっていくかの優先順位を決めなければならないが、何が一番良いかはその会社と人によるのだろう。うまく決めるためのフレームワークなど作れればよいがこれは別の機会にしよう。データ更新1つとっても大問題だったいままでやってきたこと、考えて来たことをまとめてみたら、ちょっとしたデータ更新1つでも思っていたよりはるかに大問題であったことに気づいた。言い換えれば普段いかに適当にやっているかということでもあり、反省。「うまくやろう」な話は実に地味なのでよほど見識がある人以外からは評価されづらいが、やらないと自分がうまくやれなくなるのでやらざるを得ないのはアナリティクスディレクターもデータマネジメントも事情は一緒なのかもしれない。分析も理解できていないのにさらに世界が広がって益々中途半端になってる感はあってもわりと楽しいので学べることは学ぶつもりだが、併せてアピールする方法も考えなければならず、さらに考えることは増えるのだった。