クラウドファンディングサービスを運営する、READYFOR株式会社でプロダクトマネージャーをやっています。kecyです。
この記事は「READYFOR Advent Calendar 2022」の14日目の記事としてお送りします。
今回は、自社プロダクトの開発を進めていく上で大きなテーマの一つとなる「優先順位付け」についてREADYFORでの事例を紹介します。
「RICE」とは
RICEは、プロダクト開発の施策それぞれに優先度のスコアをつけるための手法です。
「RICE」の頭文字である、
- Reach: リーチの広さ
- Impact: 事業へのインパクトの大きさ
- Confidence: 成功確度＝期待通りのインパクトが実現する確度
- Effort: 工数の大きさ
の４観点で点数評価して、
という計算式で優先度スコアを導き出します。
RICEからReachを抜いたICEという手法もあり、RICEやICEの詳しい考え方についてはこちらの記事が参考になるでしょう：
さらにその発展形として、Gunosy社ではRICEに「Vote（投票）」を加えて、メンバーの推し度をスコアに加味しているそうで、こちらもたいへん参考になりました：
ただ、RICEを実践しようとするうえで問題になるのが、
- Reach・Impact・Confidence・Effortのそれぞれの点数をどうやってつけるか？
- 点数をなるべくコストを抑えてつけられるようにするにはどうすればいいか？
です。おそらく多くのプロダクトマネージャーがぶつかるポイントでしょう。
この記事で紹介するのは私のチームの中で試行錯誤している、RICEの実践例です（説明の都合上、実際の業務で使っているものを一部改変・省略しています）。
READYFORの話
ここで、その背景としてREADYFORの組織体制や自分の立ち位置について説明させてください。
早く具体的な実践例を見たいという場合は読み飛ばしていただいて構いません。
◇
READYFORでは、Spotifyが採用していることで有名な「スクワッド」という自律した組織単位を全社で取り入れています。
組織の「乳化」を目指す。職種を超えた連携を生み出す「スクワッド組織」運営とは（SELECK）より
プロダクト開発のスクワッドでは、PMがリードとして数名のプロダクトエンジニアやデザイナーと一緒に仕事をするのが一般的です。
スクワッドとしてのミッション・役割に従いながら、「何をどんな優先順位でどのように開発していくか」は基本的にスクワッドのリードとメンバーに委ねられます。
私がリードしているスクワッドでは、クラウドファンディングの「プロジェクト実行者（個人、NPO団体、スポーツチーム、病院、etc）」の方々に向けて、READYFORで継続的に資金集めをしてもらえるようにプロダクト改善・機能開発を行なっています。
プロジェクトをやりたいと思った方が直接READYFORを選んでくれることも多いですが、READYFORの営業部門が資金集めの需要のある団体に対してアプローチして商談化・案件化するケースも多く、クラウドファンディング実施にあたっては専任の担当者が伴走支援することになります。
プロジェクトによって目標金額や達成金額の規模は大きく異なり、大型の案件では数千万〜数億の支援金が動くことになります。
READYFORはそのうち一部を手数料としていただいて会社を運営しています。
こうした背景から、私たちのスクワッドでは自ずとSaaS的な考え方が求められることになります。
すなわち、
- 売上規模の異なる顧客の中でどんなセグメントに向けて開発を行うか？
- 顧客や、顧客と直に対話しているビジネス部門からどのように要望や課題を集めるか？
- ビジネス部門を通じて開発施策をどうやって顧客に届けるか？
- これらを円滑に進行するためにビジネス部門とどのように期待値調整や合意形成をやっていくか？
といった観点を大切にしながらプロダクト開発を行なっていかなければなりません。
優先順位を判断するにあたっては、定量データだけでなく顧客の声をはじめとする定性データを取り入れつつ、社内での納得度のために説明可能性も大事にする必要があり、何らかのフレームワークを取り入れられないかと模索していました。
そこで思い至ったのが「RICE」でした。
RICEを実践するうえでぶち当たる壁
さて、本題に戻りましょう。
- Reach・Impact・Confidence・Effortのそれぞれの点数をどうやってつけるか？
- 点数をなるべくコストを抑えてつけられるようにするにはどうすればいいか？
というプロダクトマネージャーが直面する壁の話です。
自分の場合は、例えば、、
- Reach（リーチの広さ）
- 施策によってリーチできる推定人数が使われることが多い
- しかし、顧客セグメントごとに売上規模が大きく異なり、純粋に人数だけで測るだけではKGI最大化には繋がらない...
- 施策ごとに人数を推定するのはコストが大きい。続けられる未来が見えない🙈
- Impact（事業成果に対するインパクトの大きさ）
- 一口にインパクトと言っても「短期的な成果につながるもの」「長期的な成果につながるもの」「業務効率化に寄与するもの」などいろいろある。それらも踏まえて数字を一つ出すの難しすぎない？
- さらに自分のスクワッドは「顧客に継続してもらうこと」をミッションにしており、インパクトを短期的に評価可能な指標にするのがとても難しい
- Confidence（成功確度）
- 誰がどうやって決める？？ 結局PMのさじ加減次第にならないか？
- 顧客の声が集まっているものを高く評価したいがどうすればいい？
- Effort（工数）
- 開発のコストもあるが、仕様検討・デザイン・社内調整のコストも無視できない！
などなどの気になる点が湧き出てきました。
私たちの実践例
そんな壁を目の前にしながら、何を大事にして設計するかを整理しなおしました。
- スクワッドとして打ち立てている戦略との論理的接続
- VOC（実行者の要望）をはじめとするファクトの重視
- 社内における納得度と透明性の高い合意形成
そして「続けていけそうなこと（コストが高すぎないこと）」を意識しながらも、以下のようなやり方にたどり着きました。
大まかな流れ
- RICEの4項目それぞれをさらにいくつかの変数
x_i - KGI・戦略・ファクトとの繋がりに応じて、変数それぞれに重み（係数）
w_i - 変数と重みの加重平均
\frac{\sum^{n}_{i=1}{w_{i}x_{i}}}{\sum^{n}_{i=1}{w_{i}}}
運用上はGoogleスプレッドシートでスコア計算のためのシートを作成して利用しています。
（プラスをクリックすると折り込まれている列が展開されて、個別の変数を確認できるように作ってあります）
RICE4つそれぞれの点数の付け方について、簡単に説明します。
Reach（リーチの広さ）
READYFORでは、資金を集めたい実行者の方々に4つのプランを提供しています。
- シンプルプラン
- フルサポートプラン
- フルサポートプラスプラン
- 継続寄付
それぞれ異なる手数料体系、顧客セグメント、業務フロー、売上規模を持ちます。
点数を決める際は、これらのプランのどれに当てはまるかチェックをつけます（複数選択可）。
そして、売上規模などに応じてプランごとに係数を設定しておきます。
（また、全体で10点満点になるように係数を設定してあります）
チェックありを1, チェックなしを0にしたうえで係数をかけて加重平均を取ることで、
- 多くのプランに波及する施策ほど点数が高くなる
- 事業にインパクトの出やすいプランに効く施策ほど点数が高くなる
ということになります。
この方法によって、リーチの算定にかかる手間を大きく削減することができました。
それと引き換えに、定量的な正確さがある程度犠牲となりますが、プランごとの売上規模・顧客数などを係数に反映することで、目安としては十分使えるものになっていると思います。
Impact（事業成果に対するインパクトの大きさ）
Impactには、上述の大事な事項のうち「スクワッドとして打ち立てている戦略との論理的接続」が強く反映されています。
変数としては、
- 注力ポイントAにおけるインパクトがどれくらいか
- 注力ポイントBにおけるインパクトがどれくらいか
- 「オペレーション・コスト改善」観点のインパクトがどれくらいか
のようになります。
スクワッドではミッションを果たすための戦略として「注力ポイント」をいくつか設定していて、それらのどれにどれくらい強く繋がっている施策なのかを評価しています。
また、ビジネス部門などからの相談を受けて、
- プロダクト改善による問い合わせ対応コストの削減
- 社内ツールの改善による業務効率向上
といった施策を行うこともあるため、「オペレーション・コスト改善」の観点も変数の一つとしています。
評価にあたっては、
また、選びやすさ・分かりやすさのため、スプレッドシートでは数字を直接選ぶのではなくXS(=1)〜XXL(=13)までの「Tシャツサイズ」を選ぶ形式にしました。
それぞれの変数ごとに係数を設定して、どの観点をどのくらい重視しているかが点数に反映されるようにしています。
客観的・定量的な評価ではなく主観的・定性的な評価にはなってしまいますが、説明可能性・評価コスト抑制を重視してこういった方法を採りました。
Confidence（成功確度）
Confidenceには、
- プロダクトマネージャーの自信度
- 社内で最も顧客に近いステークホルダーの自信度
- 顧客の声（VoC）
- ファクトに基づくインサイト
を変数としていて、スコアに客観的・定量的な評価を反映するための大事なポイントです。
上2つでは、プロダクトマネージャー・社内で最も顧客に近いステークホルダーの二者がそれぞれの自信度（期待されるインパクトが出せるとどのくらい強く信じているか）をつけます。
選択肢は「0%・25%・50%・75%・100%」の5段階で、百分率の数字を10で割ったものを計算に用います（例えば75%なら7.5）。
下2つでは、その施策の根拠となる顧客の声やインサイトを計算に反映しています。詳細は省きますが、根拠として強さのあるファクトが集まれば集まるほど、点数が伸びることになります。
また、ファクトを重視するために、下2つには上2つよりも意図的に重い係数をつけました。
Effort（工数の大きさ）
ラストです！ Effortは比較的単純で、
- 企画・デザイン工数
- 開発工数
の2つを変数としています。
Impactと同様、
こちらは今のところ係数に差はつけていなくて普通の単純平均で点数にしています。
◇
ここまでで点数化したReach・Impact・Confidence・Effortの4つを使って、以下の計算式（再掲）によってスコアを算出することができます。
終わりに
今回紹介したのはまだまだ発展途上の手法で、これからも試行錯誤を重ねることになります。
こうしたロジックを整備しておいて「なぜ他の施策をおいてでもいま施策Aをやるべきなのか」を説明できるようにしておくのは、期待値調整や合意形成のためにも「ビルドトラップ」に陥らないためにも大事なことだと信じています。
皆さんはどのように開発の優先度を決めているでしょうか？ もしこのやり方が何かしらの参考になれば幸いです。
明日の「READYFOR Advent Calendar 2022」では @otaizoさんが記事を投稿する予定です。お楽しみに！！
「みんなの想いを集め、社会を良くするお金の流れをつくる」READYFORのエンジニアブログです。技術情報を中心に様々なテーマで発信していきます。 ( Zenn: zenn.dev/p/readyfor_blog / Hatena: tech.readyfor.jp/ )
Discussion