「分析のためのSQL」を勉強したときにやったこと
SQLをほぼ独学で勉強していましたが、振り返ってみると「難しかった」と思っていた記憶があります。
これって何故発生したのだろう？ということを振り返り、どう学習すればよいのだろうか？を整理できたらいいなーと思って書きました。
この記事で書くこと
データ分析を生業にされていらっしゃる方、SQLをお仕事で活用されている方からすると「何いってんだこいつ」と思われる要素が多々含まれる可能性があります。ごめんなさい。
1. 取り組んだこと
2. 分析のためのSQL習得に必要なこと
3. どこまで独学でやるべきか
この記事にたどり着いた方が「SQLの学習方法」に迷っている場合は多分1と2を、独学の限界を感じている方は2と3を読んでいただければよいと思います。
① 取り組んだこと
筆者は主に以下4ステップを3ヶ月くらい繰り返して、ようやく同僚とデータについて少しは議論できる、という状態になったと記憶しています。
1. 学習本・学習サイトで関数を学ぶ
そもそもSQLってなんぞや？というところからスタートだったため、学習サイトを検索して片っ端からやってみる、という取り組みをしました。
思い返してみると、データ抽出だけなら使わないdelete・updateなどの構文についても触れることになっていましたが、これは結果的に自身のスキルの幅を広げてくれた非常によいきっかけだったと思っています。
筆者は自社のDBとProgateとドットインストールで勉強しました。
その後、自社のDBを使って2以降のステップに進みます。
2. 1つのテーブルで知っている関数を使ってみる
1つ使うテーブルを決めて、使えそうな関数を片っ端から使ってみました。
このとき、使うカラムを限定せずにすべてのカラムに対して同じ処理をしてみることで、リファレンスに書かれている exprとは何ぞや？ということを学びました。
3. 複数テーブルを使って漠然とデータを取り出す
ある程度SelectやWhereで使える関数を覚えたあとは、複数テーブルの結合方法やその結合によって正しい結果を取得できているか？の検証を繰り返しました。
内部結合と外部結合の違いを初めは全く理解できずに苦労しましたが、同僚から「Vlookupを覚えろ」と言われて使い方を学んだところ、だいぶスムーズに理解できたと思います。
学習に詰まったら他の似たなにかを先に覚えるは大事かもしれません。
4. 他人の書いたクエリを書き直す
他人が書いたクエリを拝借してきて自身のエディタにコピーして、下記のステップを繰り返しました。
これが1番勉強になりました。
クエリに記述されているコメントアウトをすべて消す
1行ごとの処理をすべてコメントアウトで書き直す
コメントアウト以外をすべて消して、自分の書いたコメントをもとにクエリを書き直す
書いたクエリの結果と元のクエリを比較して、双方の結果が一致するまで1~3を繰り返す
① 最初にこんな感じのクエリを拝借してきて
select
id
,name
,status
from
customer
where
created_at >= '2020-01-01'② 全部にコメントアウトを書いて
select
id -- 顧客ID
,name -- 顧客名(ニックネーム)
,status -- 現在のステータス
from
customer -- 顧客情報のテーブルから取得する
where
created_at >= '2020-01-01' -- 2020年01月01日以降に登録した人③ コメントアウト以外全部消して
select
-- 顧客ID
-- 顧客名(ニックネーム)
-- 現在のステータス
from
-- 顧客情報のテーブルから取得する
where
-- 2020年01月01日以降に登録した人④ 全部書き直す
select
id -- 顧客ID
,name -- 顧客名(ニックネーム)
,status -- 現在のステータス
from
cutomer -- 顧客情報のテーブルから取得する
where
created_at >= '2020-01-01' -- 2020年01月01日以降に登録した人もしご自身が所属されている会社のDBにアクセスすることが難しい場合の学習方法についてはそのうち詳細書けたらいいなーと思っていますが、簡単なデータ抽出の練習問題は検索すると出てきます。
5. その後沼に嵌まりまして
データを抽出してくることはできるようになりましたが、その後じゃあこれなにに使うんだ？という沼に嵌まりました。
勉強して、覚えたはいいものの何に使うのかのイメージが全くないまま何となく使えそうなテーブルと関数だけ覚えていくことになり、実際に業務で役立つデータとは何で、そこからどういった条件・フォーマットでデータを抽出してくるか？のイメージが全くありませんでした。
これをどうやって解決したのか？については3の項目で書きます。
② 知識の構成分解
1. 構成要素
SQLの知識とは、データを抽出・加工するために覚える関数という知識とどこのテーブルに何が入っているか？というテーブルの知識の2つが必須になります。
学習する際の資料で得られるものは前者の関数の知識が主になってきて、後者のテーブル知識では型といった基本的なこと以外は覚えにくいです。
この2つの知識をどこまで深めるべきなのか？という判断が難しく、学習の敷居を高く感じたり、覚えたあとに沼った原因なんじゃないかと思います。
hogehogeというテーマのために必要なデータテーブルは、〇〇と△△で、それを抽出するためにAとBという関数を使おう！というのがデータ抽出のためのSQLにあたるのですが、関数の知識以外の要素が必要であることを実感しにくいのではないか？と。
2. 必要な知識の幅
この掛け算において、必要となる知識の幅を決定するのが課題になります。
たとえば、漠然と「データ抽出をしたいから」「覚えていたら使えそうだから」というモチベーションで学習を始め、何を抽出することをゴールにすればよいのかやそのデータはどこに入っているのかということを考えられなくなってしまいました。
3. 関数を覚える数
独学をある程度進めたあと、覚えたことが実際に役に立つのか？を実感するためにも課題は必要です。
ここで「実際に何を使えばいいんだろう？」という迷子になってしまうと、どこまでやればよいんだっけ？という迷いが生じてモチベーションが下がってしまうからです。
（これは筆者の体験談）
ただし、結果的に関数を大量に学ぶ自体は絶対に悪いことではなかったと筆者は思っています。
これはすなわち自身の引き出しを増やしていくこととイコールになるからです。
引き出しの数が増えれば増えるほど出来ることは増えていきますし、後で忘れたらまた調べて思い出せばよいのだと思います。
新しい環境では横軸のスキルはほぼリセットされる
これは転職や副業をさせていただく中で実際に感じたことですが、自分の会社にいる間はテーブル知識およびビジネス課題の理解度は右上方向に深まった状態になります。
しかし、転職などなどに起因して環境が変わると当然のことながらデータ分析の環境自体が変わるため、右上方向に伸ばしていたスキルはリセットされた状態になります。
筆者の場合、もともとBigQueryとMySQLを分析に利用していましたが現在はPrestoを中心に書いています。
Presto独自の関数や出来ること・できないことを理解するために勉強する必要がでてきました。
都度リセットされはしますが、学習のために何を学ぶ（キャッチアップする）必要があるかを学べたことは自身にとって非常にプラスでした。
③学習のために必要なアプローチ
実際にデータ分析をしたいからSQLを勉強してみよう！と思った場合、大事なことは大きく分けると2つあると思っています。
1. 独学で出来ることを増やす
上のほうにもさっと書きましたが、関数を覚えること、関数を使った引き出しを増やすことは独学で大体なんとかなります。
まずはユースケースと書き方を学習し、繰り返し使ってみることはいい勉強になりました。
自社のDBにアクセスできる場合、仮説を考えて様々なテーブルを触ってみることも重要です。
結果的にそこから何も分からなくても、とりあえずやりたいことが出来たということを成功体験にしていました。
2. テーブル知識は自分以外からお題を得る
データテーブルの引き出しを増やすためには、自分以外の誰かが抱えた課題をお題としていただくことで伸びていきます。
ビジネス課題というのは企業・部門・部署・担当者によって異なるので、色々な方と会話できるようになるとお題は増えていきます。
筆者の場合はその関係性の構築が残念ながら頭になかったので、最初はMTGの議事録を読み漁ってその課題をデータで可視化できるか？ということを勝手にやり、良さそうなインサイトがあったら上司に持っていく、ということをやっていた記憶があります。
おわりに
自身の置かれている環境や権限によって、学習できる範囲は異なってきます。
筆者の場合運良く、また周囲の方々が優しすぎるくらい優しい方々だったので勉強が捗りました。
ただし、環境がない場合も自分で作ることはできます。
たとえば、redash×e-stat×Google Sheetsで分析用データベースのような環境を作るなどなど。
（これはいつか具体的な手法について記述したいと思ってます）