こんにちは、サイバーエージェントのメディア広告部門、
通称MDHで開発局の局長をやっている小越と申します。
我々の部署は「メディアの為の広告テクノロジー」というミッションで
日々配信サーバーやDMPの開発を通じてメディアの広告収益を
上げる事を仕事にしています。
今回は、我々の部署で導入して、とても捗った話を紹介したいと思います。
■何をやったのか？(やっているのか？)
簡単に言うと、(1)ディレクターがSQLを覚えて、(2)データ分析に
必要なデータ抽出はディレクターがやるというルールを導入し、
実際に運用しています。
導入前の課題、導入後の効果、
そしてそれから更に何が起こったかを順番に説明していきます。
■導入前の課題
皆さんの開発組織では、PDCAサイクルはどのように回ってますか？
PDCAとは我々の部署では以下のような行為と定義付ける事ができます。
P:プラン データ分析や戦略策定を通じ、開発するべき機能や改善案を決める
D:ドゥ 開発して、テストして、リリースする！
C:チェック 実際にリリースした機能が狙い通りの効果を上げたのか分析する
A:アクション Cの内容を元にして改善アクションを決めて、Pに戻る
このうち、特にCの部分ではデータ分析が必要になってきます。
元々、我々の部署では立ち上げ以来、「エンジニアが依頼を元にデータを
抽出して」「ビジネスサイドのプロデューサーやディレクターが分析をする」
という役割分担にしていました。
しかしながら！
この役割分担では以下のような問題が起きていました。
問題１:ビジネスサイドの依頼に抜け漏れがある。
エンジニアが苦労してデータを出したのに「やっぱりOS別ももらえます？」
なんて事が起こった
問題2:エンジニアがSQL等の間違いに気づかない。
せっかく出してもらったけど、売上がどう考えてもおかしい。
「10倍近い数字なんでどこか間違いが無いかチェックしてもらえません？」
問題3:依頼は開発の都合に関係なく起こる。
あれを出したらこれを依頼され、そうかと思ったらそれは間違いだったって！
データ抽出してたら開発に集中できない！
そんな課題に対して、2つの事を試みます。
1)依頼シートを作る。どこのログに対して、何を計算してほしいか明示
2)抽出担当エンジニアを置く
このルールで回してたのですが、抽出エンジニアはやっぱりつまらないです。
もっとクリエイティブな事をしたい。
そして、何よりも1の精度が上がれば上がるほど、
「誰がやったっておんなじ結果なんだから、
これわざわざエンジニアがやる必要あるの？」
という当たり前の結論に至りました。
そこで私を筆頭に開発に関わるビジネスサイドは一念発起。
若手エンジニアに勉強会を開いてもらって自分でSQLを書くことにしたのです。
*ちなみに当たり前ですが、ビジネスサイドが書くのは参照系のSQLだけです。
■導入後の効果
SQLの学習には人によって1週間から1ヶ月かかりましたが、
この効果はばつぐんでした。
まずは、何と言っても、PDCAのCの速度が上がりました。
数値が仕事のビジネスサイドがやるので間違いがすぐにわかります。
また、
出してみて「あー、これも必要だった」はすぐにやり直せば良いのです。
続いて、エンジニアは無駄なデータ抽出から開放されました。
いちいち手を止める必要も無くて良い気分。
また、副次的な効果も結構ありました。
ひとつは、DB構成やログに対してビジネスサイドの理解が進んだ事です。
何しろ、無いデータは取り出せません。
この施策、評価するのであればどうするべきで、
それは今のDB構成またはログの構成から可能なのだろうか？
という観点で考える事ができます。
また、これまた面白いのですが、重いデータ抽出が減りました。
SQL初心者の我々は複雑な構文が書けません。また、自分でSQLを書きますので、
ながーーい、時間がかかるデータ抽出がとてもつらいです。
結果として何が起こったのかというと、データ抽出を棚卸しして、
「定常レポートに必要な値」「定常的には無いが、よく参照する値」
「めったに参照しない値」に分けて前者2つについては中間処理を
しておいて、そのテーブルを参照する形に変えました。
これちょっと補足が必要ですね。
例えば、売上のログがあったとします。
そこには、「都道府県」「売れたもの」「売れた日付」「売れた曜日」
「売れた時間」「単価」「割引率」「売上」などが載っています。
この時、曜日別、都道府県別の売上レポートをよく見る、
という話であれば予めその2つをディメンションとして合計した
テーブルを作っておくようなイメージです。
こうすると、わかりやすくて、処理時間の早いSQLだけが書かれる事になりました。
(平気で重い依頼をたくさんしていたのに・・・！)
中間集計に無いデータは当然生ログに当たらなければいけないのですが、
業務の95％くらいは中間集計データで事足りています。
■それから更に何が起こったか
ここまでの事が当たり前になってくると、次にBIツールの導入が進みました。
何しろ、自分達が書いているSQLはいつ何時、誰が書いたって同じ。
そしてパフォーマンスを把握する為にいつも書くのです。
で、あればそれを管理画面にしたいのが人というもの。
また、「定常的には無いが、よく参照する値」もいちいち出し直すのが面倒です。
そこで、「定常レポートを常時表示する為のBIツール」と
「ブレークダウンの為のBIツール」の両方が導入される事になりました。
データの在り処は自分達で分かっていますし、
いつも作っているレポートなので把握したい軸もはっきりしています。
BIツールの導入はとてもスムーズに進みました。
ちなみに、参照と構築が柔軟なツールを運良く見つけたので、
エグゼクティブ向けのレポートもこのツール上で行っています。
「やっぱ管理画面にこれ足して」というレポートあるあるも
簡単に対応可能になりました。
というわけで、以上がディレクター達がSQLを覚えて捗った話でした。
皆さんの参考になりましたら幸いです。
最後に宣伝になりますが我々の部署、MDHでは定期的に勉強会を行っています。
合同勉強会も実施していますので、ご興味のある方は是非ご連絡ください！
Photo Credit:Todd Huffman