ソフトウェアを作るチームは、要求をインプットとして、実装した機能をアウトプットする 変換器
だと捉えることができる。
こんなすごいものを作りたい!と、大きな絵 (まさに "Big Picture") を描いたとする。
この理想を、そのままソフトウェアを作るチームという変換器に突っ込もうとすると
チームはその "大きすぎる" 絵を受け止めることは出来ない。なので、
大きな要求は細かくする。
しかし、細かくした要求を無闇矢鱈にチームに詰め込もうとすると
要求たちはチームの入り口で詰まってしまって、チームはやはり受け止めることが出来ない。
細かくした要求は、明確な意図を持って取り組むべき順番を明らかにし、1列に並べてチームに与え続けるべきである。
というのはメタファーなんだけど。スクラムでは Product Backlog
というものがこの「1列に並べた要求」に当たる。スクラムガイドでは、Product Backlog のアイテムがどんな属性を持つべきかは規定していないが、「順番に並べられた」ものであることは明白に規定している。
『アジャイルエンタープライズ』という書籍では、「エンタープライズアイディアパイプライン」の上で、企業活動を記録し、披露し、洗練し、実現し、リリースしよう、と述べている。これも「パイプライン」であり、列に並べられて逐次的に処理されていくという形状をしている。
アジャイルエンタープライズ (Object Oriented SELECTION)
- 作者:Mario E. Moreira
- 発売日: 2018/03/19
- メディア: 単行本(ソフトカバー)
この「一列に並べる」という作業は強い意思決定なので、スクラムではプロダクトオーナーは1人にする、とか、プロダクトオーナーチームには Chief を置く、というのが定石になっている。委員会制による合議だと、"Big Picture" は広げるだけ広げることができるが、意思を持って「どの順に攻めてゆくか」という優先度決めは急激に難しくなる。