PMの守備範囲を広げる
早いもので2020年も残すところわずか1ヶ月を切りましたね！
今日は僕が所属しているCyberAgentメディア管轄の広告プロダクト横軸組織、通称PTAのアドベントカレンダー2020の11日目ということで自分の番がやって参りました。
普段のブログでは抽象的な事ばかり書いているので、今回はいつもより業務に近い内容で「PMの守備範囲を広げる」というタイトルで書いてみようと思います。
ここでいう守備範囲とは「今までであればエンジニアに依頼していた内容」のことを指し、それらを ”いろんな意味で” PMまでで完結させる範囲を広げるという意味合いです。
なぜそもそも守備範囲を広げようと考えるのかというところから、自分が使えるようになった小技(というほどのものでもないですが適切な表現がわからずw)を少しでも参考になればと思って真面目に書いてみようと思います。
エンジニアに ”極力” データ抽出をさせない
はじめに、3年以上前の記事にはなりますが、僕の以前の上司の記事を紹介します。
エンジニアにデータ抽出はさせない！Excelを脱し、レポート作成時間をゼロにした方法
この時期、僕はまだディレクターやPMではなかったのですが、こうしたカルチャーのおかげか、僕が所属するAJAやAbemaTVのPMメンバーはエンジニアリング経験有無に関わらず、当たり前のようにSQLをかける人が多く、僕も余程のことがない限り(ログやテーブルがかなり複雑か、生ログを扱う必要がある)、自分でクエリを書くようにしています。
記事にもありますが、分析やレポーティングのためのデータ抽出はエンジニアにとって一般的にそこまで楽しい作業ではないと思うのと、開発リソースは限定的でかつ貴重であるため、できるだけそこに時間を使わせないということは非常に大事だと思っています。もちろん一緒に分析した方が良いケースや、開発サイドにしか見えないものもあるためケースバイケースで依頼するしないを意思決定しています。
また、個人的にSQLを書くときに気を付けていることは、こんな事です。
・毎回0から自分で書こうと頑張りすぎない。パクれるものはパクって使いまわせるものは使い回す。(時間短縮、ストレス対策)
・自信がないクエリは必ずエンジニアに確認する(間違ったデータを出すとあらゆる部分に支障が出るし、思慮がなさすぎるクエリだとお金を溶かすリスクあり)
・データ量がやばそうなやつはちゃんとcountから入る。クエリが動くか確認するだけの時はちゃんとlimitをかける
(偉そうに語れるほどのスキルはないですが、)SQLは学習のためのイニシャルコストはそこそこありますが、一度大方覚えてしまえばあとは目的に応じてググったり、他の人のクエリを真似すればなんとかなるので、もしまだチャレンジしていない社内の若手ディレクターがいればトライしてみるのも良いかと思います！
