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