Redashはじめまして。夏本番、ビールがおいしい季節になりましたね。今回は、5月から取り組んできた「非エンジニア向けSQLの書き方勉強会」を通じて社内に起きた変化について、軽く話をさせてもらえればと思います。いきさつピクスタはここ数年でエンジニアや営業、マーケティング等さまざまな職種のメンバーを迎え入れてきました。去年からピクスタにジョインしたメンバーが社内の約4割を占めるほどです。人員拡大と並行して、様々な施策にも取り組んできました。最近ですと「少しだけ定期的に画像を使いたい」ユーザー向けに新設した少額定額プランのリリースが記憶に新しいのではないでしょうか。このような施策を実施する前の仮説立案や実施後の効果測定、また定例のミーティングで使用するKPI等、データ(数値)とにらめっこする場面は、みなさんの会社でも多いことかと思います。ピクスタでも、営業やディレクターら非エンジニアが自らSQLを叩き、データ抽出を行うこともありますが、私たちエンジニアへデータ抽出を依頼してくることが大半です。昨今多くの施策を実施するようになり、以下の問題が浮かび上がってきました。非エンジニアが行っているデータ抽出業務の負荷が大きいエンジニアが割り込みのデータ抽出案件に追われる非エンジニアが行っているデータ抽出業務の負荷が大きいまず、SQLが書けてデータ抽出ができるメンバーの絶対数が少なかったです。ある部署では、KPI集計のために「秘伝のタレ」的な複雑なSQLを毎週・毎月と定期的に実行し、その結果をスプレッドシートに手動でまとめる作業が発生していることが判明しました。(図はイメージです)エンジニアが割り込みのデータ抽出案件に追われる非エンジニア自身で処理できない内容のデータ抽出は、エンジニアに依頼が飛んできます。依頼のほとんどは割り込みタスクとして対応します。ピーク時には、半年で約150件のデータ抽出依頼が発生していました。1件あたり2時間で処理できると仮定しても、合計すると300時間。約2人月分のエンジニアリソースがデータ抽出のためだけに費やされていました。依頼したデータ抽出が「1回で」済めばよいのですが、エンジニアが抽出したデータを見て「なんか思ってたのと違うんだけど/(^o^)\」と再依頼が飛んでくることもありました。ユーザーに価値ある機能を届けることが役目のエンジニアにとって、この時間は到底看過できるものではありません。効果測定」のサイクルを回すスピードが遅くなることで、ユーザーに届けたい機能を適切なタイミングでリリースできない事態になりかねない...という危機感が社内に広がりました。SQLビギナーズ勉強会の取り組みこの由々しき事態を打破すべく、非エンジニア向けにSQLの書き方をレクチャーする、通称「SQLビギナーズ勉強会」を開催することにしました。単一テーブルに対するデータ抽出・集計ができるようになる2つ以上のテーブルにまたがるデータ抽出ができるようになるレベルまで引き上げ、「自分で」データ抽出を行えるメンバーを増やすことが目的です。実際に勉強会を運営するにあたり、以下のことを意識しました。参加者の心理的なハードルを下げる主催側の負担を特定個人に集中させない参加者の心理的なハードルを下げる勉強会の参加者は、ディレクターだけでなく、営業やユーザーサポート、経理やマーケティングなど多岐にわたります。「SQLはおろかプログラミングやターミナル、開発環境なにそれおいしいの?」という点ではみな同じです。回を重ねても参加者が脱落せず最後まで走り抜けられるよう、工夫を入れました。集計関数JOINという、データ抽出で必須となる3つに厳選しました。勉強会は1コマ60分のなかで、用意した講義資料をもとに、例題や演習問題を参加者に繰り返し解いてもらいました。各回独立したテーマ設定にしているので、途中から参加しても大丈夫なよう冒頭に復習の時間をはさみました。違い」といった理論の説明は、実際のデータ抽出に必要な最低限のみを伝えるにとどめました。参加者の事前予習は不要とし、当日都合が悪く参加できなかった場合でも各自で自習できるよう、資料を社内のGoogleドキュメントに共有しています。勉強会のSQL実行環境として使用しました。アクセスしてSQLを実行できる手軽さはとても良かったです。等Read系のSQLしか実行できないよう設定してあります。万が一、サービスに影響を及ぼしかねないSELECT文が実行されても安心です。主催側の負荷を特定個人に集中させない勉強会を開催にするにあたり、講義資料の準備や、会議室の予約、参加者への告知、当日の進行など、細かい作業が発生します。日々の業務・タスク遂行を第一優先としながら、準備を進めていかないといけません。いえ、私自身が当時携わっていたプロジェクトの山場と重なってしまい、開催直前でリスケすることが何度かありました。主催者都合のリスケが続くと、せっかく高まった参加者のモチベーションも落ちてしまう...ということで、定例の開発者ミーティングで勉強会の存在を周知したり、開発リーダー陣をはじめ周囲のエンジニアに声をかけて勉強会に協力してくれるメンバーを募りました。最終的には、メンバー4人体制で隔週に1回のペースで勉強会を開催できるようになりました。勉強会を開催しつづけていくにつれ、社内で少しずつ変化が現れはじめました。登録されたクエリ一覧(Queries)が大幅に増えました。実行したSQLは組織内で共有・再利用できるので、「あのデータを出したいときは、このSQLを実行すればいい」というナレッジが集積していくところがよいですね。特徴であるクエリの定期実行やダッシュボード機能を使いこなし、今まで温かみのある作業で行っていたKPIの集計・グラフ化を自動化し、業務効率を改善した部署も出てきました。この場を借りて紹介させてください。クリエイター部のリーダーSさんの場合これまで週報に使うデータを、毎週手作業でCSVをDLしてExcelで集計していました。週に2時間くらいかかっていた作業をどうにかできないと考えていたところ、最近Redashというのものが流行っているのに気づき、早速導入してみました。エンジニアさんが使ってるサービスということもあり、正直最初はよくわからなかったです(笑)。5分くらい説明を受けたあとに30分さわってみただけで、だいたいの使い方がわかりました。fotowaチームのプロダクトオーナーSさんの場合SQL勉強会でRedashを知って、早速fotowaに導入してみました。DBに繋げて叩いて、CSVに落として、加工して共有したりしていたのですが、それを全部Redashに入れてグラフ化して、非エンジニアメンバーにもアカウントを発行しました。共有が手軽になるだけでなく、メンバーももっと簡単にプロダクトの数字情報を把握できるようになります!もう最高です!エンジニアに対するデータ抽出の依頼件数が減った自分でデータ抽出を行える非エンジニアが増えたことで、エンジニアへのデータ抽出依頼の件数がピーク時の150件/半年から約60件/半年まで減りました。代わりに、要件に沿って自分たちなりに調べて書き上げたSQLをエンジニアにレビューを依頼してくることが増えてきました。エンジニアがゼロからSQLを書かなくて済むので、この変化はむしろ好都合です。非エンジニアが自分たちでSQLやデータ抽出を教えあう風土が生まれたSQL勉強会の参加者連絡用に作成した社内のチャットルームで、データの抽出方法やSQLの書き方等を参加者同士で教えあう場面が増えました。以前はエンジニアへデータ抽出を丸投げして依頼してくることが多かったことを振り返ると、大きな進歩です。まとめ勉強会の開催を通じてSQLの書けるメンバーが増えたことで、当初の目的である非エンジニア・エンジニア双方の業務負荷を削減できました。自分の知識を他人に説明し教えることで、自分自身の理解を深められたように思います。*ピクスタでは、エンジニアリングの力で社内の業務効率を改善していくことに興味のあるエンジニアを募集しています。1日目まとめおはようございます!ピクスタ開発部です。