事業やプロダクト開発を加速させるデータ分析
ここ数年、様々な業界でデータサイエンティストの求人を目にします。一口にデータサイエンティストと言っても内容は様々で、画像解析やレコメンド開発など機械学習エンジニア系のものもあれば、ビジネスの意思決定を支援するようなデータアナリスト系のものもあります。（データサイエンティストの分類についてはTJOさんの記事が参考になります）
この記事では、ビジネスの意思決定を支援するデータ分析に絞って、事業やプロダクト開発を加速させるのに必要なことについて、自分の思考の整理を兼ねて書きたいと思います。この記事を書くきっかけは、最近読んだデータ分析についての記事が、面白くて新しい気づきが多く、改めてデータ分析について整理してみたいと思ったからです。（だみ〜さんの記事、タカヤナギ=サンの記事）
この記事は、「現場とデータの両面からの分析」と「データ分析がしやすい環境作り」がやはり大切という内容で、日頃データ分析をしている人にとっては、とても当たり前の内容かもしれませんが、ほんのちょっとでも新しい気づきがあれば幸いです。
特に、BtoBのSaaSプロダクトのデータ分析をしている人にとって参考になればと思います。
各事業フェーズに必要なデータサイエンティストの役割
事業やプロダクト開発には、どのようなデータ分析が必要でしょうか。まず、事業のフェーズによって、立ち上げ期とグロース期では、求められる役割が異なります。
事業立ち上げ期におけるデータサイエンティストの役割は、サイバーエージェントの藤田さんによる「事業立ち上げにデータサイエンティストは必要なのか？」というスライドに非常にわかりやすくまとまっています。事業の立ち上げフェーズでは、データ分析そのものより、今後のデータ分析のロードマップを描き、それを実現できる環境を整備することが重要と述べられています。
この記事では、グロース期に焦点を当てて、BtoBのSaaSプロダクトを改善させるデータ分析を例に紹介していきます。
具体的なデータ分析の内容に入る前に、イメージが湧きやすいように簡単に私の日々の業務とプロダクトについて紹介させてください。
現在、私は医療×AIのベンチャーUbieで機械学習エンジニア兼データアナリストをしています。機械学習エンジニアとして問診エンジンを開発していて、最近は事業やプロダクト開発のデータ分析をメインの業務としています。
Ubieでは、病院やクリニック向けにAI問診ユビーというサービスを提供しています。患者さんが病院の待合室に居るときに、紙の問診票の代わりに、タブレットを利用して症状を入力します。患者さんが症状を入力すると、それを深ぼるような質問を投げかけます。患者さんの回答が完了すると、その内容が医師の見る画面に提供され、診療業務の効率化と充実化に貢献しています。
今は400を超える医療機関で利用されていて、事業のフェーズとしては、プロダクトマーケットフィット（PMF）して、拡大させていこうとするフェーズです。PMFしているからといって、プロダクトが完璧ということは全然なく、データ分析を駆使してプロダクトを改善しています。その際に、特に次の２点が大切と感じており、順を追って説明します。
・現場とデータの両面からの分析
・データ分析がしやすい環境作り
現場とデータの両面からの分析
突然ですが、こちらの画像を見たことがありますでしょうか。第２次世界大戦時に、基地へ生還した戦闘機が被弾した銃痕を赤い丸でプロットしたものです。この画像を見て、戦闘機のどの部分を補強するのが良いでしょうか。赤い丸が集中しているところを補強するのが良いでしょうか。正解は、逆に赤い丸が集中していない所になります。赤い丸が無いというのは、そこに被弾した戦闘機は基地に生還しなかったということです。この画像は、手元にあるデータを疑いなしに分析することに警鐘を鳴らすのにしばしば用いられています。
プロダクトのデータ分析をしているとこのような局面に出くわすことは多く、そのときは現場からの定性情報が参考になります。
例えば、AI問診ユビーは、病院の待合室で患者さんに使用してもらっています。データをもとにユーザーをセグメント分けして、どのセグメントのユーザーが使いにくいかの分析をしていました。しかし、実際に病院に見学に行くと、とあるセグメントの患者さんには、AI問診ユビーのタブレットをそもそも渡していないということがありました。よくよく話を聞くと、とある機能が不十分で、特定のセグメントの患者さんには渡さない運用であることが分かりました。
つい、データがあるとデータとにらめっこして示唆を出そうとしますが、現場に行って、定性情報を得ることでそもそもデータに現れないような課題を発見するのが重要です。
実際に、現場の裏側でストップウォッチ片手に数日間オペレーションを観察させてもらったり、チャーンしてしまいそうな顧客とのミーティングに参加したりしました。すると、課題の解像度が高まりますし、この顧客のために良いプロダクトを作りたいと身が引き締まります。また、データ分析をするときに、データがただの数字の羅列ではなく、現場の様子や顧客の顔が浮かびながら、実感を持って分析することができます。N=1の顧客の課題の解像度を高めて解決していくことが重要だと痛感しています。こちらの「顧客起点マーケティング」という書籍が参考になります。
もちろん、N=1の顧客の要望を全てを聞くのは難しいため、その課題が他の顧客でも起きていないかを、データから分かる場合は、SQLを書いて分析します。
このように、現場や営業からの声に触れることで、課題の解像度が上がり、データをどの切り口で分析すれば良いかが分かります。現場を重視するというスタンスは、自分が新卒の頃にとある人から教えてもらった「とことん観察マーケティング」という書籍からの影響も大きいです。また、データサイエンティストの松崎さんのこちらの記事では、１ヶ月間現場に入り込み課題発見をしていて、参考になります。
一方で、データ→現場のパターンもあります。データから外れ値や解釈が難しい要素を抜き出します。そのデータが起きる原因を現場に行って確認すると、我々が想定していなかったプロダクトの使われ方をしていて、プロダクト改善につながったケースもあります。
この段階の事業フェーズでは、因果推論や多変量解析などの高度な手法は使わず、クロス集計のような単純な方法で明らかに課題がある箇所を特定することが多いです。ただ、差分の差分法（DID）や回帰不連続デザイン（RDD）などの概念を知っていると、分析の切り口が増えて役立ちます。例えば、特定のセグメントで施策をしたときに、施策前にそれぞれのセグメントで平行なトレンドがあるのかを確認した上で、試作後の影響度合いを確認することを徹底しています。（DIDやRDDについては「効果検証入門」という書籍が分かりやすいです。）
データ分析をする際には、そこからどんなアクションに繋がるかを念頭に置くことも大切です。クロス集計をすれば、有意な差がたくさん出てきます。しかし、実際にプロダクト改善に繋がる示唆というのは、そこまで多くありません。プロダクトを改善するとその数値が変わりうるのか、プロダクトの変更コストはどれくらいで、それを変えたときのインパクトはどれくらいかを考えながら分析することが大事で、現場感とプロダクトに対する深い理解が求められます。
以上まとめますと、現場⇔データの両輪で、プロダクトの課題を発見し分析することが大事です。
データ分析がしやすい環境
社内でデータ分析を促進させるためには、データ基盤の整備とデータドリブンで意思決定していこうとするカルチャーが必要です。幸いにもUbieでは、創業当初からデータドリブンなカルチャーで、データ基盤の整備にも力を入れていました。（最近は、dbtというツールを使って、データ基盤を整備しています。dbtを活用したデータ基盤整備やデータ活用については、同僚が記事を書いているので、こちらをご参考ください。「さようなら、謎の数値ズレ。dbtを活用してデータ品質管理をはじめよう」、「Data Status Time Machine on Persisted dbt Artifacts」、「高速な開発とデータ品質のトレードオフを超えるためにできること」）
データ分析がしやすい環境は、何か最強のツールを入れたら一発で整う分けでもなく、地道に周りを巻き込みながら改善していく他ありません。
例えば、最近実際にやったこととしては、
・チームごとに、クリック率の定義が異なっていたので、その認識をチーム間で統一
・ビジネスサイドのメンバーも簡単にデータを分析できるように新しくマートを整備
・セッションキーが一部で欠損していて、データをジョインできなかったので、エンジニアチームに依頼して、特定のログにセッションキーを追加してもらった
・商談のデータはSalesforceに入っており、それがtorroco経由でBigQueryに連携される仕組みだが、Salesforceの特定のカラムへの入力が営業メンバー内で統一されてなかったので、統一してもらった
・Slackで#help-biというチャンネルを作り、データ周りの相談ごとやバグなどを気軽に投稿してもらう
などがあります。
新しくデータマートが整備されたことで、ビジネスサイドのメンバーもBigQuery上でガンガンSQLを書いて分析しています。現場により近い人達が、データサイエンティストの手を借りずに、自分でSQL書いて分析し、TableauやRedashで可視化して、Slackにアラートを流すように設定していて、データ分析を加速させています。
例えば、カスタマーサクセスをメインでやっている同僚が、顧客の利用状態をいくつかの切り口で分析して、ヘルススコアを定義して可視化しています。カスタマーサクセスのメンバーがSQLやデータ分析について学び、データサイエンティストがカスタマーサクセスについて学ぶことで、お互いのコミュニケーションもスムーズになり、カスタマーサクセスに繋がっています。（カスタマーサクセスに関しては、こちらのSansanの方が書かれた書籍が分かりやすいです。）
データ分析のカルチャーに関しては、他社の事例をいくつか参考にしています。ワークマンが、データドリブン経営を掲げ、全社員がデータ分析をするというカルチャーを醸成していて、それの過程を紹介したこちらの本は参考になります。また、前職のIndeedでは当時のCEOの出木場さん（現リクルート社長）も自らSQLを書いて分析し意思決定をしていました。データドリブンな雰囲気は社内で浸透していて、PMも全員SQLを書いており、そのカルチャーを参考にしています。（※Indeedでは独自のデータベースを構築していて、そこからデータを抽出するSQLライクなIQLという言語でクエリを書いていました。余談ですが、こちらの記事で紹介されている出木場さんのデータ分析の考え方はシンプルで好きです。）
このように、地道ではありますがデータ基盤を整備しながら、データドリブンの意思決定がより浸透していくように、サポートしています。
まとめ
グロース期のBtoBのプロダクト開発を例に、データ分析に大事な２つの観点をご紹介しました。
・現場とデータの両面からの分析
・データ分析がしやすい環境作り
もし、この記事で気になることや質問がありましたら、@masa_kazamaまでDMお願いします。または、Meety上でカジュアル面談も公開していますので、直接話したい方がいましたら、こちらにご連絡お願いします。
また、Ubieではデータアナリストや機械学習エンジニアを募集していますので、ご興味がある方がいましたらぜひ御覧ください。この記事で紹介したBtoBのAI問診ユビー以外にも、BtoCのAI受診相談ユビーのデータ分析もあります。
この記事が気に入ったらサポートをしてみませんか？