データ分析とインテリジェンス

みんながSQLを書けるようになるのは良いことなのかどうかについて考えてみたら、メリットよりもデメリットの方が多い気がする

みんなSQLが書ける、は本当にそれがベストなのか

PdM・PM・営業・デザイナーなど、エンジニアやデータ分析者以外で普段プログラミングを行わない人がSQLを書くことを奨励している企業が増えてきた。極端な話ではみんながSQLを書けるなんて話もある。そういう話を見るたびに「本当にそれが一番いい方法なのだろうか」と気になっている。

全ての人が全ての職種ができる、は理想だがそれが無理だから役割を分担しているのである。なぜかSQLだけは誰でもできるみたいな話になっているのは不思議だ。

SQLの習得にかける時間を別のことに充てるほうがより効果が高いかもしれない。それに、関わる人の多さに比例して事故が増えて結局本職のエンジニアの負担になったするリスクはあるだろう。

こういったデメリットも考えると、簡単に結論を出すわけにはいかなそうに思える。そこで、「みんなでSQL」について考えてみる。

除外するケース

あらゆる状況であらゆるレベルの話をしても混乱するだけなので話の前提をおく。

想定するクエリはjoinやwindow関数を利用しているもの

今回「誰もがクエリを書くこと」について想定するのは「2つのテーブルのjoin」「window関数で連番やランクを作る」「複数の関数を入れ子にして使う」が含まれ、With句やサブクエリも使って数ステップかけるクエリである。だいたい入門書の中盤以降に書いてある内容を組み合わせたぐらいのクエリだと考えてもらえばいい。

つまり、その手前にある「1つのテーブルからカラムを選ぶ、日付や属性で絞り込む、集計する」ぐらいのクエリは今回の話に含めない。BIやピボットテーブルと同じことをSQLで表現しているだけなので、できるかどうかではなく誰でもできて欲しい。

#今回の話に含めないクエリの例
select
column1
,column2
,sum(column3)
,count(distinct column4)
from tbl
where date>='2021/01/01'
and nendai in ('20代','30代')
group by 1,2

ある程度の人数がいる企業の話である

SQLを誰が書くかを考えることになるのは「データを欲しがっている人がいるのにエンジニア側に対応リソースが無いからどうするか」という状況だ。その打開案として「みんながSQLをかけたらいいのではないか」という話が選択肢にでてくる。

したがってある程度以上の規模、具体的には営業やエンジニアがそれぞれ部署を作るような人数がいることが前提になっている。数人しかいない企業であればできる人がやるしかない。

普通の企業の話である

「普通」なんてあるのかと言われると困るが、最初に想定したクエリのレベルをあらゆる人が当たり前に書ける人達ばかりならこの先の話は該当しない。書けない人が多い企業が大多数だと思われるので「普通」と表現しておく。

「みんなでSQL」を有効にするためには何が必要か

「もしみんなでSQLをやるとしたらどうしたらいいか」を考えてみよう。次にあげるほとんどのことはSQLに慣れている人ばかりの環境でも同じようなことは必要である。しかし、慣れていない人が多い環境ではより注意が必要になる。

  • 環境を切り離す
  • データの信頼性を担保したマートを用意する
  • 監視体制を作る
  • 一時テーブルの制約
  • SQLをかける人がレビューする

環境を切り離す

本番環境を直接触らせてしまうと、おかしなクエリで全体を重くしたりへたな更新をして最悪サービスを止めてしまうことも起こりえる。

なので何をしても本番には影響がでない環境を用意すれば使う側も安心だ。ただし分析用環境を使っている人への影響はでるので利用ガイダンスは必要になる。

データマートを用意する

いくらSQLの基本的なことを覚えたとしても元のデータが汚すぎるとその処理に膨大な時間を取られてしまう。これは慣れている人でも起きるのに慣れていない人にやらせたらもっと大変だ。

なのでデータマートを部署単位ぐらいで用意するのがよいだろう。以下の事をやっておくだけでもかなり使いやすくなるはずだ。

  • 大きすぎるデータは期間やカラムを絞る
  • 不要なデータは削除しておく
  • 謎の区分値が存在しないようにしておく
  • マスタはjoinしておく

DWHの利用は最低限にする

DWHを全く使わせないのでは不便になる。かといってなんでも使わせるのはおすすめできない。

個人やチームレベルで考えると大半は不要なデータだ。使えるようにすると必要なデータを探すのに手間取ったり、絞り込みを忘れて巨大なデータを使うクエリを実行してしまうかもしれない。

監視体制を作る

例えば実行時間の上限を決めておく。一定時間を超えて結果が返ってこないクエリは本人が止めるか、強制的に終了させるかする。放っておくとシステムに負担がかかり他の人の仕事が止まる。

同時に実行できるクエリの数を制限するのもいいだろう。3つも同時に使えれば十分ではないか。

一時テーブルの制約

一時テーブルも自由にに作らせるとあっという間にゴミテーブルが溜まって必要なテーブルが行方不明になる。しかしDWHと同じで一切作らせないととても不便なので、一定期間で自動的に消える仕組みがあった方がいい。

一定期間と書いたが、ほとんどの場合はその日の終りに消えても問題ないだろう。翌日必要ならばまた作り直せばいいし、長期的に必要ならデータマートとして別に作ればいい。

SQLをかける人がレビューする

全てではなくても、やはり誰かが確認する必要はある。

しかし1人2人の相手ならともかく、10人20人ともなれば書いているクエリを確認するだけでも大変だ。うまく分担するか、見る量を減らすかだが後者が現実的か。

SQLをちょっとかける人を量産することによるデメリット

SQLをちょっとかける人を量産することによるデメリットは、まず上記のどこかがくずれるとあちこちに影響が出る。そして原因の調査やトラブル対応は結局スキルがある人にまわってくる。

次に、本職がおざなりになる危険がある。SQLに慣れていれば30分で終わることを半日や1日かけてしまってその分の本来の仕事ができないのでは本末転倒も甚だしい。もっと悪いことに、時間を無駄にしていることも気づいていないかもしれない。

3つ目に、営業やコンサルが自分の都合の良いデータを選んで使うことが止められなくなる。

最後に、ちょっと出来るようになると周りが変に持ち上げたり、SQLなんて誰でも出来るという誤解をしだす。するとデータエンジニアやデータアーキテクト(データ整備人)の仕事を下位に見る人がでてくる。

SQLをちょっとかける人を量産することによるメリット

一方メリットは何だろう。

まずは自身でデータを抽出できれば欲しいデータをすぐ取ることができる。これは大きなメリットだ。別の部署に頼むとその日に対応してもらったら早い方で1週間待ちなどあたりまえだ。

2つ目に、技術への知識が身につくことでエンジニア側とコミュニケーションがしやすくなる。お互いのやっていることをお互いに全く知らない同士ではコミュニケーションをしても仲が悪くなるだけである。

最後に、これは主にエンジニアリング側にとってのメリットであるが簡単な依頼でスキルがある人を動かさなくて済む。

といったところだろうか。

メリットはあるがデメリットの方が多いのでは

メリットとデメリットを並べてみた。比べてみるとメリットの1番目と3番目は多少のスキルがある人を増やせば解決してしまう話ある(それがいいかは別として)。2番目もあるに越したことは無い、ぐらいか。

それに比べるとデメリットはどれをとっても影響が大きい。そう考えるとメリットよりもデメリットの方が多いような気がする。

ではその仕事を誰がやるのか

筆者の考えは「別の役割として、ふさわしいスキルのある人を増やす」である。データ抽出はアナリスト経験者か少なくともアナリストの訓練を受けている人が行うのが望ましい。

「みんなでSQL」の致命的な弱点は「SQLが書ければ必要なデータが取れる」と思っているところだ。SQLはデータを抽出する手段である。どのようなデータが必要なのかを決めるスキルや、事前にどのように整理しておくか考えるスキルはまったく別の話だ。

とはいえ現実問題としてすぐに採用ができないのであれば、今いる人の中から配置転換ないしは兼任することになるだろう。とりあえず若手を誰のバックアップもなしにあてたり、外注に丸投げするのは最悪の手段である。

メリットを享受するための投資とスキルがある人の採用はどちらがいいのか

「みんなでSQL」にはメリットよりデメリットの方が多いのでは、と書いたが他の選択肢よりかはベターかもしれない。

もし環境を用意して運用を行う人まで含めて上記の「みんなでSQL」を有効にするために必要なことを全部揃えることができたとしよう。その場合と比べて「ちゃんとスキルのある人」を増やすのとではどちらがよいのだろうか。あるいは、もっと他に良い選択肢はあるだろうか。

2択なら「ちゃんとスキルのある人」の方がいいとは思っているが検証したことはない。「みんながSQL」にはデメリットが大きいから誰もやらないという選択肢もあるかもしれない。ちょっとした集計と可視化だけでもそこそこのことはできるはずだ。うちではこうやっているとかの話があったら教えて欲しい。

個人の学習は無駄だ、ということではない

今回の話は組織としやることについてであり、各自が興味を持って勉強することが無駄だ、などと言うつもりはまったくない。SQLを学ぼうとする人に聞かれれば喜んでできることはお手伝いしたい。

ただし、入門書や無料サイトで学んで「できる」ようになることは「必要な材料が必要なだけ準備された状態から学ぶカレーの作り方」ぐらいの話だと考えておいてもらうのが良いと思う。

何のためのデータ抽出なのかを改めて考えよう

「データの民主化」が「誰でもデータを扱うことができる」のような意味で使われることがあり、「みんなでSQL」はその流れで発生した事象の1つではないかと考えている。

なのでSQLを誰が書くかの前に「本当に必要なことは何か」を考える必要がある。実はデータ抽出は良い意思決定はつながっていないのかもしれず、足りていないのは「検証と学習というデータを積極的に収集すること」なのかもしれない。もっと言えば、誰でも検証と学習を行うことができる仕組みだ。

この記事を書いている時点ではまだ整理できていないが、検証と学習のプラットフォーム化はもしかしたら基盤の構築や整備の今後の活動やキャリア形成にも関わる重要なテーマになるかもしれない。

関連記事

役割によってどれぐらいのSQLが必要なのかを検討した。

A/Bテストの仕組み化は、検証と学習のプラットフォームの一例。

カテゴリー:意思決定と分析のプロセス