プロダクトゴールを導入し、KPIをV字回復させた話
こんにちは、PO/PdMのいわおです。(担当プロダクト:クラウドワークス)
今回は、スクラムチームにプロダクトゴールを導入するまでの軌跡と、KPIをV字回復させた話について執筆します。
プロダクトゴールは、スクラムの"核"とも言える存在ですが、恥ずかしながら今年までプロダクトゴールを運用できていませんでした。
「プロダクトゴールってなに?」「プロダクトゴールを導入したいけど、具体的なイメージが湧かない」というプロダクトオーナーやスクラム関係者の参考になれば幸いです。
はじめに
早いもので、去年のアドベントカレンダーを執筆してから1年が経ちました。
去年から引き続き、マッチングドメインを担うチームのPO(プロダクトオーナー)を務めています。
マッチングドメインというと広いですが、具体的には仕事検索領域に注力しており、この1年は検索結果の表示順位を決めるスコアリングロジックの改善に取り組んでいました。
プロダクトゴールとは
プロダクトゴールについて、スクラムガイドでは以下のように定義されています。
また、プロダクトオーナー(以下、PO)は、効果的なプロダクトバックログ管理に責任を持っているため、「プロダクトゴールを策定し、明示的に伝える」ことはプロダクトオーナーの役目です。
スプリントプランニングやリファインメントでは、POは参加者に対して、取り扱いたいプロダクトバックログアイテム(以下、PBI)とプロダクトゴールとの関係性をチームに示します。
つまり、PBIはプロダクトゴールを達成するために存在しており、POにはこれらを明示的に伝え、管理する責任があるということになります。
プロダクトゴールはスクラムの核
スクラムは「透明性」「検査」「適応」の三本柱で成り立っており、ここで言う「透明性」とは、「プロダクトゴール」「スプリントゴール」「完成の定義」が定義され、チームで共通認識を持てている状態のことであると私は理解しています。
これらの定義がない状態で作った成果物は、透明性が低い成果物であり、定義がないので検査が困難です。正しい検査がなければ、正しい適応も生まれません。
また、スプリントゴールや完成の定義は、プロダクトゴールによって決まります。
つまり、各スクラムイベントにおける検査・適応の軸にあるのはプロダクトゴールであり、「プロダクトゴールはスクラムの核」と言っても過言ではありません。
スクラムガイドでも、以下の通り言及されています。
プロダクトゴール導入にあたっての疑問
プロダクトゴールの概念や重要性について、頭では理解していても、スクラムガイドを熟読するだけでは以下のような疑問が残っていました。
プロダクトゴールが「プロダクトの将来の状態」を表すなら、プロダクトゴールとプロダクトビジョンの違いは?
プロダクトビジョンを達成した先がプロダクトゴール?そのスケールの話だとしたら、いちPOが策定するものではないのでは?
スクラムガイドではプロダクトゴールを「長期的な目標」と言っているが、具体的にどれくらいの期間で追う目標にすべきか?
そもそもプロダクトゴールってどういうフォーマット?KPI目標とどう違うの?
「プロダクトゴールはプロダクトビジョンへのマイルストーン」
プロダクト開発関連の本を読み返したり、有識者のブログを調べたりした中で、自分の疑問をすっきり解消してくれたのが以下のスライドです。
以下の一文で、自分の疑問が一気に解消へ向かっていきました。
プロダクトビジョンが100歩先の姿だとしたら、そこへ向かうために1歩ずつ達成すべき目標をプロダクトゴールとして定めていくということです。
プロダクトゴール導入までの軌跡
チームで認識合わせ
もともと、私たちのチームではスクラムガイド輪読会を週次で実施していたため、スクラムに関する前提理解は高い水準で揃っていました。
スクラムガイドを補足するような形で先述のスライドを読み合わせながら、「実際に我々の環境・状況でプロダクトゴールを導入するとしたら」というテーマで認識合わせを行いました。
プロダクトゴールはPOが策定すべきものではありますが、唐突に「プロダクトゴールはこれです!」と示すよりも、認識合わせやアイデア発散の時間を設けた上で、POが収束させていくプロセスの方が、納得感のある内容に仕上がると考えています。(日々のプロダクト施策の企画においても同様ですね)
アイデア発散
プロダクトビジョン寄りの長期的な視点と、現在の取り組みに寄った短期的な視点で、それぞれプロダクトゴール案を発散していきました。
アクティブワーカー数を全人類の〇%にする
仕事の流通目標2兆円のうち、〇%を仕事検索経由のマッチングで創出する
など、ワクワクする案が出てきました。
運用イメージが固まる
アイデア発散の場での会話を通じて、「KPI関連のテーマと、ユーザー満足度関連のテーマを交互に追うようなプロダクトゴール運用にすれば、どちらかに偏重せず、どちらも向上していけるのでは」ということに気付きました。
プロダクトゴールを運用する前は、業績観点のKPI目標を掲げ、それを達成するために日々の施策を実行する形でした。
私たちのチームの立ち位置的に、「業績観点のKPIを伸ばす」ということが第一の目標になりがちでした。
プロダクトチームがKPI目標を追うことについて、賛否両論あるかもしれませんが、私個人としては肯定的です。その一方で、ユーザー満足度を高めていくことにフォーカスした施策もやりたい気持ちはあります。
この課題は、プロダクトゴールの運用次第で解決できるのではないかという仮説に辿り着きました。具体的には以下の通りです。
プロダクトゴールは、「3か月」で達成を目指せるラインにする
KPI関連のプロダクトゴールと、ユーザー満足度関連のプロダクトゴールを「交互」に掲げる
※原則通り、プロダクトゴールは一度に一つ
3か月で達成できる粒度にすることで、半期で2つのプロダクトゴールを追うことができ、集中してKPIを伸ばす期間と、ユーザー満足度を上げる期間とで、メリハリをつけて両立していけるイメージが湧いています。
「ユーザー満足度向上系の施策だけを半年やります」というよりは、「KPIは3か月でしっかり伸ばすので、残りの3か月はユーザー満足度を高めます」という方が、組織内でも合意形成しやすいのではないでしょうか。
プロダクトゴールの策定
運用イメージが固まり、チーム内で認識も揃ったところで、ここからはPOが具体的なプロダクトゴールを策定していきます。
先人の知恵を借りながら、少しだけアレンジしたフォーマットにしました。
「解決すべき課題」と「目指す姿(課題を解決することで、誰をどんな状態にするのか)」、そして「それを評価する指標(課題が解決され、目指す姿に近づいていることを示す指標はどれか)」を特定することに、多くの時間と労力を投入します。
※クラウドワークスでは、POが当たり前にSQLを書きます
観察→仮説立案→事実集めを繰り返し、「向かう先として正しい」と自信を持って言えるようなプロダクトゴールへ収束させていきます。
各所と合意形成
プロダクトゴールを策定できたところで、関係者と合意形成(この内容でGoして問題ないか)を行います。
接点の整備
合意形成が完了し、せっかくプロダクトゴールが決まっても、日々のスクラムイベントの中で接点がなければ形骸化してしまいます。
Miroでプロダクトゴールを可視化した上で、リファインメントのアジェンダに以下を追加しました。
プロダクトゴールの達成進捗の確認
次のスプリントで取り扱いたいPBIとプロダクトゴールの関連性を確認
以上のプロセスを経て、晴れてプロダクトゴールの運用が開始されました。
プロダクトゴール導入の成果
プロダクトゴールを導入して3か月が経過し、間もなく最初に定めたプロダクトゴールを評価するタイミングになります。
プロダクトゴールに定めた指標について、この3か月で綺麗なV字回復を遂げました。
執筆時点ではまだ数字が締まっていませんが、超ストレッチに掲げた数値目標に対して、間もなく達成というところまで来ています。やれることはやったので、締め日までに達成ラインまで伸びることを祈ります。
このV字回復の背景にある、プロダクトゴール導入による成果の定性面については、チームのエンジニアがアドベントカレンダーで完璧にまとめていただいているので、そっくりそのまま引用します。
さいごに
以上、「プロダクトゴールを導入し、KPIをV字回復させた話」でした。
次の3か月では、ユーザー満足度の向上をターゲットとしたプロダクトゴールを設定していきます。
さいごに、プロダクトゴールを運用して感じたことを簡単に列挙して締めたいと思います。
先人は偉大。原則を学び、理解し、体現する。不十分な理解で我流をトッピングするとアンチパターンを踏む。
チームの成果を最大化するための手段として、プロダクト施策に固執しない。
プロダクトゴール達成の障壁がチーム外にあるなら、関係部署を巻き込んで解決に向けて推進する。
♡(いいね)を押していただけたら大喜びします!(非会員でも押せます)