最終更新:

【図解で比較】アジャイル vs ウォーターフォール — 開発手法の違いを徹底解説


開発の進め方を比べる
ウォーターフォール要件設計実装テスト公開アジャイル小さく確かめて見直す作る試す反応見直す反応を次の計画へ
左も必要なら工程を見直します。右は短いフィードバックの考え方で、全アジャイルがスプリントを使うという意味ではありません。
ひよこ ひよこ
予約アプリを作るなら、ウォーターフォールとアジャイルはどう選べばいいの?
ペンギン先生 ペンギン先生
ウォーターフォールは要件・設計・実装などの工程を順に進めるモデル、アジャイルは短い間隔で成果を確かめて計画や進め方を調整する考え方だよ。図は比較を簡略化したもので、現実には工程をまたぐ見直しもあるんだ。
ひよこ ひよこ
ウォーターフォールってどんな流れで進むの?
ペンギン先生 ペンギン先生
要件定義→設計→実装→テスト→リリース、という順序が基本の説明だよ。でも「前に戻るのは禁止」とは限らない。Royceの1970年の論文でも工程間の反復が示され、終盤のテストまで問題が見えない進め方のリスクを指摘しているんだ。
ひよこ ひよこ
じゃあアジャイルはどう進めるの?
ペンギン先生 ペンギン先生
アジャイル全体にスプリントが必須なわけではないよ。代表的な枠組みのスクラムでは、1か月以内の固定長のスプリントを繰り返す。計画・開発・検証などを行い、デイリースクラムでは目標に向けた進み方を確かめて計画を調整するんだ。
ひよこ ひよこ
スプリントが終わったらどうなるの?
ペンギン先生 ペンギン先生
スクラムではレビューで成果と今後の方向を関係者と確認し、最後の振り返りで仕事の進め方を改善するよ。リリースを必ずスプリント末まで待つわけではなく、完成の定義を満たす成果は途中で届けることもできるんだ。
ひよこ ひよこ
ウォーターフォールってダメな方法なの?
ペンギン先生 ペンギン先生
工程ごとに成果や承認をそろえる計画が役立つ場合はあるよ。ただし医療や金融だから自動的に最適というわけではない。必要な証跡や検証、変更の手続き、リスクを洗い出して進め方を決めよう。手法の名前だけで安全性は保証されないんだ。
ひよこ ひよこ
アジャイルが向いているのはどんなプロジェクトなの?
ペンギン先生 ペンギン先生
要求に不確実性があり、小さく作って利用者の反応を確かめたい場面では、短いフィードバック間隔が役立つよ。ただし関係者が判断できる体制や、繰り返し検証できる設計が必要。Webやアプリなら必ず成功するという区分ではないんだ。
ひよこ ひよこ
チームの大きさとかドキュメントの量も違うの?
ペンギン先生 ペンギン先生
2020年版スクラムガイドでは、スクラムチームは通常10人以下としているよ。これはアジャイル全体の人数制限ではない。アジャイル宣言は文書の価値も認めているから、監査・運用・引き継ぎに必要な文書を省略してよいという意味ではないんだ。
ひよこ ひよこ
両方のいいところを合わせた方法はないの?
ペンギン先生 ペンギン先生
組み合わせるなら、全体計画と短い検証の結果をどうつなぎ、誰が変更を判断するかを決めよう。工程名を混ぜるだけでは改善しない。どこで不確実性を減らせるか、品質をどう確かめるかを基準に、進め方も見直していくといいね。

予約アプリを作る場面で考える

「予約ボタンを置けば十分」と思っていても、利用者に見せると「空いている時間から選びたい」と気づくかもしれません。このように使い方がまだ見えていない部分は、小さく作って反応を確かめると学びにつながります。これはアジャイルが重視する短いフィードバックの具体例です。

一方、外部システムとの接続条件や、公開前に必要な承認が決まっている部分は、その条件を計画へ織り込む必要があります。「計画するか、しないか」の二択ではありません。次の3点をチームで確認してみましょう。

  1. 最初から確定している条件と、使ってみないと分からない条件は何か。
  2. 誰に、何を見せれば、次の判断に役立つか。
  3. 変更が必要になったら、誰が費用・日程・品質への影響を判断するか。

スクラムの用語を先に整理したい場合はスクラムへ。方法の名前を覚えたら、まず小さな成果を確かめる場面を一つ考えてみると理解しやすくなります。

参考資料