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