分析とはひとことでいうと◯◯◯である
こんにちはHikaru Kashida です。
メルカリという会社でデータ分析チームのマネージャをやっています。
前回のnoteでは自己紹介と、これから主に分析関連のことについて書いていこうというお話をしました。
ですので、さっそく『分析』をテーマにひと記事書いてみようと筆を執っています。
この記事で書きたいことと、気をつけたこと
とりあえずまだ書き始めですので、分析とはなにかということを僕なりの解釈と言葉で書き綴ってみようと思っています。
おそらく、世の中には分析という単語の意味についての公式な記述というのもたくさんあることでしょう。そういったもの=公式の意味から始めてもいいのですが、ここではあえて完全にゼロベースで僕の頭の中にある 分析という言葉の意味について、好き勝手に論じていこうと思っています。
僕の脳内にある概念をコンパクトに説明するために、一部では抽象度を上げながら話をするので、その実際的な意味が読者に見失われないために、都度なるべくわかりやすく具体的な例を交えながら話すよう気をつけています。
「A or B」に解を出す
分析というのはなにをしているのか、ということを考えたときにこれに対する回答を超シンプルにいうと、次のようになるのではないかと僕は考えています。
分析とは、『A or B』という問いに対して解を出すこと
こう言ってしまうと、まさにとてもシンプルですね。もしかしたら、分析をガッツリやりこんでいる方々からすると、この説明は単純にすぎると感じられるかもしれません。実際これに当てはまらない分析というのも存在するでしょう。
しかし、おおよその分析課題というのは奥の奥まで突き詰めれば、この問掛けに収斂するものだというのが僕の基本的な考えです。
『A or Bで答えられる問』というのはちょっと上長なので、仮にこの記事中ではそういった問題設定のことを以後 “AoB問” と記載します
ビジネス上の問いを考えてみる
僕たちが分析を使って何かをしようとするとき、そこにはどのような目的があるでしょう?
ビジネスのシーンで考えてみると、次のような問に対して分析を使うことは、比較的よくあるのではないかと思います。
例1) この施策 / UI変更は、よかったのだろうか?例2) 新規サービスは伸びているのか?例3) このマーケットは参入すべきか?例4) いちばん投資をすべき事業ドメインやカテゴリはどこか?例5) ユーザの継続率ともっとも相関の高い行動はなにか?
ここで見てみると、例)1~3は yes/noで答えられるタイプの問いかけです。
一方で、 例) 4-5は [ A or B or C… ] という選択肢の中から、1つを選び出すという問いです。選択肢のタイプに違いはあれど、本質的は同じと考えることができますし、僕はそう考えています。
ここで重要なのは、答えyesだ!という判断を下したり、選択肢の中でベストなのはBだ!という解を導くには、つぎのふたつの要素が必要になるという点です。
ひとつめは、もちろんというか 数字です。判断ために必要な数字を出すというのは、まさに分析の醍醐味といったところでしょう。
そしてふたつめ、忘れられがちなのが判断基準です。上の表を見たときに、
PVが120% → よって施策は成功
という論理関係は決して普遍のものではなく、その場のおけるいくつかの前提条件に基づいて導出されているものでしょう。例えば、下記のようなシチュエーションという前提が考えられます。
『これまでの施策ではPVはせいぜい +5% どまりが限界だった』『今月の目標はPVを140%成長させることである』『施策はコレ以外にもあと3つは打てる』
それらの前提条件が 120%=成功という判断基準 を形成します。この基準の形成なくして、AoB問に解を出すことはできないということを覚えておいてください。
そして、分析において難しいのは、数字を計算する技術よりもむしろこの判断基準を適切に設定(もしくは設計)することだったりします。このあたりの詳細は別途お話できればと思います。
分析に入るのが適切でないケース
さて話を戻しましょう。
分析とは、『A or B』という問いに対して解を出すこと
逆に言えば、『A or B』で答えることができない問いかけというのは、分析の対象とすることが困難と言えます。
例えば、『最近どうよ?』や『競合参入してきたけどどうする?』などといった問いです。
これらは若しくはまだ質問としての粒度が粗すぎる状態で、分析に取り掛かるには適していません。もしこれらの問が重要なもので、客観的な分析による意志判断が必要な疑問なのであれば、本当に知りたいことを深掘りして、AoB問の形にできるまで落とし込む必要があります。
一見AoB問じゃないように見えるもの
さて、みなさんは普段何らかの分析的な仕事を行うことがあるでしょうか?もしそうであれば、ここまでを読んでいただいて次のように感じた方もいらっしゃるかもしれません。
普段僕が行っている分析や依頼はAoB問の形式じゃない!例えば『先月の売上はいくら?』などの分析依頼などはがよくある。これに求められている答えは “具体的な数値” であって、A or Bではない。
これに対しての僕の答えとしては2つの可能性があります。
ひとつめは、「それは実際にはAoB問として定義し、その形で答えるべき問いである」というパターンです。
あなたの上司である事業マネージャがあなたに『先月の売上はいくら?』と聞いたときに本当に知りたいことは何でしょうか?
「7月の売上は10億でした」という回答でも問題はないでしょう。しかし、本当に上司が知りたかったのはもう一歩進んだ部分ではないでしょうか?
例えば
・売上は伸びているのか?・7月は大きめの広告投資をしたが、見合った成長カーブになっているか?・7-9月の総売上は達成できそうなペースか?
などです。実際のビジネスシーンにおいて彼/彼女が本当に知りたいのは、売上の数値以上に上記のようなケースが多いのではないでしょうか。そしてこれらはすべてAoB問であるということに注目して下さい。
もし自分がいまから分析しようとしていることがAoB問の形式になっていなかったとしたら、それをAoB問として落とし込めないかを考えるべきです。
この、「最も知りたいA or B」はなにか?これを見つけ出すことは分析者としての重要な技能であり、差別化要素になります。
この「AoBデザイン力」については、もう少し詳細に後述します。
ふたつめは、「それは分析ではない」というパターンです。
これに関しては、「何をもって分析か」というのは人によって解釈分かれる点であり、ここでは必要以上に深く議論しないでおきたいと考えています。
ただ、もし実際に行っていることが単に数字を出すだけであり(その数字がベースとはなっているが) AoB問の設計とAoBの解を導出をおこなっているが他人であるとしましょう。
それは分析という言葉にはあてはまらない、正確に言うと分析全体の中の一部の作業を代行したにすぎないというのがこの記事の( = 僕の分析に対する)基本的なスタンスです。
誤解してほしくないのですが、数字を算出すると言う作業にたいして『そんなのは分析でもなんでもない!』と言いたいわけではありません。
それは分析という全体像の中の重要なひとつのパートですが、そこからさらにより広い範囲の業務まで一気通貫で行うことにより大きな価値があるというのが主張の趣旨です。
AoB問に解を出すためのプロセス
さて、ここまでで『分析 = A or B に解を出すことである』という前提に立つことができました。では、 A or B に解を出す とは具体的にどのような作業になるのでしょう?
典型的な流れで書くと次のような形で表せるのではないかと思います。
step① 解くべき問い(知りたいこと)を見つける
step② AoB問の形に落とす
step③ そのAoB問にどうすれば解を出せるかを定義する
step④ 必要な数字を揃えAoB問の解を導出する
step⑤ 解となる情報を説明可能な形に落とす
例を書きながら大枠の流れをざっくりと解説していきましょう。
これはあくまでかなりデフォルメしてごく単純化した例題にすぎませんが、実務上の分析の流れに近いと言えると思います。
AoB問を設計する(Step1-2)
まず何はともあれ、なんらかの『知りたいこと』を探す必要があります。
自分が知りたいことを分析して答えを出すというのも面白いですが、ビジネスシーンなどではチームメンバーや上長などが知りたいと思っていることにアラインしてお題を見つけることが多いでしょう。
たとえば、こんなケースを考えましょう。
施策Aを打ったから、みんなそれがどうだったのか知りたいはずだ。という設定をします。
この時点では知りたいこと自体はふわっとしていてもOKです。次のステップでふわっとしたお題をAoB問の形に落とすことができさえすれば問題ありません。
施策という意味ではおそらく、一番知りたい問は簡単に言うと次のようになることが多いのではないでしょうか?
これはAoB問の形になっていまね。つまり分析をして答えるべき問題になっていると考えて良いです。
では更にステップを進めてこのAoB問にどのように買いを出していくのかを見ていきましょう。
AoB問の設計を詰める(Step3)
問の内容をもう少しきちんと詰めていきましょう。Step2で設定したAoB問を見たときに、まだ不明確な部分が残っていることに気づくでしょうか?それは『成功』の定義が全くもって決まっていないということです。
何を持って『成功』かに絶対的な答えはありません。
施策を打ったことによるチームの達成感が大事という考え方もできるし、施策についてリリース文を出せたことで社長が満足したので成功、という考え方もできるでしょう。
この成功の定義の決め方はいろいろあると思いますが、ここでは『現状サービスではひとりあたりPVを伸ばすことが課題で、今回の施策はPV増を狙って打ったもの』だとしましょう。
すると、次の2つの項目を明文化しておけばAoB問に答えるための判断基準ができることになります。
ひとつめは成功の指標としてPVを基準にするということ。
そしてふたつめは、どれくらい上がっていれば成功と言えるか、という基準を +5% 以上と置くこと。
これは非常に単純化した例であり、実務上は成功の定義がここまでシンプルに表せないこともよくあります。また 『5%』のように具体的なひとつの数値で関係者と合意をするのが簡単でない場合などもあるでしょう。
しかし、可能な限りこのような形でAoBの判断基準を定式化しておくことが、良い分析には重要になり、またかつここは非常に多種多様なテクニックを要するパートにもなります。
必要な数字を出して解を導く & 説明可能な形にする(Step4-5)
さて、ここまで来てやっと一般的にイメージされる分析作業に入る事ができます。AoB問の解に必要な『PV』がどうなっているのかについての数字を持ってくる必要があります。
ここはExcelなりSQLなりPythonなりで作業することになるでしょう。そういったハードスキルは分析をするうえで一定必要になるのは、読者の大抵の方は既にご存知かと思います。
分析に関する書籍や記事などは、主にここのハードスキルの手法やプログラミングなどについて書かれたものが比較的多い気がします。
数字が揃ったら、そこからAoB問の解を導きましょう。
データ量が少なくない場合には、直接数字の羅列を眺めても理解できないことが多いので、グラフによる可視化が有効な手段となります。可視化はうまく行えば、(自分が解を出すのに役に立つ以上に)他者に対して情報を伝達する上で非常に有効です。
また、ここでは単にPVの上昇率を計算する以外にも、いくつかの軸での分析を行い『平日に比べて週末のPV増が顕著』という傾向を得ました。
こうした、AoB問の本筋プラスの追加の分析を行うことで、別の仮説が持ち上がり、次のAoB問の創出のヒント (=分析のタネ)になります。
例えば次のような仮説を考え、別の分析を行うことで新しいインサイトを得ることもできるかもしれません。
・施策Aは可処分時間が多いときの利用に特に有効なものだったのでは?→ 職種別に見てみるのはどうか。もともと可処分時間が多いユーザほど影響がでかいのでは。
・週末はスマホユーザが多いが週末はPCユーザが多い。PC上での体験と特に相性がよい施策だったのかも?
→ デバイス別で見てみよう
こういった深掘り分析のイテレーション(繰り返し)によってサービスや施策の特性について多くのインサイトを見つけることができ、継続的な分析によって分析者は多くの知見や数値感を貯蓄していくことができます。
今回の分析例のまとめ
今回の分析をまとめます。
施策Aを打った → AoB問:施策が成功だったか知りたい→ 判断基準:PVが5%上がっていたら成功
数的情報:PVが12%上昇
AoB問の解 = 施策Aは成功だった
おまけとして、次にような分析テーマを新たにゲットしました。
次の分析アクション→ 次の2つを行いインサイトがあれば、次の施策のアイディアとする:職種別の施策Aの反応率:デバイス別分析
分析の落とし穴と分析者が知るべきこと
ということでめでたしめでたしです。
さてここでStep3から4の流れについて一点補足しておきましょう。よく論点となるのが、Step3で決めた判断基準に必要な数字が直接観測できないケースがあるということです。
理由のパターンとしてはつぎのようなものがあるでしょう。
①そもそもデータで見るのが困難な指標である(ユーザ幸福度、など)②取得は可能だが、データを取得する実装がされていない③データは取得されているが、加工や集計が困難 / 複雑な処理を要するなど
これらを解決するためにはいくつか方法がありますが、最も重要なのはこのような状態に陥らないようにAoB問とその判断基準を設計することです。
そのために、ひとつめとして分析者は自分が持っているデータの内容を熟知いなければなりません。何が観測可能でどのようなAoB問だったら、データを使って答えうるのかを周囲の誰よりも、明確に理解し説明できなければなりません。
ふたつめは論理力に優れる必要があるということです。
このあたりも詳しくお話したいですが、いつのまにか大分文章が長くなってきたので、また別途お話しましょう。
まとめ
分析とは、『A or B』という問いに対して解を出すこと
読んでくださってありがとうございました。
また次の記事でお会いしましょう。
いつも読んでくださってありがとうございます。 サポートいただいたお代は、執筆時に使っている近所のお気に入りのカフェへのお布施にさせていただきます。