プロダクトバックログの優先順位の付け方

プロダクトバックログの優先順位付けは、開発プロセスの重要な要素です。何を最初に開発するか、優先順位を決定することは、作業を効率的に計画するのに役立ちます。

この記事では、プロダクトバックログの優先順位付けの重要性と、優先順位を作成するための手法、メンテナンス方法を紹介します。

プロダクトバックログの優先順位を決める重要性について

便利な製品とは、機能が満載の製品ではなく、ユーザーの問題を効率的に解決する製品です。
重要な機能を開発し、過負荷 (および多額のコスト) を回避するには、プロダクトバックログの優先順位付けが必要です。

必要かつ不可欠な機能のみを作成することは、企業がお金と時間を節約するための優れた方法です。

また優先順位が付けられたバックログは、リリースと次のイテレーションの計画を容易にします。

プロダクトバックログの優先順位で考慮すべき５つの要素

①　ビジネスバリュー

機能を実装することによって生み出される価値はどのようなものですか？
(利益の増加、コスト削減、品質の向上、ステークホルダーの満足度向上など)

②　サイズ（労力・コスト）

機能を実装するための労力サイズはどのくらいですか？ 多くのリソースを費やす必要がありますか？
（ユーザー ストーリーの複雑性、リスク、不確実性、完成させるために必要な労力のレベル）

③　技術的な依存関係

プロダクトバックログ内のアイテムは、依存関係があることがあります。依存関係は開発順序を考慮する必要があります。

④　リスクの軽減

機能を実装することで、不確実性を減らしたり、今後の作業のリスク低減に繋がりますか？

⑤　能力開発

チームの新たな能力開発に繋がりますか？

これら 5 つの要素のバランスを取ることは簡単ではありません。
そのため、バックログの優先順位付けは、プロダクトオーナーにとって最も困難な意思決定の1つです。

バックログに優先順位を付けるのはプロダクトオーナー責任ですが、チームメンバーはこの意思決定をサポートします。
チームで最適な優先順位付け手法を使用するため、最も一般的に使用されるバックログの優先順位付け手法を次から紹介していきます。

プロダクトバックログの優先順位付け手法を紹介

プロダクトバックログアイテムは、新機能のリクエスト・ユーザーストーリー・バグ・変更要件・技術的負債・振り返りからの改善アイテムなどがあります。

難しさは、必須の機能と不要な機能をどのように区別するかです。
ここで、アジャイルと優先順位付けのテクニックが活躍します。

プロダクトバックログの優先順位付け手法をいくつか紹介します。

価値 vs 労力（難易度）の優先順位付け

概要

このマトリックスは、価値と実装する機能の労力（難易度）の相対評価に基づいて、評価します。
価値 vs 労力（難易度）は、4 象限を使用して、バックログアイテムを配置します。チームは、価値が高く労力（難易度）の低いアイテムに最初に取り組みます。

長所

• シンプル、わかりやすい
• 数学や分析に重きを置かない

短所

• 主観的な判断を許しがち
• 大規模なバックログアイテムで依存関係が多く発生する場合にうまく機能しない

狩野モデルの優先順位付け

概要

縦軸は、顧客またはエンドユーザーの満足度を反映しています。右軸は、製品が満たす顧客の要求を表します。左軸は、満たされていない顧客のニーズを表します。これらは次の 5 つのカテゴリに分類されます。

長所

• 機能をその値でランク付けします
• ユーザー中心
• 機能の長所と短所を簡単に把握できます

短所

• 製品の構築に必要な時間とリソースを考慮していない
• 対象市場の調査に多くの場合時間がかかる場合がある

MoSCoWの優先順位付け

概要

MoSCoW は頭字語の、「Must」「should」「could」「would」 の略です。
MoSCoW を使用すると、チームはバックログ アイテムの相対的な重要性を判断できます。マストとは、製品が機能するために必要なバックログアイテムを意味します。顧客にとって価値の高いアイテムを表す必要があります。

（長所）

• 技術的または数学的すぎない
• 簡単に理解しやすく、速い作成することができる

（短所）

• プロダクトの全体像はあまり考慮されていない
• 必要なものと、望ましいものとの間に不均衡が生じる可能性がある

RICEの優先順位付け

概要

RICEとは、「Reach」「Impact」「Confidence」「Effort」の略です。

Item アイテム	Reach リーチ	mpact 影響	Confidence 信頼性	Effort 労力	RICE Score RICE スコア
A	7,000	3	40%	2	4200
B	4,000	1	60%	4	600

長所

• ユーザーを中心
• 包括的
• 実際のデータ活用と KPI に基づいており、より正確

短所

• 時間がかかる
• データが揃わない場合がある
• チームは多くの項目を推測をしなければならない場合がある

機会スコアリングの優先順位付け

概要

機会スコアリング(Opportunity scoring・ギャップ分析とも呼ばれます)は、バックログアイテムをランク付けするために 2 つ軸を使用します。
まず、満足度（縦軸）を使用して、ユーザーが機能について、どの程度満足しているのかランク付けします。次に、重要度（横軸）を使用して、ユーザーが機能をどの程度重要視しているかを測定します。
ユーザーが重要と考えるが、十分に開発されていない機能は、機会を得ることになります。

長所

• ユーザーのニーズと提供されている機能価値の間のギャップを見つけるのに役立つ

短所

• チームは既存の製品を持っている必要があり、新しい機能には対応していない
• 機能の重要性を過小評価または過大評価する可能性がある

ユーザーストーリーマッピングの優先順位付け

概要

ユーザーの行動を時系列で整理し、それを実現するために必要な機能や要件をマッピングすることで、プロダクトが実現する価値の目的や優先順位を視覚的に捉えられるようになります。
ユーザーストーリーを並び替えながら、ユーザーにとって価値のある最小限の機能セット（MVP：Minimum Viable Product）を定義することができ、初回リリースに必要な要件の一覧を洗い出すことに役立ちます。

• バックボーン「会員登録」「検索」「選択」「支払い」「閉じる」など開発対象の大まかな構造のエピックになります。
• ウォーキングスケルトンは、”会員登録”をより細かくして「新規ユーザー登録」と「ログイン機能」などの最小単位のユーザーストーリーとなります。

長所

• MVPとして迅速にリリースが可能
• カスタマージャーニーの全体像が把握できる

短所

• 主要な機能のみに焦点を当てている

アイゼンハワーマトリックスの優先順位付け

概要

アイゼンハワーマトリクスは、緊急度と重要度に応じてタスクを整理し、優先順位を付ける手法です。
アイゼンハワーは、「重要なことはめったに緊急ではなく、緊急であることはめったに重要ではありません。」と言い、この哲学をもとに作られました。

1. 高優先度:緊急かつ重要
2. 中優先度: 重要だが、緊急ではない
3. 緊急だが、重要ではない
   含まれている機能は緊急のものですが、プロダクトのビジネスに大きな影響を与えるものではないため、チームはそれらが本当に”今”必要かどうかを判断する必要があります。
4. 低優先度:緊急でも重要でもない

長所

• シンプルでわかりやすい
• 割り込み作業などを判断しやすい

短所

• 考慮される項目が少ない
• 技術的な要素（労力やコスト）は考慮されていない

プロダクトバックログの優先順位付け方｜MoSCoWとKano(狩野) Modelの違い

MoSCoWは、1994 年Oracle のコンサルタントであったDai Cleggによって開発されました。 MoSCoWは、2000 年代初頭にDSDM (動的システム開発手法) で普及しました。
アジャイルの人気が高まるにつれて、優先順位を付ける方法として広く使用されています。

狩野モデルは、1980年代に日本人教授の狩野紀昭氏によって提唱されました。
マーケティングや品質管理の分野に対して大きな影響を与え、世界的にはKano Modelとして知られています。

一般に、顧客の満足度は品質の充足度に応じて変化するものとされますが、狩野モデルでは、その品質がどの品質要素に該当するかによって顧客満足度に与える効果が異なるとされています。

つまり必須機能を特定するだけでなく、顧客が本当に価値を置いているものを重要視します。これは、魅力機能について評価する際にも役立ちます。

プロダクトバックログの優先順位のアンチパターン・失敗例

何十個ものアイテムに優先順位を付けることは困難です。
一番下に置かれたバックログアイテムが完了するのはいつでしょうか？リード タイムが長くなるにつれて、顧客は不満を抱きます。

すでにあるアイテムをストーリー マップを使用して整理してみましょう。プロダクトのビジョンをチームで再確認し、現在不要であるものは削除します。
次の数スプリントまたは数か月以内でアイテムが重要でない場合は、プロダクトバックログに追加するべきではありません。

そして重要な点は、プロダクトオーナーが「NO」ということを学ぶ必要があります。

プロダクトバックログの優先順位の見直し・メンテナンス方法

優先順位の見直し・メンテナンス

プロダクトバックログは一度完成したら終わりではありません。プロダクトに関わるステークホルダーや、顧客、市場のニーズなど、ビジネス環境は絶え間なく変化し続けます。
バックログを最新の状態に保ち、効果的に使用するためには、継続的に管理、改善を繰り返す必要があります。

プロダクトが成長するにつれて、プロダクトバックログが増加するという場合が多くあります。これは、バックログアイテムが多すぎる可能性があることを意味します。
ビジネスニーズに基づいてアイテムが整理されていないと、管理が困難になり、透明性が失われます。

さて、メンテナンスの重要性についてはご理解いただけたかと思いますので、つづけてメンテナンス方法について簡単に説明していきます。

プロダクトバックログアイテム（PBI）の見直し・メンテナンス

プロダクトバックログを管理しやすい状態に保つには、下記のような点を確認してみましょう。

• バックログを定期的に確認する
• 不要になったユーザー ストーリーを削除する
• 新たに発見されたニーズに応じて新しいユーザー ストーリーを作成する
• 優先順位の再検討
• 作業サイズの再見積もり
• 完成の定義、準備完了の定義の見直し

プロダクト オーナーは、バックログを管理しやすくすることで、成果を最大化するように取り組む必要があります。

プロダクトバックログの優先順位に関するFAQ｜教えてJoe！

プロダクトバックログの優先順位を決める役割は誰ですか？

プロダクトバックログの責任はプロダクトオーナーに責任があります。そのため優先順位についてもプロダクトオーナーの責任です。プロダクトオーナーはプロダクトの価値最大化の観点から考えます。チームは技術的な観点も含めてプロダクトオーナーの決定をサポートする必要があります。

プロダクトバックログの優先順位の手法はどんな基準で選べばいいの？

どの優先順位付けフレームワークを使用するかを選択するのは難しいことです。多くの優先順位付け方法があり、チームとプロダクトに適した方法を見つけることは、ニーズやビジョンによっても異なります。まずは試してみて、フィードバックを得ることを繰り返し、チームとプロダクトに合った方法を見つけてみてください！

プロダクトバックログの優先順位を失敗したら途中で変更してもいいの？

失敗に限らず、優先順位が変わるということはあるでしょう。特にプロダクトの初期段階では不確実性も高く、全てを決定することは難しいのです。次のスプリントで軌道修正すれば問題ありません。そのために、毎日のプロダクトバックログの見直しをお勧めしています。日々の気づきに適応したり、改善させることができます。

スクラムマスターはプロダクトバックログの優先順位にどう関わればいいの？

プロダクトバックログの優先順位は、チームで合意され共通の理解があることが重要です。スクラムマスターは、プロダクトオーナーと開発者全員が合意できるよう働きかけます。スクラム マスターは、プロダクトオーナーと開発者の両方を支援することで、プロジェクトの成功に貢献します。

バックログの優先順位には、ビジネス観点と、技術的な観点が不可欠です。
そのためプロダクトバックログの作成および優先順位付けは、チーム全体で行う必要があります。これは、グループ内の自律性と共同作業環境をもたらすのにも役立ちます。

プロダクトバックログの優先順位まとめ

優先順位付けは、すべてのプロダクトオーナー、およびチームにとって不可欠なスキルです。いくつかの優先順位付け手法を紹介しましたが、他にも多くの手法が存在します。
どの手法を選ぶかは、プロダクトやチームによっても異なり、難しく正解はありません。

この記事が、さまざまな優先順位付け手法を試したり、調べるための良い出発点となることを願っています。