実際に教えてわかった、非エンジニアでもSQLを学ぶべき3つの理由

最近は仕事の一貫で社内のカスタマーサクセスチームのメンバーにSQLを教えています。カリキュラム全体は講義とOJTに分かれていて、今はちょうど第一期生の講義が終わったところです。講義は1.5h×3回の計4.5時間で、講義の間に課題を出しています。全3回の講義終了時に参加してくれた同僚からアンケートを取ったところ、ありがたいことにたった4時間半の講義でも「もっと早く受けたかった」、「他の人にも薦めたい」という好意的な意見をたくさんもらいました。（うちのプロダクトの機能にSQLを書けるものがあったりするので特にSQL知識の重要性が高かったというのはありますが。）

そんなわけで、この講義を通じて「非エンジニアがSQLを通じてデータの扱い方を学ぶことの価値」について一定の確信が得られました。せっかくなのでこのnoteでも「非エンジニアがSQLを学ぶ価値」について言語化してみます。

ちなみに、「そんなことは知ってるから早くSQLを教えてくれ」というせっかちな人がいるかもしれません。流石に仕事で使っている講義資料は外に出せないのですが、似たようなチュートリアルを「非エンジニアのためのエンジニアリング」というサイトで連載しているのでぜひ。（宣伝）

BigQueryで学ぶSQLデータ分析入門 | 非エンジニアのためのエンジニアリング

不確実性の高い仕事で前に進むためには？ -経験主義と仮説思考-

突然ですが、あなたの仕事上の意思決定には、常にわかりやすい正解選択肢があるでしょうか？もし正解がすでにわかっている場合、それを選んで実行するだけなのでとても簡単でしょう。しかし世の中の仕事の多くは、「何が正解かわからないけど、こっちに進んだ方が良さそうかも？」くらいのそれっぽい選択肢を正解と信じて突き進むようなものだったりします。

別の言い方をすれば、多くの仕事は「課題解決のための選択」を常に求められます。たとえば「売上目標にあと1,000万円足りないけどどうしよう？」みたいな課題があって、そのための手段はいくつか思いつく。だけどその中でどれが一番売上upにつながるかはわからない。そんな不確実な状況で、それでも事業を前に進めなければいけない。もっと言えば、「そもそも課題がたくさんあるけどどれから解決しよう？」という、課題の優先順位に関する選択が一番重要だったりします。そんな膨大な選択の組み合わせの中から正解っぽいパターンを選び続けるのは、至難の技です。

そんな絶望的な状況の中でも前に進むためにはどうすればいいでしょうか？僕にとってのバイブル的な存在である書籍『エンジニアリング組織論への招待』では、そんな不確実な状況でも確実に前に進むための考え方として、経験主義と仮説思考が紹介されています。

経験主義は、自分のコントロールできるものを通じて、観測できるものを改善する発想です。そして、そこで得られた知見によって、次のステップに向かうための思考様式です。仮説思考は、限られた情報の中から、大胆にモデルを推論し、そのモデルの確からしさを発見するための行動を促す思考様式です。
（『エンジニアリング組織論への招待』 1-5. 経験主義と仮説思考）

詳しい説明はぜひこの本を読んで欲しいですが、ここで重要なのは、「コントロールできるもの」を操作し「観測できるもの」の結果を見ることでしか前に進むことができない、ということです。たとえば「商談の場では営業が話しすぎない方が受注率が上がって売上がupする」という経験則に基づく仮説があったとします。これを頭ごなしに営業社員に強制するだけでは、ただの精神論です。仮にその後売上が上がったとしても、たまたま同じ時期に別の要因が重なって業績が良かっただけかもしれません。それでは再現性のある学びが得られたとは言えないでしょう。幸い、商談の場でどんな話をするかは「コントロールできるもの」ですし、受注率も「観測できるもの」のはずです。「商談の場で営業社員が話している割合」も、録音や本人の記録を使って定量化してやれば、話し方と受注率に関係がありそうかを実際に分析することができます。こうした行動と結果の観測から知識を手に入れようというアプローチを取るのが経験主義です。

経験主義と非常に関係性の強い思考法が、仮説思考です。仮説思考では、限られた情報の中から仮説を立てて、その正しさを検証していきます。仮説はその名前の通り「仮の説」であり、正しいかどうかはわからないという前提で掲げられます。もし「商談の場で自分が話すぎない方が受注率が上がる」という仮説があれば、その正しさをどのように検証すべきか考えます。大抵の場合は、実際にそれを実行してみた結果を計測し、実行しない場合のデータと比較して因果関係があるかを検証します。具体的には、たとえば商談で営業社員が話した時間の割合と実際の受注率との関係を分析することになります。

ここでは営業の仕事を例に挙げましたが、「優秀な人を採用するには？」とか「メンバーの生産性を上げるには？」といった様々な課題についても同様のアプローチを取ることができます。正解がわからない状況で、より正解に近い仮説を得るためにはどうするか。それには「コントロールできるもの」と「観測できるもの」との関係性について様々な仮説を立て、それを検証し、別のより良い仮説を立て、というサイクルをグルグル回し続けるのが一番の近道です。

仮説検証をするには大抵、データを見る必要がある

実際に僕が仕事をするときも、「目的に効きそうな打ち手は何か？」、「その仮説はデータからどのように検証できるか？」を考えながら日々学びを蓄積しています。せっかくやった仕事が何らかの仮説の検証につながらなければ、来年も再来年も今と同じ武器で戦い続けるしかなくなります。もしかしたら、「全ての仕事は何らかの仮説を検証し、再現性のある学びを生むためにやっている」と言い換えてもいいかもしれません。（実際は上手く学びにつなげられる仕事ばかりではありませんが。）

たとえばいま僕がいるチームでは、「クライアントに今よりプロダクトを使いこなして継続利用してもらうために、我々はどうするべきか？」ということを日々考えています。具体的には、「解説記事へのリンクをポップアップで表示すればいいのでは？」みたいなことを考えて実行しながら、「実際クリックされたのか」とか「そもそも記事をたくさん読んでいる人は継続利用しやすいのか」といったことをデータから検証したりしています。逆に、「後からこういう分析したいから、このポップアップがクリックされたときにはこんなデータを取っておこう」みたいに検証手順から考えてデータを予め取っておくということもあります。Webの世界に限らず、立てた仮説にまつわる行動と結果の関係性の強さを見るには、実際にやってみた結果のデータを見る必要があります。また、たった数件のデータを見ただけでは誤差が大きすぎるので、より精度の高い検証をするためにはそれなりの数のデータを集めて分析する必要があります。

また、そもそも仮説を立てること自体が「限られた情報の中から」モデルを推論することでした。仮説を立てるためのその「限られた情報」を得るために、ざっと過去のデータを抽出してみましょうか、といったこともしばしば必要になります。

そんなわけで、不確実な状況で仕事を前に進めるためには仮説検証が重要で、そのためにはある程度の量のデータを自由に扱えた方が有利になるわけです。

SQLなんか無くてもデータ分析はできる

じゃあ自らデータを抽出したり分析したりするにはSQLが絶対に必要かというと、決してそんなことはありません。その理由は2つあります。

1つは、この世にはExcelやスプレッドシートがあるからです。ご存知の通り、簡単なデータ分析であればExcelでも十分に可能です。それもSQLを学習するよりずっと直感的に操作でき、データを用意するプロセスもとても簡単です。実際、SQLが書ける人であっても状況によってExcelやスプレッドシートと使い分けることもあります。

2つ目の理由は、よくある決まった分析であれば世の中にあるソフトウェアの機能の範囲で簡単に実現できるからです。たとえばよくできたSFA（営業支援システム）であれば、どの会社でも見たくなるような営業関連の数値を勝手にグラフ化してくれるような機能があるでしょう。Webのアクセスログ分析でよく使われるUU数やPV数は、Googleアナリティクスを導入すればトップページのダッシュボードに自動で表示されます。

そんなわけで、SQLなんか書けなくても、世の中の素晴らしいソフトウェアを使えばデータの集計や分析だって簡単にできるわけです。

それでもSQLはなぜ重要か？

それでも、「非エンジニア SQL」などと調べると、「エンジニアじゃなくてもSQLを学んでこんないいことがありました」みたいな記事がたくさん出てきます。たとえば、『第6回　［ビッグデータ編］チームの誰もが活かせる分析基盤を目指して：リクルートライフスタイルの技術力を追え！｜gihyo.jp … 技術評論社』という記事には、リクルートライフスタイル社の企画担当者300名がSQLを日々実行しているという衝撃的な内容が書かれています。

2～3年前に導入したNetezzaやAmazon Redshiftを300名程度のディレクターが利用し，自分たちのプロダクトを分析しています。ビッグデータのユーザー会などで，うちの会社は300人ぐらいが（ビッグデータ分析基盤に対して）SQLを投げているという話をすると，すごく驚かれます（笑⁠）⁠。

この例は極端にしても、「エンジニアではない職種の人がSQLで自由にデータ分析できるようになって生産性が上がった」といった話は、枚挙に暇がありません。

SQLなんか無くてもデータ分析ができる状況で、なぜ人はSQLを書くのでしょうか？その理由は3つあります。

1. SQLはデータベース上のデータを扱うための最大の共通言語である

ある程度決まったフォーマットのデータを継続的に集めましょう、といった状況では、基本的にはデータベースというものを構築してそこにデータを集めることになります。別にスプレッドシートにデータを貯めてもいいのですが、数十万行クラスの大量データを扱えるようには作られていません。実際、1つのスプレッドシートのセル数の上限は2020年10月現在で500万セルまでです。また、データを貯めるときは外部システムからデータを更新したり、データの整合性を担保したり、自動でバックアップを取ったり、色々と気にしなければいけないことがあります。こうした要求にも、データベースの機能を適切に使えば比較的容易に応えることができます。

実は、データベースというのはソフトウェアの1ジャンルのことであり、その種類はたくさんあります。たとえばMicrosoftのSQL Server、OracleのOracle Databaseなど、有名なものを挙げるだけでも10個くらいはすぐに挙がります。それらは全て「データを管理する」ソフトウェアですが、機能や得意分野が微妙に異なります。ただし、大抵のデータベースはSQLというある程度標準化された言語によって、そのデータを抽出・集計することができます。現在SQLは、自然言語における英語のように、データの世界を旅するときにとりあえず覚えておいて損がない言語になっています。

もちろん、データベース内のデータを誰かに出してもらって、Excelやスプレッドシートで分析するということも可能です。しかし、SQLでデータベースの中身をそのまま参照できた方が、自分だけで分析業務が完結するのでよほど速いはずです。

ちなみに、スプレッドシートにも実はSQLチックな書き方でデータ抽出ができるQUERYという関数も用意されています。

2. SQLで書いた処理は、何度も再利用できる

スプレッドシートで、たとえば「グループ別集計をやった結果に対してさらに絞り込みをかける」という操作をしたいとします。それには一般的に次のような操作をする必要があります。（もっと上手いやり方があれば教えてください。）

1. 元データを指定しピボットテーブルを作る
2. ピボットテーブルで適切な行と値を設定する
3. 結果を別シートにコピーしてフィルタを作成する

1回だけ実行するならこの面倒な操作も我慢できますが、「元データは日々変化するので、週に1回は結果を再チェックしたい」という状況だとかなりつらくなります。Google Apps Scriptなどを駆使すれば自動更新プログラムを書くこともできるかもしれませんが、そのプロセス自体があまりにも煩雑です。

一方、SQLであれば次のようなSQLで書かれたテキストを保存しておくだけで、何度でも同じ処理を実行することができます。

SELECT
    fullVisitorId
    , COUNT(*) AS pv
    , COUNT(DISTINCT visitId) AS session
FROM pageviews
GROUP BY fullVisitorId
HAVING pv > 5
ORDER BY pv DESC

データベースの中身が日々変わっても、SQLはデータベースの中身を直接参照することができるので、SQLを実行する度に結果は最新のものになります。変わりゆくデータに対して繰り返し同じ集計をかけて変化を見たい、というケースでは、スプレッドシートでやるよりもSQLの方が圧倒的に楽になります。

また実際に書かれたSQL文の実体は、「データベースに対するある集計ルールを記述したテキスト」です。テキストである以上は、ファイルに保存したりチャットツールに貼ったりして、簡単に他の人と共有することができます。チームメンバーは、あなたが過去にしたのと全く同じ集計を、その共有されたSQL文を使って一瞬で実行することができます。これはスプレッドシートの一連の操作方法を同僚にわざわざ教えるよりもずっと簡単です。

このように、「ある重要なデータ分析のロジック」をSQL文として保存しておくと、誰でもそれを簡単に再利用することができます。仮説検証に役立つSQL文をたくさん書いて貯めておくこと自体が、再現可能な学びを蓄積する1つのプロセスになるとも言えます。

3. あなたが必要とするデータをすぐに出せる人はあなたしかいない

とはいえ、あなたはまだSQLを本気で学ぶ気にはなっていないことでしょう。それは、「必要なデータ集計の手段としてSQLが最適であっても、SQLが書ける他の誰かがやればいいのではないか？」という疑問があるからです。

この疑問に対する答えは、「なぜ全ての職種にITリテラシーが必要なのか？」という記事で既に書きました。その記事の言葉で言えば、「あなたの目の前の課題をきれいに解ける人は、あなたしかいない」からです。

日々の業務で実行される仮説検証プロセスにおけるデータ分析は、当然その「日々の業務」と密接に関わっています。いま立てている仮説は何で、それを検証するにはどんなデータを見なければいけないか。そのデータはどうやって収集され、どこにどんな形式で蓄積されるのか。それを理解せず単にSQLだけ分かる人を連れてきたからといって、あなたの仕事に役立つような素晴らしいデータ分析が今すぐできるわけはありません。それを誰かにお願いして待っている間は、仮説検証サイクルも止まってしまいます。少し遠回りでも、よほど複雑なデータ集計でなければ自分でSQLを学んでしまった方が速いでしょう。

なお、先ほどSQLが必要でないケースとして、「よくある決まった分析であれば世の中にあるソフトウェアの機能の範囲で簡単に実現できる」と書きました。しかし残念ながら、自ら能動的に仮説検証のためのデータ分析をしようとすると、すぐにその「よくある決まった分析」の範疇を超えてしまいます。その場合は、ソフトウェアの機能で実現できないことが多く、SQLを自分で書く必要が出てきます。もちろん世の中にはSQLを書かなくても汎用的な分析ができるLookerのような素晴らしいBIツールもあります。しかし、そのようなBIツールも多くは裏側でSQLを生成しており、SQLへの理解があった方がずっと使いやすくなります。

「ビッグデータ」とか「AI」などと呪文のように叫んでも、目の前のデータが正しい選択肢を自動で教えてくれるような世界は当分の間こなさそうです。そんな未来を指を加えて待っているよりは、データを自由に扱えるように自らなった方が、仕事も楽しくなるはずです。

残念ながらSQLだけ学べばOKというわけではない

ここまでは「SQLを学べばハッピー」みたいな論調でしたが、残念ながら「SQL"だけ"学べばハッピー」というわけではありません。わざわざ登った山から突き落とすようで恐縮ですが、その理由は主に3つくらいあります。

1つ目の理由は、そもそも必要なデータに対してSQLを実行できる環境が職場になければ、SQL知識は役に立たないということです。欲しいデータが蓄積されずに捨てられていたら、ちゃんとそれを貯めるためのシステムや業務プロセスをつくる必要があります。そもそもデータ分析用のデータベース自体が無ければ、それを構築しなければなりません。データベースはあるけれど、現場のメンバーに参照権限が付与されていないというケースもあります。こうした問題を解くには一定のお金や人的リソースがかかるので、1人で勝手にやるというのも難しいです。あなたにもし課題意識があれば、上司や情報システム部門を巻き込んで、価値あるデータ分析環境を構築するよう働きかける必要があるでしょう。（そのプロセスが遅々として進まなければ、もっとデータドリブンな会社に転職するのも手かもしれませんが。）

2つ目の理由は、SQLの前に仮説検証プロセス自体を上手に回せないと、データを価値に変えられないということです。そもそも仮説思考を持って仕事を進めるようなやり方に慣れていないと、仮説やその検証方法が曖昧なまま場当たり的な行動や分析に終始しがちです。「PDCAサイクルを回しています！」と知った口を聞いていても、実態を見ると仮説の検証方法に関するプランニングが不十分で必要なデータが取れていなかったりするようなことはよくあります。

3つ目の理由は、本格的に価値ある仮説検証をするなら、SQLによる簡単なデータ抽出・集計だけではなく仮説検定に関する統計学の知識が必要になるということです。こうやって偉そうに書いている僕自身も統計学の知識の無さを日々痛感しているので、最近も本を読んで勉強してたりします。もちろんSQLを使った簡単なデータ集計だけでも、何もやらないよりはよっぽど多くの情報が得られます。ちなみにベタですが『統計学が最強の学問である』というシリーズが、ビジネスと統計学の関係をとてもわかりやすく説明していておすすめです。

さて今回は、経験主義や仮説思考と絡めて、データを見ることの仕事における大切さ、SQLの価値と限界について書きました。特に「すでにSQLを実行できる環境がある」とか「SQL書けたら業務の幅が広がりそうだと思ってた」みたいな人は、ぜひ今すぐSQLを学習してみることをおすすめします。SQLを学んだ結果として仕事がちっとも楽しくならなかったとしても、それによって「SQLを学ぶと仕事が楽しくなる」という仮説を棄却することができます。経験主義的に考えれば、どちらに転んでもプラスですね。

もしSQL学習について具体的に何から始めていいかわからんという人は、前述したチュートリアル記事を読んでもらうか、僕までTwitter DMで相談してください。

以上！今回も楽しく仕事をするためのヒントが見つかったでしょうか？

ではまた来週。