はじめに
データアナリストであれば、仕事でSQLを使わないという人はほぼいないでしょう。
現状SQLはデータアナリストにとってそれほど必須のスキルになっていると思います。
データアナリストの採用においても、SQLのテストを受けるよう求められる企業もたくさんあるようです。
ちなみにSQLはそれほど習得が難しいスキルではないとはよく言われますが、かといって万人が容易に身に着けられるスキルかというと私はそうではないように感じています。
身も蓋もない言い方をすれば、やはり向き不向きがある、センス次第、というのが実態なのかなと思います。
また単純にできる、できないのどちらかではなく、レベル差というものも存在していると思われます。
そこで、実務においてデータアナリストにはどのくらいのレベルのSQLスキルが求められるのかについて、改めて考えてみました。
なお、今回紹介するレベルはあくまで私の主観であり、今後変わる可能性もあります（異論も認めますw）
レベル1 文法的に正しいSQLが書ける
まあこれは当たり前ですが、最低限必要なレベルです。
そもそも文法的に正しいSQLが書けないとエラーになるので、目的のデータが入手できません。
SQLの講座・学習用書籍：Web記事などで、文法や書き方について解説されてるものはたくさんありますので、そういった教材を使えばこのレベルに到達するのは難しくはありません。
とはいえ、たくさんの関数や構文を知っているほどレベルが高いというわけではないので、そういった教材をたくさん学習してもこの上のレベルになるのは厳しいでしょう。
あまり使う機会のないニッチな知識がたくさんあってもしょうがないので、どの教材にも登場しているような一般的によく使用される関数や構文を一通りマスターしていれば、とりあえずレベル的には大差ないかと思います。
レベル2 要件通りのSQLが書ける
どんなデータが必要なのか、要件に合ったデータを出力できるのがレベル2です。
明確な要件があれば適切なSQLを書けるレベルだと、依頼者からのデータ抽出依頼をこなせます。
しっかりヒアリングできるスキルや、きちんと要件やデータ仕様を確認・理解できるスキルが必要です。
またデータの構造を踏まえた記述や、SQLの処理順序を理解した上での記述など、もう少し深い理解も求められます。
例えば、日時データを元にした集計を行う際、タイムゾーンを考慮しないとズレが出る場合があります。（UTCとJSTでは時間帯によっては一日ズレます）
例えば、NULL値が含まれるカラムがあると、集計の仕方によってはNULLのレコードが含まれたり含まれなかったりします。
select count(column1) from table1
すごく簡単な例でいうと、上のSQLでは通常column1にNULLが含まれないと全行をカウントしますが、NULLが含まれているとNULLを除いたレコード数をカウントします、
要件に応じて適切なカラム、集計方法をとる必要があります。
例えば、重複データがある場合、そのまま集計するのか、重複を排除して（distinct）して集計すべきなのかも考慮が必要になります。
例えば、外部結合されたテーブルのカラムを出力・集計するとき、絞り込み条件を書く場所も注意が必要です。
select *
from table1 a
left join table2 b on xxx
where b.orderdate >= '日付'
上のSQLだと外部結合にしているものの、where句にtable2のカラムの条件を入れているので、内部結合と同じ結果になります。（where句での絞り込みは結合後に行われるため）
table1にしかいないレコードも残したければ、絞り込み条件をwhere句ではなく、結合条件の箇所に書く必要があります。
select *
from table1 a
left join table2 b on xxx and b.orderdate >= '日付'
何らかの学習教材のサンプルやチュートリアルのデータしか扱ったことがないとなかなか身に付きにくい領域なので、このレベルでは一定の実業務の経験も必要になってくるでしょう。
レベル3 汎用性の高いSQLが書ける
汎用性の高いSQLというのは、再利用しやすいSQLといえばイメージしやすいでしょうか。
簡単なところでは、動的な書き方を使いこなせるとか、
例えば、直近1年間の売上を集計したいなどのとき
日付の範囲を明示的に書くと正しい結果は得られます。
しかし、翌月また同じデータが必要になったときは日付範囲を修正する必要があります。
一方、current_dateおよびdate_add関数を使えば、直近1年間の日付範囲を動的に指定できるので、いちいち修正する必要はありません。
あとはカスタムに作成したカラム、with句の名前、テーブル名のエイリアスなどに誰でも直感的にわかりやすい名前を付けられるとか、
and/orの組み合わせ条件やCASE式の分岐などを細かく場合分けするような回りくどい書き方をせずに、シンプルに書けるとか
このレベルで必要なのは、高難度のスキルというよりは、可読性やメンテナンスを意識するような丁寧さやきめ細やかさなど、だったりします。
チームで仕事する際には、チームとしての生産性や効率性、管理性といったことも求められるので、そうした面で適切なSQLが書けることがこのレベルでは必要になってきます。
しかし、一人で作業しているとどうしても雑になってきたり、我流で属人性が強くなったりしますので、そうした環境にずっとい続けるとなかなか身に着けるのが難しいスキルだったりします。
レベル4 レスポンスの速いSQLが書ける
昨今はどこの企業でもそうかと思いますが、業務で扱う生データというのは通常Excelやスプレッドシートで処理できる量ではありません。
なのでそうしたデータというのは、SQLなどで処理が必要なデータベースシステムで管理されています。
そのため非効率なSQLの書き方をすると、レスポンスに大きな差が出ることがあります。
とはいえ、ちょっとしたデータの確認をするだけとか、そもそも数秒以内に返ってくるSQLならそれほど気にしなくても良いかもしれません。
データベースシステムの高速化やチューニングレス化も進んできているので、少しくらい非効率な書き方をしても、あまりレスポンスに差が出なかったりすることもあります。
しかし、いざ大量のデータを複雑なロジックで処理しなければならない場面になって、非効率な書き方しかできないととても困ることになります。
そして意外とそういう場面はよくあったりします。
またクラウドのデータベースサービスでは、クエリの実行時間やアクセスするデータ量によって課金額が変わってくるものもよくあるので、速いクエリが書けることはコスト削減につながることでもあります。
長い目で見れば、塵も積もればとやらで無視できないコスト差になってくるかもしれません。
なので、遅いSQLしか書けない人よりも速いSQLを書ける人の方がValuableなのです。
正しいデータが返ってくれさえすれば良いので時間が多少かかっても気にしない、という考え方をいつまでもしているとなかなかそれ以上のスキルアップは難しいのではないかと思います。
このレベルになるには、実際に多くのデータを処理する場面でいかに効率の良いSQLの書き方ができるか考えてみる、といった経験が必要になるかと思います。
データ量や環境によるのであくまで一つの目安ですが、SQLのレスポンスに数分以上かかるような場合は、もっとレスポンスの速い書き方ができるのでは？と見直してみるべきかもしれまん。
そして実際にレスポンス時間を大きく改善する書き方のパターンを学ぶことが重要です。
このレベルに満たない人のSQLは、主にはテーブル結合が非効率な書き方であったり、遠回りな処理や冗長な処理が含まれていたりして、結果的に処理データ量が多くなってしまうようです。
そういった書き方をしないように気をつければ良いのですが、なかなか自分では気づきにくかったりもします。
ちなみにですが、カラム数の多いテーブルですとデータベースによっては「select * from xxx」と書くと非常に遅くなるものもあったりします。
特に何も考えずに「select * from xxx」を多用しているなんてことはないでしょうか。
なので、第三者にレビューしてもらったり、自分で処理効率を意識できるようにならないとなかななかスキルアップしにくかったりします。
レベル5 要件があいまいでも適切なSQLが書ける
例えば、「先月の商品Aの売上を知りたい」とだけ依頼されたとします。
しかし、その要件だけで果たして正しいSQLが書けるでしょうか。
もし先月分の売上がまだ締まっていなければ、現時点では確定した結果は出せないのではないでしょうか。
月をまたぐ赤伝票がある場合、先月分に含めるべきものとそうでないものの見分けがつくでしょうか。
代理店の販売データやECサイトの販売データなどチャネルが異なるデータが別管理になっていないでしょうか。
商品Aとはどこまでが商品Aなのでしょうか。（略称等で依頼されたりすると認識齟齬が出たりすることも）
どの日付で集計すべきでしょうか。（契約日、出荷日、納品日、検収日、・・・）
間違ったデータが含まれている可能性はないでしょうか、ある場合そのデータをどう扱うべきでしょうか。
データに漏れがある可能性はないでしょうか、ある場合そのデータをどう扱うべきでしょうか。
などなど。。。
こうした様々な条件やルールを漏れなく反映したSQLを書かないと正しい結果が得られない、ということはよくあります。
そのためには業界知識、業務知識、元データの作られ方、イレギュラーな業務処理、例外データの発生条件などを知っていなければなりません。
調べれば簡単に分かるのであればそれほど問題ではないのですが、それらは資料等で文書化されていなかったり、一部の人の頭の中にしかなかったり、あるいはそもそも知っている人がいなくなっていたりします。
そうした場合は、今ある手がかりでなんとかして正しいデータを導かないといけなくなります。
多角的な知識、論理的思考力、調査や探索スキル、データ検証スキルなどさらに応用スキルが必要になってきます。
こうしたスキルはシステムやデータがあまり整備されていない環境での経験がないと身に付きにくいのかもしれません。
そもそも正解データがないケースでは、様々な条件やルールをいくら解明したとしてもまだ漏れがある可能性は否めません。
なので、ある意味きりがないレベルなのかもしれません。（そういう意味ではレベル4もそうですが…）
最後に
レベル5はその環境限定のスキルだったりするので、実際にその環境に身を投じないと身につかないでしょう。
なので転職前にレベル5相当が求められることは通常ないと思います。
また転職してすぐにその企業においてレベル5になれるかというとそれもまた難しいでしょう。
転職市場では、実務上はレベル4まであれば大丈夫かと思います。
ただ、もし現職や前職でレベル5だったならば、新たな環境でもレベル5になるポテンシャルは高そうだ、と判断されて有利かもしれません。
一方、レベル3以下だと転職市場では厳しいと思われます。
ジュニアクラスのポジションで入社してから学んでくれればOKという企業なら別ですが、ミドル以上の経験者でレベル3以下だと「SQLはあまり得意でないのかな…（適性がないのかな…）」と思われてしまう可能性が高くなります。
よほど他のスキルで優位性を出すか、そもそもSQLを使わないポジションで応募しないと合格は厳しいのではないでしょうか。
ちなみにレベルという言い方をしていますが、段階的に上がっていくとは限りません。
環境によってはレベル4と5が逆転することもあるかもしれませんし、人によってはレベル4より3の方が苦手と思う方もいるかもしれません。
なので、改めて言いますがあくまで現時点の私の独断と偏見によるものです。
ちなみに今後LLM（大規模言語モデル）がさらに広まると、適切な質問をして適切なSQLを生成させるスキルなんてものも、SQLのレベルの考慮に必要になってくるかもしれませんね。
