エンジニアが分析をする上で心得たいこと〜初歩編
分析が必要になる時がくる
ベンチャーのエンジニアは、プロダクトがスタートアップフェーズをなんとか乗り越えると、ユーザー数がある程度落ち着き、各KPIを上げていくぞ！という段階に移っていきます。
そのような中で、あまり分析に気を使っていなかった状態から、徐々にどういったことに意識していくべきかをイメージして書きました。
プロダクトの成長線に合わせ、分析にフォーカスしていく
エンジニアの仕事とは
普段僕らが使っている時間を振り返ると、多くの時間はコードを書き、それをメンテナンスする作業が多くを占めているかもしれません。
しかしそれらの作業は全て、「プロダクトを作ることを通してユーザーに価値を届けること」のためにあるはずです。
普段している作業はあくまでそのステップのひとつに過ぎません。
エンジニアの業種業態で異なることがあるかもしれませんが、少なくともFiNCのエンジニアは「プロダクトを通して世界を変える」ことに向けて努力しています。
ユーザーの価値があいまいな機能はそもそも作ってはいけない
グロースフェーズになると、中長期的にプロダクトの改善を行う必要性が高まります。
なので、「なんとなくこれあれば便利そう」と気ままに機能をつけていくとPDCAができなくなるので、やるべきではないでしょう。
また、機能改善をしている中で「これはどう考えても必須」のように見える機能追加もあるかと思いますが、当たり前だとしても言語化・定義化することがPDCAのスタートラインです。
うまく言語化できない場合もあるとは思いますが、それでもよいと思います。何かしら言葉にしておきましょう。直感を否定するわけではありません。
ユーザーへの提供価値が暗黙の了解になると、仕様も何が正しいかわからず、おのずと仕様が単なる好き嫌いの争いになりやすいです。「どんな価値を届けたいか？」がわかると説得力が増し、意思決定のスピードも早まると思います。
ユーザーに提供できた価値を確かめるのも、エンジニアの仕事になる
機能の追加・改善はリリースするだけでは、本当に価値を届けられたのかはわかりません。もしかしたら気付かないうちに改悪していることすらありえます。
プロダクト開発をする中で「この新しく追加した機能はどういった変化をもたらしたか？」ということを確かめる必要が出てきます。
その結果によって、その機能をCloseすることもあるし、厚くしていくこともあります。
ユーザーのポインターや画面タップの動きを映像的にトラッキングできるツールなどもありますが、まず最初は豪華なツールはいらないので、基本的な数値をみれるようにしていきましょう。
分析を考慮した実装ステップを取り入れる
この4つのステップを踏めば、まずは十分だと思います。
- 1.作ろうとしているアイディアの提供価値を確認する
- 2.どの数値がどのように変化するかを仮説を立てる
- 3.現状の数値感を見る
- 4.実装するときに改善の数値が取れるように仕掛けておく
1.作ろうとしているアイディアの提供価値を確認する
そのアイディアが上がってきたということは、何かしらの課題に対して解決できるという期待があるはずです。
まずはそのアイディアが何を解決をするのかを、定性的な言葉で書いてみます。
例: アプリ内のお知らせ機能に、画像サムネイルの表示を加える
文字だけで視認できる情報が少ないため、ほとんど開かれていない。
お知らせ内にお得なキャンペーンを配信することがあるが、その訴求を強められるようにしたい。
など
上記は例ですが、もっとしっかり書くやり方はあります。
これをどこまでしっかりやるべきかは、人員や施策のスコープを見てきめましょう。
リニューアルなどの大きな改善は重厚にやるべきだし、小さめの課題解決ならシンプルに書くだけでもよいと思います。
2.どの数値がどのように変化するかを仮説を立てる
定性的な価値定義から、その価値を享受していると言えそうな数字を探していきます。
まず、ユーザーに価値を届けるまでのバリューチェーンを簡単にでも書きましょう。
例: お知らせ配信のバリューチェーン
お知らせを受け取る → お知らせ一覧を開く → お知らせを選択して遷移する → 内容を見る今回は、このバリューチェーンにおける「お知らせを選択して遷移する」という部分にフォーカスした開発になるので、見るべき数字はひとまず「サムネイル付きのお知らせ遷移数/お知らせに来た回数」だとざっくり見積もれます。
3.現状の数値感を見る
もし数字が取れているものがあった場合は、出しておきましょう。
数値を出してみて、そもそもお知らせ一覧に全くアクセスがないとわかれば、優先順位をバリューチェーンの前方に移した方が得策かもしれません。
（少し話は逸れますが、こういった際の優先順位を決める際には「インパクトx工数」をもとにして決めることが多いです。インパクトが少なくても、工数が相当小さかったら先にやってしまうのもアリです。）
数字が取れてなかった場合は、バリューチェーンにおけるどの部分が欠落しているのかを確認して入れていきます。
4.実装するときに改善の数値が取れるように仕掛けておく
機能改善・機能追加をする上で、作りたいものの機能要件（使用定義・完成イメージ）があると思います。
分析をできる環境を整えるためには、機能要件を満たすだけでなく、「分析要件」も満たす必要があります。
場合によっては機能要件で作ったDBで事足りることもありますが、例えば今回の例の場合では機能要件を満たす以上のことをする必要があるからです。
例: お知らせ機能改善の最低限の分析要件
（前提：ユーザーテーブルとお知らせテーブルが存在していること）
・お知らせ一覧が表示されたログを、ユーザーID、datetimeで残す
・お知らせを開封したログを、ユーザーID、お知らせID、datetimeで残すこうした数値を貯める手段をごく簡単ににまとめますが、結論から言うと「2」が分析の幅が広く対応しやすいので、オススメです。
方法1: アプリケーションのDBに分析用テーブル/カラムをとりあえずつけてしまう
今回の場合でいうと、お知らせのテーブルが存在すると仮定して、そのテーブルに read_at などのカラムを追加する、という方法などです。
そのイベントのタイミング（お知らせ遷移したタイミング）で、そのカラムを更新する処理をつける、といった具合です。
しかし、もしその read_at がアプリケーションロジックに全く関係なく、本当に分析にしか使われないとしたら、あまりベストな方法ではないでしょう。
方法2: アクセスログ/任意のアクションログを記録できる環境を整える
ユーザーのアクセスログを溜め込んでおき、クエリで抽出できるデータウェアハウスなどがあれば便利に分析ができます。（AWSのRedshift、TreasureDataなどがあります）
これで全てのログを残せる環境を整えれば、特定の機能に限らず汎用的に分析をすることができます。
また、分析のために任意のイベントのタイミングでログを吐くようにすることで、取りたい数値を自由に設定することもできます。
方法3: 分析専用のSDK/ツールを使う
Google AnalyticsやFireBaseなどは、管理コンソールから非エンジニアでも使えるようなUIで簡単な数値を見れることができます。
ただ、より詳細な込み入った分析をする際には、エンジニア側でフラグをつけてあげたりする必要はあります。
取れた数値を見える化する
最初はテンポラリーで数値を出す
もし充実した可視化ツールをお持ちであればここはあまり気を使う必要はないのですが、まだ利用ユーザーが安定しないお試しの機能追加・改善であれば数値のビジュアライゼーションにそこまで多くの時間を割く必要はないと思います。
まずはcsvなどにraw dataを吐いて、そこから簡単に集計してみて、まずは結果を確認することが大事です。
機能が安定したらいつでも見れるようにする
もしその機能がプロダクトUXのベースをなしており、継続的に数値を監視していきたいものになれば、数値を集計して表示するアプリケーションを用意すると、テンポラリーで数値を出すよりコスパが上がります。
データのビジュアライゼーションツールは数多く存在しますが、やはりどれもコストがつきます。
ただ、そこまでコストがかからなくとも利用できるものもあります。
参考: データ可視化に大金を使う必要なし-最強biツールpowerbiを導入してみた
まとめ
- プロダクトのスタートアップフェーズを終えたら、PDCAを回せるように数値を取りましょう
- 数値が取れているかを意識して実装をしましょう
現在FiNCでは基本数値の見える化が終わり、これからはその数値を「どう見るか」を踏まえてプロダクトの改善をするフェーズにいます。
ヘルスケアアプリのグロースハックをこれだけふんだんにできる環境はないと思います！
FiNCでグロースハックをする人を募集しています！
「データは分析するだけじゃ意味が無い！」そんなデータアナリストWanted!