私のSV宣言バトン～プロダクトマネージャー編 #06
GMOインターネットグループが大切にしている『GMOイズム』にある『スピリットベンチャー宣言』には、私たちの夢や社会に果たす役割などのミッション、それを成し遂げるための事業戦略が示されています。
私のSV（スピリットベンチャー）宣言バトンでは、パートナーにとって特に思い入れのあるスピリットベンチャー宣言の一節とエピソードを聞いていきたいと思います！
第6回目は、GMOアドマーケティング アドプラットフォーム部の平木さんにインタビューしました。
【プロフィール】
平木 将司（ひらき まさし）
GMOアドマーケティング株式会社 アドプラットホーム部
2017年4月、GMOアドマーケティングに新卒入社。
自社開発の広告配信プラットフォーム「AkaNe」「ReeMo」のプロダクトマネージャーとして、プロダクトの販売戦略策定、販促支援や開発要件定義、お客様の技術的課題のフォローに取り組む。
ー 思い入れのあるスピリットベンチャー宣言を3つ教えてください
優先順位・優先順位・優先順位。「売上向上・経費節約」、「緊急度・重要度」、2つのマトリックスで考えよう。
コストの見直しは、一枚一枚の原始伝票から。精算表や集計数字に頼るな。
自らの間違いや失敗に気づいた時は、素直に謝ろう。
ー 3つのSV宣言を選んだ理由をそれぞれ教えてください
優先順位・優先順位・優先順位。「売上向上・経費節約」、「緊急度・重要度」、2つのマトリックスで考えよう。
新卒入社で配属された部署が、AkaNeのディレクターチームでした。新卒採用のポジションにはなかったのですがディレクターポジションでの配属になり、案件の進行をメインで担当していました。世の中の人がイメージするプロダクトマネージャーという仕事をするようになったのは、ReeMoの開発に携わるようになってからだと思います。
ReeMoのプロダクトの開発を見始めてからは優先度の決定だけでなく、プロダクトの方向性をゼロから作っていくことが多く、さまざまなタスクの優先度や売上を鑑み、緊急性が高いものを取捨選択するようになりました。
これはプロダクトマネージャーとしてプロダクトチームやセールスの部署、そして社外のステークホルダーと仕事をするうえで最も重要なことだと考えています。プロダクトマネージャーとしての「やりたいこと」がありながらも、ポジション上、他部署や社外のステークホルダーからの依頼も多数舞い込んできます。 そんな中で事業の優先度や開発の優先度に関わらず「今何を優先すべきで、これによりどんな影響が期待できるか」「このタスク/開発の優先度を下げるとどの程度機会損失があるのか/困る人が出てくるのか」を判断しつつ業務にあたることを心がけてます。
そして「やらないことを決める」ことも限られたリソースに責任を持つプロダクトマネージャーとして重要な選択だと考えています。必ずしも毎回ベストな選択を取れているわけではないですが、なぜこれを優先したのかという答えは常に自分の中に持ち続け、失敗した際に振り返り反省できるようにしています。
コストの見直しは、一枚一枚の原始伝票から。精算表や集計数字に頼るな。
私はプロダクトマネージャーとして「生ログから効率的に売上変動要因を把握できる状態にあること」が重要だと感じています。原始伝票は毎日確認しています。数字の要因把握は方針を決めるだけでなく、上司へ報告する上でも求められているポイントだと思っています。管理画面上の集計数字だけだと、要因がわからないことが多々あります。例えば、ReeMoの売上が下がっているときに、CPMが下がっているのか、外部のニュース要因で普段と違うユーザーが流入しているからなのか等の複数の要因が合わさって、レポートに結果として出ていると思っています。Google BigQuery（※）のログを見ながら、数字の変動要因の分析、取りえるアクションは何なのかを原始伝票から考えています。
（※）Google BigQuery・・・Google BigQueryとは、Googleのクラウドサービス「Google Cloud」の一つとして提供されるプロダクト。BigQueryを活用すると、ビッグデータを超高速で解析することが可能。
プロダクトの売上/粗利に異常値が出ている際に、ここがなぜ悪いか？を把握するうえで自社プロダクトの原始伝票である、広告配信ログときちんと向き合う姿勢、そしてスキルを持つことが適切なアクションを迅速に行うためには欠かせません。
実際に過去「オークションでの仕入れ金額がかさみ粗利が大きく下がってしまった」「広告のCVR(コンバージョン率)が低下した」などの問題が発生した際に、レポート数値という集計数字のみに頼ったことで適切なアクションを取るのが遅れたという経験もあり、自戒の念をこめて選びました。
自らの間違いや失敗に気づいた時は、素直に謝ろう。
これは自身が数多く間違いや失敗を繰り返してきたからに他なりません（笑） 。自分自身の失敗と、プロダクトとしての失敗もあります。
エンジニアチームとはKPT（※）というフレームワークを用いて振り返りをおこなっています。例えば配信障害などの問題が起こったときに、起こった要因やレビューはどのように対応したら気づけたのか、どういうリリース手順を今後ふめば再発しないのかを、Problem（改善すべき問題点）を認識したうえで、何をKeep（継続）し、Try（挑戦）するかを洗い出しています。
（※）KPT・・・現在の業務を振り返り、ブラッシュアップするためのフレームワーク。「Keep（できたこと、継続すること）」「Problem(改善するべき問題点）」「Try（挑戦したいこと）」の3つの要素を洗い出し、仕事やプロジェクトの改善につながる具体的な施策・アクションを導き出す。
その中で、謝れない環境を作ってしまうと、ミスを隠してしまったり、KPTが成り立たない状態になってしまいます。そうするとミスがプロダクトに活きて来なくなってしまう。ミスをしたときに、チームのメンバー全員が素直にここが悪かったですと表明できるように自分がまず意識して、KPTのフレームワークができる状態にしています。
仕事の中で、方針を決めたり優先順位を決めたりする意思決定の機会は多いですが、それを100％完璧におこなうことは難しいです。今までも方針決定や、細かな要件設定が不十分だったことで、複数部署の方にご迷惑をかけてしまったことがあります。その際に「申し訳ない」と謝ることはもちろん、可能な限りKPT（Keep・Problem・Try）というフレームワークを用いてなぜその失敗に至ったのかを自省するようにしています。またチームメンバーにも共有したい場合はドキュメントに残すこともあります。自分に限らず誰しも失敗はあると思うので、これを受け入れチームで再発防止していく、そのためにまず自分が「申し訳ない！」と素直に謝る姿勢でミスを受け入れることが重要だと考えています。
今回は、プロダクトマネージャーの平木さんにインタビューしました。
次回もお楽しみに！
GMOインターネットグループが日々実践するスピリットベンチャー宣言の全文はこちらのnoteで紹介しております。ぜひご覧ください。
Text & Directed by. Ami Ogata