ウォーターフォール手法 (water fall model)

1. アプリケーション開発関係者からは敬遠される手法であるが…

システム構築やアプリケーション開発における開発手法群の一つ、或(ある)いは進行手法と言うべきか

考案されてから現時点に至るまで、年数面で長らく採用されて来た手法と言える

案件進行の工程を時系列に適宜区切り、原則として先頭工程から順次完了させて進捗を図る
ただしこれは、進捗上次工程を先行させるのが望ましくない状況を作り易く、また並行作業も行いにくい傾向がある
各工程においては当該の工程で作成すべき成果物を確実に完了させる事で、前工程への手戻り作業を抑止する
一般的には Microsoft社の Excel を利用して進捗状況を把握しようとする事が多いする事が多いが、金持ち企業では MS Project 等の本格的なアプリケーションを使用する事もある

# 私が使い慣れていないからなのであろうが、これが又仲々(なかなか)に使いにくい印象がある

この手法はかなり古臭くなってしまっており、現実作業においては中々正常に機能しない事も多々ある
要求仕様の変更や重篤な設計瑕疵の発覚等が生じてしまうと、柔軟な対処を行いにくい手法ではある

# 実際の所、手法が悪いと言う事では無く基盤構築を手掛(てが)けて来ている PM の質が低劣で、単に効率が悪く柔軟な対応をし得ていないだけと言う事も多々あるが…

アプリケーション開発では他の手法、Spiral Model(スパイラルモデル) や agile software development(アジャイル開発手法群) と組み合わせて採用される事が多くなっている、らしい

2. 情報システムでの基盤構築

実は、アプリケーション開発と違い基盤構築とウォーターフォールの相性は以外と良い
と言うのも、アプリケーション開発に度々発生する(発生させられる、と言うべきか) 仕様変更の頻度が基盤開発では低い、もしくは低く抑えられるからである

基盤構築は概(おおむ)ね機材調達と言う工程が発生し、漸(やや)もすれば廉価ではない金銭が動いた上で構築が行なわれる
機器調達後に仕様を変更したくても機器仕様上対応不可、と言う事があり得る
そうなると改めて機材の再調達、と言う訳(わけ)には行かない筈なので、仕様を妥協せざるを得なくなるのである

仕様変更を抑えられるのであればウォーターフォールと言うのはそれ程(ほど)悪くない手法なので、基盤構築では今尚(なお) 主流として採用され続けているのであろう

今では余り評価されない手法とされてしまっているが、個人的には今後も継続して使用されるべき良き手法では無いかと思う

1. アプリケーション開発関係者からは敬遠される手法で あるが…

2. 情報システムでの基盤構築

3. 関連 URI

1. アプリケーション開発関係者からは敬遠される手法であるが…