Photo by thekirbster
有吉です。昨年入社したpaiza(ギノ) の営業です。
皆さんSQLは好きですか？
私みたいな営業とかエンジニア以外の職種だと「データ取得はエンジニア頼み」って人も多いですよね。
私も以前はエンジニアの人に「営業で使うので、このデータとあのデータもとってください！」っていろいろお願いしちゃっていました。でも、開発業務が忙しいときに依頼が重なったりして、「ちょっとしたことは自分でできるようになって～！」と言われたこともあったりして…（申し訳ない）。
それにSQLが全然わからないと、たとえば「少しだけ対象期間をずらしたデータがすぐにほしい！」というときも、自分でできないから依頼して待たないといけなかったりして…そういうのって結構ストレスじゃないですか？私はストレスでした。
今は、SQLを勉強して少しはできるようになったことで、エンジニアの人の面倒も、自分の面倒も減らすことができたと思います。
今回は営業の私がなぜSQLを勉強したのか、どんな勉強をしたのか、そして勉強して何がわかったのかについて書きます。
■なぜ営業がSQLを学ぼうと思ったのか
◆どんなデータがあるか理解しておかないと、営業戦略が立てづらい
私は昨年まで不動産系の企業で営業をしていたのですが、前職ではデータといえば、とりあえずExcel（たまにAccess）にあるものでした。
だからpaiza（ギノ）に入社しても、最初は「どんなデータがどんな形式で蓄積されているのか」も全然イメージできていませんでした。そもそもデータベース（DB）に触れた経験もなかったので…。
でも、最低限どんなデータがあるかを理解しておかないと、それをもとにした営業戦略は立てられません。
たとえば「最近担当企業の求人への応募が急に減った気がするなぁ」といった肌感があっても、データをとってきて検証しないと、実際にいつからどれぐらい減っているのか？何が原因と考えられるのか？などが分析できませんし、的確な対策もとれません。
すぐに「Webサービスの営業としてこのままではマズいぞい」と思い始めました。
◆エンジニアに依頼が続くと負担をかけてしまう
データ取得の依頼が続くと、当然ですがエンジニアの人の作業時間を奪い、負担をかけてしまいます。
それだけでなく、依頼する側がDBの構造などを理解していないと、最適な依頼もできないんですよね。
以前は
私「こういうデータをくださ～い！」
エンジニア「どんな分析に使うんですか？」
私「（データをもらってから考えようと思ってたなんて言えないぜ…）」
みたいなケースもありました。
あとはせっかくデータをとってもらったのに、思ってたのと違ったせいで結局分析や検証に使えなかった経験もあったりして…。データの取得依頼をするにしても、多少はDBの知識がないとダメだなと感じました。
…というわけで、営業の私もSQLを勉強することにしました。
■SQLを学ぶためにやったこと
◆paizaラーニングの「DB/SQL入門編」
基本は「DB/SQL入門編」を自分で進めていたのですが、今はさらに社内のエンジニアが週1回×1時間ぐらいの補習授業も開催してくれています（ありがたい）。
今も続いているのですが、授業では「こうしたいときはどうしたらいいですか」といった質問の解説や、分析用DBを使った簡単なSQL文の宿題などを出してもらっています。あとは社内でSQLを勉強中の人たちと宿題を進めるもくもく会を、授業とは別に週1回ぐらいやっています。
そんな感じで大体2ヶ月ぐらい勉強を続けてきて、DBの概念やSQLの基本構文は理解できてきた…と、思います。すごく複雑な条件じゃなければ自分でイチからSQL文を書いたり、既に使われているSQL文の条件をちょっと書き替えてほしいデータを取得したり…といった作業はできるようになりました。
勉強を始める前は、既存のSQL文を見ると「何なんだこの必ずSELECTで始まる文は…」「触ったら壊しそうで怖いからなるべく見んとこ」って感じでしたが、今はむしろ誰かが書いてくれたSQL文を見て「オッこれはこういう条件でここからこういうデータをとろうとしているんだな」「ここを変えたらこういうデータがとれるな」と考えるようにしています。
※ちなみに私が触れる分析用DBは本番用DBとは別のもので、そもそも担当エンジニア以外はリードオンリーで追加・削除・更新などができないようになっていますし、個人情報などもマスキング処理されています。
■難しいと感じたこと
SQL文の書き方というより、実務で運用されているテーブル構造を理解するのが難しいです。一見すると同じようなテーブルやカラムがいっぱいあるけど、テーブル構造を理解しないと、どこからどのデータを取り出すかも決められないので…。
以前Rubyでプログラミングを勉強したときは、自分でコードを書いて動くモノを作ることが割と最初からイメージしやすかったのですが、データは構造や何が入っているかを理解して実態をつかむ？のが大変な気がします。
あと、ジョインするときにインナージョインすべきかレフトジョインすべきかでよく迷います…。
SQLの書き方で迷ったら、プログラミングと同様に、自分で書いたり調べたりして試してみて、「こう書くとこういう結果になるんだな」と確認しながら修正しています。わからないときや確認してもらいたいときはエンジニアの人に質問していますが…。あと、宿題や練習でなく実際の業務で使うときは、エンジニアにどのテーブルに何が入っているかを教えてもらったり、SQL文をチェックしてもらったりもしています。
会議中にさーっとSQLを書いてデータを調べたりできるエンジニアの人たちすごいなぁ…。
■SQLを学んでわかったこと
◆データを取る前に分析方針や仮説を立てるのが重要
SQLを勉強する前は、誰かが自動取得しているデータや、分析方針を明確にしないまま取得されたデータを見て、何が読み取れるかを考えたり、営業戦略の参考にしようとしたりしていましたが、あまりうまくいきませんでした。そりゃそうですよね。
データを活かして分析・検証をするなら、とりあえずデータを取ってくるのではなく、まずは何を分析するのか、どんな仮説が考えられるのか、そしてその仮説を検証するためにはどんなデータが必要なのか？を明確にしなければならない！と、勉強を始めてよくわかりました。
たとえば「担当企業への応募を増やしたい！とりあえず応募状況のデータを見よう！（しかし見てもよくわからない）」だったのが、「こういう条件の企業はハイスペックな応募者からの応募が多いのではないか？該当求人の応募者のランクを調べて相関性を検証しよう」などと考えられるようになりました。
◆DB設計やSQLチューニングは重要すぎる仕事、知識があるエンジニアは貴重
DBに触れるようになって、Webサービスって本当に膨大なデータをもとに成り立っているんだなぁ…と身をもってわかりました。paizaで言うと、たとえばユーザーのデータもあるし、求人票や企業のデータもあって、ユーザーが求人応募をすると、それらが紐づいたりするわけで…。
これらの膨大なデータを的確に管理するには、緻密な設計や運営が本当に大事ですよね。テーブルって多すぎても少なすぎてもよくないし、DBについてよくわかっていない人が適当に作ると大変なことになっちゃうんだろうなぁ…。
DBをイチから設計できるエンジニアって本当にすごいし、知見があるエンジニアが企業に欲しがられるのも当然ですね。
◆同じデータでもいろいろな取り出し方があるんだなぁ
SQL文って、とりあえず文法がおかしくなければ何かは取ってきてくれるので、最初は何か取れれば満足していました。でも、細かい条件や結合方法によって取れるデータって全然違いますよね。
何も考えずに書いちゃうと、考慮すべきフラグを見逃していたとか、形式がわかりづらいとか、大量にとりすぎて重いとか、最適ではないSQLになってしまったりする。（エンジニアの人に聞いたら「アンチパターンというものがある」のだそうですね）
プログラミングを勉強したときも、動けばOKじゃなくてより適したコードを書く必要があると感じましたが、SQLも同じで、アンチパターンを避けて適切なSQL文を書き、的確なデータを取得するのが大事なんだとわかりました。
■SQLを学んでできるようになったこと
◆簡単なSQL文なら自分で書ける＆依頼が的確にできるようになった
SQL文を少しは書いたり、既存のSQL文の条件を変えたりできるようになった！というのは当たり前ですが…。どんなデータがどんなふうに蓄積されているのかが理解できたことで、より複雑な条件のデータ取得をエンジニアの人に依頼するときの精度？も上がった気がします。
以前は「とりあえずこのデータとれば何かわかるっしょ」って感じだったのが、今は「直近で人気のある求人票の内容を分析したくてこんな仮説を立てているので、この期間に応募があった求人票に関するこういう情報を取得できますか？」などと言ったりしています。
◆お客様に数字をもとにした提案ができるようになった
勉強を始める前だと、たとえばお客様に「こういう条件の求人票を出して応募が来るのだろうか？」と言われたときに、今までだと肌感で「同じような条件で応募が来ている求人が…あったと思いますけど…」と言うしかありませんでした。
でも今は、データをもとに検証できるとわかっているから、ちゃんと調べてから「メイン言語が〇〇言語の求人票は直近で応募増加しています」「ただ実務経験が△年以上という条件が必須だと満たせるユーザーが激減するため、可能であれば見直した方がよいかもしれません」と、数字をもとにした的確な提案ができていると思います。
◆求人票の条件調整が細かくできるようになってきた
以前はお客様に「DBの知識があるエンジニアがほしい！」と言われても「（DB？エンジニアならみんな使えるんか？）どんな条件にするといいか持ち帰って上司に聞いてみます…」って感じでした。
でも今は、DBの知識や経験の重要性がわかってきたから、その場で「そのポジションの募集だとSQLチューニングの基礎知識は必須ですよね」「DB設計の経験がある人がいいですよね」とか提案できるようになってきました。私自身の知識レベルはまだまだですが…。
■まとめ
というわけで、営業がSQLを勉強してみてわかったこと・できるようになったことを書いてみました。
SQLに関してはやっとスタート地点に立てたレベルですし、もっと勉強して営業戦略のために必要な数値はすべて即座に自分で取得できるぐらいになりたいです。データを自動取得できるスクリプトも自分で組めるようになりたいですね。今はまだ複雑なSQL文を見て「多分こんなデータをこう取ってるんだな～（なんとなくはわかるけど書けない…）」と思っているだけなので…。
最初は「SQL？何それ怖い…」な状態だった自分でも、こんな感じにはなれたので、paizaラーニングの「DB/SQL入門編」を一通りやれば、誰でもスキルアップできるはずです。それこそエンジニアの人だったらすぐにできちゃうと思います。
6月25日（火）～7月2日（月）までの期間限定で、普段は一部有料の「DB/SQL入門編」を全編無料公開しているので、ぜひ見てみてください。
paizaラーニングでは、ほかにもPython、Java、Ruby、C言語、PHP、C#、JavaScript、HTML/CSSなど、人気言語の動画レッスンを公開しています。
詳しくはこちら
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら
