ウォーターフォールモデルとは、システム開発の工程を順番通りに進めていくことです。
システム開発の各工程をそれぞれざっとわかりやすく書くと、下記の通り。
1つの工程をガチガチに固めて完了させたあとに、次の工程を順番に進めます。
「今、何をやっているのか？」がはっきりして、進捗状況がわかりやすい（管理しやすい）ので、大規模なシステム開発でよく使われます。
ただ、順番通りにやる分、手戻り（やりなおし）が発生するとダメージが大きくなるのが難点。
戻る工程が多いほど、やり直す工程とコストも多くなるといったイメージです(*´ω｀)。
ウォーターフォールモデルでは各工程を順番に進める
waterfallは、「滝」の意味。
ウォーターフォールモデルでは、「滝が流れ落ちるイメージ」のように、各工程を順番に進めていきます。
システム開発の工程
システム開発の工程は、冒頭でも書いた通りです。
それぞれの工程をカンペキに仕上げる
「何を作るか？」を決める要件定義では、何を作るかをカンペキに決めます。
■要件定義のイメージ
「とりあえず、作ってみますね」みたいなことはしないのが特徴（逆に、ある程度あいまいでも作ってしまうのが「アジャイル開発」）。
要件定義で決めたことをもとに、設計（どんなプログラムにするかを決める工程）に入って。
そこでも、「どんなプログラムにするか？」をカンペキに設計します。
■設計のイメージ
「プログラムのイメージが固まってないけど、とりあえずコーディングします！」みたいなことはしないのが特徴（逆に、それでもプログラムを書くのが「アジャイル開発」）。
設計をもとに、やはりプログラミングでカンペキに動くものを作りつつ。
最後に、作ったものが動くかを確認する単体テスト・結合テスト・総合テストへと進めて完成させます。
■テストの一例
手戻りは発生しない前提
「何回、『カンペキに』と書くんだよ！」と思ったかもですが。
ウォーターフォールモデルでは、滝が上に逆流することがないのと同様、手戻りは発生しない前提です。
それぞれの工程で、問題なんてものは発生しない（白い目）ので、手戻りが起こらない前提です。
※反対に、手戻りが発生する前提の開発モデルは、アジャイルって言ったりする。
ウォーターフォールモデルは大規模なシステム開発に使われる
ウォーターフォールモデルは、大規模なシステム開発に使われることが多いです。
ウォーターフォールモデルのメリット
というのも、お堅い企業ほど好みそうなメリットがあるから。
システムの全体像が大きいときによく使われるし、お客様も安心できる
銀行のATMや、業務支援システム（例えば、伝票登録したら在庫の管理も請求書の発行もしてくれる）だと、全体像がバカでかいです。
システムの全体像が大きい場合は、それだけ開発期間も長くなるので。
「どれくらいかかるのか？」を、先に見積もっておくほうが、手を付けやすいといえます。
ついでに言うと、ウォーターフォールモデルは「時代遅れ」とディスられたりするのですが、「今、設計が50%進んでいます！」みたいに、進捗の管理や報告もしやすいので。
全体像が大きいシステムを発注しているお客様からしてみれば、かなりの額のお金を出しているので、ウォーターフォールモデルでやってくれたほうが安心感があるしわかりやすいのです。
※大規模になればなるほど、ウォーターフォールを工夫した「スパイラルモデル」（規模が大きいから何回かに分ける考え）が採用されやすいので、ついでに覚えるとよき！
ウォーターフォールモデルのデメリットは手戻りのコストが大きい
ただ、ウォーターフォールモデルにも、手戻りのコストが大きいというデメリットがあります。
「思ってたのと違う」となると、影響が出る分だけやり直し
例えば、コーディングも終えて、作ったものをテストしているときに、「思ってたのと違う」となると、影響が出る分だけやり直しになります。
簡単なもの（ささいなミス）であれば、やり直しといっても、大したことにはならないのですが。
それが、
- 「他の機能も直さないといけない」（③）
- 「もう一度プログラムの処理を考えなさないといけない」（②）
- 「お客様に聞かないといけない」（①）
みたいになってくると、その分だけコスト（時間）がかかります。
戻る工程が多いほど修正コストは大きい
言ってしまえば、戻る工程が多いほど、やり直す工程とコストも多くなります。
プログラミングに戻る（③）よりも、設計をやり直す（②）方が、修正コストは大きく。
設計をやり直す（②）よりも、要件定義をやり直す（①）方が、修正コストは大きいです。
ここまで、読んでくれたうえで、冒頭の図をもう一度、見ると理解しやすいかもです(*´ω｀)。
【余談】わりとうまくいかないことも多い
ただ、なんとなく察しているかもしれませんが、わりとうまくいかないことも多いです(*´ω｀)。
というのも、カンペキである前提で次の工程に進むということは、やり直しがききません。
エンジニア全員が、100%の仕事ができるほど優秀であればいいのですが、そうは問屋が卸さない。
実際には、ミスや抜け漏れ（それもわりと致命的）があったりするのが普通（ましてや、複数人でやっていれば、コミュニケーションのミスだってあるし、常に100%のものができたら苦労しない）。
それに、お客様も途中で「やっぱり、こうしてほしい！」みたいに言ったりする（仕様変更、通称「仕変」）ので、100%の仕事ができていたとしても、その一言で木っ端みじんにされます。
ただ、ひよこSEの個人的な意見としては、ウォーターフォールモデルが悪いわけではないし、お客様が「やっぱり変えたい」と言うのも、高いお金出してるし普通だと思っています。
問題なのは、手戻りが発生することを少しも考えずに、理想論のまま突き進むこと。
むしろ、ウォーターフォールモデルの考え方自体は、理にかなっていると考えているくらい！
反対に言えば、ウォーターフォールモデルであっても、「修正が絶対に発生してはいけない」というルールがあるわけでもないので、修正が発生したらスケジュールを考え直すだけで解決したりするのですが(実際にはそんな余裕がないから、この発言も理想論なんだけどね)。
まぁ、大人の事情としてこの辺にしておきます(*´ω｀)。
まとめ
ウォーターフォールモデルときたら、システム開発の工程を順番通りに進めていくことです。
スケジュールも作りやすいし、進捗の管理もしやすいので、なんだかんだよく使われる開発モデル。
順番に進めていく分だけ、手戻り（やりなおし）が大きいとダメージが大きくなるので、そこのコントロールをどうするかが重要なんだなぁ～くらいに思ってくださいまし(-_-;)。
コメント