今のチームには通常の機能実装とは別に保守というタスクが積んであるリストがある。
保守タスクは開発チームにしかわからないという理由から通常のリストとは別になっていて、毎週のプランニングでスプリントの20%に入る分だけのストーリーポイントのものを入れても良いということになっている。
しかし一見良さそうに見えたこのルールも実際に運用すると全然保守タスクは消化されない。
機能実装が優先という名目なので20%残せないことも多いし、タスクの見積もりの精度にもばらつきがあって保守タスクを積んでも消化されず、次スプリントでは時間が足りないから戻されてそのまま。なんなら途中まで手を付けてしまったせいでその人の手が空くまでほったらかしにされるまである。
PBIが一つになっていないと明確な順位は付けられずこうして腐っていくんだなと痛感した。
そしてPBIを一つにするためにはPBIを管理する役割の人（うちであればいわゆる企画チーム）と活動を共にする体制になっていないといけなさそう。
保守タスクはそれ自体では機能追加やユーザーへの価値へ繋がらない事が多いが、かといって決してないがしろにしていいものではない。
極端な例えだけどRubyやRailsのバージョンアップをしないのは、技術負債に繋がるだけでなくサポート外になったときある日突然デプロイできなくなったり動かなくなったりすることになる。*1
そしてそれは20%の範囲内で各自の自主性に任せてというやり方では到底賄えるものではない。
であればチームでいつ頃やるのかというのを判断していかなければならない。
そしてそれをするためには企画チームも同じようにその情報を知って機能追加とどちらを今はやっていくのかという判断をしていけるようにならなければならない、というわけ。
自分のところも含めて開発チームだけでスクラムやアジャイルでのやり方をやっているところは結構いそうだけど、それだと結局タスクや開発の事故を早期に発見出来るということ以上のメリットを享受できないと感じている。
以前やっていたところはSIerだったのでそのメリットで十分だったというのはあるけど、今の自社開発の会社だとそれだけではちょっと開発の成功率が高い社内受託以上にはなれない。
この辺が「開発チームは機能横断的である」ということの理由なのだろうなと思った。
*1:いきなり使えなくなることはそうそうないとは思うけど、そんな判断を下すようなところにエンジニアがずっといてくれるかという別の問題になる気がする
