ますますデータ活用の需要が高まる昨今。
職種としてだけではなく、ディレクターやデザイナーといった非エンジニア職の方にもデータ分析のスキルが求められてきています。
しかし、データ分析を学ぶメリットやプロセスの全体像、そのプロセスで何を学ぶべきなのかがわからないという方は多いのではないでしょうか。そこでこの記事ではこれらについてご紹介してきます。
株式会社メンバーズ メンバーズデータアドベンチャー データアナリスト
販売や飲食での接客、Web系の会社でのディレクターを経て、現職。
Web系事業会社のデータ分析部門常駐し、データアナリスト・データ分析業務全般に従事。ECサイト、定量分析を担当することが多い。最近の関心事はUXデザイン。
データ分析を学ぶメリット
データ分析を学んでみたいけど自分にメリットがあるのか、今の業務に広がりが出るか分からないという方は多いかもしれません。
個人的にデータ分析のスキルを身に着けるメリットは主に下記のようなものかと思います。
- やってみたい施策に定量的な裏付けができて、自分の提案した施策が実行しやすくなる。
- 実行した施策が本当に効果があったのかを把握でき、どんな施策を実行すればこの指標が上がるといったことが分かるようになる。
- 施策の優先順位がつけられるようになる。
データ分析のプロセス
1. 何を改善するか
ここではその事業や部署がある期間内で、どの指標を改善するかの設計・それをモニタリングする環境の構築を行います。
一般的な企業であれば経営層や事業部長・部門長などが設計してそれぞれの部署に落ちていきます。
事業（部署）KPIの設計
最終的な事業の目標（KGI）が売上だとして、それを分解すると購入者数と購入者の単価に分けられます。
どちらを主に改善するかは事業の状況によりますが、例えば購入者数が日本人口とほぼ同じであれば、これ以上改善しても売上に対するインパクトが小さいので購入者の単価に注力した方がいいですよね。逆に事業が始まったばかりで購入者数が少ない状況であれば、購入者の単価ではなく購入者数を上げようとなるかもしれません。そこで購入者数をKGIとしよう、となった場合さらに、初めて購入する人を増やすのか、それとも以前購入したことがある人に再度購入してもらうのを増やすのか、と分けることもできます。
こういったことを突き詰めて、今この事業や部署はどの指標（KPI）を改善すれば事業の最終的な目標により近づくのかを見極めていきます。
モニタリング環境構築
KPIが決まったらその指標や関連のある指標がどのような状況なのかを把握できる環境を構築する必要があります。
この環境が無いとどういったことが起こるかというと、先の例と同じく購入者数をKPIと仮定します。
購入者数を増やすために様々な施策を行った結果、購入者数が1年で2倍になりました、2倍になったのなら大成功だ、と思われるかもしれません。ですが購入者の単価が半分になっていたらどうでしょうか。事業の売上で見ると結果は変わらないので成功とは言えません。
きちんとしたモニタリング環境が出来ていたら、購入者数は増えているが購入者の単価が下がっているので今の施策はやめようなどど判断ができます。
環境としてよく使われるのがTableauやLooker StudioといったBIツールと言われるものです。これらのツールを使いこなしたり、ビジネスの目的に合わせたビジュアライズを行うデザインのスキルなどがこのプロセスでは重要になってきます。
どうやって改善するか
どの指標を改善するかが決まったら、その指標をどうやって改善するかの施策の仮説を立てたりその仮説が正しいかを検証していきます。
データ分析の仕事というとこのプロセスを想像されることが多いのではないかと思います。
改善施策の仮説立案
事業KPIを上げるための改善施策の仮説を立てます。
仮説を出す方法として、自身が普段サービスを使っていて不満に思っていることやユーザーの方にインタビューを行う、定量データをひたすらに見るなどがあります。
仮説が出せたら、この仮説を施策に落とした時に上がると想定される指標を明確にする必要があります。それって事業KPIじゃないの？って思われた方もいるかもしれません。もちろん最終的な目的はそうなのですが、事業KPIは「いろいろな要素を掛け合わせた結果の指標」なので、施策で直接的に操作できる指標ではないケースが多いです。
例えば、ECサイトの事業KPIがユーザー1人当たりの購入回数だと仮定します。
それを上げるために「初回購入後1ヶ月以内に、何らかの目的でサイトに再訪問してる人は購入回数が多いのではないか」という仮説を立てたとします。これは、初回購入後1ヶ月以内の再訪問率（これを施策KPIとします）を増やす仮説で、間接的には影響があるかもしれませんが、購入単価に直接影響のあるものではありません。ここで定義した施策KPIと事業KPIが本当に紐づいているのかを次のフェーズで確かめていきます。
このプロセスではUXリサーチと言われる手法を学んだり、自社サービスだけでなく競合サービスも使って見ることで仮説の量や質が高まるかと思います。自分たちのサービスを使ってくれているユーザーはどこで何に困っているのかという想像力がとても重要になります。
仮説の検証
立てた仮説が本当かどうかを確かめていきます。
施策KPIが上下、今回の場合は1か月以内に再訪問している人としていない人とで、その後の購入回数が変わっているかを見ていきます。再訪問している人の方が購入回数が多ければ定量的にも仮説が正しく、そうでなければ仮説は正しくないといった形です。
ここでは実際にデータを抽出することが多いので、GoogleAnalyticsやSQLといったスキルを学ぶといいかと思います。
意思決定に繋がるよう、検証結果を意思決定者に正しく伝える
仮説や検証内容が素晴らしくてもこの伝えるフェーズで失敗してしまうと、間違った意思決定に繋がる危険性があるので伝え方には細心の注意を払います。
関わる関係者が多く背景をしっかり伝えないと齟齬が生まれそうな場合は、プレゼンソフトなどを用いて丁寧に作成します。逆に普段からよく話していて認識が揃っている相手に伝える場合は、簡潔にペライチでまとめて作成することが多いです。
本当に改善につながったか確かめる
施策のテスト設計
ここでは、この施策が成功もしくは失敗だったのかを検証する方法の設計とその環境を構築します。
まず施策を実行するグループ（A）と実行しないグループ（B）で、それぞれ何人を対象者にすればいいかを設計します。あまりにも対象者が少なすぎると、その後の施策の結果が施策そのものの結果なのか、対象者が少なすぎるのかを判断できなくなるからです。また、両グループの対象者を同じような人の集まりにする必要があります。例えばAグループは直近1年で利用経験がある人でBグループは1年以上利用が無い人だと、施策の反応が違ってきてしまい、対象者の人数の時と同じく結果が施策そのものによって得られたのかが分からなくなるからです。
施策の対象者数（サンプルサイズ）の決め方や、実験計画法といったものを学ぶと良いテストの設計ができます。また、テストそのものの環境構築をする場合もあるので、Googleオプティマイズといったツールを学んでおくとスムーズです。
施策実行
ここではデータ活用という観点では行うことはほぼないのですが、施策実行中に3-1で定義した指標がどういう推移を辿っているかを伝達するといったことを行ったりします。
効果検証
「施策のテスト設計」で定義した指標が、施策を実行したグループと実行しなかったグループで差分があるのかを確認します。この場合明らかに差がある場合以外は、統計的検定を用いてこの結果が有意であるかどうかを見ていきます。
また、結果をより細かいグループで見たときにどうなってるかも検証していきます。例えば、グループ全体同士だと結果は変わらなかったが、初回に購入した商品のカテゴリがAだったグループ同士だと結果が違った、などです。
ぜひ今回の記事を参考に、データ分析の第一歩を踏み出してみてください
