ウォーターフォール開発への批判
では「ウォーターフォール」はどうなったのだろう？そもそもなんでこんなにウォーターフォールが無視されるようになったのだろうか？
ウォータフォールを復習しつつ、なぜ世の中がウォータフォールからアジャイルへシフトしたのか理解してみてみよう。
ウォーターフォール
以下のプロセスを上から順にすすめていく方式。
- 要件定義/分析
- 設計
- 開発
- 試験
- 運用
１つのプロセスが全て完了してから次のプロセスに進む。基本的に逆戻りはしない。
うまくいく条件
- 開始前に全ての要件が定まっているプロジェクトである
- 比較的小規模の統制の取れたプロジェクトである
利点
- 設計ミスなどを早期に検出できる
- プロジェクトの各工程がしっかりと文書化される
- 計画を立てやすい
- 進捗を確認しやすい
欠点
- 現実としてプロジェクト開始前に全ての要件を集めることが困難
- プロジェクト開始時点での要件に最適化したシステムを作成するため完成したシステムの仕様を変更するコストが高い
- システムがユーザに渡るまでの期間が長い
- 前工程における遅延が後工程を圧迫するため最終工程である試験が簡素化されやすい
- 逆戻りを前提としていないためプロジェクト途中における仕様変更に弱い
批判
以下のような市場の変化を受けて新しい開発手法が脚光を浴びるようになる。
IT市場の競争激化
IT市場の競争激化に伴い、IT企業は早い段階で自分たちの製品をリリースしてユーザのニーズと合致しているか判断する必要が出てきた。
加えてリリースした製品に対するユーザの不満を早期に製品へフィードバックして再リリースすることも必要としている。
こうした頻繁な仕様変更、早いリリースサイクルは従来のウォーターフォールでは実現できない。
Lean開発という思想
トヨタの生産方式では以下のようなフィロソフィーがある。
- ムダを排除する
- 知識を作り出す
- 決定を可能な限り遅らせる
- できるだけ早期に製品を提供する
- 権限を委譲する
- 全体を最適化する
- 品質を作り込む
加えて以下のことを重視する。
- 「Why」を繰り返し考えること
- 過程とメトリクス（効果測定）
- 適材適所
その後、アメリカの多くのスタートアップ企業の製品開発方式がトヨタ方式と類似していたことから「Lean開発」として大きく注目されるようになった。
Lean開発は「思想」「哲学」であり、具体的な方法論ではない。Lean開発を実践するには具体的な方法論、方式が必要となる。しかしLean開発をウォーターフォールで実践することは難しい。
競合の登場
Lean開発を実践する方法論として「アジャイル」が提唱された。
アジャイルはウォーターフォールと異なり短い期間でインクレメンタルにリリースを重ねてシステムを成長させることを主眼としている。アジャイルのためのプロジェクトマネジメント手法としては「スクラム」が最も有名だ。
他にも開発環境の変化に応じた様々な開発方式が登場する。
- プロトタイプ開発
- プロトタイプを作成してユーザの反応を調査してから設計工程に入る
- MVP開発
- 最小限の機能を持つ製品を早期に市場へリリースしてユーザの反応を調査する
- Rapid Application Development（RAD）
- 少人数でプロトタイプを開発してユーザの反応をフィードバックすることを繰り返しながら完成品に近づけていく
- 特にGUIに有効。
- Extreme Programming
- アジャイルの一つ
- 少人数で（悪い意味はないが）短期的な目標に対して属人的に取り組んでいく
- TDDを強く推奨している
長らく有力な競合が不在だったためウォーターフォールに不満があったとしても他に選択肢がない状況だった。しかし強力な競合が次々と登場し、その有効性が様々な開発現場で実証されたことでそれまでウォーターフォールに不満を感じていた人々の何割かがウォーターフォールから去っていくこととなった。
現状
アジャイルにも欠点はある。特に請負などではどう適用すればよいのか悩むケースが多い。このためシステム開発の現場では今でもウォーターフォールを踏襲しているプロジェクトが少なくない。
参考
ウォーターフォールの歴史を簡単にまとめたので興味のある人は参考にしてほしい。
