インクリメンタルなデプロイここでは失敗事例が結構なまなましく語られていて、とても強い気持ちが感じられるセクションです。規模の大きなシステムで長期間にわたって開発が続く場合、期日にまとめてリリースしようとしてたいていの場合失敗する。数ヶ月とか1年が過ぎると、そもそもの要望が大幅に変わって来たり。スケジュールが大幅に遅れて、かなり無理をして新たなシステムに移行したものの、個々の機能にあれこれ問題が発覚して、そのような状況で大幅な変更とか、まぁ対応できるわけがありません。なんだかよく聞くようなストーリーです。直前の「本物の顧客参加」にもつながりますが、部分的にでも使える状態にして、実際に使ってもらって、そのフィードバックをもとに次の機能を進めていく。問題があれば、速やかに対応。日数が経過してからだと、対応にも時間がかかったりしますが、そうでなければ対応も比較的楽ですよね。して、ちゃんと機能するものが積み上がっていって、しかもこまめにフィードバックも得ているので、あるタイミングで大幅な変更で混乱、という事態にもなりにくいと思います。多少大きめの変更が発生するとしても、それまでの実績があるので、その時点での変更コストが見通しやすい。チームの継続とか縮小とかチームを継続しながら適度なローテーション、てどうでしょう。意図してローテーションというのはあまりされていないような気もします。個人のスキルに依存するばかりで、チームとしてのパフォーマンスに対する意識が低いのではないかと。対象とする分野とか業種によって、それぞれ要求されるスキルとかノウハウが異なるとは思いますが、それを固定化することがチームとか組織としてはたして良いのかどうか。ある分野で培ったノウハウを別のチームに持ち込んでみると、そこで新たな気づきにつながって、組織全体としてパフォーマンスが上がる可能性もあると思います。個人の責任で追い詰めたところで何も解決しないどころか、時間のロスやモチベーション低下につながりますよね。チームでコードを共有して、チームで責任を持つと思えば、自然と個々のコードの品質も上がって、チームとしての評価も上がるはず。いった感じで今日はこの辺で終わりにします。