SQL人口とデータドリブンの相関
SQLを使える人が増えると、データドリブンに近づくとは必ずしも言えない。
— 𝙆𝙖𝙯𝙪𝙮𝙖 𝘼𝙧𝙖𝙠𝙞｜荒木 和也 | 🫧🖼📊📈🥠🗾 (@kazuya_araki_jp) June 4, 2024
&
欲しいデータや正しいデータを取得できないようなSQLの練度だと、SQLに触れる可処分時間が増え、その分意思決定までの速度が落ちるため、結果的にPDCAは鈍化する。 https://t.co/gVi4kSL3pU
postの通りなのですけど、もう少し解像度を上げて語ってみたいと思います。
ちなみに、似たようなことは過去に書いています。
(詳細は有料部分に書いていますが、ポエムなので大したことは書いていません)
メルカリの事例: 社内勉強会からセルフサービス化へのシフト
社内でSQL勉強会を開催している有名なIT企業と言えばメルカリですが、先のpost元でもあるように、昔から勉強会活動は盛んだったようです。
ただ、最近のnoteにこんな記事があります。
今北産業でまとめると、
BigQuery + Lookerを起点とした環境は昔から提供している。
SQLを書かないとデータ取得できないし、結果の質も担保できていない。
安くて早くて簡単なno SQLな環境であるLooker Exploreを整備し、運用している。
だいたいこんな内容のことが書かれています。間違っていたら指摘をお願いします。
SQL勉強会が設計通り順調に社員のSQLスキルの底上げが実現できていれば、後者で紹介したようなissueはおそらく発生しないと仮説しています。
なぜならば、SQLを書けるような強い人材に対してセルフBIサービスをわざわざ提供するのはコストが見合っていないため、違和感があるからです。
SQL勉強会が失敗だったという結論には必ずしも結びつきませんが、SQLを学んだだけでは、メルカリの組織が目指したデータドリブンが実現できなかったのでセルフBIサービスに切り替えたと言っても良さそうです。
※後半部分は憶測なので、事実と異なる場合があります。中の人の解説を待ちます🙇🙏
モノタロウの事例: SQLに関する取り組みそのものよりもデータ環境が心配
モノタロウはあらゆるデータがオープンになっていること、開発者かどうかに関わらずデータを扱って意思決定をすることを知り、開発が進めやすそうだなと思いました。
という文化とデータ環境とのことです。
一方で、以下の情報もあります。
モノタロウは商品採用、発注、受注、在庫、物流を自社で行っている特性上、データ分析においても複数のシステムで管理されているデータを突き合わせて行うことが多くあります。例えば商品カテゴリ毎の売上を分析するためには,商品情報と受注情報を管理しているそれぞれのシステムのデータを突き合わせて分析する必要があります。その様な分析ではそれぞれのシステム側の変更が分析に影響を与えるためシステムの変更を把握する必要や、正しい集計を行うためにはデータの入り方や更新等のシステムの仕様の理解が必要となります。
しかし、そのようなナレッジは部署や個人単位でが局在化しやすく各人によって分析や集計が異なるといったことがありました。その課題を解決するため『システム等のデータを正しく、より集計・分析しやすいように加工したテーブル』を弊社におけるデータウェアハウス（以下、DWH）として構築し、全社展開することとしました。
利用者が多い分、ドメインも比例して多い(あるいは、その逆でドメインが多いため、関係者が増える構図である)という事実があるみたいです。
ドメイン知識とデータエンジニアの向き合い方についてはまた別の機会で語ることとして、データ環境にいくつか課題を残している中でのSQL利活用推進の舵取りについては個人的には懐疑的です。
データエンジニア目線では、十分に整備されたデータ環境下が絶対条件で、その上でデータ利活用を推していくしかありません。
整備が十分でないデータを取り扱うリスクについて認識する必要があるからです。
データアナリスト目線では、不安定なデータ環境での業務遂行は非常に困難であるか、あるいは手数が増えて業務効率が低下する羽目になります。
誠に失礼な話ではありますが、以下のTech blogを拝見しての感想としては、現状分析にかけている時間が圧倒的に多い印象を受けたので、Data Martの整備やKPIレポートの整備の方が優先度が高い気がしました。
閑話休題
SQLを学ぶことでデータドリブンになるのか？
この因果を正しいと捉えているデータアナリストないし情報商材屋は巷に溢れています。
SQLを学ぶこと自体は否定しません。むしろ全人類が同じレイヤーでSQLを書けるようになってSQLにまつわる不平不満愚痴を語り合いたいです(これはただの悪口です)。
ただ、SQLを書けたらデータ関連職に俺はなれる！みたいな事には絶対になりません。
某協会の掲げるスキル要素をバランスよく摂取することでキャリア醸成が実現できるとは思いますが、少なくともSQL一本ではいささか心許ないです。
(無論ですが、Oracle Platinumくらいの資格が取れるくらいのデータベースの知識、SQLに対する造詣があればプロフェッショナルとしてご飯は食べられると思います)
先に挙げたTech Companyの事例でもありましたが、何をもってデータドリブンと定義するのか？という考え方の方がよほど重要です。
それは私や情報商材屋のような外野が口を挟むテーマではありません。あくまで組織ないし企業の決めのお話なのです。
SQLを自由に書ける環境は、果たして幸せなのか？
今回提起したかったテーマはむしろ、これかもしれません。データドリブンなんて正直どうでも良かったんや。
私は仕事柄、SQLを書く職責にある身ではありますが、可能ならばSQLなんて一切書きたくありません。
引用するデータの構造に問題がなければ、SQLは書かなくてもいいか、もしくはSELECT * FROM tableで済む世界が理想です。
しかし、現実は非情にもSQLを書かないと業務が遂行できません。
(逆に言えば、みんながやりたくない仕事に対して対価をいただいて労働しているという意味では、ある意味幸せではあるのかもしれません)
SQLを書かせる環境についての苦言は先に紹介したnoteにも書いていますが、
SQLを書く時間が惜しい。その時間に別のこと(分析業務、レポート作成、考察を述べる、etc…)ができるから。
SQLを自分で書く分には我慢できる。他人の書いたSQLを評価しなければいけないのが辛い。
レビュイーが増えると指数関数的にレビュワーとしての自分の可処分時間が増え、業務が逼迫して詰む。
レビューを無視すると、間違った結果を無視してしまうことになる。例えばマーケターが間違ったSQLで間違った結果のデータを施策に使ってしまい、後々大事故を引き起こしてしまう。
私の中でレビューをやらない選択肢がない。やらないと自分に跳ね返ってくる因果があるから。
バックグラウンドが異なる、ドメイン知識がないとできない類の業務が存在するので気を引き締めなければならない。
業務委託等で知らないデータベースに飛び込んだ際の最初の壁がこれ。
SQL的には正しいが、結果的に間違っている。あるいはSQL的に間違っていても、結果が正しい。という奇妙な現象に遭遇することがある。
この辺りは時間で解決する問題だけど、逆に言えば時間をかけて解決しなければデータ人材としての信用問題になる。
などなど、まだまだデメリットが多そうな所感です。
結論
何がデータドリブンかなんて、外野が決めるものではなく、当事者が決めること。
SQL人口を増やす際は、デメリットに目を瞑らないこと。
SQLは(できれば、希望としては、極力、可能な限り、支障がなければ、最大限の譲歩ではあるが、可及的速やかに)書きたくない。
読んでいただきましてありがとうございます。 サポート代は次回の執筆の投資に使わせていただきます。 https://twitter.com/kazuya_araki_jp https://public.tableau.com/profile/kazuya.araki#!/