はじめまして、SaaS Technology Centerデータインテリジェンス部グロースアナリティクスチームの森本智視(モリモト トモミ)です。

今回の記事では、"データ分析の考え方"について書きたいと思います。
割と長めの記事なっていますが、パイオニアで取り組んでいるデータ分析の考え方をお伝えできればと思います。

この記事で話すことをざっくり3行でまとめると

というお話です。では、一つずつ説明させてください。

このnoteを書いた背景

”データ分析”をより身近なモノにするべく、日々社内で奮闘していますが、人によって”データ分析”が意味することや考え方にバラツキがあることを感じていました。

バックグラウンドや今まで経験してきた業務によってバラツキが発生するのは当然です。

都度口頭で説明して一つ一つ認識を揃えていましたが、せっかくなら言語化して、まとめてしまおう。

そうすれば体系的に整理されて、より分かりやすい説明ができると思ったのがきっかけです。

ビジネスにおけるデータ分析の意味

では、”データ分析”は何のために行うのでしょうか？

端的に言ってしまえば、ビジネスに結論を出し、”Outcome”を創出・最大化するため、に尽きます。

ビジネスモデルや会社によって目標はさまざまですが、基本的には日々私たちはお客様に商品・サービス・価値を届け、その対価としてお金を頂戴しています。

ただ闇雲に商品やサービスを届けようとしても限界があります。

当たり前ですが、ビジネスのリソース(ヒト・モノ・カネ・情報)は有限の資産です。

有限のリソースの中で最大限の”Outcome”を出すために分析は行われていきます。

弊社のデータ組織のTopであるChief Data Officer 保田も上記を明言しており、日々、社内外に積極的に発信しています。

分析の前提

上でも述べていますが、分析の目的は、”Outcome”を創出・最大化することです。

”Outcome”に貢献するために、重要なことが1つあります。
それは、分析とアクションが紐づいていることです。

貢献するためには、何かを行動を起こす必要があります。

どれだけ素晴らしい分析を行っても行動が伴わなければ、その分析の価値は0に等しいです。

分析にたくさん時間をかけても、”ふーん”で終わってしまう事例はよくあるのではないでしょうか？(自分もたくさん経験しました・・・)

分析は無限にできてしまうので、スタンスをとったり、Issueから始めることなどの取り組みが大切です。 

分析の方向性

そもそも分析には大きく2つの方向性があります。探索的分析と仮説的分析の2つです。(※本記事での独自表現なのでご了承ください)

それぞれ下記で説明していきます。

探索的分析とは、データを眺めて、あれやこれやとしながら、データから言えそうなストーリーはないか？を調べていくことです。
具体的には、「とりあえずデータを見てみよう」というような場合によく用いられる分析手法です。

一方で仮説的分析は「xxxは検証するとyyyではないか？」と言う仮説や問いを持ち、それが正しいか、正しくないか？と白黒をつけていきます。

つまり、探索的分析はゴール地点がない状態で出発し、ゴールを模索する一方で、仮説的分析は一旦ゴールを決めた上で、そのゴールを目指す動きと認識ください。

どちらの分析の方がアクションに紐づきやすいかというと、仮説的分析の方が何かしら”アクション”につながりやすいのです。

有限のリソースの中で、無限にゴールが存在しうる探索的分析より、一定方向性が定まってる仮説的分析の方がゴールに向かいやすいからです。

もちろん、最初に立てた仮説・問いが正しくないと証明される時もあります。(・・・少し悔しい気持ちになる時もあります)

ただ、その場合は持っていた仮説・問いを棄却し、新たに練り直して再度アプローチすれば良いだけです。

1回の分析で綺麗な結論が出ることもありますが、右往左往しながら一歩一歩進むことも多々あります。
愚直に何度も向き合い、仮説を磨き込みながら分析の精度を上げていくのです。

これ以降、分析と表現する場合は仮説的分析の話だと思ってください。

分析の流れ

さて、実際に分析を行うには大きく4つの流れで考えていくのがオススメです。

他にも他社さんからさまざまな記事が紹介されているので、参考にしてみてください。

リクルートの出木場さんが仰っているデータ分析3原則の”分ける、集める、比較する（有料記事）”や、ATカーニーさんの”超”分析の定義と3ステップ”俯瞰・分解・比較”などは個人的にオススメです。

 では一つ一つ見ていきましょう。

仮説構築

まず重要なのは、最初に”何を為したいのか、その姿を計測するために定量指標では何を用いるべきか？”を考えることです。

どの数値を上げたい(or 下げたい)のか？を明らかにした上で、背景・したいことを言葉に書き起こし、関係者と認識を揃えていくのです。

軽視されがちですが、この言語化が超重要です。

というのも、関係者のバックグラウンド・立場などが全て揃っていることはなく、皆それぞれ個々の考えが存在するので、その結果少しずつズレが生じてしまいます。

分析には、その小さなズレから大きな認識齟齬や不要な議論が巻き起こったりします。
横道に逸れず分析を進めるためには、言語化は無くてはならない工程です。

認識が揃った後に仮説を出していきます。
仮説の出し方は自分の体験や簡単な調査を用いるでも何でも大丈夫です。

仮説は可能な限り幅広に出して、「数」や「幅」を広げていきます。
そして、ある程度仮説が出てきた時点で、その中で最も筋が良さそう(≒効果が高そう)な仮説を選びます。

仮説を選ぶ際にはデータを用いて定量的に決めることも重要です。
ただ、一定感覚的な要素も考慮に入れて仮説を選んだ方が良い時もあります。

全てそうする必要はありませんが、チームで議論をしたり、一人の強い熱量に委ねたり、と、少し揺らぎや余白を持っておくと良いです。

揺らぎや余白があると、よりチャレンジングな検証や思ってもいない発見ができることもあるからです。

データを集める

仮説を出せた後は、実際に手を動かしてデータを集めていきましょう。

データと言っても、アンケート調査、利用ログ、お客様情報など様々な種類のデータがあります。

一旦ここではログ分析などの定量的な分析に焦点を絞って話します。

データを集める際には、可能な限り細かい粒度で必要なデータを集めていきます。
「大は小を兼ねる」とは逆で、細かい粒度でデータを持っていれば、その後必要に応じてデータを好きな粒度にまとめることができるためです。

またデータソースが点在しているケースも多々あります。
その際はデータの定義が一致しているのか？に注意が必要です。

同じカラム名だけど、定義が少し違う。
カラム名が違うけど中身が同じなどの現象は”あるある”な話しです(ここの確認は地味で大変ですが、大切な工程です・・・)

データを分解・比較する

データが集まったら、データの動きのイメージを持ちながら、兎にも角にもまずは“ざっくり”数値を見ることが重要です。

最初から細かく見たくなる気持ちは分かりますが、視野が狭くなるので必ず大きく確認していきましょう。

例えば、売上を分析する場合、まずは月次の売上推移を可視化し、「なぜこんな動きをしているのか？」を考えたり、前年度と比較したりと色々な見方を考えていきます。

分解の観点だと、売上 → サービスA + サービスB ＋ サービスC ・・・とサービス区分で分けたり、比較の観点だと、2020年度売上 / 2021年度売上 / 2022年度売上と年度別に比較したりします。

時には、分解と比較の組み合わせなども行い、データを咀嚼し、理解を深めて、意味を見出します。

ここがデータ分析の肝です。楽しいこともあれば大変なこともたくさんありますが、最も盛り上がるところです(笑)

取るべき打ち手を導出する

 ここからは分析結果を通してアクションを考えていきます。

最初に決めた仮説に対して、データ分析を通してYes / Noのどちらになるのか？と結論を明確にし、どの様なアクションを取るべきなのか？を考えるのです。

具体的には「xxxという指標を改善するためにはyyyの施策を打つべきである」や、逆に「今は急いで対応しなくて良いので優先度を下げて他のzzzzという施策に取り組むべき」、というような形です。

取るべきアクションを決めた上で、現実的に実行できる施策設計に落とし込んでいきます。

パイオニアでの実例

ここまで概念的なお話をしてきましたが、具体的にパイオニアの事例を簡単に紹介します。詳細を細かくお伝えすることは出来ないですが、ざっくりのイメージは掴んでいただけるかと思います。

仮説構築

パイオニアが提供している、あるサービスの内の1つで新規機能がリリースされました。ここでは仮にhogehogeというサービス名にさせてください。

hogehogeの利用率は悪くなかったのですが、利用率をより高める必要が出てきました。

そのため、「hogehogeの利用率を高める」ことを目的としたドキュメントを作成した上で、関係者と認識を揃えていきました。

ある程度認識をそろえた上で利用率を高めるための仮説を皆で出し合っていきます。

こうしたら利用率が上がるのでは？そもそもhogehogeを知らない人がいるのは？などなどさまざまな仮説が出てきました。

その後、チームで議論し検証するべき仮説を定量と定性の観点で決定していきました。

データを集める

今回のケースは、既に取得しているログデータで対応できそうでした。

自分達が知りたいことを整理したうえで、その定義に一致するデータを取得していきます。

今回は1ヶ所に既に集約されていたのでスムーズに動けました。

なお点在している場合、上記でご説明したように一つずつ担当者に確認しながらデータを集める必要があります。

データを分解・比較する

データが集まったので、ザクザク分析をしていきます。

まずはhogehogeのリリースからの時系列で利用率の推移を出していきます。

その後、利用している人と利用していない人で区分けして、何か違いがないか、利用していない人はなぜ利用していないのか？など色々と切り分けて、納得度を高めていきます。

この分析を通して、いくつかの新しい発見も出てきました。

取るべき打ち手を導出する

ある程度分解・比較し、納得度も高まった段階で、取るべき打ち手を考えていきます。

今回の場合、データ分析を通して、利用率を高めそうな打ち手が見出せたので、その打ち手をより具体化し、提案した上で関係者と認識をそろえていきました。

最終的には施策の実施まで進められ、結果として当初の分析の目的だった「hogehogeの利用率を高める」を達成できました。 

まとめ

今回はパイオニア流の分析の取り組み方・流れをお伝えしました。

最初にお伝えした通り大きな流れとしては、

を意識して取り組んで頂ければ幸いです。

ただ、この流れが全てではありません。

環境やメンバーによって異なることも多々あるので、1つの型としてご理解頂ければと思います。

最後に

パイオニアのSaaS Technology Centerではデータ人材を絶賛、募集中です！
事業部やプロジェクトの課題をデータ分析で解決し、パイオニアの変革に貢献してくださる仲間を探しています！

「まずはどんな仕事をやっているのか聞いてみたい」
「応募前にチームのメンバーと話してみたい」
という方は、ぜひMeetyでお話ししましょう！

SaaS Technology Centerで募集してる職種はこちらです。
ご応募お待ちしています！