最新情報をお届けします！
非エンジニアがSQLを叩くことが、当たり前に！？ ピクシブで働く重松裕三さん（27歳）もSQLを叩くディレクターの１人。さまざまなクエリを試行錯誤し、抽出したデータはサービス改善に活用する。ディレクターもSQLが出来たほうがいい？教えて重松さん！
※SQLとは、データベース内のデータを操作／定義するための言語。クエリとは、SQLに沿って書かれた命令文を指します。
フルスタックで活躍するデザイナーやエンジニアが増えている昨今。非エンジニアも領域を広げていく時代に！？
ピクシブで働くディレクター 重松裕三さんは、SQLのクエリを自身でも書くという。しかも、新卒のビジネス職でピクシブに入社をしている。
「もともとエンジニアではなく、ビジネス職として新卒入社しました。PHPの書籍を買って、実際にゼロからサービスを作るなど、独学で勉強して。その中でデータベースを扱うシーンがあり、SQLを使うようになったんですよね」
そして、バリバリ仕事でもSQLをつかうようになったという。
「ピクシブのサービス改善を目的として、その手段にSQLが必要だと捉えるようになりました。さまざまなパターンでクエリを試行錯誤するうち、複雑なクエリも書けるようになったんです」
そんな重松さんは自身でチームも率いている。驚くべきは、ディレクターに限らずCSなどのメンバーも、SQLに対する知識を持ち、クエリが書けるというのだ。
ディレクターをはじめ非エンジニアがSQLを書けると何がいい？
教えて、重松さん！
[プロフィール] ピクシブ ディレクター 重松裕三
2012年に新卒でピクシブへ入社。イラスト投稿SNS「pixiv」のディレクター、広告などを扱うアカウントプランナーを経て、クリエイター向けCtoCマーケットプレイス「BOOTH」、画像1枚でグッズが作成できる「pixivFACTORY」、イベント対面決済「pixiv PAY」の立ち上げに携わる。現在はディレクター兼プロダクトマネージャーとして上記のサービスを担当。
― まずSQLをどんな業務に活かされているのか？具体的に伺ってもよろしいでしょうか？
ユーザー動向を分析するために使っていますね。たとえば、あるサービスにおける売上をあげていこうと考えたとき、まずSQLを使ってデータを抽出します。そこから「総売上の約80％を、購入単価が高い上位20％のユーザーが占めていた」などがわかったとする。じゃあその人たちに向けた施策を打つのが良いよね、アプローチすべきだね、といった話へとつながっていきます。
その他にも、メルマガを作成して送ることもディレクターの仕事のひとつ。誰にどんな内容を送るか、考える根拠にもデータを活かすことができます。
ECサイト上でのユーザーの動向データをみれば、「タイトルAを買った人は、次にタイトルBを買う傾向がある」ということもわかります。すると「過去にタイトルAを買った人には、タイトルBのレコメンドをメルマガで配信する」という施策につながります。
そのメルマガでも効果がでれば、本サイトのレコメンド機能のロジックに組み込むことも検討してもいいかもしれません。
― 具体的に”SQLを叩く”とはどんな作業なのでしょうか？実際にSQLをつかってデータを抽出する、その手順を教えてください。
ツールは「Sequel Pro」というMysql管理ソフトを使っています。よく使うクエリはEvernoteにまとめていて、そこからカスタマイズしてみたり。全く新しいクエリを作ることもあります。出力したデータはスプレッドシートに書き出します。
※画像はイメージです。
（記事公開用に提供いただいたクエリ。実在しない値が含まれています。）
― SQLでデータベース内の情報を扱うわけですが、エンジニアとディレクターでの権限や役割の切り分けはどのようにしていますか？
基本的にディレクターが行なうのはSELECT（読み込み）だけ。SELECTに関してはほとんどエンジニアを介さず自身で行っています。
INSERT(書き込み）やUPDATE(書き換え）はエンジニアの権限が必要になります。エンジニアにお願いしているのは、定期観測すべき数値がでてきて、抽出システムの開発が必要になったとき。それと難しく複雑なクエリの作成が必要なときですね。
― ディレクターである重松さんがSQLを叩くのはナゼなのでしょうか？
圧倒的に早く、必要なときに必要なデータを手に入れることができるからですね。エンジニアにクエリを書いてもらう場合、二者間の都合を合わせることに少なからず工数が発生してしまう。自分でクエリを書けば、その時間ロスはありません。その結果設定したKPIの達成に向けたPDCAサイクルを回すなど、高速に実行することができます。
たとえば「こういう購買行動をしたユーザーにこういうアプローチをかけたら高い効果が得られるのでは？」といった仮説を、自分自身だけの工数でミニマムに試す。そこで成果が出れば、サービスの機能として実装するため、エンジニアに開発を依頼する。だめならやめる。意思決定がしやすくなります。
自分ができることは自分でやるほうが生産性が高い。自分ができるレベルをあげることは組織としての生産性向上にも繋がっていくと考えています。
― SQLを扱うことで、身につくスキルはありますか？
サービスへの理解が段違いに変わってきます。クエリを実際に書くかは別として、「書ける」ことが大事。実際にサービスがどう動いているのかを、プログラムをみてわかるというのは強みです。
多くの場合、SQLとデータベース設計はセットで学びます。そうするとデータベースがどういう構造になっていて、それぞれのテーブルがどんな役割を担っていて、僕らはどういう情報を持っているのかわかるんです。
たとえば、新しい機能として、ある商品の購買をキャンセルするボタンを設置するとします。購買したかどうかの情報を持つ「オーダー」テーブルのなかに「キャンセル」というステータスをもたせるのか。それとも「キャンセル」というテーブルを新たにつくるべきなのか。そんな議論が開発時になされます。
データベース構造を理解していればそのメリット・デメリットがわかる。エンジニアだけの判断ではなく、ディレクターとしてどうするべきなのか、エンジニア以外のメンバーにとってなにが最善なのかを考え、議論することができます。
― SQLを学ぶ上で大事なことはなんですか？
書くときに「こういうデータが欲しい」と頭の中にあることが大事です。
SQLは、基本的な構文とデータベースの構造を理解すれば、だいたい使えるようになります。仮説に基づく“欲しいデータ”が定まっていれば、ロジカルに書いていくだけです。僕の場合、複雑なクエリが必要になったときはエンジニアに書いてもらって、書き方を学んでいました。本で勉強する場合でも、仮説と必要なデータが頭にあった状態で読むと格段に吸収スピードが変わると思います。
クエリを書いて、データベースから情報を自由に引き出し、様々な観点からプロダクトの現状を分析する。そうすることで、つぎの施策に繋がる新しい発見があるはずです。
サービスつくるのって楽しいじゃないですか。設計レベルの話からサービスづくりに加われることは、多くのディレクターにとって魅力的なことだと思います。もちろん楽しいだけじゃなくて、ディレクターとしての仕事がより捗る。「ディレクターだからSQLを知らない」なんて考えはもったいないです。
（おわり）
文 ＝ 大塚康平
4月から新社会人となるみなさんに、仕事にとって大切なこと、役立つ体験談などをお届けします。どんなに活躍している人もはじめはみんな新人。新たなスタートラインに立つ時、壁にぶつかったとき、ぜひこれらの記事を参考にしてみてください！
経営者たちの「現在に至るまでの困難＝ハードシングス」をテーマにした連載特集。HARD THINGS STORY（リーダーたちの迷いと決断）と題し、経営者たちが経験したさまざまな壁、困難、そして試練に迫ります。
Notionナシでは生きられない！そんなNotionを愛する人々、チームのケースをお届け。
