---
# アジャイルとウォーターフォールについて本気出して考えてみる
URL: https://agile-monster.com/blog/agile-and-waterfall/
Published: 2012-09-25
---
なぜアジャイルなのですか？改めて考察するウォーターフォールとの違いに参加してきました。
ウォーターフォールはよくディスらr・・・アジャイル開発と比較されることが多いです。私もアジャイル開発を経験する前にも何度か開発プロジェクトを経験しました。しかし、それらはウォーターフォールをしていたわけではなく、「ウォーターフォールのようななにか」に過ぎなかったように今では思います。
だから、ウォーターフォールについても勉強したいと考えていたのでとてもよい機会になりました。
株式会社ジャムズを経営されている玉牧 陽一さんのご講演のポイントをまとめます。 詳細については下記リンクをぜひご覧ください。
https://www.slideshare.net/yoichitamamaki/ss-14456822
## ウォーターフォールの原点に関わる流れ
- **1970年** [Managing the Development of Software Systems](https://web.archive.org/web/20100712085706/http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf) via Winston Royce
ウォーターフォールの本質が書かれている論文
- **1985年** 米国防総省の規格書「[DOD-STD-2167](http://en.wikipedia.org/wiki/DOD-STD-2167A)」★
Royceの論文を参考に米国防総省がPRJの進め方をまとめた規格書- これがウォーターフォールの原点と言われている- この中では手戻りは絶対だめ！！と述べている ⇒追記：手戻りがだめと明記されたのは1988年発表の2167A版（原田さんありがとうございます）- 1995年のレポートで、「この方法によるPRJの約75%が失敗もしくはうまく適用できずに終わっている」と報告されている（※参照）
- **1994年** 上記の改訂版「**[MIL-STG-498](http://en.wikipedia.org/wiki/MIL-STD-498)」**
繰り返し型開発
- **2010年** CMU/SEI「**Considerations for Using Agile in DoD Acquisition」**
アジャイルを用いた調達やこれからの導入を促す趣旨のレポート
## ウォーターフォールの本質となった論文の概論
- 1970年 [Managing the Development of Software Systems](https://web.archive.org/web/20100712085706/http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf) via Winston Royce
- 一番シンプルな開発モデル
- 小規模で自らが利用するソフトウェア開発には十分かつ合理的
- しかし大規模なシステム開発ではうまくいかない
- 実際のPRJでは追加工程が要求される（管理コストによるオーバーヘッドなど）
- **一方通行でうまくいくわけがない**
- **手戻りは存在する**があくまで想定内（1つ手前の工程まで）におさめる
- **顧客を巻き込むことの大切さ**
- ソフトウェア開発はシンプルなモデルのような簡単なものではない
**要点まとめ：**
1970年の論文だが今でも多く使われているウォーターフォールの本質が述べられている。ウォーターフォールでは手戻りは絶対だめという風潮があるが、これはウォーターフォールの原点となった「[DOD-STD-2167](http://en.wikipedia.org/wiki/DOD-STD-2167A)」で手戻りはあってはいけないものとされているからである。しかし、Royceの論文では**手戻りがあることを前提**としていて、その手戻りを想定内におさめることが大事だ述べている。当然この論文がそのまま開発に活かせるものではないが、それまで体系的にPRJの進め方をまとめられていなかった中で初の取り組みであった。
## ウォーターフォールとアジャイル
- 問題解決 ＝ 要求、アウトプット
- 問題解決における前提的 ＝ PRJの外で決めるものでPRJの中ではStatic
- 問題解決における前提的 ＝ PRJの外で決めるものでPRJの中ではStatic
- 解決手段 ＝ 要求を満たすための方法
- 解決手段における前提的 ＝ 良い方法は既存でそこに近づける
- 解決手段における前提的 ＝ PRJの中で決めて行く
**ウォーターフォールが難しい点**
- 初期の要求がなかなか**確定しない**場合
- 後の工程になって要求が**変更**になる場合
- 事前に**予見しきれない技術的課題**
- リスク管理とその運用の難しさ
- コミュニケーションの質の悪化
- **官僚的な追加作業**
**アジャイルとウォーターフォールの使い分け**
**要点まとめ：**
アジャイルとウォーターフォールはそれぞれに前提条件・向き／不向きが異なる。そのため、現状やプロジェクトの特性を正しく理解して適正をみる必要がある。
一般的にアジャイルとウォーターフォールの併用はよしとされないことが多いが、先攻してアジャイルで開発をはじめて仕様や設計が固まった時点でウォーターフォールにする併用の形の成功例もある。
どちらがいい／悪いではなく、概念やプロセスを理解してそれを活かせるように**現場現場で適用して行くこと**が重要である。
**我々の仕事（ソフトウェア開発もアジャイル開発もウォーターフォールも）はそんなに簡単なものではない**。
## スパイラルとアジャイルの違い
- スパイラルとは小さなウォーターフォールの連続
- スパイラル→渦を描きながら最終的には真ん中に収束して行くイメージ
- アジャイル→ぐるぐるまわりながら中心ですら適切な場所に移動していくイメージ
- 収束を前提とするかしないかの違い
## まとめ
今回の勉強会を通して感じたことは、
>
>
> "WF（[ウォーターフォール](http://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB)）と[Agile](http://d.hatena.ne.jp/keyword/Agile)"とか"WFとWFでないもの"っていうよりも、なんでもないもの大半で一部のWFと[Agile](http://d.hatena.ne.jp/keyword/Agile)って感じのイメージ。 — takao.oyobeさん (@TAKAKING22) [9月 25, 2012](https://twitter.com/TAKAKING22/status/250555500150784001)
>
>
>
>
> やっぱり神懸かり的な[ウォーターフォール](http://d.hatena.ne.jp/keyword/%A5%A6%A5%A9%A1%BC%A5%BF%A1%BC%A5%D5%A5%A9%A1%BC%A5%EB)による成功体験は、プロジェクトマネジメント視点ではしてやったりな気がするなー — takao.oyobeさん (@TAKAKING22) [9月 25, 2012](https://twitter.com/TAKAKING22/status/250555824236290049)
>
>
です。 少しこのあたりの話になると盲信的に、 「アジャイル最高！」 「ウォーターフォールはだめだ！」 「ウォーターフォールでないとだめだ！」 となってしまっているケースをよく見ます。 しかし、アジャイルもウォーターフォールもあくまで目的を達成するための選択肢に過ぎず、どちらがいい／悪いという議論は無意味な気がしています。 それよりも、
- **自分たち（プロジェクト、チーム、環境、状況）を理解して、今何が必要なのかを見極められるようになること**
- **それによって結果を出すこと**
こそが重要であることを忘れてはいけません。
・・・という前提で、きちんとウォーターフォールできる状況を考えてみると、
- ゴールが明確であること
- 状況／環境がコントラブルであること
- プロダクトがコントラブルであること
- 要求の出し手／プロダクトの作り手が機能できること
- 関係者のコミュニケーションが良好であること
- 上記全てがPRJの終了まで継続すること
これらの条件が必要かなと思います。 **うーん難易度が高い！！** **でも一度はキレイに滝を滑り降りたい！！** なんて野望を胸に抱きました。