トップ > データ分析 > SQLレクチャー会をチーム内でやっている話

SQLレクチャー会をチーム内でやっている話

データ分析

ここ最近、チーム内でSQLのレクチャー会をやっています。世間的にはプランナーの人や営業の方がSQLを書くのもそれほど珍しいことではなくなってきていると思いますが、チーム内ではまだまだ一般的ではないです。なんとかしていきたい。

SQLレクチャー会の目的はこんな感じです。

  • チーム内のSQL / 分析力の底上げ
    • データの民主化的なやつ
  • データライフサイクルの改善
    • 集計側であれこれ無理に頑張るより、入力データを集計側に合わせてもらうほうが圧倒的に省力化されることが多い
    • データの入力側と集計側の意識を合わせることで、チームのデータ分析のしやすさを高めていきたい
  • 毎月、毎期末作っているスプレッドシートの自動化
    • 手間を減らしたり、手作業によるミスを減らしたり

このエントリをきっかけに「うちでも似たことやってるけど、この取り組みをやってみたらさらにうまくいったよ」といったことが知れるとうれしいです。

背景: レクチャー会のパートナー

営業事務チームのid:shiozaki-aさんと一緒にやっています。バックグラウンドはこういった感じの方です。

  • 様々な仕事で助けて頂いてますが、このエントリの文脈だとSalesforceの管理やレポート作成などをしてくださっています
    • 主にセールスチームやプロデューサー向け
  • スプレッドシートでの集計やダッシュボードの作成は慣れておられる
    • レクチャー会スタート時点ではSQLを含むプログラムの経験はなかった
  • 混み入ったレポートをSalesforce上で作るのがなかなか難しいという課題感
    • できるできないで言えばSalesforce上でもきっとできると思うのですが、Salesforceエンジニア的な人がチームにいるわけではない
  • 毎月、毎期末作っているある程度定型のスプレッドシートやダッシュボードがいくつかあり、それらを自動化したい

id:syou6162がSQLの解説をして、id:shiozaki-aさんに練習問題を解いてきてもらって、という感じで週1~2回(一回1時間程度。6月から始めて、今日で13回目でした)のペースでやっています。

レクチャー会の内容

こんな感じでやっています。

  • レクチャーパート
    • id:syou6162が今日のお題(例: GROUP BY)を解説
    • 普段の業務に関連しているようなレポートの簡易版をSQLで書いてみたり
  • 実践パート
    • 毎回5問ほどid:shiozaki-aさんに練習問題を解いてきてもらう
    • 完璧に解けている必要はもちろんなくて、できたところまでをscrapboxに張ってもらったり、考えた過程を書いてきてもらう
    • 「こういう捉え方いいですね」とか「ここは一気にやるのは難しいから、小さい問題に解きほぐしていってみましょうか」という感じで、わいわいSQLを書く

約二ヶ月前のスタート時点はSELECT ... FROMから始まり、最近だと以下のような内容をご自身で解いてもらえるようになりつつあります(すごい!)。

  • ORDER BYやLIMIT
  • GROUP BYを用いた集約
  • WHERE句を使ったフィルタ
    • サブクエリとかも一緒に
  • DATE_TRUNCなど頻出のデータ変換の方法
  • JOINを使って複数のテーブルを結合した分析
  • BigQueryで抽出したデータをData Studioやスプレッドシートを使って可視化、分析
  • ウィンドウ関数を使った過去の時点との変化の分析など
    • ここは難しいところもあるので、もう一周しようかなと思ってる

10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)をベースに、自分たちの業務を題材にレクチャーしたり、練習問題を解いてもらったり、という感じです。

レクチャー会にあたって気を付けていること

実務で使うデータを元に練習問題を作る

巷にはSQLの本が山程出ています。そういった本をベースに勉強してもらう、ということも考えたのですが、このレクチャー会ではそれは意図的にしませんでした。本をベースにすると、サンプルデータセットが付いてくると思うのですが、それが実務のデータと近いとは限らないからです。SQLも覚えないといけないのに、仕事とも関係ないデータについて頭に入れておくのは大変だし、そもそもデータに対する興味を持ちづらいと思いました*1。

今回のレクチャー会では、Mackerelの業務で使う馴染のあるデータ(具体的にはSalesforceの商談やキャンペーンの情報などをBigQueryに転送したもの)を元に、id:shiozaki-aさんが課題に思っておられる題材になるべく近いものを練習問題として手作りしました。こうすることで

  • データセットに対する理解はすでに頭にある状態からスタートできる
    • どういうテーブルがあって、あれとこれはJOINできそうとか関連付いている、といったことをイチイチ意識しなくてもよい程度にはデータのことは知っている
  • 直近の課題を解決できるかもしれないし、普段の仕事も楽になるかも...という感触を持ってもらえると、自分事として取り組んでもらいやすい
  • 集計結果がおかしい、といったことに対する肌感がある
    • 集計結果に矛盾がありそうだから、なんかSQLミスってる...?といった感覚は馴染のあるデータでないと持つのはなかなか難しいです
    • 小難しい分析テクよりも、ドメイン知識のほうがずっと大事

恐怖心を持たずにSQLを書けるように整備する

プログラムを書いたことのない人にとって、謎の英単語が並ぶSQLを書いていくのは最初は怖いことだと思います。恐怖心があるとなかなか勉強が進まないと思うので、雑に触ってもらっても大丈夫なように環境を整備しました。

  • GCPやBigQueryの権限は最低限に絞る
    • 既存のビューやテーブルは変更 / 削除できないようになっている
    • どれだけ触ってもらっても他の人の成果物を壊したりすることはないので、自由に使ってください
    • 今のところ、BigQueryのWebコンソールからSQL叩いてもらってます
  • BigQueryを使う上では、大量のデータのスキャンが走って課金が大変なことに...という恐怖もあると思う
    • スキャン量の上限が設定されていることや、定期的にスキャン量の多いクエリをデータ基盤側で監視しているので、もしまずかったらid:syou6162から言いに行くので大丈夫ですよ、と伝える
    • 触ってもらうデータは営業系のデータなので、スキャン量は気にする必要もほとんどない、といった背景もあります
  • 画面共有をしながら、細かいハマりどころを一緒に潰していく
    • 赤文字の英語で何か怒られてしまって、頭がフリーズしてしまう、というのは最初はあることかと思います
    • エラーが出たらしばらく自分で考えてもらって、難しそうであればエラーが何を言っているか、どうやると解消できるか、一緒に画面を見ながら探っていきます
    • Google Meetの画面共有をしながらやっています
      • 元々、東京と京都で地理的に離れていることもあり、コロナはあんまり関係なくリモートで画面共有しながらやってます

相手の背景知識に合わせて説明する

id:shiozaki-aさんは営業事務をずっとやられているので、スプレッドシートの扱いは慣れておられます。SQLとスプレッドシートは考え方が似ているところが多々あるので、「SQLについて説明する」というよりは「スプレッドシートでこういう操作のことを、SQLで書くとこうなるんですよー」という説明を多用するようにしています。「スプレッドシートの裏側では実はこういうSQL相当のことが行なわれているんだ」ということが頭の中で分かってもらえたら、SQLの理解も早まったように感じました。

あと、全てをSQLで完結させることに拘らないように気を付けています。ある程度の集計までやってしまえば、後は慣れたスプレッドシートでやってもらってもいいです。例えば、縦持ちから横持ちへの変換はSQL単独でやると割と面倒ですが、スプレッドシートやData Studioのピボットテーブルでやってしまえば一瞬ですよね。ツールは適材適所かつ相手の得意を生かせる形で、を意識してます。

正解に辿り着くまでの過程を共有する

慣れている人間がSQLを書くとばっと書けることも多いですが、慣れていない人はもちろんそんなことはできません。また、最終的なSQLだけ見てそれが理解できたとしても、それを一から自分で構成するのは難しかったりします。

そういったこともあり、レクチャー会では正解に辿り着くまでの過程でどう思考しているか、を丁寧に説明することを心掛けました。長くなったSQLのデバッグはエンジニアでもしんどいので、なるべく細かくステップに分割するように勧めました。WITH句を多用することで個々のSQLはなるべくシンプルに、BigQueryに怒られたとしてもどこで失敗しているのか考えるべきスコープが小さくなるように、という意図です。例えば「担当者×月毎の商談数を出す」というお題なら

  • ひとまず、担当者と商談を一緒に眺められるようにしよう
    • JOINだけやってみる
  • 月毎に商談数を出したいので、月で丸める必要がありそうですね
    • DATE_TRUNCだけやって、月で丸められているか確かめる
    • 例えばこの辺でWITHでまとめておく
  • 担当者×月毎に出したいので、GROUP BYと集約関数使うとよさそうですね
  • ちょっと見にくいので、日付でORDER BYしてみますか
  • セールスの人からはピボットテーブルで見たいと要望がいかにもきそうなので、SQLで出した結果をスプレッドシートを使って横持ちに変換してみましょうか

といった細かいステップに分割しながら説明しています。WITH句を説明するときも、スプレッドシートのアナロジーで

  • WITHの中身の一個一個のクエリは、スプレッドシートのタブに相当しているものだと思ってもらって大丈夫です
  • スプレッドシートの個々のタブでは、シンプルな集計や変換だけをやりますよね
    • それを繰り返して最終的に欲しい集計結果を作っていく
  • SQLを書くときも同様で、WITH句で各ステップは簡単なSQLで構成して、徐々に積み上げていくとよいです

という感じで説明しています。

教える側 / 教わる側という構図はなるべくしない

巷のSQLの本をベースにレクチャー会をやると、SQLを教える側と教わる側という構図にどうしてもなってしまいがちかなと思います。しかし、実際の仕事のデータを元に練習問題を作ってみると、作る側にとってもメリットがありました。

  • データや分析のことをきっかけに、普段の業務の課題意識を共有しやすい
    • お互いが「あれどうにかしたいなー」と思っていること、実はそんなに大変じゃないとか、一緒にやるともっと簡単にできるとかありますよね
    • SQLやデータ分析は職種が違ってもコミュニケーションを取りやすくする一種のツールや共通言語みたいなものだと思っています
      • 共通言語があると会話もしやすくなる
  • データ基盤の生の使われ具合を見ることができる
    • これは僕の今の仕事がデータ基盤を整備する人間である、という背景があります
    • データ基盤は単独では価値を生まなくて、分析する人が正確かつスピーディーに分析結果を意思決定に役立ててもらって、初めて価値が出るものです
    • レクチャー会や練習問題を解いてもらっているのを横で見ることで「ああ、ここ確かに紛らわしいな。メタデータに意味書いておかないと...」「この条件の集計苦労されていることが多いから、データウェアハイスに集計済みのものを提供したほうがいいな」など、分析者がどこが使いにくそうかといったデータ基盤の管理者的にはとても重要なフィードバックが得られます

こういった背景もあり、教える側 / 教わる側というより、双方にとって意義のある会にできれば〜ということを考えながらやっていますし、id:syou6162としても毎回学びが多いです。

shiozaki-aさんのレクチャー会の感想

ご本人の許可をもらったので、転載します。

SQLの勉強会をしてもらってるとセールスチームに言うと、そこまで頑張るんだって驚かれます。
わたし的には、知らないことを知れるのは楽しいので特に頑張ってる感じではないけど周りの感覚だとそうなんだな～と不思議な感じです。
syouさんも書いてたけど、「謎の英単語を書き連ねていくSQLを書いていくのは最初は怖いことだと思います」は確かにそうだと思います。
PCの設定さえ、会社のシステム担当にやってもらうのが当たり前で育ってきた事務畑の人間には、
黒い画面（エンジニアの人がコード書いてる画面のことを勝手にこう呼んでますww）みたいで、
私が触って大丈夫か！？？？という不安と、自分とは別世界のお話という感覚があり、自分で独学勉強する分野だとは思えないww
触って大丈夫だと太鼓判を押してもらって、その上教えてもらえる天国のような状況です！！！　
今回はsyouさんに声をかけてもらえて、勉強できる環境（時間・説明資料・練習問題）を整えてもらえたから出来てる。という状況です。
SQLの勉強してきて、セールスフォースの項目やいろんな実装についても考える事や、気づきがあった。
（例：受注予定月の項目を「●月」という文字列で持ってるけど、データ集計する時にはそれじゃ意味がないな。とか）
実際に使っているデータを元に説明してもらったり、練習問題やったりできるのはめっちゃありがたい。
この間JOINのところを本で読んでる時に例として書かれているデータの項目とか並びとかをを見とくだけでも大変で、
途中で飽きて後で再読ってなったので知ってるデータだと理解しやすいってことを余計に感じました。

参考: 他社さんの事例

*1:なぜなら普段使っていないサービスのデータに対して、自分は全く興味を持てないから...!