ウォーターフォールが悪いのか？

長年このシステム開発と言う仕事をしていると、「立てられた予定」と「実際に行われた作業」との間の乖離が問題になってる。で、この乖離が作業スケジュールの送れという形で表面化し、スケジュールに間に合わせる為に非常に緊密な作業を行う．．．．と言うのが所謂「デスマーチ。略して「デスマ」

ちなみにWikipediaでは、

ソフトウェア産業において、デスマーチとは、長時間の残業や徹夜・休日出勤の常態化といったプロジェクトメンバーに極端な負荷を強い、しか も通常の勤務状態では成功の可能性がとても低いプロジェクト、そしてこれに参加させられている状況を主に指す。

と概要に書いてある。


以下、思いついた事を箇条書きで

1. ふつうのウォーターフォールは、要件定義　基本設計　概要設計　詳細設計　製 造　テストと言う流れ。
2. 全体のボリュームが決まる前にカットオーバーが決まっている
3. スケジュールは、「大体こんなもん」で積み上げて行くが、単なる「つじつま合わせ」になっている。
4. 実際にそのスケジュールで出来るかどうかは、始めた時点はもちろん、誰にも分からない。
5. 各フェーズで遅れても、始めのうちは、「まだ先があるから」と思っているんじゃないか。
6. 遅れが積もって、大きくなる頃には、製造フェーズに入っている。
7. 結局、前フェーズの遅れの尻拭いのために作業期間が短縮され、デスマを迎える。
8. しかも、開発フェーズでおそらく一番重要かつ、時間のかかるテストフェーズへのシワ寄せが一番大きい
9. テスト期間が短くされている為に、十分なテストが出来ず品質に影響がでる。
   
10. しかし、ウォーターフォールというプロセスが悪い様に言われるが、悪いのは、運用であって、方法論ではないと思う。
11. カットオーバーとそこに至る作業見積りを最初にしてしまう事が問題だと思う。
12. 設計図も無い状態で「10階だてのビル？３日で作りますよ」と言っているのに等しい（ちょっとオーバーな表現）
13. 設計図も無い状態で、どうして「３日」なんて言えるのか。
14. でも、システム開発の現場では、これが「普通に」行われている。
15. ウォーターフォールでデスマ を発生させない為にも、フェーズ終了時の予実確認と次フェーズの再見積りを行う事が重要ではないかと思う。
16. もちろん、作業見積もりの為の「作業時間の集計/サンプリング」を行って、それをベースに見積もりを行う。と言う方法は一部で行われている様ではあるが、どこでも行われている訳ではない。
17. 結果的に、3. に書いたように「大体こんなもん」で見積もられてしまう。

まあ、言いたい事は、15. で終わっているんですが、ウォーターフォールの良い所は、良くも悪くも、（長年使われている事もあって）「分かり易い」、「やり易い」だと思う。

アジャイルの様な方法論の場合、「やったことのある管理職」がいない。と言うのが普及しない原因の一つではないかと思う。開発者にとってみれば、ある意味、「開発者天国」の様な感じもあるけどね。

個人的には、まず、「スケジュールの柔軟な運用」を希望します。 > 誰にいってるんだか。