Subscribed unsubscribe Subscribe Subscribe

自分より長生きするソフトウェアより、自分より長生きするチーム

scrum

同僚が、
「自分より長生きするモノが作れたら、開発者としては幸せだろうね。」
と書いていた。


私も以前はそう思っていたんだけど、いつ頃からかそう思わなくなった。その「想い」によって、よいソフトウェアも、ダメなソフトウェアも生み出されるんじゃなかろうか...と考えるようになったからだろう。


ダメなソフトウェアというのは、いろいろあるが、開発者が去った後にメンテできなくなってしまったソフトウェアも、やはりダメなものだと思う。ソースコードがいかに優れていても、メンテナンス体制が組まれなくなってしまえば、徐々に利用価値を蝕んでいくようになる。実装がまともでないものは論外だが(リリース時点でだめとか、リリース前に負けてるとか)、設計も実装も当初の運用もすべてまともであっても、時が過ぎるとダメになってしまうものは、よくあるのだ。


自動車のエンジンが危険なく動き続けるためにはメンテナンスが必要で、それは少なくとも製品の寿命に等しい期間必要になる。なので、その期間存在できるチームを作る必要がある。外部の力を頼ってもそれは同じで、保守費はかかるし、バージョンアップのときに前のソフトウェアは引き継げない。


だから、本質的にはチームを小さく維持して長生きさせることと、継続的にアウトプットを出し続けるようマイルストーンバックログを整備することが、ゾンビを生み出さない唯一の道なのではないか。


実は、ソフトウェアを必要としない状況であればゾンビも生まれないのだけれど、実際は目の前の状況は既に生まれたゾンビと新しい状況への対応で日々戦っているので、今のところソフトウェアを要求していることが多いとみている。次善の策として、複数のゾンビを処理しながら、一つの生きているソフトウェアを生み出し、それをやり続けるチームを維持する。


あと、つらいと思ったら続かないので、楽しくやる仕組みを考えるのは大事なことだと思う。

- - -

こういうことが、スクラムに出会ったときにちょうど気づいたところだったりする。
...ような気がする。