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

みんなSQLが書けることを自慢している会社もあるけれど、本当にそれでいいのだろうか

営業やデザイナーなど、エンジニアやデータ分析者以外で普段プログラミングを行わない人がSQLを書くことを奨励している企業を時々みかける。極端な話では営業全員がSQLを書けるなんて話もある。

もちろん企業の宣伝やブランディングを兼ねているだろうからうまくいっている話しか出てこないわけだが、それをそのまま受け取って自分達でも真似してみようと思うところもあるだろう。

そういう話を見るたびに思うのは「本当にそれが一番いい方法なのか」ということだ。

誰もがすべてのことをできればよいのは当然だ。しかし、中途半端にできると本職の人が10分で終わることを半日や1日かけてしまうことや、本当は出来るのにできないと思い込んでしまう人が出てくる。

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

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

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

いくら考えたところでやってみないとわからない、というのはたしかなのでまずはもし「みんなでSQL」をやるとしたらどうしたらいいかも考えてみよう。

環境を切り離す

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

なので何をしても影響がでない環境を用意してそこでなら何をしても良いと保証する。これなら使う側も安心だ。

データの信頼性を担保したマートを用意してそれ以外は使わせない

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

なので事前に整理したデータマートを用意して、それだけ使わせるのがよさそうだ。

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

これだけやっておくだけでもかなり見通しが良くなるのでSQLを書くことに集中できる。

マスタはJOINしておく

idだけが入っていて、名称のマスタが別にあるので必要に応じてJOINする、というのは慣れている人にとっては当然のことだが、毎回JOINするのも結構面倒だし間違えやすい。

なのでマートを作る際によく使うマスタについては事前にJOINしておいてよいと思う。というかカラム数が多すぎて困る、ということでない限り全部やっておいていいのでは。

実行時間の上限を決めておく

一定時間を超えて結果が返ってこないクエリは本人が止めるか、強制的に終了させるかする。状況を確認するためのモニタリングの仕組みも併せて作っておく。

JOINのやり方がまずい、大量のテーブルをJOINしているなどいろいろあるが、放っておくと他の人の仕事が止まる。

一時テーブルの制約

一時テーブルでも勝手に作らせると無法地帯になるので作らせないか、一定期間で自動的に消えるとかの仕組みはあった方がいい。これをしないとあっという間にゴミテーブルが溜まって必要なテーブルが行方不明になる。

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

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

しかし1人2人の相手ならともかく、10人20人ともなれば書いているSQLを確認するだけでも大変だ。うまく分担するか、見る量を減らすかだが面倒だとやりたがらない人も多い(気持ちはわかる)ので後者が現実的か。

もう1つレビューの役割として営業やコンサルが自分の都合の良いデータを使って勝手なことをしてしまうことへの予防がある。

これはExcelではよく見かけるがSQLも自在に書けて全て自身で完結できると誰にも止められなくなる。そして困ったことに会社からの評価は高くなる。

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

SQLをちょっとかける人を量産することによるデメリットは、まず上記の話がくずれるとあちこちに影響が出るので結局スキルがある人の工数がそれなりに取られる。

もちろんこの中には慣れている人や得意な人だけが行う場合でも必要なこともあるのだがそこまでエンジニアが時間を取られることもなく自走できる人が多いはず。

次に本職がおざなりになる危険がある。本職の人が10分で終わることを半日や1日かけてしまっては本末転倒も甚だしい。しかも普段違う仕事をしていると時間を無駄にしていることも察知できない。

もう1つ、本職でない人がちょっと出来るようになると周りが変に持ち上げたり、ひどいのになるとSQLなんて誰でも出来るという誤解をしだす。なお実際にSQLを触っている人はそんなこと言わない。

一方メリットは

  • 簡単な依頼でスキルがある人を動かさなくて済む
  • 動ける人がいない時に自分でできると欲しいデータがすぐ手に入る
  • 技術への知識が身につくことでコミュニケーションがしやすくなる

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

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

ちょっとSQLを書けば済む話ならパラメータだけ変えるSQLやBIツールで簡単に見られる仕組みを作っておくべきだ。

それに、たしかにスピードは出るだろうがそこまで緊急な仕事が頻発するのはスケジューリングがうまく行っていないといったより根本的な問題もあるだろう。だとしたら10人・20人にちょっとづつやらせるなら1人雇った方がいいのでは。

こうしてみるとどうもメリットよりもデメリットの方が多いような気がする。

ではその仕事を誰がやるのかはまた別の問題

もちろん興味を持った人が学びたいというのなら積極的に支援したいが、とにかくみんなでやるならきちんと検証してからでも遅くはあるまい。

なお、データを整備したりダッシュボードを作ったり、それでは対応できない場合の対応は誰がやるのかというのはまた別の問題でこれは「データ整備人(仮)」という、「データベースからSQLを書いて抽出する」という仕事についての考察というか「なにこれ?」という話に繋がっている。

誰もやらないという選択肢もあるかもしれない。ちょっとした集計と可視化の向こうには実はデータ分析による意思決定はつながっていないのかもしれない。だとしたら、誰もやらなくても大した問題にはならない。これはいまだ結論は出ておらず、今後とも検証を続けていく。