Livesense not engineers Advent Calendar 2018の１日目をお届けします、稲垣と申します。
普段はIESHIL CONNECT ／ IESHILのディレクターをしています。

今日は、「非エンジニアがSQLを書く」の先にぶつかる「SQL力を活かす分析の壁」について、普段考えていることを書いてみようと思います。
SQL活用をはじめたもののどうもうまく使えてない気がする、どうやって活用まで広げていいのかわからない方に、少しでも考えるヒントになったら嬉しいです。

「非エンジニアのSQLはあたりまえ」な越境型組織

Livesenseでは初期の頃から職種越境の文化が強く、
営業さんまで、社員全員がSQLを使う 「越境型組織」 ができるまでの3+1のポイント
といったように「SQLはあたりまえ」な空気が浸透しています。

クックパッドさんやピクスタさん、スペースマーケットさんなどのように、この数年でSQLあたりまえ•̀.̫•́✧ という企業がどんどん増えてきているように思い、とても嬉しいです。

かくいう私が入社したのは４年半前。
「SQL？データ分析？なにそれおいしいの？？」状態から、今では欲しいデータを自由に取り出して課題・改善仮説立てまで一気にできるようになりました。
また単純にクエリが書ける・書けないだけの話ではなく、クエリスキルで解決できない集計・整形をExcel関数やマクロ、正規表現で扱う方法など、選択肢も豊富になってきました。

最初は正しいクエリが書けることや、SQL文だけで必要な集計結果までたどり着けることに躍起になっていましたが、「SQLはあくまでツールの１つだ」と消化できること自体にとても意味があったように思います。

活きるSQL力までの壁

きっかけは人それぞれでも、何かしらの「実務に活きる」が当然ベースにあるでしょう。

ほしいデータが取れる、とは

上限はありませんが、「SELECT ~ FROM ~ で結果が返ってくるってわかった」は大きな一歩です。
スキル醸成に向けたある程度の目安になるとしたら、以下のような点でしょうか。

• 基本的なクエリ記述ルールが分かる
• 人の書いたクエリの条件（期間指定など）を一部書き換えて更新できる
• 人の書いたクエリを引用し、自分がほしい内容に書き換えられる
• ゼロベースで自分の書きたいクエリが書ける

また、この段階とは別軸で、「活きる力」に大きく関わるポイントがいくつかあります。
より本質的で、↑↑で書いた段階を気にするよりもこっちにフォーカスした学習の方が早いだろうなと感じています。

• やりたいことから必要な構文を逆引きできる検索力
• 自分のクエリが合っているかどうか検算する力
• 自分が扱うDBのテーブル・カラムの把握 データの中身から、そのテーブル・カラムの意味・役割を推察できる力

特に、「人のクエリの転用」から「ゼロベースで書きたいクエリが書ける」にジャンプアップするタイミングで必ず向き合う必要が出てきますね。

さて。ここまでは、よくある「非エンジニアがSQLを学習する」ときのお話です。
「ほしいデータが取り出せるようになったぞー！」めでたしめでたし、となるでしょうか。
モニタリングなどの際には良いでしょうが、改善仮説立てや課題整理のためのデータ分析となると、むしろここからがスタートです。

そして、ここが今日の本題です。
データが自在に取り出せる力は、それを何らか次の改善につなげられてこそ、その真髄が発揮されるはず。
その思いから、後輩に向けてデータ抽出・分析の勉強会をする機会を何度か持ってきた中で、いくつかの課題に気が付きました。

データ抽出とデータ活用の間

一時の私は、大変な誤解をしていました。
「SQLが書けて、データを取り出せたら、数字の振れ幅や変化を眺めて仮説を立てられるようになるはずだ」
とんでもない飛躍に我ながら笑ってしまいますね。笑

この飛躍を埋めないと、本当に活きる力にはなりえない、と私は考えています。
実際にいろいろな人と話したり、FBを繰り返す中で、どうやら以下のような段階に分かれそうだ、と見えてきました。

• 必要なデータを取り出せる
  • ★ 必要なデータの定義ができる
  • クエリが書ける
• 生データから事実・仮説を見極める
  • ★ 取り出したデータを眺め、特徴的な事実を抜き出せる
  • 特徴的な事実の背景理由や関連事項などの仮説を立てられる
• ★ 生データ ⇔ 抜き出す事実 ⇔ 仮説 を、論理の破綻・飛躍なくつなげられる

中でも、特に無自覚的になりやすい落とし穴に★をつけてみました。
勉強会などをしていて「言いたいことはわかるけど、それって具体的にどういうこと？」となりやすく、自分でもまだまだノウハウ共有に苦戦しているポイントです。
それぞれに、なぜ気づきにくいのかを挙げると以下のようになります。

必要なデータの定義ができる

クエリレビューを依頼された際によくする質問の１つに、「このCOUNTは何を数えたかった？」が挙げられます。
簡単な例で言えば、PV・セッション・UUなど、「どの粒度で集計をしているか」などですね。
おかしな質問のようですが、特にSQLを使ってデータを取り出す場合、DISTINCTの有無やGROUP BYの対象のように「自分のクエリは何をどんな風に数えたり・足し上げたりしているか」をちゃんと自覚しないと全然違う結果が出てしまいます。
特にSQLを覚えたての頃は、構文を書くことでいっぱいいっぱいになりがちで、「何を数えているの？」と聞かれてはじめてハッとすることが多いように思います。

取り出したデータを眺め、特徴的な事実を客観的に抜き出せる

特に重要なのが、「客観的に」という部分です。
データ分析をするとき、多くの場合でたどり着きたい仮説や傾向が前提にあるため、その前提に都合が良い事実や、検証しやすい事実の方に目を向けたくなりがちです。
その誘惑をぐっとこらえ、まずは目の前に広がる事実に向き合えるか否かは結果に大きな違いを生みます。

生データ ⇔ 抜き出す事実 ⇔ 仮説 を、論理の破綻・飛躍なくつなげられる

本当に当たり前のように聞こえますが、自分も含めてこの点の飲み込みに苦戦する人はものすごく多いです。その大半は、結論に都合良いように、無自覚に間を補完してしまうこと。
事実から仮説を立てているつもりが、いつのまにか事実を拡大解釈していたり、データにないことを想像で付け加えたり、「市場的に」などそれっぽい言葉を持ってきてみたり、となかなかダイナミックな飛躍が生まれがちです。笑
データが取り出せることの価値は、仮説の確からしさを裏付けることにある！と考えれば、とてもとてももったいないですね。

また、育成観点での難点としては、レビューやFBの際に重箱の隅をつついているような響きを伴いやすく、コミュニケーションに最も工夫が必要なポイントとも言えるかもしれません。

壁を超えるための「間違っていい」安心

ここまで書いてきたデータ抽出・分析の壁。
４年半を通じ、様々な人にお世話になりながら、いくつかの壁を気がついたら乗り越えていました。

クエリ習得に悪戦苦闘したり、誤った分析へのフルコンボなレビューに改めて挑んだりとコツコツ努力もしましたが、もっとも大きな力になってくれたのは、数字から新たな課題に気づけたときのワクワクと
「分析は間違っていい。間違ってる指摘を受けて見直せれば何も問題ない」と普段の業務を通じ上司に教えてもらったことのように思います。

レビューを受けて軌道修正できれば、たどり着く結果はより望むものに近づくかもしれません。
レビューを受けて軌道修正できる人には、間違えても次のチャンスが巡ってきやすいものでしょう。
こう思えるようになったことで「間違ってるよ」と言われることの恐怖がだいぶ薄らぎました。

だから、「間違っていいよ。でも”間違ってるよ”はちゃんと言うからね。」を自分のスタンスに、これからも学習に対して試行錯誤していけたらなーと思っています。

カレンダー１日目の終わりに

この記事にした内容は、２年くらい前からモヤモヤと感じていたので、勝手ながら文章化する機会にさせていただきました。

なんだかずいぶん散文的になってしまいましたが、、、むしろこれから記事を書く非エンジニアの皆さんの技術的な意味でのハードルを易しめに設定できた、と捉えています。笑

技術や仕組みで物事を解決することの面白さを、肌で実感できるレベルでおしえてくれたたくさんの人たちに今年も感謝を込めて。
来年も、新しい技術との出会いから新しいワクワクが生まれますように！