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