RICEスコアリングをつかって優先順位をチームで決められるようにする
みなさんは1つの目標に向かってたくさんの施策がアイデアとして出たとき、どうやって優先順位を決定しますか？僕が所属する『note』の『ごほうびチーム』が実践した例をご紹介します。
ごほうびチームって？
クリエイターが創作をつづけるための「ごほうび」を適切に増やし、配分することを目指すチームです。投稿した記事にスキがついたり、SNSでシェアしたらバッジがもらえたり、編集部にピックアップされたり。それらをひっくるめて「ごほうび」と呼んでいます。メンバーは、エンジニア3名、デザイナー1名、、プロダクトマネージャー1名（僕）の計5名です。
優先順位をこれまでどう決めていたか
プロダクトマネージャーである僕の勘でした。
もう少し正確に言うと、僕の判断として、たくさんのアイデアの中から「これは効きそう」っていうもの、かつつくるのが大変ではないもの、をどんどんとテストしリリースしていました。これは良いところもあれば悪いところもあります。
良いところ
決まるのが早い
プロダクトマネージャーの勘が良ければその分良くなる
悪いところ
プロダクトマネージャーがボトルネックになる
学びが1人にしかたまらない
プロダクトマネージャーの勘が悪ければ全然目標を達成できない
僕が関わったことのあるプロダクトでは、プロダクトマネージャーが1人で優先順位を決めることもあれば、プロダクトマネージャー＆リードデザイナー＆事業責任者の合議で決めるパターンもありました。いずれにせよ少ない人数でパパッと決められるのが良いところです。
プロダクトマネジメントの優先順位付けフレームワークの究極ガイド
プロダクトマネージャーの勘からチームの勘へ
僕がAppチームとの兼務や、他にも複数のプロジェクトを担当していたこともあり、完全にパツっていました。いわゆるボトルネックになっていました。僕が決めないと進まないのに決めるリソースが無いのです。そこで、プロダクトマネージャーが優先順位を独占的に決定するのではなく、その方法を民主化してチームで決定できるようにトライした、というのが今回のお話です。
余談
プロダクト開発は簡単に言うと以下の流れです。3以外はすでに特定の人だけがやるのではなく、チームで取り組めているという元から自律的なチームでした。手前味噌ですが普通にすごい。
目標を決める
アイデアを出す
やるべきことと順番を決める
検証や実装をする
効果を分析する
次のアイデアを出す
どうやってやるか？
僕の頭の中を分解してゼロから構築してもいいのですが、別に大したものではないですし、車輪の再発明になるので「プロダクト 優先順位 決め方」とかでググります。すると下記が出ました。
37個もフレームワークがあります。ここでつらくなりますが自分でゼロからつくるよりマシなのでなんとか探します。満たしたいことは以下です。
同じような粒度の施策が複数あって明確に優先順位をつけられる
四象限でわけるくらいじゃダメ
早く着手したいので決めることにたくさんの時間を割きたくない
狩野法のアンケートなんかは時間かかるのでダメ
チームで共通の理解をしたいので構成がシンプルであってほしい
加重スコアリングとか構成が過剰なのでダメ
界隈の巨人に採用されてたり情報がネットに落ちてるやつがいい
マーケやコンサル会社が商品として作っただけのものはダメ
そこで最も適切だったのがRICEスコアリングです。
次点はICEスコアリングです。noteの複数の開発チームで実際に採用されています。また、業界的にもよく採用がされている印象です。ICEの紹介でnoteを素材にしてくださっている神もいらっしゃいます。
かなり近いのですがなぜICEではなくRICEにしたかというと、
RICEの方が各項目の選択肢が少なくシンプル
ICEだったら10段階だけどRICEは3~5段階でいい。
7と8の区別ができる気がしない
Impactの勘を最もチームに身につけてほしい
僕がImpactを見積もるときは真っ先に対象ユーザー数を出す
経験則としてReachがかなり大事
ReachがImpactの外にメイン変数として出されてるのナイスすぎ
Reachがめっちゃ細かい数字になるので同じ順位のアイテムが生まれない
つくってみた
miroでつくってみました。miroにテンプレがあったのでノリで使いましたがとても後悔しました。なぜならスプレッドシートのように自動で計算やソートができないからです。良い子はスプレッドシートでやりましょう。
Featureをリストアップできたら（これもチームでやっています）、チームみんなで集まってBIツールをゴニョゴニョしてReachを出します。複雑なクエリになりそうなものは社内のデータチームに相談しました。
Impactは3, 2, 1, 0.5, 0.25の5段階です。1はこれかな〜っていう基準をつくってから相対的にどうだろうって決めていきました。0.25のやつが画像にありませんがそもそもそのレベルのFeatureは壇上に登ってきませんでした。
Confidenceは100％, 80%, 50%の3つです。仕様がもう確定してるやつは100％になりますが、これも相対的に決められればOKです。
Effortは普段スクラムでプランニングしているときのサイズの基準をそのまま使っています。20とか15のやつは「ようわからんけどゴツイ」くらいの感じですね。これも相対的になっていれば問題なし。
項目が全部埋まると自動的にスコアは計算できるので、やるべき優先順位が定まります。もちろんスプレッドシート、ならね。
これからの課題
これでプロダクトマネージャーの優先順位決定待ちではなく、チームで取り組めるようになりました。どんどんとプロダクトマネージャーしか"やれなさそうな"お仕事が無くなっていって嬉しいです。やればできるもんですね。というかフレームワークが37個もあるくらいだから各社当たり前にやってるのでしょう。こうやって仕事を仕組み化・一般化していくと、その仕事に参加できる人が増えます。プロダクトの質につながる多様性を発揮する場面が増えるということです。そういった意味で、プロダクトのスケールだけでなく質も上げることのできる行動ができたのかもしれません。
次の課題(宿題?)としては2つあります。1つは成果がRICEスコアリングの予想通りだったかということの確認。5個くらい施策をやったあとに結果をふりかえる必要があります。そのとき何が合っていて何が間違っていたかを分析しなければなりません。Impactの見積もりが大きすぎたのか、Effortが想定よりオーバーしていたのかなど。そこまででやっとRICEスコアリング自体の学習が回せます。
もう1つはプロダクトマネージャーのリソースを確保できたはずなのでそのぶんがんばらないと、ということです。プロダクトマネージャーがより大きなユーザー課題の発見やプロダクト戦略の作成、プロダクトの健康な運営のための組織設計など、レイヤーや範囲を一段階上げてもいいでしょう。既存プロジェクトの推進力を高めるのももちろんいいでしょう。とにかくやっていきましょう。
一緒にやっていけるかたも激募集しております。よろしくおねがいします！
サポートいただいたらお菓子か本を買います！