みんながSQLを書ける（データを民主化する）メリットとデメリット
「データの民主化」はSQLだけの話ではないのだけれども
「データの民主化」という言葉は定期的に聞こえるが、定義がどうもつかめない。考えたところでわからないので具体的にそのうちの一部を構成していると思われる「データ抽出」を取り上げる。一応題名には入れておいたが、以降「データの民主化」は使わない。
「データ抽出」は大きく分けて「入手する」「加工する」の２つに分かれる。前者の代表例が「データベースからSQLを使ってデータを入手する」になる。
「入手する」には他にも「他部署になぜ必要なのかを説明して権限をもらう」などもある。また、入手と加工が同時に行われることもあるのではっきり切り分けることはできない。とはいえ「みんながデータ抽出を全部自分でできるようになったら」だと話が広すぎるし現実的にありえない。
というわけで、SQLを中心に置くのが話が伝わりやすいと思うので今回はここを主語にする。
さて、社員の多くがSQLを書いていることを宣伝している企業もあるぐらい、みんな（といっても大抵の場合はビジネスサイドの現場に限られる）がSQLをかけることについては肯定的な意見が多く聞こえてくる。その度に、本当にそれがいいことなのだろうかと疑問を感じている。
そこで「みんながSQLを書くことの」メリットとデメリットについて考えてみる。
みんながSQLを書けるようになるメリット
抽出依頼が減る
データを入手するまでの期間が短くなる
データそのものやデータ抽出への理解度が上がる
抽出依頼が減る
特に単純な集計が減る。とはいえSQLを書く時間は元からたいしてかからない。内容を決めるための打ち合わせや細かいコミュニケーションが無くなる、という方が正しいだろう。
なお「データの業務が効率化できる」ではないのは抽出の仕事がなくなるわけではなく、かつデータの扱いに長けていない人に変わるだけだから。
データを入手するまでの期間が短くなる
依頼して打ち合わせして、抽出側の仕事が詰まっていたらさらに何日も待たないとデータが手に入らない、という状況はSQLが書ければ解決する。
とはいえ多くの場合は書けるといっても期待されるのは基本的な部分だ。なのでデータがある程度は整備されており、単純な集計（カラムと条件の指定、それから集計の方法を決定すること、つまりスプレッドシートでいうピボットテーブルでできる範囲）であれば機能する。
それ以上の段階が必要なクエリ（JOINとか）になってくると、各人のスキルに依存する。
データそのものやデータ抽出への理解度が上がる
実際に手を動かすことでデータがどのようになっているかや定義の確認の大変さを理解できる。データ抽出という仕事の大事さも経験して初めてわかることもあるだろう。
ただし、データの作られ方や利用の注意点などを理解しても分析の質が上がるわけでもない、という点には注意が必要だ。
みんながSQLを書けるようになるデメリット
みんなでSQLを書くということは経験やノウハウが分散するということでもある。なので「SQLに慣れていない人」がたくさんできることになってしまう。すると、次のようなデメリットが考えられる。
本職がおざなりになる
環境への悪影響を及ぼす
レビューに時間がかかる
効率化するモチベーションがあがらない
また、SQLを学んでも分析が出来るようになるわけではなく、リテラシーも身につかない。次のようなことはSQLだけで起きることではないが、みんながSQLが書けるようになることでさらに大きな問題を引き起こす例だ。
定義の違うクエリが大量に発生する
都合の良いデータを作ることを止められない
分析した気になれる
本職がおざなりになる
SQLに慣れていれば30分で終わることを半日や1日かけてしまう。詳しくない人同士であれこれ話しているところにエンジニアが気づいて介入したらすぐに片付く、というのもよくある。その間、本来やるべき仕事は止まる。
SQLを書くことで本来の仕事ができないのでは本末転倒も甚だしい。もっと悪いことに、時間を無駄にしていることも気づいていないかもしれない。
環境への悪影響を及ぼす
たまにしかSQLを書かないとパフォーマンスまで気にしないからだろうか、スプレッドシートやダッシュボードで一度に大量のSQLを処理させようとする。
すると重すぎてちょっとしたデータを見るのにも毎回数分待たされたり、時には動かないものを作ってしまいがち。さらに悪いことに、リソースを食いつぶして別の人の仕事を止めてしまう。
レビューに時間がかかる
他人が書いたクエリを読むのはいつでも大変だが、慣れていない人のクエリは冗長になることも多いので余計に時間がかかる。また、修正にも時間や回数が多くかかる。
データに責任を持つ部署がレビューしないで各個人や部署の責任で解決してもらう方法もあるが、おすすめはできない。短期的は効率化できるように見えるが結局あとでさらに大きな課題となるだけだ。
効率化するモチベーションがあがらない
複雑な場合分けを毎回書こうとして間違えたり、抽出に時間がかかってもたまにしかSQLを書かなければ耐えられるし、そういうものだから仕方がないと思ってしまう。そのため効率化しようとするモチベーションが働かず、非効率なままで仕事を続けてしまう。
データを使い始めたばかりで1人や2人しかいないのであればともかく、これがもっと大きな企業で各部署で独自に行っていたりすると膨大な無駄が発生する。
定義の違うクエリが大量発生する
データに個別のニーズがあることは当然のことだ。しかし、誰も把握せずに個別に独自の定義で指標を作り始めてしまうことは問題がある。
部署間どころか同じチーム内で隣に座っている人との間ですら認識が合わない。SQLが書けるとデータベースから抽出する時点でずれが発生するのでなお一層状況を悪化させる。
コミュニケーションをしようとしても数字が微妙にずれる。そのたびに間違い探しと対応の協議が必要になる。多くの場合、大した誤差はないから問題ないことにされ、またすぐに同じことが繰り返される。
都合の良いデータを作ることを止められない
データを使う際に最も戒めなければならないことの一つに「自分に都合の良い結論を出せるようにデータを選ぶ」こと（チェリーピッキング）がある。
データ抽出に別の人が介入していても「キャンペーンがうまくいったように見える数字が欲しい」と直接言われることがあるぐらいに当たり前に行われているようだ。
全てが個人に閉じていると誰も把握できないうちに話が進んでしまう。報告を受ける人が結果にしか興味がなかったりリテラシーが低く言われたことを真に受けてしまうならば、報告する側にとっては非常に都合が良い。特に報告を受ける人にとって都合が良い話はあとでその間違いを指摘しても手遅れになることが多い。
データが整備がされていれば、選択肢が狭まるのでおかしな使い方をすることは難しくなっていく。なので特に整備が進んでいない企業で、各人がSQLでできることの幅が大きいとリスクが高くなる。
分析した気になれる
SQLを書こうとあれこれ調べたり、書きながら試行錯誤するのは楽しい。うまくデータが入手できたら満足感がある。
しかし、分析すること（その先の企画・意思決定・実行も含むかもしれない）が仕事であるならば、その仕事にはまだ手がついていない段階だ。分析した気にはなれるが、実はやるべき仕事にはまったく手がついていない。
どの視点で見るかにより違いそう
誰がどうやるかに関わらず、データを入手する仕事自体がなくなるわけではない。ということは、みんながSQLを書くということは
データの扱いに長けている人ではなく慣れていない人が
効率化のモチベーションがある人ではなくない人が
都合の良いデータを使うモチベーションがない人ではなくからある人が
全体での整合を考える必要がある人ではなくない人が
抽出を担う、ということでもある。
そう考えてみると、「みんながSQLを書いて自分でデータを入手できること」は「個人で考えるとメリットが、全体で考えるとデメリットが多い」とまとめることができそうだ。
ビジネスサイドがSQLを学ぶことに意味はない
「全体で考えるとデメリットが多いのであれば、ビジネスサイドがSQLを学んだところで損するだけだ。だからビジネスサイドがSQLを学ぶことに意味はない」という話にした方がある意味盛り上がるのでPV稼ぎするならそう言いたいところではあるが、そんなことはない。
全ては状況による。となれば、「ビジネスサイドの人が、SQLを学ぶメリットが大きいのはどんな状況なのか」と問う方がよいだろう。
答えを先に書けば「分析したいのでデータが欲しいのに、他に抽出の仕事を全うする人がいないので自分でやらないと進まない」という状況である。詳しい話はまた今度。