開発の優先度を決めるためのフレームワーク3選
プロダクトマネジメントをしていると必ずぶち当たるのが、開発する機能の優先度設定です。
顧客からの要望、経営陣からの指示、自分のアイデア・・・
たくさんの開発項目がバックログに積み上がっているかと思います。
開発リソースも限られているので優先度を決めて開発スケジュールを作っていく必要がありますが、皆さんどのように優先度を決めているでしょうか。バックログの優先度を個人がなんとなく決めてしまうということは無いかと思いますが、このようなやり方を取ると以下のようなリスクがあります。
・ みんなが使いそうな機能よりも、自分が使いそうな機能で満足しがち
・ ありふれている確実なアイデアよりも、斬新なアイデアに興味を惹かれがち
・ 新機能開発に必要な工数を低く見積もりがち
このようなリスクを避けるためにも、そしてステークホルダーに対して納得感がある説明をするためにも、開発する機能の優先度は合意された枠組みの元で決定することが重要です。
ここでは、開発の優先度を決めるための一般的なフレームワークを３つ紹介してみたいと思います。
１．価値対複雑度モデル(Value vs. Complexity Model）
最初に紹介するのが、Value（価値）とComplexity（複雑度）の2軸で優先度を判断する価値対複雑度モデルです。
まずValue（価値）は、2つの側面から見積もる必要があります。
A. ペルソナ・市場に対してもたらす価値（効率化、コスト削減など）
B. あなたの会社が受け取る価値（新規顧客、アップセルなど）
恐らくこの際に複数の要素を組み込む必要性が生じるはずです。
A については、顧客に対してどの程度の効率化をもたらすか、どの位の顧客のプロダクト認知度向上を見込めるか。Bについては、新規顧客数やアップセルの見込みがそれにあたるはずです
これら複数の要素をValue軸のサブセットとしてリストアップし、重み付けを行い、最終的なValue値を計算するための枠組みを作ります。
次にComplexity（複雑度）です。開発を複雑度を図る要素としては、開発コストが第一に挙げられますが、それ以外にも以下のような要素も考慮する必要があります。
運用コスト
顧客トレーニング、移行、照会対応のコスト
開発リソースのスキル希少度
リスク（法規制変更、新技術による代替など）
これらの要素も考慮に入れた上で優先度を決める必要があるため、2つ目の軸はあえて単純な開発コストとしていないのです。Valueと同じようにComplexityについても複数の要素を組み合わせて最終的な値を計算する枠組みを定義します。
開発する機能やプロダクトに対してValueとComplexityが算出できたら、4象限にマッピングします。マッピングされた象限から、以下のように優先度を決めることが出来ます。
1. High Value, Low Complexity (投資対効果が高い)
2. Low Value, Low Complexity (クイックに小さな効果)
3. High Value, High Complexity (効果は高いが慎重に対応する必要がある)
4. Low Value, High Complexity (基本対象外)
基本戦略としては、まずは1番を最優先に取り組みつつ、2番についてもリソース状況を見ながら適宜対応、となります。3番は高い複雑性を受け入れてでもやるべきかを慎重に判断した上で対応を決める必要がありますし、4番は法規制対応でもなければ対応不要ということで問題ないはずです。
２．RICEスコア
次に紹介するのはRICEスコアです。まず以下の４つの指標を定義します。
Reach 一定期間内にどの位の顧客に影響を与えられるか（顧客数）
Impact 各顧客にどの程度の影響を与えられるか（0-3までの数値)
Confidence 影響度見積もりの確度（0-100%）
Effort 開発工数（人月、ストーリーポイント）
カッコ内の単位は例なので、適宜決めてもらって大丈夫です。
4つの指標が定義出来たら、RICEスコアは以下の数式で算出されます。
Reach ✕ Impact x Confidence / Effort = RICEスコア
例えば、ある開発機能に対して次のように見積もったとします。
Reach 四半期中に100顧客
Impact 2（高インパクト）
Confidence 80%
Effort 10人月
上記の例だとRICEスコアは16(=100x2x80%/10)となります。
RICEスコアが高いほど優先度も高くなるということですね。
３．狩野モデル
最後にご紹介するのは、日本人の大学教授である狩野紀昭氏による「狩野モデル」です。
狩野モデルは東京理科大学名誉教授の狩野紀昭氏が提唱したもので、海外でも“Kano Model”という名称で有名なものです。この狩野モデルでは、顧客の求める品質について「魅力品質」「一元的品質」「当たり前品質」の３つに分けています。
https://www.juse.or.jp/departmental/point02/08.html
元々は商品企画の際に顧客の求める品質をモデル化する目的で考案されたものですが、開発項目の優先度設定にも活用することが可能です。
まずはSatisfactionとFunctionalityの２軸を設定します。
Satisfaction: 顧客の満足度（どのくらい満足してくれるか）
Funcionality: 機能の充足度（どのくらいリッチな機能か）
この２軸から構成される平面上で対象となる開発項目がどのような曲線を描くかによって、以下の４種類に分類することが出来ます。上に貼った図も参考にして下さい。
Attractive：予期しない喜びを与えるもの。シンプルな機能でも大きな満足度を獲得できる。 初期iPhoneのタッチスクリーン、ダイソンの羽根のない扇風機など。
Performance：SatisfactionとFunctionalityが正比例するもの。バッテリー寿命、ネット速度など。
Must Be：当然必要な機能として認識されているもの。機能の充足度が低いと大きく顧客満足を損なう。車のブレーキ、ホテルのベッドなど。
Indifferent：あってもなくても良いもの。足の生えた蛇。
さて、あなたの開発したい機能がこの４つの内のどれに当てはまるか、どのように判断したら良いのでしょうか。
一般的なのは、ユーザに対して以下の問いを投げかけることです。
Disfunctional: もしこの機能が無かったらどう思うか。
Functional: もしこの機能があったらどう思うか。
回答を以下のテーブルにマッピングすることで、開発を検討している機能がどの分類に当てはまるかを評価することが出来ます。
分類ができたら、一般的な優先度付としては以下の順になります。
Must be → Performance →Attractive →Indifferent
このフレームワークではユーザからの目線のみで評価しており、他に紹介したものと違って開発コストを考慮していません。従い、既にリリースされているプロダクトに対するバックログの評価よりも、新規プロダクト開発における機能の優先度付けに向いています。もちろん、新規プロダクトにおいてもMust beだけにフォーカスせず、競合との差別化要素（＝Attractive）にも着目する必要はあります。
また、注意したいのは特定の機能が常に同じ分類で居続けるとは限らないこと。どんなにAttractiveな機能だったとしても、競合が同様の機能を提供するようになってしまったら真新しさは薄れていきます。気がついたらMust Beになっているかも知れません。代替する新技術が出てきた場合にはIndifferentにすらなってしまうこともありえます。
これを避けるためにも、定期的に各機能の分類を見直す必要があります。
まとめ
最後に、それぞれの特徴をまとめておきます。
１．価値対複雑度モデル：価値と複雑度の２軸が基本だが、現実的にはそれぞれを構成するサブセットの定義が必要。
２．RICEスコア：４指標ベースでわかりやすいが、ImpactとConfidenceの数値化は恣意的になる。
３．狩野モデル：ユーザ・顧客観点からの評価がベース。競合との差別化要素を明確化しやすい。開発コストの観点が抜けているため、別途組み合わせが必要。
他にも調べると色々なフレームワークがあります。それぞれ特徴があるので、プロダクトの性質、組織やリソースの状況に応じて使い分けなければなりません。
しかし、最も重要なこと。それはどのフレームワークを使用するにせよ、その背景や中身についてステークホルダーとしっかり合意形成しておくこと。これに限ります。これが出来ていないと、バックログの優先度付の際に揉めること間違いなしでしょう。
参考
この記事が気に入ったらサポートをしてみませんか？