TechとPoemeの間

Qiita に書かないエンジニア業の話

絵に描いた餅のままでは実現できないので、小さく切って1列に並べる

ソフトウェアを作るチームは、要求をインプットとして、実装した機能をアウトプットする 変換器 だと捉えることができる。

f:id:mura-_-mi:20201209233752p:plain

こんなすごいものを作りたい!と、大きな絵 (まさに "Big Picture") を描いたとする。

https://1.bp.blogspot.com/-11IY8US22b8/XXXOmmFKlRI/AAAAAAABUwI/q0vKcClXCAYAp2vvTMgZHwk7HUMKoq84QCLcBGAs/s1600/kotowaza_enikaitamochi_man.png

この理想を、そのままソフトウェアを作るチームという変換器に突っ込もうとすると

f:id:mura-_-mi:20201209233952p:plain

チームはその "大きすぎる" 絵を受け止めることは出来ない。なので、

https://4.bp.blogspot.com/-ahPTU-go-1w/VMIvV5tXOXI/AAAAAAAAq7E/jOEKRp4T1RY/s800/cooking08_kakugiri.png

大きな要求は細かくする。

f:id:mura-_-mi:20201209234347p:plain

しかし、細かくした要求を無闇矢鱈にチームに詰め込もうとすると

f:id:mura-_-mi:20201209234426p:plain

要求たちはチームの入り口で詰まってしまって、チームはやはり受け止めることが出来ない。

f:id:mura-_-mi:20201209234519p:plain

細かくした要求は、明確な意図を持って取り組むべき順番を明らかにし、1列に並べてチームに与え続けるべきである。


というのはメタファーなんだけど。スクラムでは Product Backlog というものがこの「1列に並べた要求」に当たる。スクラムガイドでは、Product Backlog のアイテムがどんな属性を持つべきかは規定していないが、「順番に並べられた」ものであることは明白に規定している。

『アジャイルエンタープライズ』という書籍では、「エンタープライズアイディアパイプライン」の上で、企業活動を記録し、披露し、洗練し、実現し、リリースしよう、と述べている。これも「パイプライン」であり、列に並べられて逐次的に処理されていくという形状をしている。

アジャイルエンタープライズ (Object Oriented SELECTION)

アジャイルエンタープライズ (Object Oriented SELECTION)

  • 作者:Mario E. Moreira
  • 発売日: 2018/03/19
  • メディア: 単行本(ソフトカバー)

この「一列に並べる」という作業は強い意思決定なので、スクラムではプロダクトオーナーは1人にする、とか、プロダクトオーナーチームには Chief を置く、というのが定石になっている。委員会制による合議だと、"Big Picture" は広げるだけ広げることができるが、意思を持って「どの順に攻めてゆくか」という優先度決めは急激に難しくなる。