ビジネスサイドがSQLを学ぶことについて
ビジネスサイド＋SQLは過大評価されすぎている
非エンジニアでかつデータ関連職ではない人をまとめて「ビジネスサイド」と表現しよう。
どういうわけか、「データ分析」を学ぶ際にSQLを身に着けることが話題になりやすい印象を持っている。そして、ビジネスサイドがSQLを学ぶことについては過大評価がされていると感じている。もっと先に身に着けるべきことがおざなりになっていたり、SQLを学ぶ以外の選択肢が考慮されていないことが多い。
そこで、ビジネスサイドとSQLについて思うところを書いてみる。
ビジネスサイドがSQLを書くことになる状況自体を問題として捉える方がいい
ビジネスサイドは通常は企画、意思決定、実行のいずれかまたは全部が中心だろう。分析は企画するために必要な情報を作る行為であるが、分析の一部（あるいは前段階）であるSQLを書くことを含めた「データ抽出」自体には責任を持たない。
なので、当人の希望や上司からの指示があった場合を除けばあとは「データを抽出したいが他に誰も実現できる人がいないので自分でやらないと進まない」状況ということになる。
SQLを書ける人がいない
SQLを書ける人はいるが頼めない
SQLを頼むことはできるが対応が遅すぎて待てない
対応はしてもらえるが抽出側の能力が低いため任せられない
SQLを書ける人が来るまで待てない
これらは状況は違うが、いずれもビジネスサイドがSQLを学んでも根本的には解決しない。たとえその時は解決したように見えても、すぐに同じ問題が別の場所、あるいは組織が拡大したり人が入れ替わったりしてその場所で同じ問題が起きるだけだ。つまり体制の問題であり、こうなる状況自体を問題にする必要があるはずだ。
このような状況においては自分でSQLを学ぶこと以外にも体制の変更を行う、あるいは変更を訴えることも選択肢に含めるのがいいだろう。ビジネスサイドがSQLを書くのは対処療法でしかない。目の前の重要事項に急いで対応しなければならないことはあるのは仕方ないとしても、あくまで一時的にするべきであろうと考える。
初歩的なSQLだけではあまり使い道がない
SQLを学ぶのならば、どれぐらいのレベルまで学ぶのかも考える必要がある。SQLは簡単だという人もいるが、たしかに初歩的なことであればその通りだと思う。ここでいう「初歩的なSQL」とは、
軸と指標の指定
テーブルの指定
条件を指定してフィルタ
集計関数
を想定している。SQLでいうと
select
from
where
count
sum
group by
order by
で完結して、join,caseは使わず、withやサブクエリもないSQLのことだ。言い換えるとピボットテーブルでできることのレベルである。
もしも初歩的なSQLで解決する環境であれば必ずデータ整備ができる、つまりSQLができる人がいるはずだ。そして、SQLができる人がいるならば欲しいデータを依頼をして抽出してもらうか、BIツールやスプレッドシートで対応できるように整備してもらうのが先だ。いずれにしても、真っ先にSQLを自分で学ぶよりも必要なのは「依頼のやり方を学ぶこと」である。
また、今後はさらに自然言語処理の発達によりSQLを書かずとも込み入ったSQLが必要なアウトプットが手に入るようになってくる。全てをカバーできることはないと思うが、これから初歩的なSQLだけを学ぶことにはあまり意味はなくなってくるだろう。
もし整備されていない環境ではこれぐらいのSQLではまったく足りない。ぐちゃぐちゃなデータをそのまま集計したところで使い物にならない。
なお、初歩的なSQLを学ぶぐらいなら大したことではないから考える前に学んでしまえばいい、と言われると反論はしづらい。
ビジネスサイドが込み入ったSQLを学ぶ長期的なデメリット
ではもう少し込み入ったSQLを書けるようになるレベルまで学ぶとしよう。想定としては、
withやサブクエリを使って前処理も含めて1つのSQLで行う
joinを正しく使い分ける
複数の関数を組み合わせて指標の新規作成や既存指標のアレンジ（特殊な区分を作る、とか）を行う
あたりを考える。これぐらい書ければいろいろなパターンの抽出には自力で対応できるようになる。
自分でデータを入手できることは個人レベルで考えれば短期的にはメリットがありそうだ、とみんながSQLを書ける（データを民主化する）メリットとデメリットで書いた。一方で、長期的に考えるとどうもデメリットが目立つ。
学ぶべきことが学べなくなる
限られた時間の中で学べることは限られており、優先順位をつけなければならない。SQLを学ぶことに時間を費やせば、当然その分は他のことには使えない。
SQLの書き方は入門書に書いてあるのでそれを読めば理解はできるだろう。しかし書いてあることを理解するだけでは意味はない。説明書を読んで理解しても道具として使いこなせないのでは意味をなさない。
「SQLができる」、つまり「実務で、限られた時間の中で正しく結果を出せる」ようになるためには例えば次のことが必要だ。
わからないことについて全てではなくても自分で調べて進めることができる
結果が正しく出てこない場合に自分で対処できる
大規模データを適切に扱うことができる
データを理解するための調査ができる
これらを身に着けるやはり数をこなしてなれることはまず必須であり、それなりの時間がかかる。ということは、本来の仕事を全うするには大して寄与しないスキルのために時間を大きく使うことになる。
SQLができる人が来た時点でSQLを使わなくなる
一時的に必要だからと時間を費やしても、本来のビジネスサイドの仕事をする際にはSQLのスキルはほぼ使わなくなる。
その後に使うことがあるのは本来やるべき人がいない、いても忙しいなどの理由でできない場合に対応する場合ぐらいだ。
SQLを使う仕事が中心になってしまうかもしれない
SQLができる人がいなければ自分で学ぶことにはなるが、ビジネスサイドとしての仕事の時間を削れば出せる成果が減るし、本来の時間にSQLを書く時間を上乗せするならば業務の時間が増える。いずれにしても体制の問題を個人の努力や犠牲で解決しようとすることになる。
さらに、もし今いる人で解決できる（ように見える）のであれば、わざわざ他から探して来なくてもいいと少なくとも会社は考えてしまうかもしれない。
やがて周りの人からSQLを書いてほしいと頼まれることになれば、ますますビジネスサイドの仕事ができなくなる。その時になって人を増やせることになったとも、もしかしたら代わりに来るのはビジネスサイドの人かもしれない。
SQLを書く（つまりデータ整備）側になることに対して抵抗が無かったり、たまたま水が合えばよい。しかしそうなるのは少数派であろう。
たまにしか書かないので身に付きづらい
ビジネスサイドが自分の分析のためにSQLを書く機会はそんなに多くない。もし多いのだとしたら本来の責任を果たせていないので、SQLについて考える以前の問題がある。そして、当たり前だがたまにしかやらないことは身に付きづらく、非効率である。
慣れている人が書けば30分で終わることに数時間を費やし、同じく詳しくない周りのビジネスサイドを巻き込んで時間を無駄にしているのはよく見かける。
長期的なメリットは何か
一方で、SQLを自分でそれなりに書けるようになることがメリットになるのは幅広くいろいろなことをやる場合だろう。
独立して個人で動く
役割分担する意味もないぐらいの企業でいろいろなことをやる
データ活用の初期段階で最低限のデータを自力で用意する
あたりが思い浮かぶ。ただこの場合でもSQLを多く使う機会は少ない。そう考えると、やはりデータ関連の仕事へのキャリアチェンジを考えているのでなければ長期的なメリットにもなりづらいだろう。
SQLは選択肢の1つであり、しかも優先順位は低い
「データ分析」と言っても幅広い。ビジネスサイドが「データ分析」について身に着けるならば優先順位としては次のようになるのではないだろうか
データ分析のための考え方
データ分析のやり方
BIツールの使い方
データの依頼のやり方
データ抽出のやり方
初学者にはやり方から入るのもいいのでは、とかこのあたりはもうちょっと詳しくまとめる必要はありそうだが今回の話とは関係ないので割愛。
SQLは「データ抽出のやり方」のうちの1つであり、つまり優先順位としてはかなり低い。特に「データ分析の考え方」や「データ分析のやり方」を知らないのにデータ抽出のためのSQLだけを学んだところで出てくるのはなんの価値もないどころか間違えた意思決定をもたらす「分析」だ。
最終的に自分でSQLを書くしかない場合は多々ありえるとしても、最初から自分でやる以外の選択肢しか持たないのではまったく違う動きになる。「データがなければ分析ができない」と「だから自分でSQLを書けるようにならないといけない」この2つは別の事として考えよう。でないと「データが無いから自分でSQLができるようにならないといけない」になってしまう。
「ビジネスサイドが身に着けるべき”情報リテラシー”は何か」
思いついたSQLの話を題材に気軽に書き始めたら思わぬ分量になってしまった。
本題は「ビジネスサイドが身に着けるべき”情報リテラシー”は何か」だ。こういった話がまとまっていないからとりあえずSQLを学ぼうという人が出てくるのかもしれない。
いつまとまるかわからないが、まずは書いてみようと思う。
この記事が気に入ったらサポートをしてみませんか？