開発するべきフィーチャーの優先順位の付け方

XPにしろスクラムにしろ、フィーチャーと呼ばれる顧客やユーザーにとって意味のある単位で分解し、フィーチャー単位で進捗を測っていく方法は共通だ。アジャイルな計画と見積作りでは、イテレーションはフィーチャー単位でカウントするべきと述べており、どの機能から作り始めるべきかについて、下記4つの指針を述べている。

フィーチャーの金銭的な価値
- 重要な機能から実装せよ
フィーチャーを完了させるまでの作業コスト
- 実装後の見直しにコストがかかるなどのリスクも見越して全体の作業コストが最適化される道を選べ
フィーチャーを実装することにより得られる情報
- 作ろうとしているプロダクトの真の要求、プロジェクトの最適な進め方に関する情報がより多く得られるフィーチャーから作れ
フィーチャーの実装により取り除かれるリスク
- より大きなリスクを取り除けるフィーチャーから作れ

2番目から4番目までは実はほとんど同じ事を言っているように思われた。つまり、プロジェクトのリスクを低減させるためにはプロダクトやプロジェクトの情報が必要であり、それが明らかになる前に大きな機能を実装するのは手戻りのリスクが高いということだ。現在私が取り組んでいるプロジェクトは、主に下記のようなリスクがある。

プロダクト面のリスク
- 未経験の種類のプロダクト
  - プロダクトが今まで全く世に出たことのないもので、その要求が分からず作り直しが多く発生するリスク
プロジェクト面のリスク
- 初めての協業パートナー
  - 協業パートナーとのコミュニケーションリスク、先方の技術リスク
- 初体験のアプリケーションフレームワーク
  - フレームワークの機能の不足リスク、使いこなせないリスク
- 初体験のプロジェクト管理手法
  - 進行が十分に管理できずタスクや方向性が定まらないリスク

ここまで初が揃うとこれらのリスクを低減するための処方箋を先に打つことが大事である。これらのリスクを一気に解消するのであれば、下記のような特徴を持つフィーチャーを選定すべきであろう。

プロダクト面のリスクに対して
1. プロダクトの方向性を決定づける重要なフィーチャーである
プロジェクト面のリスクに対して
1. 機能を完成させるまでの全てのワークフローを通り、ワークフローの中に不足している
2. 可能な限り多くの技術要素を広く浅く使用する
3. アジャイルな見積のためのベースを確立するため可能な限りシンプルな機能にする

プロジェクト面のナレッジが十分に得られ、協業パートナーとのコミュニケーションの方法やプロジェクト管理の方法がある程度明らかになった後でないと大量のタスクを消化するのは危険である。そのため、もしプロダクト面のリスクを取り除ける重要フィーチャーが非常に重たい場合は、それを後回しにしてまずはプロジェクト面のリスクを取り除けるフィーチャーから先に実装した方が良い。
プロジェクト面の3番目の要求は他の要求とトレードオフになる可能性もあるが、できるだけこういったフィーチャーを選定するべきだろう。