estie データマネジメントグループのソフトウェアエンジニアの和田です。私については → 入社エントリ
この記事の内容
さーて、今回の estie inside blog は
- estie、データドリブンになりたいってよ
- データの活用先を考えるブレスト会をやったらアイデアが沢山出たよ
- データ活用を実現していく仲間を募集中だよ
という内容になっております！それでは本編どうぞ！
estie、Snowflake を導入しましたよ（再）
少し前にこのブログでも紹介したのですが、estie の新しいデータ基盤として Snowflake を導入しました。
estie、Snowflake を導入しましたよ - estie inside blog
上記の記事では、データマネジメントグループが管理しているデータパイプラインの課題をメインに紹介したのですが、Snowflake に対しては分析利用への期待も高まってきています。プロダクトのログを Snowflake に取り込む対応もほぼ完了し、各チームで SQL を書いてプロダクトを改善するための調査するようなシーンもだんだんと増えています。
「データドリブン」に対する（個人的な）思想
新しい基盤も導入されデータもある程度見れる状態になってくると、「データドリブンな会社になりたい！」みたいな期待感がだんだんと高まってきます。が、過去にデータアナリストなどを経験してきた自分としては「データドリブン」についてちょっと思想があり……
「データを使うこと」から出発したくない
私は「データドリブン」＝「データに基づいて、意思決定を行うこと」だと認識しています。このときビジネス上で一番大事なのは「意思決定を行うこと」です。
弊社取締役の束原が PMF前後を担う事業責任者として意識していることという記事の中で
事業のリーダーとして、全てを数値化し、数字でマネジメントできる状態は理想ですが、数字よりも早く出てくる先行指標は、そのお客様（リーダー）の発見とリアクションです。
と書いていますが、私もまさにそう思っています。意思決定を行うためには必ずしもデータは必要はないです。もちろん、人間の直感では判断つけられずデータを使うしかない分野もあるとは思いますが、今の estie のプロダクトのフェーズではあまりそのようなシーンは多くはないと思います。
そして、「新しい基盤も導入されデータもある程度見れる状態」になったから「データドリブンを目指す」というのは、「意思決定」を一番に置いた考え方とは少しズレ始めているかも？と個人的には考えています。
（アナリストやデータエンジニアというキャリアの自分にとっては、アイデンティティが揺らいでくる話でもある気もするのですが、それは別のお話……）
意思決定したいことを挙げてみるブレストをやってみた
上記を踏まえて、プロダクトチームと「決定したい意思」を挙げる会をやってみました。
ざっくりと
- 決定したいと感じていることを思いつきで挙げてみる
- その決定を下すために必要な事実を考えてみる
- その事実をデータ（数字）で表現するとしたらどんな形になりそうかを考えてみる
というプロセスで実施しました。
データからではなく、「意思決定したいこと」から出発しているのがこだわりポイントです。
ブレスト会の結果
ボカしているのでやや見づらいですが、中央の赤いエリアにある付箋が「意思決定したいこと」です。めっちゃある（嬉しい悲鳴）
2 チームで 62 枚の「意思決定したいこと」が上がり、それに必要な事実・データが繋がっている状態です。弊社のプロダクト開発に関わるので全てオープンにはできないですが、いくつか上がった例を紹介します。
決定したいこと: どの機能を改善するのかの優先度
- 必要な事実
- 機能毎に、顧客満足度との相関関係が判明する
- データ
- 顧客満足度データ
- プロダクトの利用機能ログ
限られた時間・人員の中でプロダクト価値を最も大きくするためにデータを使うというのは有効な活用方法ですね。データが正確に事実を表すかどうかはさておき、「どの機能も当然大事である」という前提のもとでは、人間の感情ではなくデータを共通認識にすることでチームが一丸となって行動できそうです。
決定したいこと: 顧客開拓を最適化するアクション
- 必要な事実
- 顧客セグメント毎に、刺さる機能が判明する
- データ
- 顧客満足度データ
- プロダクトの利用機能ログ
こちらは、営業活動をより洗練したいというアイデアです。よりセグメント分類を正確にしたり、それぞれのセグメントに対してアピールポイントになる機能の発見を、既存の利用ログから探せないか？というデータ活用イメージに着地していました。
決定したいこと: 開発生産性を最大化するための組織のあり方
- 必要な事実
- 開発体制の変更によって、開発生産性の変化することが判明する
- データ
- GitHub ログ
- Jira ログ
こちらは、プロダクト開発のプロセスそのものをデータで改善できないか？というアイデア。決定したいことから出発しているので、プロダクトに直接関係しないデータの活用に着地したのが面白いところ。
決定したいこと: 不要な機能の削除
- 必要な事実
- 顧客にとって必要とされていない機能の判明する
- データ
- プロダクトの利用機能ログ
これは両チームで共通して出た項目です。どちらもエンジニアから挙げられていて、プロダクトを継続的に開発・運用していくことに対する課題感を垣間見た気がします。。
ブレスト会の結果の活用
各プロダクトチームにとっては、真ん中の「意思決定したいこと」が重要になってきますが、我々データチームとしては一番外側のデータの部分をしっかり構築していくことが課題になります。
例えば上で例として挙げたアイデアを見ると、
- 「プロダクトの利用ログ」は様々な意思決定に役立つので、優先度高く整備したほうが良さそう
- 「顧客満足度」はちゃんとしたデータがなく、そもそも継続的に計測するところから設計しないといけない
- 生産性を表すデータをすぐに表現できるのかはわからないが、「GitHub」「Jira」のデータを Snowflake に取り込むプロセスは構築して良さそう
みたいに整理できます。
整理した情報をもとに、Snowflake 内のデータを整備していくことになるのですが、どういうユースケースがあるのかがもう既にわかっているので、やっていることの意義を認識できてやりやすいなぁと個人的には感じています。
Help!
正直ブレスト会でこんなに意見が出てくるとは予想していなかったというのが本音でして、プロダクトチームの意思決定を加速させるためのデータ整備がまだまだ追いついていない状態です。
今！estie のデータ基盤を整備すると！プロダクト改善に直結することになるので！自己肯定感が爆上がりするぞ！
気になるそこのアナタ！まずはカジュアルに話しましょう！
もう少し知りたいという方はこちらの記事もどうぞ！
