Androidエンジニアの私が2018年社内で最もSQLを書いた話
この記事は eureka Advent Calendar 2018 20日目の記事です。
早いもので2018年も残すところ残り10日となりました。 個人的に2018年の業務で行ったことを振り返ると、
- Android開発 (Kotlin)
- サーバーサイド開発 (Golang)
- データ抽出・分析（BigQuery Standard SQL / MySQL）
と様々なコードを書いてきたなぁとゆう感じがしています。その中で得た知見の一部はこのアドベントカレンダーでもAndroidのMotionLayoutとFirebaseAnalyiticsに関する記事を 2つほど他に書いていますのでよければご覧になってください。
去年に引き続きノリで3本予約したアドベントカレンダーですが、３本目となるとややネタに困ります。今年業務で酷使したBigQueryのWindow関数について書こうと思っていましたが、モテモテ機械学習恋愛工学博士のMizuki氏に書こうと思っていた10倍くらいの記事を書かれてしまいました。
毎日のようにSQLを書いていたなぁと思い、Redash Metadataでどのくらい書いたかを調べてみたところ、Redash上では社内で最もクエリを作っていること分かりました。ので、なぜこんなに書いたのだろう…とゆう回顧しつつ、Eureka内の分析環境やプロダクト開発で活かし方についてご紹介します。
Eureka社内での分析の担当しているメンバー
前項のとおり社内での分析の状況をRedash Metadataを利用して確認してみました。クエリの作成数のランキングとそのメンバーとそれぞれの担当チームが下の表です。
ご覧になって頂いてわかるのが様々な職種のメンバーがRedashでクエリを作っていることです。もちろん、ランキング内で人数が多いのは、BIチームとゆうデータを用いた意思決定を支えるチームですが、その他のサーバーサイドエンジニアやネイティブアプリのエンジニア、さらには非エンジニアであるプロジェクトマネージャーやマーケッターも上位に入ってきています。
当然Redashだけが分析ではありませんし、tableauなどの分析ツールも利用しているので一概には言えませんが、少なくともデータそのものが社内の多くのメンバーに対して開かれた状態にあります。
データの民主化
こうした意思決定に必要なデータに対して多くの人にアクセスできるよう整備されている環境のことがしばしばデータの民主化(Data Democracy)と呼ばれたりします。以下の記事はデータ関連の「民主化」の文脈で非常に勉強させていただいたのでご覧になってください。
Eurekaの環境のように社内の誰もが意思決定に必要なデータに対してアクセスできる環境は広義の「データの民主化」の一つに当てはまると思います。
BIチームの存在
このようにデータ分析の環境を整えて誰もが意思決定に必要なデータにアクセス可能にしている、いわば「データの民主化」を主導しているデータ界のアウンサンスーチーさんのような存在(?)なのがBI(Bussiness intelligence)チームです。
BIチームはデータの集積から整備、意思決定に必要な情報となるための分析・整形を行っているチームです。つまり、BIチームの恩恵をもろに受けてデータ分析ができ、私をはじめとしたデータ分析をメインとしないエンジニア・非エンジニアのメンバーがRedashなどのいくつかのツールを利用してデータにアクセスできるようになっているとゆうわけです。
データ分析のモチベーション
私はPairsのGlobal版(台湾・韓国展開中)のプロダクトチームに所属しています。メインはAndroidアプリの実装を行っていますが、Global担当のプロダクトチームで次に行う施策・機能開発について話あうことも多いです。
その中で、
「ユーザーは○○のような機能がほしいんじゃないか？」
「□□の画面があれば多くの人がメッセージ交換ができるのではないか？」
「△△があったら毎日アプリを開くのではないか？」
といった議論がなされることがあります。ただ、もしこういった仮説だけの場合「本当にそうなのか」といったアンチテーゼに対抗できません。何かしらその仮説を裏付ける必要があります。
例えば、定性的情報としてのユーザーインタビューや定量的情報となるアンケート、それに加え過去・現在のユーザー情報であるログデータ等の活用とゆう選択肢があります。
「ユーザーは、 XXのタイミングでアプリを使うと言っていたので、○○のような機能がほしいんじゃないか？」
「X割の人がYYの理由で利用してないと回答していたから、□□の画面があれば多くの人がメッセージ交換ができるのではないか？」
「X％の男性ユーザーがYの時間帯にZ分ほど利用するから、△△があったら毎日アプリを開くのではないか？」
これらの補足する情報があると仮説の確度が上がることが多いです。つまり「リリースしてみたけど全然使われなかった。」とゆうエンジニアとしても悲しいことを避けることができます。
より多くのユーザーに自分やチームで作った機能を利用してほしい、時間をかけて実装するならあまり使われないと悲しいよねといったごく普通の感情がデータ分析を行う支えになっています。
施策でのデータ活用時の注意点
プロダクトチームで行う施策では抽出・整形したデータは分析して、仮説の補強としても利用されることもありますし、効果測定に利用されることもあります。
データを元に議論することで、「○○じゃないか？」「いや ☓☓じゃないか？」といった漠然とした議論になることを防ぎます。(社内では空中戦と呼ばれたります) ただ、データがあっても議論や意思決定にうまく活かせないこともあります。
そこで、施策に利用する仮説・効果測定のデータを考える際に注意している点をいくつかご紹介します。
そもそもデータを元にした施策なのか
仮説づくりのために、DBにあるようなデータを利用することもありますが、ユーザーインタビューやアンケートなどの比較的定性的な情報を利用することもあります。このような情報はDBにあるデータでは見えづらいものです。ユーザーのニーズは必ずしも過去のデータにあるとは限りません。
一方で、そのような定性情報に基づいて行った施策の場合、効果測定においてデータを利用できる場面が多くなると思います。
「〇〇したい」と言っていたユーザーは本当にできるようになったのか？
この観点でどのような指標を追うべきかを考えるとより無駄になってしまう機能開発を防げることもあります。
抽出・整形しただけのデータだけを元に議論しようとしていないか
抽出・整形しただけなデータでは経験上議論が発散してしまうことが多いです。抽出・整形したデータをもとに考察を加えることが重要だと思います。これにより
その考察からどうするか？
その考察は別の見方ができないか？
考察を強めるには別のデータが必要ではないか？
といった議論の軸ができます。議論の発散を防ぎ、いろいろ話した結果、会議室の時間が終わってしまった。とゆうことが少なくなります。
ただ、困ったときにはあえて抽出しただけのデータを元に議論して、新しい意見を得られたりブレストのように次の手数を増やせたりすることがあるのも事実です。
セグメントの性質を見極めること
定性的な情報を得るためにはログなどのデータ抽出を行うよりもインタビューやアンケートのほうが有効的です。データ抽出・分析を行うのであればなるべく詳細なデータを出すほうが適切なケースが多いです。
極端な例で言えば、マッチングサービスの場合男女のデータをあわせて見たデータの可用性は高くありません。男性と女性で利用方法が全く異なりますしビジネス指標も異なります。他にも、長い期間の平均データなども季節要因や広告費等マーケティング環境の変動を大きく受け価値が低くなることが多いです。
適切にセグメントを分けてみると感覚に合致したデータが得られることが多いです。例えば
- 男性 / 無料会員
- 登録 24時間以内
- チュートリアルを突破している
- 年齢18~35歳
といったように区切ります。可能であれば外れ値と呼ばれるユーザーのデータなどもはずせるとなお良いです。
施策以外でのデータの活用
意思決定に必要なデータというとビジネス的な施策や経営的な判断などのイメージを強くもつかもしれませんが、Androidエンジニアとしてデータを活用しています。
Fabricで得られたアプリのクラッシュログの調査にもデータを役立ています。Fabricのログではデフォルトの設定だと時刻と端末の種類しか分かりません。Androidエンジニアの方はわかるかもしれませんが、複雑なクラッシュログの調査は端末の種類などの情報よりもどのようなページ遷移・操作を行ったのかだと思います。
そのために以下のように nginxやFirebaseAnalyticsのログ、APIでのサーバーサイドのログなどを掛け合わてみることによって、より調査に役立つ情報となります。
このようにBigQueryの一箇所に集積して見えると、以下の表のようにユーザーの一挙手一投足が手に取るように見えてきます。たった10秒間のイベントが数件から数十件確認できたりするので、特定のパターンでしか再現性のないクラッシュの調査には非常に役立ちます。
まとめ
数えてみると仮に365日毎日働いていたとしても、1日 1つ以上のSQLをRedashで保存していたので自分でも引きました。(Forkなどでのコピペのようなクエリも多いとおもいますが。)
Androidエンジニアである私がデータ分析をできる環境に、やっている上で注意している点、活用Tipsなどに関してご紹介してきました。データを見ることは好きなので今後も良いモチベーションにもなりますし、プロダクト開発での重要度は限りなく高いと思っています。
それができる環境に感謝しつつ、なにか一つでも皆様の参考になれば幸いです。
