古典的な開発モデル「ウォーターフォール」。今も大規模案件や官公庁システムで使われる理由と、致命的な弱点をやさしく整理します。スパイラル・プロトタイピングなど派生モデルとの違いまでまとめて押さえましょう。
星見 めい
ウォーターフォールって、英語で「滝」って意味だよね?
なんで開発の話で滝が出てくるの?
紫垣 こはる 先生
いいところに気づいたわね。
ウォーターフォールモデルは、工程を滝の水が上から下へ落ちるように一方向で進めるの。
だからこの名前なのよ。
蜂谷 まこと
補足すると、工程の順番は『要件定義→外部設計→内部設計→プログラミング→テスト→運用』が基本です。
上流から下流へ、と表現します。
小夜川 ほのか
ええと…要件定義って、何を作るか決めるところですかぁ?
紫垣 こはる 先生
そうよ。
お客様の『こういうシステムが欲しい』をきちんと文書にまとめる工程ね。
家を建てる前に、間取りや広さをぜんぶ図面に決めてしまうイメージよ。
蜂谷 まこと
ポイントは各工程の終わりに必ずレビューを行い、成果物の完成を確認してから次へ進むことです。
工程ごとに区切りと合意がはっきりするんですね。
小夜川 ほのか
区切りがあると、今どこまで進んだか見えやすそうですぅ。
星見 めい
でもさ、滝って一度落ちたら上には戻れないじゃん。
それってヤバくない?
紫垣 こはる 先生
まさにそこが最大の弱点なの。
手戻りが起きにくく、起きると大変なのよ。
テストの段階で要件の勘違いが見つかったら…?
星見 めい
うわ、設計からぜんぶやり直し…マジか。
蜂谷 まこと
そのとおりです。
後工程で見つかった誤りほど修正コストが大きくなります。
だから要件定義を最初に厳密に固める必要があるんですね。
小夜川 ほのか
完璧に決めるの、ちょっと大変そうですねぇ…。
途中で『やっぱり変えたい』ってなりそうなのぉ。
紫垣 こはる 先生
ふふ、その不安は正しいわ。
だから要件が途中で変わりやすいサービス開発には向きにくいの。
逆に、仕様が最初からきっちり決まる案件には強いのよ。
星見 めい
じゃあ、ウォーターフォールにもいいところはちゃんとあるんだ?
紫垣 こはる 先生
あるわよ。
工程と成果物が明確だから進捗管理がしやすく、誰が何の責任を持つかもはっきりする。
だからSIerの受託案件や官公庁システムでは今も主流なの。
蜂谷 まこと
覚え方のコツです。
長所は『管理しやすい・明確』、短所は『変更に弱い・手戻り困難』。
長所と短所が表裏一体なんですね。
星見 めい
なるほど、きっちり一方通行だから管理は楽、でも融通が利かないってことか!
小夜川 ほのか
弱点をカバーする別のやり方もあるんですかぁ?
蜂谷 まこと
あります。
代表がスパイラルモデルとプロトタイピングです。
小夜川 ほのか
スパイラルって、螺旋階段みたいにぐるぐる回るイメージですかぁ?
紫垣 こはる 先生
とてもいいイメージよ。
設計→実装→評価を何周も繰り返して、リスクの大きい部分から少しずつ作っていくの。
失敗の影響を早めに小さく抑えられるわ。
星見 めい
プロトタイピングの方は?
試作品を作るって言ってたけど。
蜂谷 まこと
はい。
完成前に試作品をユーザーに見せて『これで合っていますか』と確認し、感想をもとに要件を固める手法です。
画面のデザインなど、言葉だけでは伝わりにくい部分に有効ですね。
紫垣 こはる 先生
他に、システムを小さな単位に分けて作っては動かすを繰り返すアジャイル開発もあるわ。
ウォーターフォールとは正反対で、変更に強いのが持ち味よ。
星見 めい
片方は一方通行で管理重視、もう片方はぐるぐる回って変化に強い。
対になってると覚えやすいじゃん!
紫垣 こはる 先生
そう、その対比が試験でも狙われるのよ。
開発モデルは『どんな案件に向くか』までセットで理解しておくと強いわ。
確認クイズ
ウォーターフォールモデルの特徴として最も適切なものはどれか。
- 短い反復を繰り返し、開発途中の要件変更に柔軟に対応する
- 上流から下流へ工程を順次進め、後工程からの手戻りが難しい
- 試作品をユーザーに見せ、要件を確認しながら開発を進める
- リスクの大きい部分からサイクルを繰り返して完成度を上げる
こたえを見る
正解: 2. 上流から下流へ工程を順次進め、後工程からの手戻りが難しい
ウォーターフォールは要件定義から順に上流から下流へ進み、後工程で前工程に戻る手戻りが難しいモデルです。進捗管理がしやすい反面、要件変更に弱いのが特徴。1はアジャイル開発、3はプロトタイピング、4はスパイラルモデルの説明で、いずれも反復や試作で変更に対応する手法のため誤りです。