ソフトウェア開発におけるチケットは優先順位の高いものから並べるのが基本ですが、優先順位のつけ方って難しいですよね。スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発
この本では以下の4つの観点に着目すると良い、と書いています。
- 価値
- 知識・不確実性・リスク
- リリースの実現可能性
- 依存関係
1. 価値
一言で言うと、「この機能は次のリリースで本当に必要なものか？」ということです。
この本では例として、iPhoneのコピー＆ペーストの機能について触れています。iPhone3Gの頃はコピー＆ペーストの機能がなかったんですね。それでも別に、コピー＆ペーストの機能がなかったかといって売れなかったか？と言えば、「このビッグウェーブに乗り遅れる訳にはいかない」ほど売れましたよね。「あって当たり前の機能」が本当に「その製品にあって当たり前」なのか、考える必要があります。むしろ、その製品特有の機能、といったものの方が、より優先順位は高いはずです。
次のリリースで必要なのか、それでも分からない場合は後回しにしてしまいます。本当に必要な機能ならユーザーからリクエストがきますし、そもそもリクエストが来ないならその製品は・・・残念ながら使われていないので、開発を進める前に、もっと使われるようにするにはどうするべきか、考えた方が良いかも知れません。
2. 知識・不確実性・リスク
「求められているリアルタイム処理が技術的にできるか分からない」「スマホ向けデザインのノウハウがない」「このUIが市場に受け入れられるか分からない」といったリスクがこの項目に当てはまります。こういった項目は、優先順位を上げてとりかかる必要があります。
優先順位を上げてとりかかることで、こんな事が分かります。
- そもそもやる必要のあることなのか、早期に検討することができる。
- 実際に取り組むと「もっとシンプルなアプローチはないのか？」といった具体的な検討をすることができる。
- 必要であれば外部の専門家を呼ぶといった追加コストが早期に分かる。
実際に取り組んでみないと、現実感を持って要件を見ることができません。そもそも、やってみるには粒度が粗すぎて、ばらしてみるとそんな難しいことではなかったのかも知れません。何より、こんなリスクを後々まで放置するのは怖すぎますので、最初に片付けるのが得策ですね。
3. リリースの実現可能性
あるテーマについて完全に実装するよりは、頻繁にリリースできることを重視します。
「このチケットで80%ぐらいテーマを達成しているけども、100%にするにはあと10チケットほど必要」みたいな場合は、10チケットやる前にリリースして、ユーザーからフィードバックをもらう方が適切です。
4. 依存関係
機能には依存関係があって、優先順位に影響をもたらす場合があります。
例えば、「ユーザーはメールアドレスを登録できる」「更新があったらユーザー宛にメールで通知する」みたいなものですね。この本では依存関係を解消するテクニックとして、以下の2つが挙げられています。
- 依存関係のあるいくつかの項目をまとめて1つにする方法
- 要件の分け方を工夫して、依存しないようにする方法
個人的には両方とも現実的でないなと感じます。まとめて1つにするのは要件が膨らみすぎる恐れがありますし、要件の分け方を工夫するといっても限度があります。なので、依存関係があるものについてはプログラマが適切に「この機能にとりかかるためには最低限この機能が必要です」といった説明をして、プロダクトオーナーと一緒に優先順位を検討するべきです。テクニックよりコミュニケーションで解決する方が、適切なケースが多いです。
まとめ
ユーザーのフィードバックをどんどん取り入れて、早期にリリースし続けるためには、適切な優先順位付けは欠かせませんね！ その他のトピックについて気になる方は、スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発
