ウォーターフォール型の開発の問題点 〜人月の神話〜
最近本を読む時間ができたので、人月の神話を何回も読みなおしている。できれば、要約をブログで公開できたらと思い準備している。
- 作者: Jr Frederick P. Brooks,滝沢徹,牧野祐子,富澤昇
- 出版社/メーカー: 丸善出版
- 発売日: 2014/04/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
人月の神話で一番有名な章は、「銀の弾などない」である。その説明は割愛する。ところで、人月の神話の新装版には著者のブルックスが、過去の自分の言説を振り返って自説が正しかったか確認する章：「『人月の神話』から20年を経て」が載っている。その中にウォーターフォール型の開発の問題点を述べた章がある。その邦題が以下、
捨石にするつもりで構築してはならない ーーーウォーターフォールモデルは間違いだ！
これでは人月の神話を読んだことがない人にはわからないので説明すると。
「人月の神話 第11章 １つは捨石にするつもりで」
たいていのプロジェクトでは、最初に完成したシステムはほとんど使い物にならない。遅すぎたり、大きすぎたり、使いにくかったりする。ひどいものになると、この３つすべてが当てはまっていることもある。こうなると、痛手だとしても賢明な対処として最初からやり直す。問題が解決できるように再度デザインしたバージョンを作成するしかない。（中略）経験からいって、すべての大規模システム*1では、これはやらざるを得ないことなのだ。
この章を、ブルックスは以下のように振り返る
「人月の神話 第19章 『人月の神話』から20年を経て」
「１つは捨石にするつもりで構築せよ」という考え方における最大の誤りは、ソフトウェア構築に関して古典的な順次モデルまたはウォーターフォールモデルを暗黙のうちに想定していることだ。
また、このようにも
彼（ウィンストン・ロイス*2）は、『人月の神話』に先んじて、構築者に対して「２回構築すること」をアドバイスしていた
まとめると
・大規模システムをウォーターフォール型で構築すると初回はまともなものはできない
・元々のウォーターフォール型開発プロセスには「２回構築すること」が求められていた
…実際のところ日本の大規模システム開発では誰も２回もシステム開発してない、その結果がスケジュールの遅延とデスマではなかろうか？もともとウォーターフォール型の開発プロセスが持つ問題点を人海戦術でフィックスしているのではないか。
ウォーターフォール型の開発プロセスが持つ問題点
ブルックスの文章を端的にまとめる
① システムテスト後の修正が発生しやすいし、修正しにくい
「人月の神話 第19章 『人月の神話』から20年を経て」
ウォーターフォールモデルは、システムテストとそれが含意するユーザテストを構築過程の最後に持ってきている。そこで利用者にとって考えられないような扱いにくさや、とても容認できそうにない性能、あるいは利用者のエラーや悪気を引き起こしそうな危険性などを発見したときには、もうすっかり完了してしまっている可能性がある
② コーディングと単体テスト、結合テストまでが同時に構築されると想定されているが、実際は足並みが揃わない
システムテストがいつまで経っても始まらない現象。
上流に向かう動きがなければいけない
この段落は、ブルックスの文章そのままのほうがわかりやすいので引用する。これはウォーターフォール型の開発プロセスが持つ問題というより、ウォーターフォール型の開発プロセスを取る限り本来はやらねばならない責務である。
「人月の神話 第19章 『人月の神話』から20年を経て」
本章の扉を飾っている力強い鮭のように、構築の下流工程から来る経験とアイディアは時には１段階以上流れに逆らって飛び越えて上がり、上流の作業に影響を与えるようでなければならない。
インプリメンテーションをデザインすると、あるアーキテクチャの特徴が性能を阻害することが分かるかもしれない。すると、アーキテクチャに手を入れなければならなくなる。（中略）
ゆえに、何かをコードとして実現する前には、２回以上アーキテクチャーインプリメンテーションのデザインサイクルを繰り返すのが無難なのだ。
ウォーターフォール型の開発プロセスで開発を一発で終わらせたい場合、すべてのインプリメンテーション/アーキテクチャは既知のものであり設計者の設計は実装時に問題が出ないようにしていなくてはいけない…無理である。
