[ 通常表示 ]  [ 簡易表示 ]  [ シンプル表示 ]

「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典イメージぴよ画像「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

ウォーターフォール型

pointこの用語のポイント

pointシステム開発のやり方だよ

point工程を分けて1つずつ終わらせていくよ

point工程の後戻りはしないよ

スポンサーリンク

簡単に書くよ

ウォーターフォール型とは

システム開発のやり方のひとつ
であり

まず設計を全部やって~設計が全部終わったらプログラムを全部作って~プログラムを全部作り終わったらテストを全部やって~テストまで終われば完成!のように、工程を1つずつ順番に終わらせていき、(基本的には)工程の後戻りをしないやり方
です。

image piyo

詳しく書くよ

一言で言えば「工程を1つずつ順番に終わらせていくやり方」が「ウォーターフォール型」です。
水が高いところから低いところに流れ落ちるように、最初の工程から最後の工程に向かって、1つずつ順番に終わらせていきます。

ウォーターフォール型

例えば、そうですね。

ピヨ太君はピヨ子さんからの依頼でピヨ子さん専用の新作ケーキを作ることになりました。
いまだかつて誰も食べたことがないような苺ショートケーキを作ります。

ウォーターフォール型2

苺ショートケーキは、ざっくり言えば苺とショートケーキが合体したケーキです。
最高の苺を最高のショートケーキに乗せることで、最高の苺ショートケーキが完成します。

ウォーターフォール型3

最初にピヨ太君がやったのは設計です。
まず「どんな苺が最高の苺なのか?」と「どうすれば最高の苺になるか?」を考えました。

ウォーターフォール型4

次に「どんなショートケーキが最高のショートケーキなのか?」と「どうすれば最高のショートケーキになるか?」を考えました。

ウォーターフォール型5

最後に「最高の苺と最高のショートケーキを、どのように合体させれば最高の苺ショートケーキになるか?」を考えました。

ウォーターフォール型6

おっと、どうやら設計工程が終わったようです。
ピヨ太君の頭の中に最高の苺と最高のショートケーキ、そして最高の苺ショートケーキのイメージができあがりました。

ウォーターフォール型7

次にピヨ太君がやったのは、実際に作る作業です。
まず、設計工程でできあがったイメージ(設計書)を元にして最高の苺を作りました。

ウォーターフォール型8

次に、設計工程でできあがったイメージ(設計書)を元にして最高のショートケーキを作りました。

ウォーターフォール型9

最高の苺と最高のショートケーキができあがったら、2つを合体させて、最高の苺ショートケーキに変身させました。

ウォーターフォール型10

おっと、どうやら実際に作る工程が終わったようです。
ピヨ太君の目の前には、とても美味しそうな苺ショートケーキがあります。

ウォーターフォール型11

最後にピヨ太君がやったのはテストです。
実際に味見をして、本当に美味しい最高の苺ショートケーキかを確認しました。

ウォーターフォール型12

うん、美味しいです。
これは最高の苺ショートケーキでしょう。
早速、ピヨ太君はピヨ子さんに作ったケーキを届けました。

ウォーターフォール型13

最高の苺ショートケーキ全体で見ると、ピヨ太君は

1.設計
2.実際に作る
3.テスト


の工程を1回ずつ、やりました。
それぞれの工程は順番に行い、後戻りはしません。
設計が全部終わってから作り始め、全部作り終わってからテストを行い、テストが終わった時点で完成です。

ウォーターフォール型14

この話においてピヨ太君がやったやり方「全体に対して作業工程を1つずつ順番に終わらせていき、後戻りをしないやり方」がウォーターフォール型です。

ウォーターフォール型のメリットは、どこまで進んだかが分かりやすいことでしょう。
ウォーターフォール型では(基本的には)工程の後戻りをしません。
そのため「今は設計工程だから先は長いな」や「今はテスト工程だから、もうすぐ完成だね」のように「今はどの工程にいるから、どれくらい進んでいて、あとどれくらいで終わるね」が予想しやすいです。

進み具合が予想しやすいことは、管理のしやすさにつながります。
部下に「さっき頼んだ作業、いつ終わる?」と質問したときの返事が「多分、あと3日くらいで終わります」と「いつ終わるか分かりません」だったら前者の方が管理する方としては助かりますよね。
それと同じです。

一方のデメリットは、要求される能力水準が高いことでしょうか。
完璧な設計を行い、その完璧な設計を元に完璧に作り、その完璧に作った物をテストするから予定通りに終わるのです。
もちろん、ある程度のリスクは見込みますが、基本的にウォーターフォール型は「全部、上手くいく前提の開発手法」です。

最悪の場合では、テストの結果を見て「あっ!この設計だとダメじゃん!」と判明します。
そうなると大変です。
最初に戻って、やり直しです。

ですが、そんなやり直しの時間は予定に組み込まれていません。
デスマーチの始まりです。

ウォーターフォール型は「理想論に基づいた開発手法」と言えると思います。
工程ごとに高品質を維持できてこそ成り立つやり方です。

とはいえ、昔からよく使われている一般的な開発スタイルですけどね。
今も多くのシステム開発がウォーターフォール型で行われていると思います。

ちなみに「工程を1つずつ順番に終わらせる」「工程の後戻りをしない」は建前です。
あまり真に受けないでください。

実際には、スケジュールの都合で設計工程と作る工程が同時に進んだりします。
作る工程の途中で「あれ?これってヤバいじゃん!」と気付いて設計工程に逆戻りすることもあります。
お客さまから「あ~、こんな機能もくっつけてよ」と仕様変更の依頼が入り、作る工程を進めながら並行して追加の設計を行ったりする場合もあります。

残念ながら、予定は未定であり決定ではありません。
それが哀しい現実です。

あと、ついでなので書いておくと、テストをするテスターよりも、プログラムを作るプログラマ、プログラムを作るプログラマよりも設計とかもするシステムエンジニア(SE)の方が、普通はお給料が高いですし、偉そうにしています。

その理由はウォーターフォール型を基準として考えられているからです……と言い切りたいところですが、特に根拠はない私の想像なので「思います」としておきます。
その理由はウォーターフォール型を基準として考えられているからだと思います。

ウォーターフォール型では先工程の方が(テストよりも作る作業、作る作業よりも設計する作業の方が)

ミスるとヤバい

です。

テストでミスっても、そこまでヤバくはありません。
ミスに気付くのが前提ではありますが、ミスったテストをやり直せば、それで済みます。

設計をミスったらヤバいです。
仮にテストの段階で設計のミスに気付いたとしましょう。
まずミスった設計をやり直す必要があります。
直した設計に基づいて作り直す必要もあります。
作り直した物をテストし直す必要もあります。
やり直しが、いっぱいです。

いわゆる上流工程になるほど、責任が重く、要求能力が高くなります。
だから、テスターよりもプログラマ、プログラマよりもSEの方がお給料が高く、偉そうな雰囲気が感じられるのでしょう。

純粋に作業の大変さだけを見れば、テスターもプログラマもSEも、そこまで大差ないかもしれませんけどね。
そこら辺の「おまえ、この作業はミスったらヤバいんだからな」なプレッシャーによって、待遇が変わってくるのだと思います。

image piyo2

一言でまとめるよ

まぁ「ウォーターフォール型」って単語が出てきたら「工程を1つずつ順番に終わらせていき、後戻りをしないやり方なんだな~」と、お考えください。

一番上に戻るよ
スポンサーリンク