チームの成果を最大化するためにPOが意識していること
この記事は クラウドワークス Advent Calendar 2023 シリーズ 1の24日目の記事です。
こんにちは、「クラウドワークス (以下 crowdworks.jp)」でプロダクトオーナー(PO)を担当している いわお です。
明日のアドベントカレンダー最終日にアツアツのバトンを渡せるように、何かいいこと書かなきゃと息巻いています。空回りしないように気を付けます。
はじめに
crowdworks.jpは、「仕事を依頼したいクライアント」と「働きたいワーカー」を結びつけるプラットフォームです。
私はマッチングドメイン（主に以下画像の赤枠部分）を担うチームのPOで、「お仕事を獲得できるワーカーさんを一人でも多く増やすぞ！」 というミッションで日々業務に取り組んでいます。
チームの成果を最大化するためにPOが意識していること
スクラムガイドによると、POの役割は以下のように定義されています。
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化すること の結果に責任を持つ。
「スクラムチームから⽣み出されるプロダクトの価値」=「チームの成果」と解釈し、POとして意識していることを5つご紹介します。
定量的な事実集めを妥協しない
定性情報だけのPRD(要求仕様書)にしない
シンプルで洗練された指標を掲げる
抽象度が高いことへの意志を持つ
施策はチーム全員で考える
1. 定量的な事実集めを妥協しない
「仮説を検証するのが施策」だとしても、事前の検証を妥協していいわけではありません。
定量的な事実集めを徹底し、仮説の確からしさを事前に検証します。
それにより「最初はAが良いと思ってたけど、Bの方がぜんぜん確からしいな」となることがよくあります。
この定量的な事実集め（仮説の確からしさの検証）は、ひたすらSQLを書きまくることになるので、とても時間がかかりますし大変です。
それでもチームのリソースを使う前にAを消せるのであれば、結果として生産性が上がるでしょう。
「とりあえずAでやってみてから考えよう」というPOの妥協によって、チームのリソースを無駄にしてはいけません。
「やらない判断」をしたうえで生き残った「確からしい仮説」を、最終検証する手段が施策です。
2. 定性情報だけのPRD(要求仕様書)にしない
crowdworks.jpで使用しているPRD(プロダクト要求仕様書)のフォーマットには「背景にある課題・仮説」を書く欄があります。
ここには必ず定量的な事実を書き、仮説の確からしさを示すようにしています。
「hogehogeな課題がありそう」という定性的な解釈しか書かずに 「本当にその施策をやる必要があるのか？」 が精査されずに実行されていては、いくらリソースがあっても足りませんし、いたずらにプロダクトのコード量を増やしてしまいます。
また、施策着手前の定量的な事実集めが甘いと、リリース後にどの指標が改善すれば成功と言えるのか？の解像度が粗く、効果検証の質が上がらない＝施策の精度も上がらないと考えています。
3. シンプルで洗練された指標を掲げる
指標が無数にあっても成否が曖昧になるだけなので、「洗練された」と自称できるほどシンプルなメイン指標を決め、Redashのダッシュボード上にデータを可視化しています。
先述した定量的な事実集めを通して、以下4つのすべてに該当する指標を特定し、これをメイン指標に掲げます。
先行指標すぎず遅行指標すぎない
施策におけるターゲットユーザーのみを対象にしている（例: 会員登録後n日以内かつ、○○な行動をしたユーザー）
施策の効果が直接的に反映される指標
施策の成否を判断できる指標（「この指標が改善した＝成功と言えるのか？」を必ず問う）
そして、施策のリリース後はダッシュボードをモニタリングしながら、チームでネクストアクションを検討していきます。
また、自分たちの仕事がどういう結果をもたらしているのかが可視化されていると、モチベーションも高まりやすくチームの士気が上がる効果もあると考えています。
実際に、チームメンバーから嬉しい声をいただいています。
前回、前々回のスプリントの施策の結果が目に見えて出てきていて、とても面白みがある
指標がちゃんとしていて施策の効果がわかるのとても良き！！
4. 抽象度が高いことへの意志を持つ
具体的なことへの意志（≒こだわり）よりも、抽象度が高いことへの意志（≒ビジョン）を持つようにしています。
たとえばPOで言えば、「この施策をやりたい」「施策をこう進めたい」というのが具体的なことへの意志、「プロダクトのために、チームとして中長期的にここに注力すべき」 というのが抽象度が高いことへの意志です。
POにこれがないと、各施策に一貫性がなく積み上げた先に何があるのかよく分からなくなっていったり、チームドメインとは無関係な施策を何となく担うことになったりと、ボトムアップで自律駆動な「プロダクトチーム」ではなく、トップダウンで受託感あふれる「開発チーム」と化していくと考えています。
またPOだけでなく、メンバー全員に抽象度が高いことへの意志（例: こういうチームにしていきたい、こういう価値を届けていきたい）があるチームほど強いと考えており、まずは自分なりに意志を表明するようにしています。
このとき、一度だけでなく繰り返し伝え、さらにメンバーからのフィードバックを積極的に取り入れることで、個人の意志がチームの意志に変化し、それにより推進力を向上させることを目指しています。
5. 施策はチーム全員で考える
POひとりで施策を考えていても良いモノづくりはできませんし、PO=依頼者のような構図は絶対に避けなければなりません。
POの能力がボトルネックとなり、チームの成果が伸び悩むことを防ぐためです。
そこで私たちのチームでは、企画の初期フェーズ（PRDを作成するよりも前）からデザイナーやエンジニアを巻き込み、一緒に施策の叩き台を考えるプロセスを取り入れています。
ただし、チーム内に第三者の視点があることは大切だと考えており、以下のようなイメージで企画を進めています。
UX関連のテーマならデザイナー×POで施策案を考える→エンジニア陣に壁打ち→（技術的な観点に限らず）フィードバックをもらいブラッシュアップ
バックエンドの技術的な要素が強いテーマならエンジニア×POで施策案を考える
さいごに
いろいろと書いてきましたが、チーム全員が楽しく働けていてこその成果です。
「チームの成果を最大化するためにPOが意識していること」改め、 「チーム全員が楽しく働けるためにPOが意識していること」 のご紹介でした。
本題とは逸れますが、チームのスクラム改善も絶え間なく続いており、10年を超える歴史あるプロダクトでも、スプリント内でデザイン→設計→実装→スプリントレビュー→リリースまで一気通貫できるリズムを作れてきています。
教科書的にはスプリントごとにインクリメント（動く成果物）を作ることが当然とされますが、容易なことではありません。
スクラムイベントは一通りやっているけど、インクリメントは2~3スプリントで1つ、というチームも多いのではないでしょうか。
よろしければ私たちのチームのスクラムマスターの記事もぜひご覧ください。
We're hiring!
クラウドワークスでは、各種サービスや各種ポジションでエンジニアを募集しています。 ご興味のある方は以下のリンクからご応募ください！
https://crowdworks.co.jp/careers/
♡(いいね)を押していただけたら大喜びします！（非会員でも押せます）
この記事が気に入ったらサポートをしてみませんか？