データ分析とインテリジェンス

データ分析実務におけるチェックリスト

■分析実務におけるチェックリストがないので作ろう

キャプチャがたくさんあるツールの使い方マニュアルや、抽象的な一般論が中心の専門書はたくさんあるのだけれども、実務において直面する様々な問題に関する情報があまり見当たらないというのは以前から気になっていた。もちろんそれぞれ必要なものではあるのだけれども、ある一面しか捉えていないのでそれだけでは足りない。

おそらく各人がその都度自己流で対応しているいわば職人芸の領域になっており、特に初学者は近くに教えてくれる人がいないと自己流に陥りやすく、なんとなく目先の仕事はさばけているけれども実はまだまだ無駄が多かったり違う会社に行ったら通用しない、なんてことにもなりかねず、社会全体として考えると大分無駄な時間が費やされてるのではないかと思われるので、様々なチェックリスト(と言う名の「自分の失敗事例集」)をまとめるのは有用だろう、ということで書き始めた。

このチェックリストはきっといつまでたっても未完成のままで、新しい問題に直面するたびに追加していくことになるが、こんな失敗があると教えていただけると嬉しい。

■インプットファイル

正しいインプットファイルを手に入れたとしても、入力するファイルを間違えてしまえば元も子もない。明らかにサイズが違う、項目名が違うので読み込みに失敗するなどはすぐ気が付くかもしれないが、凡ミスながら致命的なエラーとなりえるので細心の注意を払う必要がある。ファイルの入手についてはデータを受け取る際に気を付けることデータを受け取ったらチェックすることを参照のこと。

ファイル名は正しいか

まず最初に、ファイル名を確認するのは基本。意図したファイルが読み込まれていなければ結果が違うのは当然であり、間違えが発覚して原因を調査する際に真っ先に疑うべき項目。紛らわしいファイル名を付けると見逃しがちになるのと、各人がそれぞれ独自のルールで動くと勘違いを起こすので、最低限チーム内での共通認識は必要。

ファイルの中身は正しいか

定型処理の場合は同じファイル名を使いまわすことが普通であるが、いつもと同じファイル名だから問題ないと油断していると危険だ。最新のファイルに上書きしたつもりで上書きされていない、上書きはしたがさらに別のファイルを上書きしてしまったせいで中身が違う、別の誰かが知らないうちに別の(大抵は古い)ファイルに置き換えてしまった、ということが起こり得る。最初の数件だけでよいのできちんと自分の目で確かめる。

変更が反映されているか

ファイル名は正しい、ファイルの中身も正しい、でもアウトプットが違う。その時は「インプットファイルAを読み込みテーブルAに格納、その後インプットファイルAを修正したが読み込み忘れてテーブルAはもとのまま」、となっていないかを疑う。次に、「インプットファイルAを読み込みテーブルAに格納、その後インプットファイルAを修正したのでテーブルBに格納、でもその後の処理ではテーブルAを読み込むようになったまま」になっていないかを確認する。中身が正しければこのいずれかで大部分は解決するはずだ。対策は、修正したらすぐに読み込みなおし、テーブルを変更したらその後の処理もその場で修正する。後でやろうと思うと必ず忘れる。データ量が多すぎて取り込みに時間がかかる場合は、そもそもファイルの修正をしなければいけない理由をなくすことから始めよう。

データ型は正しいか

よくあるのは文字列型のデータを数値型で読み込んでしまっている。そのファイルで完結する処理であれば問題ないこともあるが、あとで結合してもうまくいかない場合はこのケースが考えられる。後でひっくり返すよりも取り込む段階で確認しておくほうがよい。また、同じ店舗コードを使っていたとしても、自社では10桁、クライアント企業では12桁といったように管理上の問題や過去の遺産などの理由により違う場合がある。事前に確認してどこかで揃えておくのが望ましいとはいえすぐに変更するのは難しいので、最初の処理で桁を揃えるか、両方とも数値型で読み込むするなどして型を揃える。

前処理に時間がかかりすぎていないか

エラーにはならないとしても大量に処理をしなければならないとなると時間もかかればミスも増える。入手する時点、あるいは取り込む前の処理で負担が軽減できないかを試みるべき。

余計なデータが多すぎないか

前処理に時間がかかりすぎる原因の1つ。ごく一部分だけが必要なのに不要なデータが大量にあるせいで余計な時間がかかる。まずは入手段階で事前に不要なデータを渡さないようにできないかを調べる。システム連携されていて簡単には手が出せない、相手側のスキルやリテラシーが低くて対応してくれないというような場合は、受け取った後に一段階はさんで事前にバッチなどで処理してから、必要な部分だけを使うようにできないか考えよう。なお、余計なデータを抱え込むと手続が面倒になったり、流出リスクを背負い込むなど手間だけ増えるがなんの利益にもならない。修正することがお互いの利益になるということは大きく強調してもよい。

■結合

INNERJOINで件数が増えていないか

INNERJOINであれば2つのテーブルの共通部分が取られるので件数は同じか減るはずだが、なぜか結果はもとのテーブルより増えていることがあるが、これは通常意図した結果ではない。原因は1つで、結合キーが「2つのテーブルの双方で」重複しているからだ。IDでの絞り込みのように、結合キーが重複するべきでないのであればユニークになっているのかを確かめる。レコードがユニークなのに結果が正しくなければIDと月の組み合わせで結合しなければならないところ、IDだけで結合してしまったのでIDが重複になっているというように結合キーを疑う。

LEFTJOIN(RIGHTJOIN)で件数が増えていないか

LEFTJOINについてはテーブルAにテーブルBをLEFTJOINしているならば、テーブルAの件数が得られるはずであるが、もし増えるようなことがあったテーブルBに結合キーの重複があるか、INNERJOINと同様に結合キーに不足がある。RIGHTJOINも同様。

フラグの立て違いはないか

IDに対してある種の条件を満たすかどうかのフラグ(商品の購入者フラグや除外対象者フラグ)を立てるというのはよくあるが、この時の条件を間違えるケースがままある。フラグを立て間違えると真逆の条件を指定することになりまったく違う結論になってしまうので危険度が高い。特に慣れないうちは、1・LEFTJOINかRIGHTJOINはどちらかしか使わないようにする、2・条件を見たす場合にフラグを立てる(is not null then 1)のか、あるいは(is null then 1)のどちらかしか使わないようにする、を守った方が良いだろう。

複数テーブルのJOINが遅くないか

複数テーブルのJOINを行う際、実行はオプティマイザーにより最適化される、とは言われるものの実際にどうなっているかはよくわからないところがある。3つのテーブルをIDをキーにしてINNERJOINすることを考えよう。1つのテーブルが100人程度の非常に小さいテーブル(例えばキャンペーンの当選者を想定すればいい)、残り2つが大きいテーブル(会員マスタとPOSデータのような)だとする。当然1つのSQLでまとめてJOINを書くことを考えるのだが、なぜかとても時間がかかる場合がある。

対処法は「100人のテーブルと会員マスタをまずJOINして、その次にPOSデータとJOINする」だ。このように小さいテーブルを先に作るようにしておけば、劇的に早くなることがある。おそらく大きなテーブル同士のJOINを行わなくて済むからだろうと推測されるのだが、このあたりは調査中。とはいえ早くなる方法があるならそちらを採用すべき。ただし無暗にテーブルを作成しすぎると収集が付かなくなるので、処理が軽ければ不要になったらすぐ消しておく。また必要になったら作り直せばよい。

■ソート

ソートキーは正しいか

テーブルにあるカラム名ならselectになくてもエラーにならない。当初「都道府県」でソートしたところ不正なデータがあったので「都道府県2」というカラムを作成し、クレンジングしたデータを入れたがうまくソートがされなていない。なぜかと言えばソートキーが「都道府県」のままだったからだった。

全然違う名前だと気づくことでも、このように似た名前だとうっかり見逃してしまうことになるので、まずソートした場合は意図した結果になっているかを最初の数件でもよいから確認すること。これでほぼミスを防ぐことができる。油断してこの簡単な確認を怠ると、万が一の場合に支払うコストが高い。

昇順と降順は正しいか

よくありがちで、ソートの並び順が逆になっている。集計結果だったらあとでExcelでソートしなおせば済むが、スコアリングの結果上位100人を抽出する、という場合においては並び順が逆ではとんでもないことになる。これも目視で確認というのが確実。SQLに慣れているからとコードだけ見て結果を確認しないのは油断であり怠慢である。

■集計

集計単位

時間別・店舗別・都道府県別・全店舗など様々な単位での集計が行われるが、集計単位には気を付けなければならない。のべや売上は合計すれば同じになるが、UUはその単位ごとで集計されるため、細分化されればされるほど合計値は増えていく。そこまでなら理解している人は多いのだが、それでも間違えるケースとしてはまず店舗単位での集計を行っていたので、そのデータを都道府県単位でまとめようとして、そのまま都道府県単位で集計を行ったら売上は正しかったが1人当たりの売上が大幅に小さくなってしまった、というような場合だ。これはIDが店舗単位ではユニークではあっても都道府県単位ではユニークでないため、そのままIDをカウントすると大きな値になってしまったということ。まずは都道府県×IDで集計してこの単位でユニークにしてから都道府県単位の集計をする、という手順を踏まなければならない。もちろんsqlであればcount distinctを使えばよいのだが、集計ツールによっては使えないことがある。

■課題は永遠に残り続ける

ざっと思いついた範囲で書いてみたがもっとあるはず。とはいえ全て出しつくすまで待ってもしょうがないので公開してしまい、思いついたり新しい問題にぶつかったりするたびに都度更新していく。

実務で起きる問題については他にもデータ分析がプロセスであることを意識しないと見えないことデータ分析のためのSQL 目次などいくつか途中なままになっているが、他にもデータハンドリング(前処理)なども書く(予定)。

このエントリーをはてなブックマークに追加

タグ:仕事 分析


最新のブログ記事5件

すごい人工知能が開発されたら起きる未来について
csvファイルの扱い方
仕事を早くすることのメリットについて
機械学習はアルゴリズムを使ったPDCAである
データ分析がプロセスであることを意識しないと見えないこと

ブログトップ > データ分析実務におけるチェックリスト