ユアマイスター株式会社エンジニアブログ

ユアマイスター株式会社のエンジニアが日々徒然。

社内SQL勉強会でSQLを書ける人を増やし、データの可視化を推し進めている話

f:id:yourmystar_engineer:20190708094458j:plain

どうも。ユアマイスター星(@inase17000)です。

前回の投稿からだいぶ間があいてしまったということもあり、なかなか書き出せていませんでした。反省。 最近なんとなく始めたけど、意外と自分も楽しんでしまっている話をブログにしておこうと思います。

社内にSQLが書ける人が増えたらいいなーって思ってるひとのなにかの参考になれば幸いです。

きっかけ

ユアマイスターでは新機能の企画や、キャンペーンの効果検証などでデータベースからデータを取り出したいなと思った場合、ほとんどエンジニアに依頼をしてエンジニアがSQLを組み立ててデータを受け渡しする、という流れになっています。そしてredashがあるおかげで、クエリを保存できたり複製できたりするのでエンジニアチーム内でのやり取りに問題はあまり感じていませんでした。

しかし、今後マーケティングやプロダクトマネージメントのレベルをあげようと思ったときに、エンジニアしかデータ抽出ができないのはボトルネックになりえる&スピードを落とすことになると考えたため、他チームにもSQLを書ける人を増やそう活動をはじめたわけです。何人かに声をかけSQL勉強したいニーズを把握し、最小限の規模でスタートを切りました。

最初にやったこと

こういった自由研究的な活動で一番大事だと思っていることは、「やろう!」と決意することよりも「やり続ける」という実行の部分だと考えています。

人間は弱いもので、1ヶ月もすればどうしても初心を忘れがちになるもの。それは本業の忙しさであったり、難しい壁にあたり乗り越えられなかったり、いろんな要因がありえます。

迷いそうなときに自分を取り戻すためには、「Why?」を明確にすることが有効です。それはプロジェクトマネージメントにおいてもプロダクトマネージメントにおいても変わりません。

ということで、SQL勉強会に参加するみんなには1〜数ヶ月後の目標を立ててもらいました。

  • 欲しいデータを自分で作れる。
  • 自分に作れるデータと、作れないデータの判別がつけられるようになる。
  • 社員さんが30分かかって作ったSQLを1時間で書けるようになる。
  • 問題を貰ったらその日中に正解する。
  • 学んだことを言葉にして表す。人に説明できるようになる。
  • 初心者レベルを脱する。
  • 自分が必要なデータを見極められて正確に取れるようになる。
  • 理解できたら他の人にわかりやすく説明できるようになるまで詰める。

アクションレベルの目標も抽象的な目標も混ざってはいますが、それぞれ各人がSQLを学ぶ目的を自分の言葉で表明してから始めることを重要視しました。

そして、一週間程度数人で実行しながら生まれてきた合言葉も明文化することにしました。 かなり早い段階で、この社内SQL勉強会をヨットスクールに見立てて、小さな湾の中から大海に出ていくための練習場所として進めることを決めました。

SQLヨットスクール校訓

今回の社内SQL勉強会をヨットスクールに例えることにしたので、スクールの中の合言葉=校訓もヨットっぽい文章で仕立てています。

一. 宵越しのSQLを持たない

その日のうちにやれ。海に出たら明日があると思うな。

一. コピペのSQLに価値はない

自分の手で書け。コピペでできたつもりになるのが危ない。再現性をつくれ。

一. SELECT MAX(パッション) FROM 自分 WHERE 対象 = 'SQL';

熱意なきスクール生に風はつかめない。帆に満帆のやる気を詰め込んでくれ。

一. 取得するデータの意義を考え、肌で感じろ

そのデータを取る目的、期待値が北極星。自分の船を進める方角はデータの意義にあり。

それぞれ簡単に解説しておくと、

一. 宵越しのSQLを持たない

これは、本業との優先順位を考えるとどうしても後回しにしてしまいがちな学習に時間的期限を設けることで本人の意識を保とうと考えました。あと、実は数日越しでのレビューや相談は僕自身の脳内メモリも混乱していくのでそれを防ぎたいというのがありますw

一. コピペのSQLに価値はない

初心者にありがちな、ググって出てきたSQLをそのままコピペで動いたーと喜んでおわる学習にはなってほしくなくて、それぞれの構文の意味や使い方を手で書きながら覚えてほしいという思いから言語化しました。

一. SELECT MAX(パッション) FROM 自分 WHERE 対象 = 'SQL';

本人のパッション、自主性を中心に運営していきたいと考えていたので3番目に入れていきます。ただ参加しているだけで気づいたらSQLが書けるようになるなんてことはないよ、というメッセージでもあります。(ダイエットも同じ)

一. 取得するデータの意義を考え、肌で感じろ

今回の勉強会の主旨として、ユアマイスターならではのデータモデルも理解してもらおうと思っています。そのときに初期の段階から、実際に利用しているユアマイスターのテーブルやカラムの存在を認識しながら、自分の取得しているデータの意味を考えながらやってほしいと感じています。

こんなことを合言葉に、各人が意識しあいながら、別個の進捗で進めています。

どんなことをやっているか

スクールに参加している各人は最終的にエンジニアになるわけではなく、集計のための生データの抽出や集計自体をSQLでできるようになるのがゴールと捉えています。パフォーマンスを意識したSQLを書けるようになるのは下記のような基本構文を学んでからでよいと思います。

また、プログラミング言語のようでとっつきにくいSQLですが、簡単なSELECT文を反復練習で書いてもらう中で、ExcelでやっていたCOUNTIFやVLOOKUPの感覚をSQLでテーブルとカラムを使ってどのように表現するかというポイントに目を向けてもらうようアドバイスしました。自然と、過去の経験が活かされ理解がはやまったような気がします。(これは複数の言語やフレームワークを経験したエンジニアだったらわかると思いますが、◯◯でいうところの△△、という覚え方が助けになる感覚です)

それでは、具体的に毎日どんなやり取りをしているかをご紹介しましょう。

(学ぶひと)

  1. SQLの問題が欲しいとグループチャットで宣言
  2. 問題をもらったらチケット化する
  3. SQLを書き、終わったら添削を依頼する
  4. レビューされたSQLに対して修正があれば再提出
  5. 学んだことを振り返り、チケットに記載

f:id:yourmystar_engineer:20190708100504p:plain

問題文の例はこんな感じです。

始めて数日の人は...
①エアコンクリーニングのサービス一覧
②エアコンクリーニングのサービス一覧(公開中サービスのみ)
③エアコンクリーニングで、2018年に作られたサービス一覧(公開中サービスのみ)
④エアコンクリーニングで、2018年に出店した店舗のサービス一覧(公開中サービスのみ)

経験を積んできた人は...
①2019年1月以降の予約で、予約日から作業日までの日数別の件数
②2019年1月以降の予約で、予約日から確定された日までの日数別の件数
③2019年1月以降の予約で、予約日からキャンセルされた日までの日数別の件数

といった具合で、より実践的なSQLを抽出する経験を積んでもらえます。いままで自分が抜いたことのある切り口のデータに至るまでの段階的なプロセスを問題にしようと意識しています。

また、教えるひと=僕の動きはこんな感じです。

(教えるひと)

  1. 連絡があったらグループチャットで問題を伝える
  2. 適宜質問に答える
  3. 添削を依頼されたらレビューを行う
  4. ときに応用問題を追加で出してみる
  5. 定期的に振り返りと目標との差分を考えるよう促す

実際まだ日々カスタマイズをしているところです。毎回できるだけオリジナルな問題出そうとしてるのでなかなか大変><

1ヶ月やってみて勉強会参加者からのフィードバック

  • リアルなDB、テーブルを使ってSQLを学べるのがとてもいい。続けたい。
  • 参加者同士のアドバイスが発生していい感じ
    • 例)SQLに適宜コメント行を追加すると読みやすくなるよ!
    • 例)SQLをフォーマットすると見やすくなるよ!
  • パフォーマンスを意識した書き方が全然わからないので徐々に教えてもらいたい。

かなり前向きなフィードバックをもらえたため、継続していこうと思っています。この1期生たちが卒業するころには問題文もたまり、つまづくポイントもだいたい明らかになっていると思うので、資料などにまとめてプログラム化して横展開できるような知見にしてやろうと画策中。

今後の目論見

SQLを書けるひとが増えると、見たいデータを取得できるひとが増えます。すると、いろんなデータを見たくなるわけで。

そうなったときに、チームとして成長が必要なポイントが別の場所にうつっていくと思っています。

まずは、「どんなデータが欲しいのか」つまりデータの要件定義をする力が必要になってきます。と同時に、抽出されたデータを見て「どんなインサイトが得られるか」を考える分析・意思決定する力が必要になると考えています。それぞれデータ抽出前後の話にはなりますが、どちらかというと前者を優先して伸ばしていくことが重要です。

つまり何かデータを抜こうとする前に、仮説を立ててそれをどういう数字があれば実証できるか考える力が必要で、SQLを書けるひとを増やすとともに、ケーススタディをしながら養っていこうと思います。プロダクトに関わる全ての人が自由にデータを見れる状態を作り、即時の意思決定を助けられるように今後も取り組んでいこうと思います。

以上、長くなりましたが、社内SQL勉強会の紹介でした!