受託開発でRICE分析を導入してみた

先日、担当クライアントとのタスク優先順位づけに「RICE分析」を導入しました。
自分で導入するのは初めてでしたが、結果よかったので共有します！

RICE分析とは

IntercomのSean McBrid氏が提唱した「優先順位付けのためのシンプルなフレームワーク」です。
プロジェクトアイデアを以下の4つの要素で評価します。

• R: リーチ数
• I: 影響度
• C: 確度
• E: 労力

詳細は参考記事をご参照ください。

• RICE: Simple prioritization for product managers（上記画像の引用元）
• RICE: プロダクトマネージャーのためのシンプルな優先順位付け方法（日本語抄訳）

なぜ導入しようと思ったか

こちらのクライアントはいつもプロダクトやお客様のことを考えてらっしゃるので、実現したいことが次から次へと出てきます。
また弊社も前任の開発会社から引き継いだシステムを拝見し、ぜひ取り組んでみたい改善案が多く、バックログは日々積み上がっていくばかりでした。

このまま新しいものや声の大きいものを優先していてはプロダクトマネジメントとして良くないと課題を感じ、
ビジネスインパクトの強いものから順に取り組めるように導入することにしました。

導入フロー

1. RICE分析導入の意図説明および合意
2. 項目のたたき作成
3. 項目フィードバックおよび更新
4. クライアントによる採点入力
   1. 「労力」のみ弊社が採点
5. 合計点の高い順に並べたうえで調整し確定

最終的なアウトプットはこちらです（※イメージ）

↑今回はまずやってみようと気軽に導入したので、この内容が必ずしもベストだと言いきれるものではありません。ご了承くださいm(_ _)m

工夫したポイント

• 非エンジニアであるクライアント含め、チーム全体が理解できるように平易な言葉で項目作成した
• 採点工数を下げる工夫をした
  • 「RICE分析はあくまで指針程度にしてあとは柔軟にやりましょう」と合意をとった
  • READYFOR社の取り組みを参考に、各項目を分解しさらに選択肢をこちらで用意した
• グノシー社の取り組みを参考に、オプショナルで「推し度」を導入した
  • 前述のとおりクライアントは「やりたい！」が強いので志向に合わせて採用
    • たとえばスコアの差異が少ないときの決め手になるように
    • ただし他項目とくらべて重みを少なくした
• 採点時は合計スコアを隠すことで感情に引っ張られないようにした

振り返り

• よかった点
  • バックログ優先順位がロジカルに決まり、チーム全体の納得感が生まれた
  • クライアントがそのタスクをどのように捉えているかを把握できた
    • たとえば「ぜひやりたいです！」とのお言葉からかなり優先度が高いかと受け取っていたものが、採点ではいずれの項目もポイントが低く、実はそこまで重要視していないことに気づいた
• 改善点
  • 開発側からの起票が大量で事前整理することができなかったため、適切に採点できなかった
    • → バックログ起票時から適切にタスク分解すべきだった
  • 事前に定めたコンバージョン項目だとうまく採点できていないと感じるタスクもあった
    • →より適切な項目があったかもしれない、追い追い調整予定

以上です。

特に受託開発だと、クライアントのご要望のままに着手してしまうこともあるのではないかと思いますが、
RICE分析を導入することでタスクの優先順位づけができるだけでなく、
副次効果として、クライアントとの認識合わせにも有効なことがよい気づきでした。
よろしければご参考に、ぜひ活用してみてください！

おまけ

上記の内容を社内PM勉強会で共有したときにいただいたフィードバックです。
プロダクトごとにフェーズや方針が異なるため、状況に応じて柔軟に活用できるとなお良さそうですね☺️

• 影響度の項目や計算方法はかなり重要、よりよくできそう
• 工数だけでなくて費用の観点でも優先順位づけできそう→QCDSとの使い分けを考えたい
• リーチが多いけどインパクトが少ないケースのスコアは必要あるのか？→ICE分析というのもあるみたい
• 採点ルールをきちんと決めないと結局「全部優先度高い」となってしまうこともありそう
• 推し度はスコア計算に含めないほうがよいかも、あくまで最後の判断材料として切り分けるのはどうか
• OKRやKPIごとにRICE分析をすると指標が明確で採点しやすそう