解像度を上げると「データ分析」はもっと幸せになる　現役データサイエンティストが教える、データ分析の4つの要素

データ分析に求めるものは、人によって違う

松村優也氏：「データ分析の解像度を上げたい」というタイトルで発表します。よろしくお願いします。

まず自己紹介です。松村優也と申します。Wantedlyという会社の推薦チーム（レコメンデーションチーム）で、データサイエンティストとチームリードをやっています。情報検索の分野と機械学習に興味があります。本日が2020年での初登壇になります。

まずはみなさん、データ分析はうまくいっていますか？　自信を持って「私はデータ分析うまくやっています」と言える方……って別に聞かないですけど。僕は、正直そんなに自信を持って言えないです。

そこでまずは「こんな経験ありませんか？」ということで、「苦い経験たち（フィクション）」をまとめてみました。これらは別に僕が体験したことではありませんが。

例えば「新設のデータ分析チームができました」というときに、ビジネスチームからすごいSQLの作成依頼が殺到してしまって、「本来したかったデータ分析ができない」といった苦しみを味わっている人は、いるんじゃないでしょうか。

あるいは上司やマネージャーから「先月の売上はいくらだった？」って聞かれて「〇〇万円です」と答えたら、「で、結局それってどうなの……？」って。なんか不満そうだったり、聞かれたことには答えたはずなのに、とか。こういう不一致もあるのではないでしょうか。

u++さんが居るのでここでKaggleのことを言うのは怖いのですが、Kaggleでソロ銀を獲得していたから、十分なデータ分析力があるって判断して、データ分析チームにインターンの学生を呼んだけれども、いまいち活躍できなかったみたいな。こういうような苦い経験ってあるのではないかなと思っています。

これがなぜ起きるかといったら、結局データ分析という抽象的な概念に対して、人によって求めるものがズレるから。期待値にズレが生じているから起きているのではないかというのが、今回のトピックです。

さっきのデータ分析の例で言えば、データ分析チームの人は、もっといろんな意思決定に関わるような分析をしたいと思っているけれども、ビジネスチーム的には、いろんなSQL、数字を出してくれるものだという気持ちだったりします。

2番目の例で言ったら、ただ数字を出すだけではなくて、上司としてはもっといろんなインサイトが欲しかったのかもしれない。そういうところで、期待値のズレが生じているという問題があると思っています。

データ分析って何？

結局、データ分析の「分析って何だろう？」というところで、ざっと調べたんですけど、広辞苑によると、分析というのは「ある物事を分解して、それらを成立させている成分・要素・側面を明らかにすること」らしい。

よく見るやつです。データサイエンティスト協会のスキルセットにおける、データ分析の用語という意味では、ちょっとズレるかもしれませんが。こういうものがあります。

（データ分析については）いろんな人が解釈していると思って、Googleで検索してみました。すごくなんだかバズワードを感じる検索結果で、「データ分析とかデータサイエンティストはこうあるべきだ」みたいなブログが無限にヒットしました。

絶対的な正解はきっとないので、自分なりに理解・解釈して解像度を上げて、普段の業務に利用していくのが重要かと思いましと。このように、ちょっと年末年始にデータ分析に対していろいろと想いを馳せていたというのが、今回の発表のきっかけです。

いろいろと調べて、自分の中で一番スッキリしたデータ分析についての理解を紹介します。プラスアルファ、ちょっと自分の解釈も入れています。

分析とは「A or B」の解を出すこと

みなさんご存じKashidaさんのnoteが、僕としては一番スッキリしました。Kashidaさんのnoteでは、分析という言葉を一言で言うと、「『A or B』という問いに対して解を出すこと」と定義していました。

このnote、以前は有料だったんですけれど、この年末か年始に無料で公開されているので、ぜひ読んでもらえればと思います。これを読めば、今日の僕の発表はいらない気がします。

「A or B」問題。「A or B」という問いに対して解を出すことは、どういうことか。例えば、「ここのUIの変更施策がよかったか？」というのはYesかNo。「A or B」というかたちで答えられるのは「A or Bの問い」と定義します。

例えば「この予測モデルで作られるランキングって、今よりいいですか？」という問い。ちょっと無理やり寄せていますが、これもYes or Noで答えられます。

答えは別に2択でなくてもよく、「ユーザーの継続率と一番相関が高い行動は何？」に対しては、インプレッションかもしれないし、ほかの指標があるかもしれない。というように、複数あってもいい。こういうのも「A or Bの問い」といっています。

事実となる数字が必要

「A or B」という問いに対して解を出すにはどういうものが必要かというと、こうなっています。「このUI変更施策がよかったか？」という問いに対して、まずデータ分析という部分から始めるとしたら、集計とか数字を出すと思います。「PV数が120パーセントになった」というような「事実＝数字」がまず必要です。

これだけでは、それ自体がこの施策が成功だったかどうかについては言えません。例えば「実はいつもの施策だったら、毎回PV数200パーセントになっています」ということなら、これは失敗になるかもしれない。逆にいつもは105パーセントぐらいしかPV数が上がっていないのであれば、今回は成功と言えるかもしれない。

基準がなければ解は出せない

つまりなにか基準がないと、この問いに対する解は出せなくて、それを「判断基準」と言っています。例えば「これまでの施策ではせいぜい105パーセントにしかならなかった」「今月の目標はPV数を140パーセントにすることです」「今月中にあと施策は3つ実施できる」みたいな、その時の状況に応じた基準があって、それを踏まえた上で「このUI変更施策がよかったか？」という問いに対して、「PV数が120パーセントになったのでYes」と答えられる、ということを言っています。

このように、「事実＝数字」と「判断基準」を用いて「A or B」という問いに対して解を出すのがデータ分析と定義されています。つまりこういう（提示したプレゼン資料に書かれている）4つの要素があるということです。データ分析に必要な要素は4つあって、1つ1つ軽く説明します。

「A or B」という問い

まず1つ目、「A or B」という問いです。そもそもこれがなかったら、データ分析は始まりません。よくビジネス課題を分析課題に落とし込む翻訳者とか言われたりするんですけど、それがここに当たるのではないか、この要素を作り出す能力というのがここなのではないかと思っています。

抽象的な（雑な）問いをここまでブレイクダウンして、この「A or Bという問い」を設計する必要があると思っています。最初の例でいうと、「先月の売上いくらだった？」というマネージャーの問いに対して、分析者は、実は「今、この売上は伸びていると言えるのか？」というところまで落とし込んで回答を出す必要があるのかもしれません。このように本当に知りたいことを推し量る能力が必要なのではないかと。

もちろん、そもそもデータを集計して「事実＝数字」だけを出すだけでいい場合もあると思っています。先ほどの例で言うと、ビジネスチームからのSQL作成依頼の中には、本当にただお客さんに出す数字がほしかっただけかもしれないので、そこは判断して、そうすべきではないかと思っています。

事実＝数字

「事実＝数字」の部分ですが、こちらは存在する実データに基づく客観的事実ということです。人によって変わらない客観的事実で、いわゆる一番分析っぽいところだと思っています。

これはいわゆる手を動かす能力だと思っていて、その数字を出すというところで、SQLデータを集計する能力だったり、モデリングだったり。事実やデータに基づいて予測するとか。それを表すものを作るという意味で、「Kaggle力」と言われるのも、これに当たるのではないかと思っています。

正しく事実を出す、あるいは導出できる環境を適切に作るという意味では、「データエンジニアリング力」が、ここに入ってくるのではないかと思っています。

判断基準

「判断基準」については、さっきも言ったとおり、状況によって変わるものです。PV数が120パーセントになったからといって、常に損失とか成功とは言えません。その場におけるいくつかの前提条件に基づいて導出されるものです。

ここはけっこう一般的に忘れがちだと思っていて、「分析して」と言われたときに、「数字が何パーセント上がりました。去年に比べて何倍です」と答えたところで、結局それはどうなったかというのは判断できない。ここの判断基準をきちんと設けることで、意味のあるデータ分析、意思決定につながる分析ができるのではないかと思っています。

こちらはもちろん、状況に基づいていろいろ変わってくるので、ドメイン知識は超重要です。論理的な思考力が求められると思っていますし、面倒くさいことに、みんなの納得感も大切だと思っています。絶対的な正解がないので、きちんと人に説明して意思の疎通をとるのが、とても大切になってくると思います。ここをないがしろにしたら、逆の意思決定をしてしまうことさえあると思います。やばいですよね。

「A or B」という問いへの回答

最後は、「A or B」という問いへの回答です。「判断基準」に基づいて「事実＝数字」から「A or B」という問いに対して導出するものです。

もちろん、とりあえず「Yesです」と答えるだけだと人に伝わらないので、それをきちんと人に伝える能力、可視化などを駆使して説明可能な形にする能力を求められると思います。

またちょっとadditionalですが、その分析結果から、さらにインサイトを求めるというところで、別の仮説例えば次の「A or B」という問いのヒントになるようなものを見出す能力があると、さらに差別化できるのではないかなと思っています。

4つの要素に着目すれば、意思や期待値のズレは減らせる

ここまでデータ分析を4つの要素に分解して、それぞれについて説明＋それに必要な能力を紹介してきました。このように4つの要素を、データ分析に関する普段の業務とかチーム編成とか、育成であったり採用であったりというようなときに意識して、そのときそのときでどの要素に注目すべきなのかちゃんと考えていけば、その意思や期待値のズレは減らせるのではないかと思っています。

注意です。最初に言ったとおり、データ分析という解釈に対して正解はありません。これはあくまで僕がスッキリした解釈ですから、正解があるわけではないと思っています。

今日、伝えたかったこと

最後に今日伝えたかったこと。今話したように、「データ分析」という抽象的なものの解像度を上げて、自分なりの解釈でいいので明確な定義を持っていれば、もう少し「データ分析」とふだんうまく付き合っていけるのではないかと思っています。

さらに言うと、社内ないしはチームにおいて、「データ分析」というモノに対して共通認識を持っていれば、もっと幸せにデータ分析できるのではないでしょうか。

……というメッセージで、私の発表は終わらせていただきます。ありがとうございました。

（会場拍手）