よくある新人と先輩の風景
データ分析/AIの PoC で、新人に「データを増やしてください」と言われたことはないでしょうか？
たとえば、こんな感じ。
新人「いただいたデータを〇〇（バズったアルゴリズム）にかけました。Accuracy が〇〇%でよくありません。データ量が足りないからだと思います。データを増やしてください」
先輩「〇〇（オシャレなアルゴリズム）の前にさ、データはちゃんと見たの？」
新人「いえ、でも〇〇なら、みんな使ってるし、データ量の問題だと思います」
先輩「アルゴリズムとデータ量の前に、損失関数を最小化する特徴量を見つけないとダメなんじゃないの、って言ってんの」
新人「でも、データ量を増やすのも、施策のひとつですよね」
先輩「君は、自分の仕事をやりきる前にお客さんの工数を使え、って言ってんだよ。そんなこと言って競合に変えられたら、どうするの？ 部長に説明できる？」
新人「できないです・・・ でも、具体的にどうしたらいいんですか？」
先輩「いろいろな可視化の手法をためして、試行錯誤しなよ。それが君の仕事だよ」
世の中的には、すぐれた手法がたくさんあります。
しかし新人がよい分析結果を出せるかというと、時間がかかるのではないでしょうか。
どうやったら効率的に進められるか、というと、タイトルの通りなのですが、EDA の話をツラツラとポエムしてみたいと思います。
今どきのデータは、仮説検定がやりづらい
AI 案件の採用面接をしたことがありました。正解率がでなくて困ったらどうするか聞くと、よく返ってくるセリフの一つが
「お客様の業務をよく聞くこと」
でした。
私は、この答えを聞くと、「AI と IT の違いを考えてないのかなぁ」と思ってしまいます。
ポイントは、①完璧じゃないこと、②多次元性、の2点です。
完璧じゃないこと
True/False できれいに答えが出るシステム開発ならそれでいいんですけど。AI はたいていの場合でだいたいうまくいくやり方です。完璧じゃありません。
お客様が教えてくれる「お客様の業務」は、正確な答えじゃありません。
アンケートで１０段階評価をすれば参考になるかもしれませんが、正確さに欠けます。
データでの裏付けがないと、正しく理解したとは言えないのではないでしょうか。
多次元性
正確さを欠いた情報を仮説にしてしまえば、少しはやりやすくなります。教科書的には仮説検定にもっていって、仮説の成否を見ればよいハズ。
仮設検定の典型的な使い方は、科学的な実験で、
- コントロール可能な変数と目的変数を観察する
- １〜３個くらいまで説明変数を絞り込む
- 実験をする
- 仮説の成否を確認する
というやり方ではないでしょうか。
仮説が成り立たない場合、仮説そのものが間違っていたか、ランダムではなかったり、別仮説（別変数）の混入の可能性があります。
昨今のデータは、多次元量になっています。人間は完璧ではないので、変数の量が多くなると見逃してしまいがちです。
意外と多い？ テキトー項目データ
さらに、目的を考えずに、「とりあえず、取れるだけ取ってみましたー」みたいなデータが意外と多くないでしょうか。私も痛い目を見たことが何度かあります。
これも一種のノイズが混入しやすく、仮説検定を扱うには、厄介な問題ではないかと推測しています。
歴史的背景
歴史を振り返ると、探索的データ分析は、統計的仮説検定の偏重への警鐘と、その対策として提示されたようです。
以下、Wikipedia の統計的データ解析から「展開」の項を抜粋します。
テューキーは、統計学においては統計的仮説検定（確証的データ解析）が重視されすぎており、データを用いて検定すべき仮説を示唆することにもっと重点を置くべきと主張した。
要は、データから仮説を出そうよ、ってコンセプトですね。
このコンセプトは、多次元化したデータ、テキトー項目データを扱うときには、とくに有効と思いますが、いかがでしょう？
EDA を実施する、効率的なやり方 -仮説生成-
それでは、どのように仮説を検証していけばよいでしょうか。
データの項目から仮説を出す例がありました。
仮説を出した後に、可視化へと進めています。
さらに効率的なやり方 -ビジネスとデータの解像度をあげる-
データだけを見て業務担当に見せると、「そんなの当り前」と言われてしまうことがあります。昔の部下がやってました。
結果、「ビジネスとデータ、両方大事」という、いつものオチになってしまいがちです。
しかし、現実の仕事で顧客のヒアリングと EDA をまわしていくのは、かなりのパワーが必要ではないでしょうか。
解決策の方向は二つあると思います。一つはツールに頑張ってもらう。もう一つは重要なところを早く見つける。
前者は、いくつかツールが出てきているようです。アドベントカレンダーで触れる予定です。
後者は、ビジネスとデータを行き来しながら、解像度をあげていきます。この考え方は「解像度を上げる」というスライドに、深さ、広さ、構造、という３つの考え方が出てきます。
データ分析においての、深さ、広さ、構造は、なんでしょうか？
例えば
- 深さ： 現場でデータが生成される場面を見学する。リモートで工場見学をする。
- 広さ： データが生成される、仕事のプロセスを確認する
- 構造： 用語集を作成し、業務の概念とデータのカラムの関係を整理する
などがあるかもしれません。
分析麻痺症候群に気をつけながら、分析の目的に関係ある箇所に注目します。そこを深堀りしていき、仮説を作成します。
無駄な作業を避けながら、重要なところだけをピックアップすれば、より効率的になるでしょう。
このやり方はジュニアには難しいものの、ビジネスとデータ分析の経験が一定以上あると、こちらの方が早いです。また、マネジメントする人はビジネスの仮説を出し、ジュニアにはデータから仮説を出す、という役割分担をすると、納得感をもって仕事を進めてもらえるようです。
まぁ、私だけの特殊事例かもしれませんが、うまくいった方はコメント欄で教えてください。