大きなリリースをするべきではない4つの理由

自戒を込めてメモ

大きなリリースはバグを増やす

大きなリリースになればなるほど、コードベースに潜むバグが増える。充分なテストがないチームでは、コードレビューにテスト相当のタスクが求められるようになり、本質的な設計の優先度は低くなる。結果として、長期的に見たコードの品質は落ち、よりバギーなコードが生まれやすくなる。

また、大きなリリースでは変更があまりに多すぎるため、バグの特定が困難になる。それどころか、見過ごされるバグが生まれ、顧客に届く価値は不完全なものになる。

大きなリリースはロールバックも大変になる。下手するとロールバックすらできない。大きなリリースは戦艦建造のようなもの。戦艦はデカい巨体を地上で組み上げてそれをいっきに海へ浮かべる。海から地上へは戻せない。でも、ソフトウェアは戦艦の建造とは異なり、大抵の場合プログレッシブにやれる。

小さくプログレッシブに機能をリリースできるチームは挑戦的になれる。問題が起きても場合やり直しが容易であり、ひとつのリリースに多くのものを詰め込む必要がないことで余裕を持って品質の高いに開発の計画を立てられる。

リリースが少ないチームは絶対に納期を守らねばならないというプレッシャーをかけられている。なぜなら、そのリリースを逃せば次のリリースはずっと先になるから。

開発チームとしては体裁を保つためにリリースでは絶対に成果をださねばならない。先送りはできないというプレッシャーをかけられる。プレッシャーをかけられた開発チームは毎日遅くまで残業することになる

大きなリリースでギリギリになって仕様の漏れが発覚しても、自分がリリースの遅れ引き起こす要因になることを恐れてメンバは仕様忘れをひた隠しにする。ドキュメントの欠落などで、もともとあるはずだったものが消え失せることもある。

度重なるリリースの遅延により、必要とされていた仕様が不要になってしまうことすらもある。その結果、顧客に届く価値は全く意味のないものになる。