プロダクト開発時に施策の優先度を決めるのは簡単ではありません。感覚的に決めてしまい十分な根拠を持てなかったり、他のメンバーが認識している優先順位と異なったり、結果的にその優先順位付けが正しかったのかわからなかったりと、悩みがつきません。
これをどのように解決すべきかを私なりに考えてみました。
問題
- プロダクト開発時にタスクの優先順位を正しく決めることは容易ではない
- 多くのチームは責任者が思いついたタスクの中から良さそうと思ったものに着手している
- タスク優先順位付けという、難度と影響度が高い意思決定について振返り改善するという機会を持たないという損失を多くのチームが被っている
課題の設定
- タスクの優先順位を決めるための有用なスコアリング手法を取り入れる
- 優先順位付けを振返り、精度をあげる運用手法を取り入れる
解決方法の検討
タスクの優先順位を決めるための有用なスコアリング手法を選ぶ
-
こちらの記事にて、12の優先順位付けフレームワークが紹介されている
- Value vs. Complexity
- Benefit vs. Cost (Weighted Scoring)
- Kano
- Buy-a-Feature
- Opportunity Scoring
- Affinity Grouping
- Story Mapping
- Eisenhower Matrix
- ICE Scoring
- Impact Mapping
- MoSCoW Analysis
- RICE Scoring
- この中から優先度を定量化できて、かつ、適切な分解ができるものを選択する
- 考え方の例
- 1 Value vs. Complexity では2要素の分解なので少なすぎる。Valueについて因数分解が必要になる
- 6 Affinity Grouping はスコアリング方法ではない
- 今回設定した課題の解決には以下の2つが向いている
- 9 ICE Scoring
- 施策ごとにImpact、Confidence、Effortの3点を予測、スコアリングして比較する
- 12 RICE Scoring
- 施策ごとにReach、Impact、Confidence、Effortの4点を予測、スコアリングして比較する
- 9 ICE Scoring
- 考え方の例
優先順位付けを振返り、精度をあげられるような運用手法を取り入れる
- 上述の手法を用いてチームまたは責任者がスコアリングして記録する
- なぜそのスコアにしたのかを書いておく
- 施策実施後に効果を検証する
- スコアリング時の予測と検証結果を突き合わせて、スコアリング時の予測へのフィードバックを記録する
- 次のスコアリング時にフィードバックを参考にしてスコアリングする
結論
- 以下の改善サイクルを回すことで、プロダクト開発での優先順位付けの精度を向上し続けることができる
- プロダクト開発でのタスクの優先順位付けは、適切に要因を分解して予測を記録する
- 適切に要因を分解して優先順位を付ける方法として、ICE Scoring、RICE Scoringが有用である
- 施策実施後に計測結果と予測を比較して振り返ることで、結果と乖離した予測を認識する
- 次の施策の効果予測の際に、蓄積した予実評価を活用することで精度をあげる
- プロダクト開発でのタスクの優先順位付けは、適切に要因を分解して予測を記録する