データアーキテクト(データ整備人)を”前向きに”考える会』開催!】みんな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を書いて抽出する」という仕事についての考察というか「なにこれ?」という話に繋がっている。誰もやらないという選択肢もあるかもしれない。した集計と可視化の向こうには実はデータ分析による意思決定はつながっていないのかもしれない。したら、誰もやらなくても大した問題にはならない。これはいまだ結論は出ておらず、今後とも検証を続けていく。