とある小売事業者のPOSデータで売上1000円以上のレシート枚数を集計する必要があるときに、SQLだと条件句に以下のように書くと思います。
where 売上>=1000
ビジネスの実現場ではこの集計だと間違っているかもしれません。
もしPOSシステムのデータの仕様が以下であった場合、各仕様を考慮した集計ロジックを組まないと正しいデータ（1000円以上のレシート枚数）は得られません。
- このPOSデータの売上カラムには通常「税込み金額」が入っているが、ある種の商品の場合は「税抜き金額」が入っている。
- 代金の一部または全部がポイントカードのポイントで支払われた場合、POSデータの売上カラムには売上からポイント支払い分を減算した値が入っている
- 購入後に商品の一部の返品（キャンセル）が発生しているケースがある
- クーポンが使用されたり割引が発生すると「割引カラム」に減算金額が入る
※上記の仕様はあくまで架空の例です。実際のシステム事例ではありません。
正しいデータを集計するには
先ほどのデータの仕様を知らないと、間違ったロジックを組んでしまう恐れがあります。事前にきちんと仕様書が整備されていて確認できるのであれば問題ないかと思いますが、必ずしもそうした状況であるとは限りません。仕様書自体が失われていたり、どこに管理されているか所在不明だったり、テーブル定義書のみなど一部しかなかったり、古いバージョンのものしかなかったりするなんてこともよくあります。
もし詳細な仕様を知らなくてもシンプルに集計ができるように、複雑な仕様を吸収してデータ加工されたデータマートがあるなら、そのマートの仕様を確認するだけで良いのですが。
そうしたケースで正しいデータを集計するには、まずは仕様を知っている、あるいは最新の仕様書を持ってる人を探すところからでしょうか。見つかれば問題ないですが、そうでない場合は自らデータの仕様を調査せざるを得ないかもしれません。
データを調べる場合、集計すると丸まった値になり明細レベルの情報が見えなくなるので、基本的にはローデータを直接チェックすることになると思います。通常と異なるデータ（売上と税額を見て税率がおかしいデータ、売上が0やマイナスのデータ、それらがあった場合の前後のデータの入り方）などが見つかると、知らなかった仕様に気づくかもしれません。
とはいえこうした作業を逐一するのは大変なので、データの仕様は形式知としてしっかり管理され、共有される状態にある必要があります。
正しいデータが集計されない状態だと。。。
しかし、データ集計を行う担当者が少数しかいなかったり、外部の業務委託者に丸投げされていたりする場合は、担当者が作成した集計コードに対して第三者等によるレビュー・検収・管理などがきちんと行われていないということが多く、結果としてブラックボックス化してしまっていることがあります。
分析を依頼する側も必要なのはアウトプットでそれを導く部品の詳細にまで興味がない、あるいは検収できるスキル・時間がないということが多いので、暗黙的に正しいデータであるとして確認を怠ってしまうことさえあります。
その場合、担当者がきちんとデータ仕様を調査して適切なロジックを組んでくれていればよいのですが、それも定かではなく結局は担当者次第の属人的作業になってしまいます。
また依頼自体が詳細かつ具体的でなく、依頼者と分析者で要件に関する認識の齟齬が発生してしまっているケースもよくあります。（売上データが欲しいけど税込みなのか税抜きなのかは指定されてなかったりなど）
もし担当者がデータの仕様を知らないあるいは誤解したまま集計ロジックを開発していると、集計結果も仕様が反映されていないものになっているかもしれません。またもしその担当者が退職・異動等でいなくなってしまうと過去のコードの所在も不明となり、このレポートの集計結果はどのようなロジックで出されたものか後任の担当が調査もできなくなる可能性も生じます。
一般的にはプログラムのコードは共有リポジトリ等によって管理され、誰かが変更したり更新したりしても判別・切り戻しできるようにバージョン管理等もなされてるかと思いますが、データ分析で扱う集計プログラムは、レポートシステムなどはともかくとして、複数名で共同開発するということはあまりなく、担当者が一人でアドホックな対応を次々にこなすというパターンが多いため、コードの管理も担当者任せになっているケースがあります。
さらに怖いのは誤ったデータを元にしたアウトプットが、誰もその誤りに気づかないまま広く出回ってしまうことです。
その数値を元にして何らかの判断が下されているならば、その意思決定は実は何の根拠もないものだったということになりかねません。いずれどこかで集計結果の数値に違和感を持つ人が現れたりすると、集計ロジックの再調査が行われ結果として分析側で謝罪することになったりおおごとになる場合もありえます。
正しいデータを集計できる仕組み作り
分析のために正しいデータを集計するには、データ処理のコーディングスキルや分析手法の知見だけでなく、取り扱うデータの仕様や定義に関する知見も必要になってきます。
データ仕様の知見は、データアナリスト個人の努力でなんとかする類のものではなく、またデータアナリストだけが知っていれば良いものでもなく、できれば依頼者側においても共通のナレッジとなるべきものです。どのようなデータが必要なのか、お互い正しく合意するためにも、企業としてチームとして蓄積・整備していかなければならないものでしょう。
まずはWikiなど情報共有の場を活用して、そうした知見を蓄積・共有していくのが一般的かと思います。しかしどんどん増えていくでしょうから、どこにあるかわからない、見てもらえないといった状況に陥らないように定期的に整理・メンテナンスも必要になります。
なお、その役割をデータアナリストが主として担うべきかどうかに関しては議論になるかもしれません。データアナリストはデータ仕様に関する知見は必要ですが、その整備まで担うとなると肝心の分析業務に支障をきたす恐れもあります。
個人的にはデータ管理者のような専任担当者を設置し、データアナリストやビジネスサイドおよび分析基盤エンジニアたちと密に連携しながらデータ整備を行ってもらうのが理想ではないかと思います。とはいえ、なかなかそうした要員を備えた企業は多くないと思われるので、当面はデータアナリストまたはエンジニア達がなんとかせざるを得ないことが多いのかもしれません。
