プロダクトマネジメントの業務において、プロダクトロードマップを決める優先順位付け（プライオリタイゼーション）は重要かつ難しい業務のひとつです。実際に、VCでパートナーとして携わる私もSaaSスタートアップからよく相談を受けます。
優先順位付けは、限られたリソースで事業価値（≒企業価値）の創出を左右するため、急成長できるか否かを占うと言っても、過言ではありません。
しかし、日本のSaaSスタートアップの場合、顧客からの要望に基づいて何となく決めていたり、創業者のドメイン知識を背景に仮説を信頼してプロダクトを作り始めたりするケースも少なくありません。そうなると、一貫性も透明性に乏しく、組織がまとまらないばかりか、事業インパクトのない開発にリソースを投下したり、PMFに必要以上の時間とコストを浪費したりして苦しむリスクが上がります。
一方で、優先順位付けにフレームワークを利用しようとしても、世に100以上もあるため、頭を悩ませたことがある方もいらっしゃるのではないでしょうか。
そこで、この記事ではプロダクトマネジメント初心者の方向けに、ALL STAR SAAS FUNDが厳選した、「明日から使える基本の優先順位付けフレームワーク」と、その長所と短所、利用上の注意点について解説します。
（執筆：湊雅之＋宮田善孝）
SaaS PdMにオススメ、「優先順位付けフレームワーク」5選
プロダクトマネジメントの優先順位付けフレームワークには大きく分けて、設定する人の主観的な情報に基づく「定性アプローチ」と、数値に基づいてシステマティックに評価する「定量アプローチ」があります。
定性アプローチは、より顧客価値や事業のゴールのようなトップダウン思考の良さが生きる一方、あいまいで主観的な判断が入りやすいのが欠点です。
定量アプローチは、数値で評価するため判断基準の透明性が高い一方、機械的な判断でステークホルダーの意思統一が図れなかったり、機能のデリバリー重視に陥りやすかったりするのが欠点です。状況によって使い分けたり、組み合わせたりするのを意識することが大事だと考えます。
では、それぞれのアプローチについて、早速見ていきましょう！
定性アプローチ 2選
1. ユーザーストーリー・マッピング
ユーザーストーリー・マッピングは、2005年にジェフ・パットンが発表した「プロダクトの全体像をユーザー体験視点で整理する方法」です。日本語訳の著書もあるので、お馴染みの方も多いかもしれません。
宮田善孝さんの著書『ALL for SaaS』にも詳細に記載されていますが、ユーザーストーリーマッピングの基本的な流れは以下の通りです。
1. プロダクトビジョンの概要の書き出し
3つの必要な構成要素を洗い出す。
- What: プロダクト名と解決する課題
- Who: プロダクトのユーザー
- Why: ユーザーベネフィット（例. 売上アップ、コスト削減）
2. ユーザーストーリーの洗い出し
ユーザーがプロダクトをどう使うかを「●●したい。△△だから」という文章で、ストーリーとして付箋などに書き出す。
3. マッピング
横軸に業務フロー、縦軸にユーザー視点の重要度でビッグ・ピクチャーを作る。重要度は、ユーザーにとって基本的な業務ほど高く、応用的な業務ほど低いという評価にする。
4. 業務フローのカテゴライズ
書き出したユーザーストーリーを業務フロー（横軸）に沿って並べ、工程（ステップ）を洗い出す。工程ごとに足りないユーザーストーリーがないかをチェックし、不足していれば足す。
5. 重要度で優先順位付け
各組織で定めた重要度で優先順位をつける。『ALL for SaaS』では、プロダクトビジョンの実現度合いと顧客価値の観点から優先順位を付けた。他にも、重要度をCore・Use・Engage・Exploreという4段階に分けたり、CFO・経営企画向けの経営管理クラウドを提供するログラスでは『魂、骨、肉、皮、毛』という独自の5段階で設定したりといったケースもあります。
6.開発スケジューリング
重要度に沿って、ユーザーストーリーのグルーピングを行い、四半期ごとなどのおおまかな開発スケジュールに落とす。グルーピングの際は、ユーザーストーリーの技術要件や相互依存関係、代替手段も考慮する。
どんなシチュエーションに最適か？
スタートアップの全ステージで使えるフレームワーク。ユーザー体験視点で優先順位付けを行い、PMFを目指す初期段階としてMinimum Viable Product（MVP）を定義するタイミングでも有効です。
長所
- すばやく効率的にMVPを特定するのに役立つ
- ユーザー体験（≒ユーザー価値）を中心に整理できる
- プロダクト開発に関わる全てのステークホルダーと一緒に行うことで共通認識を作れる
短所
- 事業価値（Viability）や開発の複雑性（Feasibility）が考慮されない
- 顧客や抱える課題の理解があいまいだと作れない、作っても無駄が多く発生する
2. テーマベース法
テーマベース法（Theme-Based Roadmap）は、OKRに記載されるハイレベルな戦略的な目標（テーマ）をベースに優先順位を付ける手法です。ユーザーストーリー・マッピングとは違い、事業インパクトのある戦略的な視点に重きを置いています。
テーマ例は以下のようなものです。
- MAU/DAUを+○○%改善する
- チャーンレートを-△△％改善する
- カートチェックを提供する
テーマベース法は、“機能無しロードマップ”と呼ばれることもあります。日本ではあまりメジャーではないですが、アマゾンなどの米テック大手企業でも使われている手法です。私が受けたスタンフォード大学のPdM講座でも優先順位付けの方法として推奨されていました。
テーマベース法の構成要素は以下の通りです。
- プロダクトビジョン
- 戦略的な意図
- イニシアチブ
- 時間軸（横軸）：Now, Next, Later （現在、次、その後）
作り方の手順はいたってシンプルです。
1. OKRなど「テーマの実現」に必要なイニシアチブを洗い出す
2. 各イニシアチブの内容を詳細に書き出す
その際には、顧客からのフィードバック、プロダクトの活用状況データ、前述のユーザーストーリー、プロダクトチームからのアイディアを参照しながら、以下を記す。
- テーマと紐付いた機能（スコープともいう）
- OKRとの結び付きや顧客
- プロダクトエリアタグ（決済、マーケティングなど）
3. Now, Next, Laterの時間軸に各イニシアチブを並べる
どんなシチュエーションに最適か？
OKRを運用しているような、PMF後のアーリー以降のフェーズに適しています。特に事業部門を交え、しっかりユーザーのフィードバックを踏まえた上で、最終的な事業インパクトまで落とし込むには最適だと考えます。
長所
- 経営陣やプロダクトチームだけでなく、社内の誰が見てもわかりやすい
- アウトプット（機能）ではなく、アウトカム（顧客の課題解決や戦略ゴールの実現）に健全な議論が起こる
- 少ないミーティング数で決められる
短所
- OKRが適切に実施されていなかったり、戦略機能が弱かったりする組織では運用が難しい
- プロダクト部門と事業部門が異なる目標を掲げている場合はワークしにくい
ユーザーストーリー・マッピングやテーマベース法は単体でも運用可能です。ただ、ハイレベルな手法なので、大まかな優先順位をこれらでつけて、以降で紹介する定量アプローチで細かく優先順位を付けるといった、組み合わせのケースもあります。
定量アプローチ 3選
3. RICE法
RICE法は、Reach・Impact・Confidence・Effort（リーチ・インパクト・確度・投下労力）の頭文字からきています。機能やテーマベース法で上げたイニシアチブをこの4項目で評価して、以下の式でスコアリングします。米大手SaaS企業のIntercomで使われている手法（原文 | 和文）としても有名です。
各4項目の評価方法は以下の通りです。
- リーチ：何人の人に影響を与えるか？（定義された期間内で見積もる）
- インパクト：ユーザー1人当たりどれくらいのインパクトを与えるか？
(大規模＝3倍、大規模＝2倍、中規模＝1倍、小規模＝0.5倍、小規模＝0.25倍） - 確度：見積もりにどの程度自信があるか？(高＝100％、中＝80％、低＝50％）
- 投下労力：何人月かかるか？（整数で、最低でも半月を目安に。見積もりにはこだわらないこと)
RICE法をベースにしたアウトプットは、このようなイメージです。
RICE法には類似として「ICE法」や「バリュー×エフォート評価法」などの変形が多くあります。起業家やPdMの重視するポイントで使い分けるのも良いでしょう。
注意点は、RICE法単体で優先順位を決めきることはあまりしません。優先順位付けプロセスの起点であり、ステークホルダーとの議論の際に使います。
どんなシチュエーションに最適か？
スタートアップの全ステージで利用可能です。評価項目を相対的に定量評価できるので、プロダクトマネジメント初心者の方でも比較的取っつきやすいフレームワークだと思います。ただ、初めは経験的な評価がしにくいので、その都度の見直しが必要になります。
長所
- すぐ実行できる
- ただし、評価基準をSMART（具体的・測定可能・実行可能・関連性の高い・期限が明確）にする必要がある
- 優先順位付けにバイアスを排除できる
- 評価項目を相対的に比較できるので、実践的である
- ステークホルダーと視覚的に共通認識を作り上げることができる
短所
- 機能同士の相互依存関係を考慮していない
- 相互依存関係のある場合、マニュアルで優先順位を下げる必要がある
- 戦略ステップやユーザー体験との整合性がない
- RICEの中で、特に確度（Confidence）は経験的な勘になりやすい
4. Kanoモデル
Kanoモデル（狩野モデル）は、これまでの手法と異なり、外部情報（顧客へのアンケート）に基づき、顧客満足度に影響を与えるプロダクトの品質を分類して優先順位付けする手法です。1980年代に東京理科大学の狩野紀昭教授によって提唱され、世界中に広まっています。UXリサーチの手法としても活用されることもあります。
Kanoモデルは下図にあるように、横軸に現在の充足度合い、縦軸に顧客満足度で、ユーザーの認識している品質を5つに分類します
5つの品質はそれぞれ定義されています。下記はこちらの用語解説ページから引用しました。
- 魅力的品質要素：それが充足されれば満足を与えるが、不充足であっても仕方がないと受けとられる品質要素。
- 一元的品質要素：それが充足されれば満足、不充足であれば不満を引き起こす品質要素。
- 当たり前品質要素：それが充足されれば当たり前と受け止められるが、不充足であれば不満を引き起こす品質要素
- 無関心品質要素：充足でも不充足でも、満足も与えず不満も引き起こさない品質要素。
- 逆品質要素：充足されているのに不満を引き起こしたり、不充足であるのに満足を与えたりする品質要素。
Kanoモデルの実施プロセスは以下の通りです。
1. アンケートを作成する
アンケートでは機能ごとに充足質問と不充足質問を5段階評価で質問する
- 充足質問：○○が実現される（有る）と、どう思いますか？
- 不充足質問：○○が実現されない（無い）と、どう思いますか？
2. 顧客ターゲットを対象にアンケートを実施・集計する
3. アンケートの集計結果から、以下の通り分類する
どんなシチュエーションに最適か？
スタートアップの全ステージで利用可能です。ただし、ユーザーは自分の欲しいものを知っているという前提にあるため、CRMやビデオ会議ツールのような世にありふれたプロダクト分野に用途が限定されます。ゆえに、ビジョナリーなプロダクトや現状はマニュアルで作業しているケースでは、活用しにくい手法だと考えます。
長所
- 最も客観性が高い
- チームがやりたい機能を過大評価せず、必須機能を過小評価することを是正できる
- 機能への顧客への期待や成功可能性の予測性が高い
短所
- アンケートが必要なため、時間がかかる
- 公平な結果を得るためにターゲット顧客の比重に合わせたアンケート対象者数の選定が必要になる
- 顧客が機能を十分に理解していないリスクがある
- SaaSの機能をアンケートで説明し切るには相当な工夫が必要になる
- 事業性や戦略性が一切考慮されない
- 機能同士の相互依存関係を考慮していない
5. スコアカード
スコアカードは、評価項目を自分で選定して定量評価し、スコア化するシンプルな手法です。また、評価項目の重み付けの有無も分かれます。
下図は、重み付けしたスコアカードの例です
作り方も至ってシンプルです。
1. 機能やイニシアチブを列挙する
2. 評価項目と重み付けをステークホルダーを含めたプロダクトチームで決める
3. プロダクトチームで各評価項目を100点満点で定量評価する
自由度が高く、前述の定性アプローチと組み合わせることも可能です。たとえば、テーマベース・ロードマップと組み合わせて実施しているのが、freeeです。同社VP of Product Managementの宮田さんのこちらの資料に詳細が記載されています。
どんなシチュエーションに最適か？
全ステージで使えます。自由度が高いので、PdM初心者から上級者まで活用できると考えます。
長所
- 簡単ですぐ実行できる
- 優先順位付けにバイアスを排除できる
- 評価基準がシンプルで、透明性が高い
- 自由度が高く、戦略視点や事業視点を定量化しやすい
- ステークホルダーと評価項目を紐付けることで、チームのアラインメントを取りやすい
短所
- 重み付けをする場合、政治的な意図や意思決定操作が発生する
- ステークホルダーに評価させる場合、プロダクトビジョンやPdMの意思が薄まる
優先順位を付ける際の7つの注意点
最後に、良い優先順位付けを行う際に、忘れてはいけない「7つの注意点」で締めます。
1) 万能ツールはない
上記で見てきた通り、フレームワークには長所と短所があります。“One size fits all”なツールはこの世にないのです。長所と短所を理解した上で、独自にアレンジしたり、別のフレームワークを用いてみたりと、試行錯誤を繰り返しましょう。特に、初期のスタートアップではとても大切だと思います。
2) ステークホルダーの「意思統一ツール」である
基本的にフレームワークは、1人で作業して意思決定するためのツールではありません。フレームワークを使った優先順位付けのプロセスを通して、経営陣、PdM、開発、マーケティング、セールス、カスタマーサクセスなどの全てのステークホルダーを1つの方向にアラインさせるためのものです。顧客とのディスカッションに使うのも有効です。
3) プロダクトビジョンとの整合性を常にチェックする
優先順位付けは、プロダクトビジョンを実現するステップを決めるためにあります。もし、プロダクトビジョンとのズレが発生しやすいとしたら、使うフレームワーク自体を見直すべきだといえます。優先順位付けフレームワークは「虫の目」に陥りがちですから、常に「鳥の目」としてのプロダクトビジョンとの整合性を気にかけましょう。
4) アウトプット（機能）ではなく、アウトカム（事業や顧客へのインパクト）を重視する
一番よくある間違いが機能のデリバリーにばかり意識がいってしまうことです。機能は顧客の課題を解決し、事業に貢献する手段です。決して目的ではありません。PdMの仕事では、機能開発が唯一の解ではありません。時には全てのステークホルダーと協力し、顧客や事業へのインパクトを主導することにあります。機能はその一つに過ぎません。
5) 優先順位付けのやり方を定期的に振り返る
優先順位付けはリサーチなどで検証したとしても、実際にリリースしてユーザーが価値を感じるまで、ただの仮説です。リリース後には四半期単位で「優先順位付けの過程のどこの仮説が正解で、どこが間違っていたか」を確認することを忘れてはいけません。その確認作業こそが、新たに優先順位付けを行う時の最高のインプットであり、より精度を高める“秘伝のタレ”になります。
6) 優先順位付けは常にイテレーションが発生する
優先順位付けは、一回きりの儀式ではありません。市場、顧客、競合、チームの状況は常に変化しています。また事業を進める上で、新たな発見や戦略の変更はスタートアップでは目まぐるしく発生し、それらに合わせて見直されるべきものです。繰り返しますが、優先順位付けプロセスは、ステークホルダー全員が意思統一を図るための重要なプロセスです。
7) 競合が提供している機能や、簡単にできるものを優先しない
これもよくある間違いですが、競合に追いつきたい焦りや、リソース不足といった事情で、「簡単にできるもの」を優先しがちになることがあります。それは本質的に間違っています。あくまでもプロダクトビジョンと顧客価値に重きをおいて考えるべきです。
謝辞
本記事を作成するにあたり、ALL STAR SAAS FUND アドバイザーであるfreee VP of Product Management 宮田善孝さんにご監修いただきました。宮田さんには、この場を借りて厚く御礼を申し上げたいと思います。
参考文献
1. ユーザーストーリー・マッピング
- 宮田 善孝著 『ALL for SaaS SaaS立ち上げのすべて』
- Story Map Concepts
- A Quick Guide on User Story Mapping
- What is User Story Mapping? Steps, Examples + Best Tools Available
- 4.VP of Product Management が語る、SaaS企業を牽引するプロダクト開発のポイントとは
2. テーマベース・ロードマップ
- What is a Theme-Based Roadmap and Why Is it Important?
- How To Build A Product Roadmap Everyone Understands
- FEATURE-LESS ROADMAPS
- Modern Product Roadmapping
3. RICE
- RICE: Simple prioritization for product managers
- RICE: プロダクトマネージャーのためのシンプルな優先順位付け方法
- RICE PRIORITIZATION METHOD
- 9 product prioritization frameworks for product managers
4. Kanoモデル
- 狩野モデル
- 狩野モデルから探る品質のあり方とは
- 調査サービス紹介＃01 「狩野モデル」を用いたアンケート調査
- 9 product prioritization frameworks for product managers
5. スコアカード
- Product Prioritization Frameworks
- How to prioritize features using weighted and unweighted scorecards
- SaaSにおけるProductとBusinessの関係
その他
