ウォーターフォールモデルの落とし穴。

情報処理の勉強をしていれば一度は聞いたことがあるでしょう。
「ウォーターフォールモデル」
(たぶん)現在主流となっている開発手法。
水が流れ落ちるように計画→設計→製造→テスト→稼動(納品)と進めて行くやり方です。

すごく納得のいくスマートな手法なのですが、私ははっきり言って多少問題有りな手法だと思っています。
何が問題かというと、この手法は「全ての工程が手戻りなく進む」を前提にしているからです。

そんなうまいこといくか。

いや、うまくいくこともあるんですけど。
つまり、始めからある程度開発の全貌が細部までつかめていることが前提なわけですよ。
そうでなければ、詳細設計やっている間に「あれ？」ってことが生じて基本設計に戻ったり、プログラム設計やっている間に「おや？」ってことが生じて詳細設計に戻ったり。

一番大きいのはテストですね。
バグっていうのは出るものです。
それはいいんです。
でも直すのにいつまでかかるのかっていうのは難しいですね。
だって、いくつ出るかわかんないんだし。

しかもテストしているうちに「ここの仕様ってどうなってるんだっけ？」という、いわゆる設計漏れが出てきたりします。
特に大きいシステム開発とか、(設計書が残っていないくらい)古いシステムのリプレイスとかにありがちですね。
そうすると結局、詳細設計なり基本設計まで戻ることに。

ほら、手戻っちゃった。
手戻る＝余計な工数が出るってことですからねえ。

まあ、一概に悪いところばかりではなく、ちゃんと機能など詳細がを把握しやすい開発においては、むしろコンパクトに進めることができ、規模を把握しやすいので良い手法と言えるでしょう。

きっとウォーターフォールモデルっていうのはある条件下においては良い手法だけど、汎用性のある手法ではないと思うのです。

だから、いいかげん別の手法も試してみようね♪＞うちの会社


先日予告したとおり、明日から異国へ旅立ちます。
そういうわけで次回は月曜日。