データ講習「SQLチャレンジ講座」を開催してみた
どうも、yuchidaです。株式会社オトバンクの片隅でデータ分析をしている者です。（フルリモートにつき勤務はおうちですが）
お初の方は是非マガジンの方で最初の記事から読んでいただけると大変喜びます。
https://note.com/otobank/m/mf2bc5d097614
せっかくなので会社のことをちょっと説明すると、オトバンクはオーディオブックという「本を音声化したもの」を売る「audiobook.jp」というサービスを提供している会社です。
日本発のオーディオブックの会社として黎明期から業界を支えてきた「FeBe」が2018年3月にリニューアルしました。ちなみに私の初出社日がこのリニューアルの前日という奇縁です。
日本語オーディオブック数No.1のaudiobook.jp、話題のビジネス書からハイクオリティの文芸まで色々取り揃えています。聴き放題は初月無料なので、時代のニュースタンダードに興味がおありの皆さんは是非使ってみてくださいね。
お得な年割プランも是非お試しください。
さて、前回記事からずいぶん時間が開いてしまいましたが、日々粛々と業務をこなしております。具体的には今回お話する内容を色々としていました。
いつもどんな業務をしているのかは、以前お話させていただいた通り主に3つ。
①改善施策の分析設計＆分析
②他部署の方々が自力でほしいデータを取り出せるようにするための手助け
③施策を考えるための材料になるデータを共有する
今回はこのうちの2つ目、「他部署の方々が自力でほしいデータを取り出せるようにするための手助け」についてちょっと大きめの試みをしていたので、その辺りを共有させていただこうかと思います。
データの民主化のために
オトバンクでは、意思決定においてデータや数値を重視しています。データを全く見ないで意思決定するのは、自分の好みやその場の雰囲気で決定しているに過ぎない、という考え方です。もちろん定性情報も大事で、時にはデータや数字を取れない/それを超えた意思決定もするのですが、定量情報を取った上で判断するというのが基本スタンスです。
ただ、そのデータの取り出し方をわかっている人が少ないのが課題でした。BIやPMの一部だけが定量情報を扱え、それ以外の人たちはBIに依頼して数字を出す、という状況。これだけデータが重要と言いながら、そのやり方について適切な形でレクチャーし誰もがわかるようになっていないのはおかしいのでは、と反省しました。そこで、みんなが定量的なデータを使って意思決定していく（定量「だけ」使うではなく、定量「も」使う）組織にするために、講座を開催することにしました。名付けてSQLチャレンジ講座です。
これを受ければあなたもSQLが書ける！（…ハズ）
SQLチャレンジ講座のゴールは「自分の部署で必要なデータを自分でSQLを書いて出せるようになる」と設定しました。
ただ、今回受講する方々はそれぞれ習熟段階も、必要なデータの質も全く異なります。普段営業業務などをやっている完全未経験の方から、プロダクト開発やCRMをやっていて業務でもかなり使ってる人までいたため、一律にゴールレベルを設定してしまうとかなり習熟に差が出てしまいます。
そのため、プロジェクトのゴールを「初学者用」「習熟者用」の２段階に分割することにしました。
2段階式のゴールにすることで複数のニーズに対応。
初学者用ゴール：audiobook.jpについて基本的なデータが出せる
習熟者用ゴール：分析や施策に使う応用的なデータが出せる
初学者は、いわゆる営業先に提出する資料等を扱うのですが、アプリの利用履歴など応用的な所を見る必要が少ないため、基礎的なデータが出すことができれば十分です。
教材
今回使ったのがこちらの講座。Naoki Shinbo様の作成された「ゼロからはじめるデータ分析のための実践的SQL入門〜最短経路で現場で使えるSQLを習得〜」になります。
完全初学者にもおすすめです。
https://www.udemy.com/course/sql_for_data_analytics/
講座として非常によく纏まっており、SQLの初学者でも十分に内容が理解できるものとなっています。
データベースとしてはBigQueryを使用しているのですが、自社では主にMySQL・Prestoを利用しているため、使用できるクエリの構文等が若干異なっていたりすることもあります。
そのため、この講座をベースにして細かい点を補足するという形での講義形式になりました。
どんな事をやったか？
まずは講座を受講
講義は週１回、受講者の方々にはそれに合わせて１週間に１章ずつ自学してきてもらいました。（最初の２章は説明と準備なので３章までまとめて初回分）
第1回：データベースから生データを取り出す
第2回：取り出したデータを加工・集計する
第3回：複数のテーブルからデータを取り出す
第4回：サブクエリを使えるようになる
第5回：出したデータを適切に加工する
SQL触ったことある方ならなんとなくどの回でどの構文の事やってるんだなーとご想像つくかと思いますが、恐らくだいたい合ってます。
…実際これ講義作るために私も受講したわけですけれども…
これが…！
私がSQLを学ぶ時に…！！
あったなら…ッ！！！
（yuchidaは実務叩き上げでSQLを始めたので体系的に学んでいない）
ぶっちゃければ「もうこれでいいじゃん」となりそうになりました。ただ知識については十分でも、先述の通り構文のお作法が若干違ったり、そもそもどのデータベースに何のデータが入っているかがわかりません。実務で使うには、もう１歩の習熟が必要になります。
SQLの基本構造ですね。
講義＋演習
それぞれの講座の章の内容について、わかりにくかった点の復習や細かいお作法の違い等も含め「実務で使うデータベースでどのように使うのか」を実例を交えて講義形式で行いました。
この教材については、元になっているUdemyの講座がしっかりしている分それほど大変ではありませんでしたが、微妙な構文の差や代用の方法等を調べて行くのはなかなかに骨でした。
例えば、MySQLではCOUNT_IF構文が使えないので、SUMとIFを組み合わせて条件に合うものを1・そうでないものを0にして合計する、みたいなやり方ですね。
COUNT_IF(条件式) 条件式に当てはまるものの数をカウントする
SUM(IF(条件式,1,0)) 条件式に当てはまる場合1、当てはまらない場合は0として合計する
こちらは0除算が発生する時のクエリ例です。
SQLには「正解のクエリ」はありません。このように、決められた値を出力する際も、色々な出し方があります。どんな書き方でも正しい出力が行われていれば良いので、演習などでも「クエリ例」という言い方を徹底しています。
そのため、実務でよく使われるやり方や便利な出し方等も含めて、それに必要な知識なども補足していきました。
いつでも何でも質問OK
SQLに限らず、学習の際に私が最も重要だと思っていることは「どんな些細な事でも気軽に質問できる環境」です。
わからないことはその場で解決。目指すは積み残し無し。
そもそも人間は習っていない事・知らない事は出来ません。知っていても習っていてもわからないことは出てきます。そうでなければ学校のテストで100点以外取るわけがないじゃないですか！（ド忘れだとかよく覚えてなかっただとか色々原因はありますが）
「テストで大事なのは点数よりも復習」という格言もありますが、わからない点はわかるまで学習し、それを自分のものにするという事が重要です。
今回の講座もそのポリシーに従い、どんな簡単な質問でもOKという形にしました。「疑問は成長の種」です。
たくさん質問出していただきました！
講座の後は演習解説と宿題
講座の方は全９章からなっていますが、第８章・第９章はそれまでの内容の総ざらい・組み合わせた応用問題等になってくるため、具体的に講義として解説する部分がほとんどありません。そのため、講座第６回からは応用・実践演習として実務で使うような課題を受講者に宿題として出し、その解説を講義でするようにしました。
実はこれにはちょっと経緯がありまして…
第１回～第５回では演習を講義内で解いてもらっていたのですが、SQL初学者にとってクエリを書くのはなかなかに骨が折れる作業です。1つのクエリを書くのに30分1時間はあっという間に過ぎてしまうことも。その手間を計算に入れていなかったため「演習時間内に書き終わらない」「書けるようになった実感が湧かない」という事態が起きていました。
そこで第６回以降は演習を講義内ではなく「今まで講座の受講に充てていてもらった時間を使って宿題を解いてもらう」という形でやってもらいつつ、提出された宿題に対して添削をする形式に変更しました。A.K.A.- PEN先生という奴ですね。
この添削が受講者の方々には好評だったようで、「添削コメントやさしくて涙出た」「クソクエリ書いてもどっか褒めてくれる」「添削コメントが励みになった」（ほぼ原文ママ）と受講者の方々からの声をいただいております。頑張った甲斐がありました。こんなあったかいこと言われたら私が泣いちゃう。
これにより、あくまで講義として受け身で理解しようとしていたのが「自分で書く」事からの学びに繋がったという風に思っています。
添削やってよかったと思った瞬間。
修了試験
一旦前半の初学者用講義が終わった所で、講座の修了試験を行いました。
「実務に使われる、きちんと基礎が理解できれば使える」ものを問題として出し、提出していただくというものです。
普段の宿題は構文の解説や使い方を説明するために、実務の中でもかなり難しい方に偏らせていました。が、実際に使う際にはそこまで複雑な条件が必要なことは一部のレアケース以外ほぼありません。
こういう質問は版元さんからたくさん飛んできます。
条件色々複雑な条件を足して、必要な知識を使うような問題にしてあります。
必要十分な問いを作るのも苦労しましたが、修了試験において心を砕いたのはそこよりもむしろ「再提出へのアドバイス」です。
今回のプロジェクトのテーマとしては「参加者全員、誰も取り残さない」というものがありました。そのため、修了試験は1発で合否判定するというよりも、その人がわかっていない所を洗い出し、それを埋める事で問題なくクエリが書けるようになる事が命題でした。先程も触れましたが、「テストで大事なのは点数よりも復習」です。
答えを直接教えるのではなく、どこが間違っているのか・何故これだと違うのかの指摘と、理解できていない部分の洗い出しは想像以上に骨が折れるものでした。
SQLに「正解のクエリ」はありません。つまり、そのクエリがちゃんと欲しい値を出しているか判断するには、その奥にある原理原則を理解している必要があります。ただ答えを写せば良いというものではないのです。
諸々の甲斐あって、受講者全員に無事修了判定を出すことができました。
そして応用編へ
と、こうして初級編がつい先日終わった所ですが、現在応用編の講義をしているところです。…実は執筆時点で明日の講義の資料がまだ出来てない (ﾟДﾟ)
（一応ちゃんとギリギリで仕上がりました…）
応用編は主に習熟者用、普段から実務でSQLを使っている方々のために、より発展的な内容、主にBIチームが依頼を受けて行うようなアプリやWebでのユーザーの行動分析等が出来るようになるための講義になっています。
こちらは初学者用のような講座が存在せず、教材は全て私一人によるお手製です。
行動の段階を出すためにファネルの説明を入れたり、格納されているデータを読み解くためにJSONの解説をしたり、統計的な分析をするためにχ二乗検定の説明をしたりと、割と範囲が膨大になってきています。…これ大変、作るの大変ですよ！！（叫）
なんとか60分という枠に収めつつ、いかにシンプルかつわかりやすく原則を伝えられるかを考えながらやっています。
勝手に師匠と崇めているBIの大先輩の言葉で「BIに必要なのは10000を10で説明する事」というのがありました。今日もその言葉を胸に、冗長になってしまったスライドをシンプルに削り込んでいます。
得た学び
今回このプロジェクトを行った際、得られた学びは大きく４つあります。
業務に使う重要スキルについて、組織で体系的に学ぶのは大事
知っていることとできることは全く違う
わからないことをその場で質問するのは、みんなのためになる
業務形態によるナラティブの溝
1つ1つ解説していきます。
業務に使う重要スキルについて、組織で体系的に学ぶのは大事
当たり前のことではありますが、スキルを体系的に学ぶ体制が組織で整っていることは大きいです。
学習にかかるコストは時間も金額も大きく、自学自習はなかなかに大変です。それを会社側で学べるという形にしておくことによって、学習に意欲的になったり、社員のスキルアップに繋がったりと極めて大きい意味があるなと感じました。
今回は実務で今後使うという方を中心に行ったので、参加者は決して多くはありませんでしたが、今後も全社員が内容を確認できるように資料や動画を残したので、いずれSQLを学びたいという人が社員に出てきても、会社側がバックアップしつつスキルを身に着けられる体制になったかなと思っています。
知っていることとできることは全く違う
特に宿題添削の件ですが、「単に知識として持っている事」と「実際にそれを使うことが出来る事」にはかなりのギャップがあることに気付きました。
スキルは使ってこそ。学んだ後は実践で身に着ける事の重要さを実感した気がします。
学びっぱなしにするのではなく、きちんと使って、使い続けることでより習熟していく。そう考えると、学ぶタイミングについても重要なのかもしれないなと思ったりしています。
必要になった時に学べる環境が整っているというのが理想的なんじゃないかなと思いました。
わからないことをその場で質問するのは、みんなのためになる
「いつでも何でも質問OK」としたことで、受講者の方々から結構基礎的な所の質問が出てきたり、些細な疑問を出して貰えるようになりました。
実際にその辺りの説明が抜けていたり、わかりにくくて他の人にも伝わっていなかったりという事があり、「自分が今わかっていない事」を表明することの大切さを改めて学んだ気がします。
今オトバンクでは全社や事業部でのミーティングで「わからないことを積極的に質問できるようにしよう」という事で、ただ発表を受け身で聞くだけでなく、わからない事を表明できる場を作ったり、逆に「ここまでわかった」と言えるような形で、発表者に他の人の理解度がわかるようにしています。
Feedback is a giftという言葉がありますが、それは個人だけでなくその場にいる全員に恩恵のあるものだと思っています。
業務形態によるナラティブの溝
現在オトバンクで取り組んでいることに「ナラティブの溝を埋めよう」というテーマがあります。ナラティブという言葉には聞き覚えのない方が多いかと思いますが、ググっていただくかこちらの本が詳しいので是非ご参照いただければと思います。
https://publishing.newspicks.com/books/9784910063010
ナラティブとは物語・その物語を生み出す「解釈の枠組み」の事です。端的に言えば、その人たちが置かれている環境による「一般常識」みたいなものですね。
例えばAさんの立場からBさんを見るとBさんの行動は理解できなかったりするときでも、Bさんの立場では当たり前の事だったりします。こういう時、AさんとBさんとのナラティブには「溝」があると言えます。この溝を埋めていくのを、オトバンクでは全社で取り組んでいます。
私が所属しているオーディオブック事業部と、SQL初学者の方々が所属している部署では、業務内容がだいぶ違います。audiobook.jpで提供しているサービスの内容・料金設定について、毎日のように触れているオーディオブック事業部とは違い、全てを正確に把握しているわけではありません。
また、先述の通り初学者にとって「クエリを書く」という作業は大変時間がかかるもの。4年以上毎日SQLを触っている私にとっては15秒で書けるクエリであっても、初学者には20分くらいかかることだってあります。最初の方は演習としてやりたかったものの難易度が高く、時間が確保できずに次回に回す、等も必要だったり。
前者の溝については、必要な事柄について適宜説明をきちんと入れるようにしました。後者は演習を講義内でやるのではなく、宿題として別の時間でやってもらうという形式にすることで解決を試みました。どちらもそれによって理解度が高まり、より良い講義にすることができたかなと思います。
このように私には「一般常識」であっても、他の人にはそうではない。ナラティブの溝を如実に感じる事が多々ありました。他人に何か新しい技術をインプットする際には、教わる側のナラティブを考えるとスムーズだなと思いました。
次回予告…？
今回はデータ講習「SQLチャレンジ講座を開催してみた」ということで、どんなことをしたか、どんな学びを得たかについて皆様にご紹介しました。何か参考になるものがあったなら幸いです。
noteの記事についても諸々と書きたいことはあるのですが、通常の業務が結構カツカツでございましてなかなか書く時間が取れてなかったという感じです。更新遅くて大変申し訳なく…！
で、次に書きたいなーと思っているのは…
「古いデータどうすっぺか」
というあたりについてです。近いうちに書こうと思っているので気長にお待ちいただけると嬉しいです。
もし良ければaudiobook.jpの方もご利用ください。yuchidaでした。
この記事が気に入ったらサポートをしてみませんか？