最近は、はてなブログでグロースハック的なことをやっている 
id:polamjag です。このエントリははてなエンジニア Advent Calendar 2018 の 20 日目のために書かれました。
昨日のエントリは SRE の 
id:hokkai7go さんによる re:Invent2018に行ってきました - Hatena Developer Blog でした。re:Invent アツいですね。Amazon.com の CTO のキーノート、Skrillex のロゴ T シャツを着ていて、一体どういう文脈なのかと思ったら Skrillex が re:Play というアフターパーティーに出演していたらしいということを知り、そこからもスケールの違いを感じました。
今の数字がどうなっているのか、どう取っているのかを調べられるのはエンジニアだけかも
サービスを伸ばすためにどういう施策をやったらいいのか考えたり、考えた施策の優先順位を決めたり、といったときには、普通はなんらかの数字が重要な判断基準になると思います。数字といっても、今月の売上はいくらでした、といった粒度の数字だけではそういった判断はできないはずで、なぜ売上がそうなっているのか説明できないと本質に近づくことはできないと思います。
いわゆるコンシューマ向けのサービスであれば、ユーザーのみなさまの行動が重要な説明材料になるはずです。既に多くのユーザーさんに使っていただいているサービスであれば、今月はこのサービスでどういう行動をしましたか、なぜそうしようと思いましたか、といったことを全員に直接質問して回るのはたいてい不可能でしょう。というわけで、ユーザーのみなさまの行動のログをとっていい感じに分析できる必要がある、というふうに言えるでしょう。
Web アプリケーションやスマホアプリにおける行動ログを集計する仕組みには、概ね以下のような段階やジャンルが存在すると思います:
- 行動ログを集めてるデータ基盤的な存在があるならそれで
- Google Analytics などのサービスを入れていて、それで見れるメトリクスならそれで
- サービスのデータベースに入っているアプリケーションのデータを集計することもあると思います
- 基盤めいたものに入っていない状態なリバースプロキシなどのアクセスログを直接集計するのは最終手段に近い
- どのようなセグメントのユーザーによる操作なのか、といった情報は普通のアクセスログには現れない
こういった仕組みの面倒を見るのは、基本的にはアプリケーションエンジニア (あるいは SRE などインフラサイド) の担当であることが多いと思います。また、実際にどういうフックポイントでどういう情報を送っているのか、データベースはどういうスキーマで何が保存されているのか、ということを知っているのも当然ながらアプリケーションエンジニアであるはずです。
ログについては、社内にそういうチームや横断組織があるならうまく連携してやっていくという感じかもしれないですし、なければとりあえずチーム内でまわしていくということになろうかと思います。手元にそういう仕組みがない状態でも、昔のログがとりあえず S3 に置かれてあれば、そこそこ大規模であってもほぼ前準備なしで Amazon Athena でいい感じに集計できたりと、まず素朴な数字を見てみてスタート地点に立つということをやりやすくなっているのではないかと思います。
ということで、実際に施策の実装をやっていく前のフェーズでも、アプリケーションエンジニアがグロースハックめいたことをやっていくためのスタート地点以前に立つためにできることはいろいろありそう、そのあたりから回していけるとチームの初速を出せるかもしれませんという話でした。
明日は 
id:takuji31 さんが Kotlin についてなにか書く回です。引き続きはてなエンジニア Advent Calendar 2018をよろしくおねがいします!
