WF型でもいいじゃない。

ウォーターフォール(以下WF)型の開発と言えば、
とかく誹謗されがちです。
その理由の一つが、
「工程を後戻りする際のコストが大きすぎる。」
でしょう。
「実際のところ、顧客の要求は要求定義、設計工程以降も
　思い出したように出てくるため、後戻りは容易に予測される。
　柔軟に変化に対応できにあWF型の開発は時代遅れで、
　使えない。」
といったところでしょうか。

実際そうですよね。
せっかく試験工程まで行ったのに、実は仕様に漏れがあって
設計工程まで巻き戻らないといけない機能が出てきたり。
あるいは、その機能の「あるべき論」をもう一度行う必要性が
出てきたりして、要求定義を今更始めたり・・・。

それにも関わらず、SIerの持っている方法論は、大抵WF型が中心で、
滝つぼに向かって、粛々と開発が進むことを前提としている。
（滝つぼに向かうというか、単に墜落だったりすることも）

一方、アジャイルという考え方があります。
顧客の要求は変化するものだ、変化を柔軟に受け入れよう、
プラクティス重要…。
それぞれが置いている前提が違います。
顧客の要求を固められる＝WF型の前提
顧客の要求は固められない＝アジャイル型の前提

現在の開発スタイルに対する考え方については、
アジャイル型の肯定＞WF型の肯定で、アジャイル型で
開発をしたいが、いくつかのしがらみがあって、
それができない（→どうしたらいい？悶々）という状況では
ないでしょうか。

以上が、前振りです。
私の意見としては、「WF型でもいいじゃない。」です
方法論が先にあるのではなく、顧客を念頭に置いて、
取るべき方法論を考えなくてはならないと思うわけです。
顧客の特徴や、システム規模、自社の体制といった変数を元に
方法論は決めるべきで、方法論を先に決めて、案件に臨む
のはナンセンスです。
その点で、SIerに、WF型くらいしか方法論を用意されていない
というのは、顧客にとっての損失です。
単一の方法論で、どんな案件にも常に当てはめれるほど、
システム構築というのは単純なものなのでしょうか。
もし、そうであれば、デスマなんて言葉はとっくの昔に死滅しているはずです。

WF型＝悪という図式ではなく、顧客と、このプロジェクトにとって
ベストな方法論を選びましょうよ、そして、SIerはその選択肢の幅を
用意しましょうよ、というのが結論。

最後に、少し実体験を。
昔、私が携わった組み込み開発は、WF型での開発しか考えられなかったです。
プログラムはC言語で書いて、それを実機に似せた
シミュレーターに乗せてテストを実施する。
そのテストが合格すれば、実機でのテストを実施する。
この、シミュレーターのテスト、実機のテストというのが、恐ろしく
手間がかかるんです。物理的な実機が絡むので、テストパターン一つをこなすに
しても、人間の動作が関わるわけで、非常に時間がかかる。
製造した自動車の試験の際に、この自動車のデザイン仕様を今から変える！
ということには絶対ならないですよね。
品質を設計工程で確保するという、WF型の開発はとても理に叶ったものでした。