こんにちは。ディレクターの川原田です。 クックパッドでお気に入りレシピを保存する「MYフォルダ」のサービス開発や、保存・記録に関する新規サービスの検討・開発を担当しています。
ディレクターの仕事は様々ありますが、今回は私が身につけたことで仕事領域が広がった！と感じているSQLについてお話ししたいと思います。
いきなりですが、SQLが使えてよかった点をまとめると以下です。
よかったこと
- 数値抽出から分析まで自己完結
- エンジニアとのコミュニケーションがスムーズに
- 仕事が増えていそうで実は効率アップ
- 周囲の知的好奇心を刺激
それぞれ具体例を交えてお話します。
数値抽出から分析まで自己完結
事例１：ログ構造を理解でき後の仕事がスムーズに
昨年、アプリのサービス開発を担当した際、エンジニアの設定したログが、実際に送信されるかどうかを事前チェックをしました*1。
アプリのリリースはタイミングが決められており、ウェブのようにリリース後の修正がすぐには反映できません。そのため、仕様や設定にミスがあると修正が反映されるまでの期間のログが欠損してしまいます。
ログの事前確認により、欠損を防げただけでなく、新規に設定したログデータの構造も理解できていたので、リリース後すぐにデータベースに蓄積したログをSQLで抽出し、利用状況の把握を自ら行うことができました。今まではエンジニアに抽出してもらうことが多かったのですが、自己完結できたことでエンジニアの負荷を軽減できました。
また、この時はログデータ構造を理解した際に、出したい数値を抽出するためのSQLを書いておいたのですが、この虎の巻がリリース後の自分やチームを助けました。
事例２：エンジニアのタスクを削減
SQLを使え、ログ抽出を自ら行うとデータ構造の理解も進むため、必然と会社のサービス全体のログ構造の理解も進みます。
今年初めに、Web版のクックパッドに機能追加を行ったことがありました。その際、既存のログ構造を把握できていたため、今回の機能においては新規のログ設定は不要、とディレクター側で判断がつきました。そのため、この時の開発においては、ログの設計や設置というエンジニアタスクが削減されました。
SQLがわからずともデータ構造を理解していれば同じことができそうですが、実装時にテスト環境で検証する際、テスト環境のログもSQLで抽出ができたので、今回に関してはログの新規設置が不要だ！と自ら確信が持てたことはよかったです。
エンジニアとのコミュニケーションがスムーズに
事例３：データ設計の検討時に、エンジニアと会話がちゃんと出来る
事例２の時、見たい数値が既存ログで対応できそうという予測がつけられ、実際に取得ができたことをエンジニアに共有することで、エンジニアも新たにログの設定が不要であることが理解できました。
今まではどのようにログが設定されるのか理解できていない状態で依頼をしていたので、設定後取得できないものがあったり、より深く調査したいと思っても不可能なことがありました。
SQLを身につけたことで、ログ設計の検討をディレクターだけで出来たり、エンジニアが行ったログ設計の内容を聞いてKPIの数値が確実に取れそうかの判断がついたりと、設計検討時に、より具体的な話ができるようになりました。私からのオーダーがエンジニアに伝わりやすくなりました。
事例４：エンジニアが書いた長いSQLをダブルチェックでき、書いた人も依頼した私もお互い安心（逆もしかり）
この頃、社内ではre:dashというツールを各部署で使っています。re:dashでは、SQLで抽出したデータをそのままグラフにでき、任意の間隔で自動更新ができます。また、複数のグラフやデータを組み合わせてダッシュボードとしてまとめられます。今までは抽出データをスプレッドシートに貼り付け、グラフ化し、そのシートを共有していました。
re:dashダッシュボードのサンプル
このre:dashの浸透により、様々なデータの可視化が便利な一方、可視化させたいことが多くあり、グラフ化するために複雑で長いSQLを書く機会が増えました。例えば「あるサービスに３ヶ月継続して訪問している人をアクティブ、それ以外を非アクティブして、その２グループの有料会員の継続率（１年間月ごと）を出す」などです。
少し時間はかかりますが、私のチームでは、あまりにも複雑そうなものはエンジニアと私で独自でSQLを書いてみて、結果を見比べ、その後にSQLを互いにレビューするという手法を取っています。
細かな点の漏れ（アプリのバージョン指定が間違っている、サービス閲覧の定義が足りていないなど）が見つかり、お互いのミスをカバーしあえます。
今では、エンジニアに複雑な抽出を任せっきりにすることは、お互いに不安だと感じるようになりました。
仕事が増えていそうで実は効率アップ
SQLを扱えると仕事が増えるのでは？と、思われるかもしれないですが、事例４に書いたre:dashというツールの採用もあり、以前よりも新規プロダクトの定期的な数値分析の効率はアップしています。
新規のプロダクトだと新たなログ集計ツールの用意自体が工数増になるので省略することが多く、日々SQLで抽出してスプレッドシートに貼って、、、ということが多々ありました。今ではすべてre:dashにお任せしています。
また、プロダクトや目的ごとにダッシュボードを作ることで、改めて分析し直す時や新たなプロダクトの分析をする際も、過去の様々なSQLから参考になりそうなものをさっと取り出せるので、ゼロから考えることが減りました。
さらに私自身のSQLの理解が進んだことで、見たい数値が取れてない！ということもなくなり、エンジニアとの認識齟齬もなくなっているので、結果としてチームの効率もアップしています。
周囲の知的好奇心を刺激
事例５：ペアプロならぬペアSQL
ありがたくも、周囲から質問だけでなくSQLを一緒に考えて欲しいと頼まれることも出てきました。
あるときは、ちょうど自分が最近身につけたウィンドウ関数を使った累積和や、事例４の時に身につけたwith句が使えそうだったので、説明しながら出し方を共に考え、実際に書くところまでを一緒に行いました。
人に教えることで自分の理解も深まり、普段自分が出そうとしている内容とは全く違うSQLを考えることで、分析の仕方に新たな発見もありました。
事例６：初心者向け勉強会を開催
上半期（１〜６月）まで所属していた部署は人数が多く、ディレクターも多くいました。私含め部署内にSQLが書けるディレクターがいる一方、SQLを書けないけれど興味を持っている初心者もいました。勉強会を開催することになり、私が講師役を務めました。
勉強会は、SQLとは何かをただ理解するだけではなく、「SQLを書く！」に徹した内容を伝え、実際に書けるようになることを目指した内容にしました。実践に集中できるように、SQLとは？という基本理解は、弊社エンジニア青木峰郎の著書「１０年戦えるデータ分析入門」の第１〜３章にお任せし、各自で事前に読んできてもらいました。
10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)
- 作者: 青木峰郎
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/06/30
- メディア: 単行本
- この商品を含むブログ (6件) を見る
また、勉強会当日は最初にお題を出し、以下のように「お題＝出したい内容（日本語）からSQLを作る、その作る過程で基本のSQL構文を理解してもらう」方法で伝えました。 お題を分解し、どこから（from）、どんな条件の（where）、何を（select）出すのか？を考えた上でSQLを書いてもらいました。
スライド抜粋
また、私が普段実践している「出したいことがあっても出し方がわからない（何のカラムを見たら良いか、カラムに何が入るのか不明な）時は、実際に自分で操作して自分のログを抽出する」という自己解決法を伝えました。誰でも今からやれる方法ですし、エンジニアに聞く前に少し調べるだけで、解決したり、聞き方が明確になったりして有益だと思っています。
勉強会の実際のスライド（一部抜粋）は以下です。
勉強会で人に教えることで自分自身の理解が深まったり、理解しやすい伝え方を考えたりと、とてもよい機会でした。また、参加してくれたディレクターのみんながその後チーム内で継続して、SQLを習得するために１週１題を実践しています。 自分の知見を共有することで、周囲にもよい影響を与えることができ、とてもよかったです。
最後に
SQLが書けると色々な数字が出せること自体が面白くなり、データ構造がわかるとあれこれ調べたくなります。それはそれでデータ分析の入り口に立てた！という意味では良い気がしますが、どんな仕事も同じで、その仕事の目的を明確に持ち、また常にその仕事の目的が何かを意識すること、単に作業すること自体を目的にしないように心がけることが、当たり前ですが大事だと思います。
この会社で、初めてディレクターという職種で２年半働き、様々なことを周囲から学んだ中で、特にこのSQLのスキルに関しては身につけて心底よかった！と思っています。この記事が、もし今後SQLを学んでみようという方の役に少しでも立てたら幸いです。
事例６で紹介した本はとてもわかりやすいので、最初の１冊にされることをオススメします。
*1:この時はAndroidStudioを使いました
