前々からやろうやろうと思っていて今年ちゃんとやったことに SQL があります。

今年坂本くんが入ってきたタイミングで教えてもらって、
現在は作ってもらったアカウントで自分で Redshift からログを
叩いて必要な分析データを収集しています。

元々これをやりたいと思ったきっかけは、
「そもそもこれエンジニアの仕事じゃねーんじゃね?」と思った事です。

新しい施策の評価、次の施策の為の下調査の為にログを叩いてもらって
データを出すという事をやっていたのですが、

・そもそも構文が間違ってなければ誰がやっても結果が同じ
・結果の確からしさを一番分かるのはPかD(この数字は1日で2倍にならないでしょ、的な)
・施策やサービスが軌道に乗るまでは変更が多くて、システム化しづらい

ってなわけでどう考えてもビジネスサイドの数字担当、具体的にPかDが
やった方が時間的な話はさて置いといて良いだろうと思ったのです。

また、個人的には「ここのログにはあれがあって、ここのログにはこれがあるので、
こうしてもらえるとこういうデータが出ますんで」

って感じでお願いしてたのですが、頭の中では
「だったらこれ、俺がそういうふうに SQL かければ解決すんじゃねーの?」
って思ってました。

で、やってみると捗りますのでオススメです。

・捗り(1):どこで何のログが吐かれているかがわかるので、プロダクト設計時に
お願いしやすい。

そもそもSQLを書くにはどこのテーブルのカラムがなんなのかを理解できないと
いけないので自然と覚えます。

それは即ち、自分の担当事業の何が可視化されているか?のリストです。

そこまでわかっていると、どのデータが出せて、どのデータが出せないかが
理解できます。それがあれば、新たな設計をする時には
「ここのログはこう吐いといて下さい、後で○○分析しますんで」という言い方ができます。

まあ、当たり前にやっておけよって話ではあるのですが、
スピードで立ち上げる時にはね、全てを想定しきれないのよ。

・捗り(2):エンジニアに無駄に手を止めさせる事が少なくなる。

良いことです。エンジニアはエンジニアリングに集中してもらいましょう

・捗り(3):分析の為の分析現象はまず起こらない

そもそも数字責任を追っている人が分析をするので、必要な分析だけになります。
他の人にお願いした時の「ちょっと手が届かない感」がなくなります。

個人的にはこれが一番快適かな。

必要なデータを必要に集計する。良い事です。出し戻しが無くなってみんなハッピー。


というわけで皆さん、2016年は英会話を目標にするより、SQLを目標にしましょう。

サイバーエージェントの社内英語化はまだ起こらないかもしれませんが、
SQL ならいきなり使えますよ!

ちなみに来年は TECHCAMP さんにいってアプリ作成を覚えたいと思っています。
なかなかお値段が張りそうですのでここに書いて自分を追い込む事にしました 笑