「分析の"3C"」という名のお作法（我流）

こんにちは。この度はYMプロダクト部長からアドベントカレンダーへの寄稿のお誘いを受けて、人生で初めてブログなるものを書くことなりました。

（この記事はユアマイスターアドベントカレンダー2020の18日目の記事です。）

アドベントカレンダーというもの自体を寡聞にして存じ上げておらず、「そもそもアドベントカレンダーってなんやねん」という無知蒙昧の輩でございまして、ほかの方々の投稿をいくつか読ませていただきましたが、やはりエンジニア界隈発の遊びと言いますか、よろずテッキーなお話がみなさん多いなという印象。とはいえテクノロジーを語れるわけもなく、自分の引き出しをひっくり返した結果、「分析の"3C"」というテーマに落ち着きました。
勘の良い読者諸兄にあられましては、「3Cってなんか聞いたことあるな。あれでしょ？元マッキンゼーの大前研一さんが考案した、"顧客（Customer）、競合（Competitor）、自社（Company）の観点から市場環境を分析し、経営戦略上の課題を導く分析ツールのひとつ"だよね～（wikipedia感）」とお気づきになっていることでしょう。

まったく関係ございません。

「分析の"3C"」自体、オリジナルというか、僕が今までのデータ分析というものに長く携わってきた業務経験から得た経験則をテキスト化した概念ですので、ややこっぱずかしいですがお付き合いいただければ幸いです。

そも、分析とはなんぞや？

はい。来ましたね。読者諸兄にあられましては、「こいつ導入からいきなり禅問答みたいなこと言いだしたぞ」と思わず眉をひそめたことでしょう。わかります。
そもそも、「分析の"3C"」っていうものが自分の中で最終的に出来上がった背景に、この「分析」って単語自体が割りと乱暴に使われがちだったり、無意識下で実行していて決まった型みたいなものを教えられたことがなかったりというところがあるので、導入としてその部分からまずお話をしたい。

ぶんせき
【分析】
《名・ス他》物事をいくつかの要素に分け、その要素・成分・構成などを細かい点まではっきりさせること。

日本語的にはこういう意味だそうです。
ちなみに、分析という熟語は"分"と"析"という二字から構成されており、

・分＝分けられた部分。分けまえ。
・析＝ばらばらに切りはなす。とく。さく。わかつ。

という意味をそれぞれ持っています。
さりとて、何でもかんでも細切れにすれば良いのか？というとそうではないことは、賢明なる読者諸兄においてはお察しの通り。「あるテーマについての解を求める」ぐらいのノリで使われているのが実態ではないかなと思います。では何をもって分析呼べるのか、を定義したものこそが本稿で取り扱う「分析の"3C"」になります。

「○○について分析しといて～」と言われたときに、「これただの君の感想じゃん」となるところを「まあ、一応分析してるね」とするために押さえてもらえればよい最低限のポイント、ぐらいに捉えてもらえればと思います。

3つの"C"

イメージしてみてください。以下文章は分析と言えるのかどうか？

「相撲において有利不利を決める要素は何か？」
「相撲は体重が重い方が有利である」

答えは、「分析である可能性がある」です。
あるテーマについての解を求める、という目線で、1行目から2行目に至るまでの思考プロセスをより細かく見てみると

「相撲は有利不利を決定する要素は何か特定したい」（解を得たいテーマ）
「立ち合いにおいては質量のぶつけ合いであれば、体重が重い方が衝突時のエネルギーが高くなりやすいため有利なのではないか？」（仮説）
「各取り組みにおいて体重の大小と勝率に相関があるか？」（検証）
「体重が重い方が軽い方に対してn%勝率が高い」（結論）

という流れになるかと思います。「相撲は体重が重い方が有利である」ではなく、「体重が重い方が軽い方に対してn%勝率が高い」となっていればひとまず及第点かなと思います。
相撲フリークの諸氏のために弁明しておくと、例題としてのテーマ設定で便宜的に相撲を取り扱っただけで、実際に体重が重い方が勝率が高いかは知りません。

ただ、思考プロセスとしては概ねずれてないのではないかなと思います。
流れを簡潔にすると

テーマがあり→仮説を作り→検証し→その結果から結論を導き出すという流れになっています。

"3C"というのはテーマ設定以降にある、「仮説を作り→検証し→その結果から結論を導き出す」の3つのプロセスにおいて、必ずしている"はず"のことを指します。「分析である可能性がある」と書いたのはそれらがなされているかもしれないしされていないかもしれない、少なくともあのテキストからだけではそれがわからないということです。

ではそれらが何かというと
・Categorize（分類）
・Calculation（数値化）
・Comparison（比較）
の3つになります。数値化をCaluculationと呼ぶのは正直こじつけなんですが、キャッチーにしたかったための措置です。寛大なる読者諸兄においてはお目こぼしいただけると幸い。

1つ目の"C"：Categorize = 分類する

しょっぱなからですが、何気にこれが一番大事です。仮説と直結しているので。切り口、と言ってもよい。

例に取り上げた話で言えば、「重い方が有利なのではないか？」という仮説のもと、「体重が重い方」と「体重が軽い方」に分けていますよね。
実はこれが「動体視力が良いこと」が実際の答えだったりすると後工程はすべて無駄になっちゃいます。のでこの部分の精度が高いことがかなり重要。ここについてはセンスと経験なのかな～と思ってます。ビジネス上でも業界知識がない人が立てる仮説とある人が立てる仮説は切り口が違ったりしますからね。自分が門外漢で、仮説に自信がないテーマであれば、仮説が的外れであることによって無限に時間がかかる可能性を考慮して早めに取り組むことをお勧めします。

2つ目の"C"：Calculation = 数値化する

例でいうと「取り組みの勝敗データを、体重が重い方と軽い方に分けたうえで、勝率を算出する。なんなら体重差のデータを取り組みごとにとって、その差分の大小と勝率の相関を出す」というプロセスに当たります。「数値化」と言ってますが「集計」という表現の方が分かりやすいかもしれません。

実際に分析する際に一番コストがかかるのがここ。
膨大なデータを仮説に基づいて作った軸に沿って分類・集計するわけですが、データの可用性が低かったり、そもそも仮説検証に必要なデータが存在しなかったりするのはよくある話。
それを何とかかき集め、数値に落とし込むことができれば、分析のプロセスの9割は終わっている状態になりえます。

実際の業務の中では、必ずしも数値化する意味があるものを分析対象として扱うわけではない（例えば、競合との機能差分について分析しろ、みたいな定性的なテーマだったりする）のですが、概念的には

・ある　または　ない：0　または　1
・色の違い：R255G0B0とか　R0G0B255とか

のように、落とし込まれてるものだと理解しています。いや、主張します。
なぜ数値化という表現にこだわっているのかというと、3つ目の"C"があるからですね。

3つ目の"C"：Comparison = 比較する

シンプルです。プロセス上は消化試合と言っても良い。
カテゴリごとに数値化したものを比較し、それが当初設定した仮説に合致した結果であるかを確認するプロセスです。「体重が重い方が勝率が高い、あるいは低い」というのは数値を見比べれば一目瞭然です。

本来はここが一番面白いというか、立てた仮説が正しかったことが証明される瞬間なので、分析という一連のプロセスにおける醍醐味なのではないかなと思うのですが、データを集めて数値化するプロセスで力尽きてその時点でミッションコンプリートした気になったり、想定していた結果と違っていることを知るのが怖いからきちんと踏み込んで解釈していなかったり、ということが非常にありがちです。仮説構築のプロセスを他の人がやってたりするケースでは特に顕著。

まあ、実際のところはここで想定していない結果にぶち当たり、仮説構築からやり直し、というのはよくある話で、1~3を繰り返し繰り返し実行し、テーマに対しての解を得ることが"分析"というパッケージなのかなと思います。

まとめ

分析という行為をプロセスごとに見たときに必要な要素としては以上の通りなのですが、では逆にいずれかが欠けているとどうなってしまうのでしょうか？という点に最後に触れておきたい。

パターンとしてはそれぞれ

1.Categorizeがない
→　ただのデータの集合
2.Calculationがない
→　ただの主観的な感想
3.Comparisonがない
→　ただのデータ抽出

のようなものになってしまいます。

1はそもそも仮説が存在していないので、何も読み取れない状態だったり、軸がないので比較自体不可能な状況。「商品Aの売上のトレンドからどういうときに売れてるのか知りたい」というテーマに対して「商品Aの売上データ全件をただぶん投げる」みたいな状況です。曜日によって違うのか、季節によって違うのか、仮説は一切なし。なかなかですね。

2は要するに「なんとなく体重が重い力士の方が勝ってる（っぽい）」というやつです。
「力士Aは体重が重く立ち合いの当たりの強さが持ち味、Bという力士は回しをつかんだら離さず寄り切る握力と足腰、AとBだとAの方が勝ってるよね」みたいな個別事例は揃ってるのに、それぞれの要素がどれほど勝率に寄与しているかは、軸もバラバラだし、数値化されていないしよくわからん、ゆえにただの感想。
数値的裏付けがないことに自覚的であれば良いのですが、集計コストにビビッてサボってるだけのパターンも存在するので要注意。

個人的には3のパターンが最もよく見かけると感じていて、先に書いた通りではありますが、仮説構築に数値化する人が直接関わっていなかったり、そもそも解を得たいテーマを数値化する人は知らなかったりする場合に起こりえます。というか後者であれば必ず起こる。
数値化パートを依頼した側から「で、どうだったの？」と問われても、「さぁ…？（データまとめただけだし）」みたいなコミュニケーションが発生しているが、とはいえ集計コストがそれなりにかかっていて、業務としてはやり切った感を感じていたりすらするので、これが繰り返されることでひたすらデータ出すだけマンいっちょあがりです。
なので、特にDBに直接触れてデータを取り扱う仕事をしている人は、データを解釈する時間をしっかり確保し、それを伝えることを大切にしてほしいなと。データ出すだけマンになるか、分析できますマンになるかの分水嶺はここにあると思います。

終わりに

概念的には数年前から自分の中では持っていたものですが、人に伝えるという目線をもってテキスト化したのは今回が初めて。むずい。
「分析しました（ﾄﾞﾔｧ）」と言っても恥をかかないための最低限のお作法として、読者諸兄のお役に立って居れば幸いです。

おしまい。