見出し画像

非エンジニアがSQLを使えるようになるメリット・デメリット

阿部真幸(Masayuki Abe)

以前こんなツイートをしたところ、かなり"いいね"を頂きました。

一部の専門家だけではなく、一般のビジネス職などの人でもデータを活用できるようにする『データの民主化』的なトレンドも相まって、共感いただける方が多かったのかな、と推測しています。
今回は、私のようなビジネス企画職（マーケや事業開発）など、非エンジニア職の人がSQLを活用できるようにすることのメリット・デメリットを経験を元にまとめてみました。
メリット→デメリットの順番に説明していきます。

【メリット1】自分でデータ抽出できることで業務スピードがアップする

今まで抽出ができる人に頼んでいた”データ抽出”という業務を自身で完結できるので、分析業務のスピードがかなりアップします。
例えば私が過去にいた職場環境では、アプリやWebサービスを開発しているエンジニアの方に依頼し、そのエンジニアが片手間でデータを抽出するという業務フローになっていました。
この場合、データ抽出まで数営業日かかります。出戻りが発生した場合も、さらに数営業日追加されます。

<Before>：アイドリングタイムが多い
エンジニアにデータ抽出を依頼する
↓
数営業日後にデータをもらう
↓
分析作業
↓
足りないデータに気づいてもう一度データ抽出を依頼する
↓
数営業日後にもう一度データもらう
↓
分析やり直し

これが、自身でデータ抽出を完結できることで、こう変わります。

<After>：アドホックに分析できる
SQLたたく
↓
データ抽出
↓
分析作業（分析しながら、不足データがあれば追加で抽出）

つまり、よりアドホックに分析業務が行えるようになります。

【メリット2】今まで依頼していたエンジニアの工数が削減できる

上記のように、開発の片手間にお願いしていたデータ抽出業務をエンジニアの方がやらずに済むようになるので、エンジニアは本来のミッションに集中できるようになります。
これに関しては、会社ごとに組織体制があると思うので一概には言えませんが、現在エンジニアが片手間でデータ抽出業務を行っている場合は当てはまります。

【メリット3】ビジネス側がデータの構造を理解できるので、データ活用によって出来ること／出来ないことの区別がつけられる

昨今のビッグデータブームによって、『データがあれば何でもできる』風な雰囲気を個人的に感じることがあります。もしかしたら、そんな認識を持っているビジネスパーソンの方もいらっしゃるかもしれません。
確かにデータ活用により、人間だけでは難しい「予測」や「分類」などが出来るようになるのは事実ですが、それは魔法ではありません。
また、データとして取得出来るもの／出来ないものもありますし、取得方法によってその結果も変わります。
事業に関わる多くの人が、"今の事業で取得しているデータの構造をきちんと理解できるようになる or 理解しようとする姿勢を持つ" ことで、現実的にデータを活用して出来ること・出来ないことの区別の精度が上がり、無茶な要求によるロスが減るのではないでしょうか。
要するに、SQLを書くにはデータ構造を理解する必要があるので、
突拍子もない『ねえ、こんな事できない？』という無茶ぶりが減るのではないかと思うのです。

【メリット4】企画者が効果測定から逆算して、データ取得～格納の要求が出せる

これは私が集客やCRM系の業務が多いので当てはまるのですが、データの構造を理解することで、具体的にデータ取得や格納方法の要求が出せるようになりました。例えばこんな感じです。↓

<Before>：要求が抽象的
例）今回のKPIはこのボタンのクリック数なので、IMP数と合わせて取れるようにしておいてください。
↓
<After>：要求が具体的
例）今回のKPIはこのボタンのクリック数です。ログの発火タイミングはボタンTAP時で、同時にパラメータとして〇〇を飛ばしてください。
IMPのログの発火タイミングはこの画面のリクエスト時で、パラメータは〇〇…
データ型は"int"でお願いします…

このようなイメージで、実装の際、エンジニアの方との会話がだいぶスムーズになりました。

【メリット5】BIツールでダッシュボードを作れる

これは全てのBIツールに当てはまるわけではありませんが、私が過去に在籍していた企業では、「Re:dash」を採用していました。Re:dashでは、SQLを書いて参照しているDBからデータを抽出し、チャート化することができます。よってSQLを書くことができれば、自分やチームが見たいデータの抽出・チャート化が簡単に出来るようになります。
そして、複数のKPIのチャートを集めてダッシュボードを作成するのも難しくありません。
他にも有名なBIツールである「Tableau」や「Googleデータポータル」ではSQLを書かずともダッシュボードを作ることは出来ますが、書けると便利な場面はあります（カスタムSQLなど）。

次に、デメリットについてまとめます。総じて、SQLを使う人が増える分、管理コストや確認コストが増えるのかなと思います。

【デメリット1】管理しないと、クエリがどんどん増殖する

過去に使用していた「Re:dash」では、アカウントがあれば誰でもクエリを作成することが出来ました。逆に言うと、管理をしないとクエリはどんどん増え続けるということです。
管理をしない場合、「このクエリは使ってるの？消してもいいの？」みたいな状態になります。つまり、SQLを使ってデータ抽出をする人が増えると、その分管理が必要になるというデメリットがあるのかなと思います。

【デメリット2】クエリやデータの理解が間違っている場合、それがそのまま意志決定のミスになる

データを抽出、分析する場合、多くは意思決定に使います。よってデータを抽出するためのクエリが間違っていたり、データがどういうデータなのかという理解が間違っていた場合、それはそのまま意思決定のミスに繋がります。よって、しっかりと理解ができている状態で業務にあたる必要がありますし、場合によってはチェック者を置く必要があります。
非エンジニアでSQLを覚えたての時、起きやすい間違いかなと思います（私も何度かミスをして周りに迷惑を掛けました…）。

【デメリット3】重いクエリを投げてしまって周りに迷惑をかける

これもSQLを覚えたての頃に起きやすい間違いかと思うのですが、無邪気にめちゃくちゃ重いクエリを投げてしまうこと、ないでしょうか？（私はありました。ごめんなさい…）
組織や企業によって状況は違いますが、めちゃくちゃ重いクエリを投げてしまうことで、例えばこのような事が起きる可能性があります。

・サーバーに負荷がかかるので他の処理が遅れたり、支障が出る。
・DBの構成次第では従量課金の料金がたくさん発生する。

例えばBigQueryはクエリごとの従量課金なので、軽い気持ちで重いクエリを投げて、大変な料金が発生する場合があります。（100万円以上かかった人がいるとかいないとか…）
このような事が起きないように気を付けるためにも、個人・チームで対策をする必要があると思います。

新しいことへの挑戦はキャリアの可能性を広げる

SQLに限らずですが、新しいことを覚え、理解し、仕事で積極的に使っていくことは、自身のキャリアの可能性を広げてくれると思います。
私もSQLがきっかけでデータ分析を行うようになり、付随してデータ関連の業務を行えるようになりました。最近では転職し、マーケや事業開発をやりつつ、Tableauのダッシュボード開発やデータマート開発にも携わらせてもらっています。
1つの職種にこだわり過ぎず、様々なことに挑戦できる人が増えるといいなぁと思っています。

以上、非エンジニアがSQLを使えるようになるメリット・デメリットなどでした。過去の私と近い立場で、SQLをこれから習得して業務に使おうとしている方などや、そういったチームにお役に立てたら嬉しいです。
最後までお読み頂きありがとうございました。また書きます。

------------------------------------
よかったらtwitterのフォローもどうぞ。
https://twitter.com/MasayukiAbe7
------------------------------------


いいなと思ったら応援しよう！