読者です 読者をやめる 読者になる 読者になる

なんとな~くしあわせ?の日記

ClojureとかAWSの設定とかをメモする技術ブログ

ウォーターフォール型の開発の問題点 〜人月の神話〜

技術論 雑記


最近本を読む時間ができたので、人月の神話を何回も読みなおしている。できれば、要約をブログで公開できたらと思い準備している。

人月の神話【新装版】

人月の神話【新装版】

人月の神話で一番有名な章は、「銀の弾などない」である。その説明は割愛する。ところで、人月の神話の新装版には著者のブルックスが、過去の自分の言説を振り返って自説が正しかったか確認する章:「『人月の神話』から20年を経て」が載っている。その中にウォーターフォール型の開発の問題点を述べた章がある。その邦題が以下、

捨石にするつもりで構築してはならない ーーーウォーターフォールモデルは間違いだ!

これでは人月の神話を読んだことがない人にはわからないので説明すると。

  • 捨石とは?

「人月の神話 第11章 1つは捨石にするつもりで」

たいていのプロジェクトでは、最初に完成したシステムはほとんど使い物にならない。遅すぎたり、大きすぎたり、使いにくかったりする。ひどいものになると、この3つすべてが当てはまっていることもある。こうなると、痛手だとしても賢明な対処として最初からやり直す。問題が解決できるように再度デザインしたバージョンを作成するしかない。(中略)経験からいって、すべての大規模システム*1では、これはやらざるを得ないことなのだ。

この章を、ブルックスは以下のように振り返る

「人月の神話 第19章 『人月の神話』から20年を経て」

「1つは捨石にするつもりで構築せよ」という考え方における最大の誤りは、ソフトウェア構築に関して古典的な順次モデルまたはウォーターフォールモデルを暗黙のうちに想定していることだ。

また、このようにも

彼(ウィンストン・ロイス*2)は、『人月の神話』に先んじて、構築者に対して「2回構築すること」をアドバイスしていた

まとめると
・大規模システムをウォーターフォール型で構築すると初回はまともなものはできない
・元々のウォーターフォール開発プロセスには「2回構築すること」が求められていた

…実際のところ日本の大規模システム開発では誰も2回もシステム開発してない、その結果がスケジュールの遅延とデスマではなかろうか?もともとウォーターフォール型の開発プロセスが持つ問題点を人海戦術でフィックスしているのではないか。

f:id:panzer-jagdironscrap1:20140511233042p:plain

ウォーターフォール型の開発プロセスが持つ問題点

ブルックスの文章を端的にまとめる

システムテスト後の修正が発生しやすいし、修正しにくい

「人月の神話 第19章 『人月の神話』から20年を経て」

ウォーターフォールモデルは、システムテストとそれが含意するユーザテストを構築過程の最後に持ってきている。そこで利用者にとって考えられないような扱いにくさや、とても容認できそうにない性能、あるいは利用者のエラーや悪気を引き起こしそうな危険性などを発見したときには、もうすっかり完了してしまっている可能性がある

f:id:panzer-jagdironscrap1:20150131125606p:plain

② コーディングと単体テスト結合テストまでが同時に構築されると想定されているが、実際は足並みが揃わない

システムテストがいつまで経っても始まらない現象。

上流に向かう動きがなければいけない

この段落は、ブルックスの文章そのままのほうがわかりやすいので引用する。これはウォーターフォール型の開発プロセスが持つ問題というより、ウォーターフォール型の開発プロセスを取る限り本来はやらねばならない責務である。

「人月の神話 第19章 『人月の神話』から20年を経て」

本章の扉を飾っている力強い鮭のように、構築の下流工程から来る経験とアイディアは時には1段階以上流れに逆らって飛び越えて上がり、上流の作業に影響を与えるようでなければならない。
インプリメンテーションをデザインすると、あるアーキテクチャの特徴が性能を阻害することが分かるかもしれない。すると、アーキテクチャに手を入れなければならなくなる。(中略)
ゆえに、何かをコードとして実現する前には、2回以上アーキテクチャーインプリメンテーションのデザインサイクルを繰り返すのが無難なのだ。

ウォーターフォール型の開発プロセスで開発を一発で終わらせたい場合、すべてのインプリメンテーション/アーキテクチャは既知のものであり設計者の設計は実装時に問題が出ないようにしていなくてはいけない…無理である。

終わりに

「『無理』というのはですね、嘘吐きの言葉なんです。途中で止めてしまうから無理になるんですよ*3、設計者は感動を食べてWORDを書けばいいのです」とはブルックスは言わない。次章で漸進的(インクリメンタル)構築モデルについて述べている。それについてはまたいずれ…

*1:これはUNIXの元となったMULTICSの経験から来ているとのこと、どうです?論拠ありまっせ

*2:ウォーターフォール開発プロセスの提唱者

*3: ワタミ創業者、渡邉美樹の名言、迷言、格言集。『無理』というのはですね。。。