なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い
•
25 likes•9,450 views
「なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い」の説明資料 http://agileucdja.doorkeeper.jp/events/1736 当日の話のビデオをyoutubeに上げて頂きました。 ウォーターフォールが何だったのかを消化しきれなくて先に進めない方や,そういう人に納得しもらう説明が必要がある方のお役にたてれば幸いです。 (1/4) http://youtu.be/uueTeig6QoI (2/4) http://youtu.be/6upGG7xpQyw (3/4) http://youtu.be/46SwtfOAWqs (4/4) http://youtu.be/tisy_98A434
なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い
- 1. なぜアジャイルなのですか？ 改めて考察するウォーターフォールとの違い 2012年9月25日 株式会社ジャムズ 玉牧陽一 @Jamzz
- 2. Ⅰ.ウォーターフォール開発 2
- 3. １．ウォーターフォール開発 歴史的背景と現状 • 1970年発表「Managing the Development of Large Software Systems」by Winston Royce • 米国防総省の規格書「DOD-STD-2167」 （1985年6月） • 米国防総省「MIL-STD-498」（ 1994年12 月） • CMU/SEI「Considerations for Using Agile in DoD Acquisition 」（2010 年4月） 3
- 4. ２．ウォーターフォール開発 W.W.Royceの論文から • 最もシンプルなプロセス – 基本的なステップ ANALYSIS CODING 4
- 5. ２．ウォーターフォール開発 W.W.Royceの論文から • ANALYSIS – どんなものを作るのかを決める – ドメイン分析 • CODING – ソフトウェアを実装し、設計者の意図通り機 能することを確認する – 実装 – デバッグ 5
- 6. ２．ウォーターフォール開発 W.W.Royceの論文から • 小規模で自らが利用する様なソフトウェ ア開発には十分かつ合理的 – すべての工程が最終成果に直接かかわる内容 である – オーバーヘッドとなるコストや時間は発生し ない しかし、、、 6
- 7. ２．ウォーターフォール開発 W.W.Royceの論文から • 大規模なシステム開発ではうまくゆかな い • 直接的には最終成果に関わらない追加的 な工程が要求される – 管理のオーバーヘッド（コスト、納期）が必 要 – さもなければ失敗する 7
- 8. ２．ウォーターフォール開発 W.W.Royceの論文から • 壮大なプロセス SYSTEM REQUIREMENTS SOFTWARE REQUIREMENTS ANALYSIS PROGRAM DESIGN CODING TESTING OPERATIONS 8
- 9. ２．ウォーターフォール開発 W.W.Royceの論文から • SYSTEM REQUIREMENTS – システム要件を定義する – ソフトウェアだけでなく人間系を含む業務な どの全体をシステムとして考える 9
- 10. ２．ウォーターフォール開発 W.W.Royceの論文から • SOFTWARE REQUIREMENTS – ソフトウェア要件を定義する – 開発対象となるソフトウェアについて考える • 機能要件 • 性能要件 • 品質要件 10
- 11. ２．ウォーターフォール開発 W.W.Royceの論文から • PROGRAM DESIGN – ソフトウェア実装設計 – ドメイン分析結果に基づいて実装レベルの設 計を行う • 構造設計 • 実装モデル 11
- 12. ２．ウォーターフォール開発 W.W.Royceの論文から • TESTING – テスト – 要件を満たしているか確認する – 運用上問題がないか検証する 12
- 13. ２．ウォーターフォール開発 W.W.Royceの論文から • OPERATIONS – フィールド運用 – ソフトウェアのリリースと導入を含む – 運用マニュアルなどの設計を含む 13
- 14. ２．ウォーターフォール開発 W.W.Royceの論文から • 望ましい工程の反復 SYSTEM REQUIREMENTS SOFTWARE REQUIREMENTS ANALYSIS PROGRAM DESIGN CODING TESTING OPERATIONS 14
- 15. ２．ウォーターフォール開発 W.W.Royceの論文から – 下流工程で上流工程における問題が発見され た場合には該当する工程に戻って再検討を行 う – 連続する工程間の反復により成果物は洗練さ れる • これはより良い成果のために意図している 15
- 16. ２．ウォーターフォール開発 W.W.Royceの論文から • このコンセプトにおける最大のリスク – 工程の反復が局所に限定されない場合 SYSTEM REQUIREMENTS SOFTWARE REQUIREMENTS ANALYSIS PROGRAM DESIGN CODING TESTING 16
- 17. ２．ウォーターフォール開発 W.W.Royceの論文から • 最後の工程であるテストで問題が現実の ものとなる – 分析、設計工程における机上の検証には限界 がある – 問題が制約や前提条件に関わる場合には仕様 変更が必要になり、納期やコストの予定超過 は免れなくなる 17
- 18. ２．ウォーターフォール開発 W.W.Royceの論文から • リスクを限定するために必要となる５つ のステップ – STEP 1 : PROGRAM DESIGN COMES FIRST – STEP 2 : DOCUMENT THE DESIGN – STEP 3 : DO IT TWICE – STEP 4 : PLAN, CONTROL AND MONITOR TESTING – STEP 5 : INVOLVE THE CUSTOMER 18
- 19. ２．ウォーターフォール開発 W.W.Royceの論文から • STEP 1 : PROGRAM DESIGN COMES FIRST – 上流設計工程の追加 SYSTEM REQUIREMENTS SOFTWARE REQUIREMENTS PRELIMINARY PROGRAM DESIGN ANALYSIS PROGRAM DESIGN CODING TESTING OPERATIONS 19
- 20. ２．ウォーターフォール開発 W.W.Royceの論文から • PRELIMINARY PROGRAM DESIGN – アーキテクチャ設計 • DOCUMENT SYSTEM OVERVIEW • DESIGN DATA BASE AND PROCESSORS • ALLOCATE SUBROUTINE STORAGE • ALLOCATE SUBROUTINE EXECUTION TIME • DESCRIBE OPERATING PROCEDURES 20
- 21. ２．ウォーターフォール開発 W.W.Royceの論文から • STEP 2 : DOCUMENT THE DESIGN – 仕掛の見える化 • 進捗の見える化 – コミュニケーションの媒体 • 工程間の引継ぎ • 保守を含むチーム間の引継ぎ • マニュアルなど運用への引継ぎ – 品質の見える化 • 実現する要件とその検証結果 21
- 22. ２．ウォーターフォール開発 W.W.Royceの論文から – 規模に応じて相当多くのドキュメントが必要 • 規模が小さかったり内部使用目的の場合にはそれ ほど多くなくても良い – ドキュメントの種類 • NO.1 : SOFTWARE REQUIREMENTS • NO.2 : PRELIMINARY DESIGN • NO.3 : INTERFACE DESIGN • NO.4 : FINAL DESIGN • NO.5 : TEST PLAN and RESULTS • NO.6 : OPERATING INSTRUCTIONS 22
- 23. ２．ウォーターフォール開発 W.W.Royceの論文から • STEP 3 : DO IT TWICE – 開発工程を２度行う – PRELIMINARY PROGRAM DESIGN工程でプロトタ イピングを行う – 経験をフィードフォワードする 23
- 24. ２．ウォーターフォール開発 W.W.Royceの論文から • STEP 4 : PLAN, CONTROL AND MONITOR TESTING – プロジェクトの中で最も多くのリソースを消 費し、かつ、最後であるために最大のリスク となるのがテスト工程 24
- 25. ２．ウォーターフォール開発 W.W.Royceの論文から – テストを計画し、状況を把握し、品質をコン トロールする • ドキュメントに基づいてテストスペシャリストが 実施する • 単純なミスの検出にはテストは不経済 – レビューが効果的 • テストのカバレッジは１００％を目指すべき • 受入検査をどのタイミングで誰が実施するのかが マネージメント重要な判断である 25
- 26. ２．ウォーターフォール開発 W.W.Royceの論文から • STEP 5 : INVOLVE THE CUSTOMER – 事前に合意があったとしても設計が進むにつ れて様々な解釈が行われるものである – リリース前の早い時点に公式で承認を得た形 で顧客を巻き込むことが重要 – 要求や運用に関して請け負った側が勝手に定 義することは問題を招く 26
- 27. ２．ウォーターフォール開発 W.W.Royceの論文から • 顧客によるレビューと承認のポイント – PSR : PRELIMINARY SOFTWARE REVIEW • アーキテクチャ設計レビュー – 顧客にはアーキテクチャ評価は難しい – せいぜいドメイン分析結果のレビュー – CSR : CRITICAL SOFTWARE REVIEW • 実装設計レビュー – 顧客には実装設計レビューは難しい – FSAR : FINAL SOFTWARE ACCEPTANCE REVIEW • 受け取り検査 27
- 28. ２．ウォーターフォール開発 W.W.Royceの論文から • 結局Winston Royceが言いたかったこと – 大規模ソフトウェア開発特有の課題 – 管理強化を目的とする工程の追加と細分化 – 管理のためのオーバーヘッドを担保する追加 のコストと時間の必要性 • 管理コストと時間を過小評価して失敗し た場合に損害が甚大なものとなること 28
- 29. ３．ウォーターフォール開発 誤解と偏見 • 上流工程への逆流は何としてでも避けな ければならない – 前後の工程での反復を想定しており、成果物 の洗練のためには必要だと考えられていた – 工程を飛び越える逆流のリスクは指摘されて おり、このリスクを限定するための手法が提 案されている 29
- 30. ３．ウォーターフォール開発 誤解と偏見 • 生産性や品質を向上させるためのもので ある – 失敗による損害のリスクを限定するためのも のである – リスクに対してコストや時間の追加の必要性 を具体化したものである 30
- 31. ３．ウォーターフォール開発 誤解と偏見 • 極めて官僚的なプロセスである – ウォーターフォールはそもそも大規模開発の リスク対策でありリスクを無視するような官 僚的な実践は意図しない – 誰が、なぜ官僚的なプロセスを望むのか？ 31
- 32. ４．なぜウォーターフォール開発に対する 支持は根強いのか • 建設、インフラ開発のアナロジー • 生産工程のアナロジー – コンベア方式 – 供給主導の大量生産のモデル • 成功体験 – それまで有効なプロセスがなかった – 初めてのプロセス導入であった 32
- 33. ４．なぜウォーターフォール開発に対する 支持は根強いのか • 水の流れのメタファ – 必ずいつかはゴールへ辿り着くという安心感 がある – このメタファは心理的に強力 33
- 34. Ⅱ.ウォーターフォール開発とアジャ イル開発 34
- 35. １．パラダイムとコンテキスト ウォーター スパイラル CCPM かんばん アジャイル フォール 問題領域 前提的 前提的 前提的 前提的 発見的 解決手段 前提的 前提的 発見的 発見的 発見的 問題・解決 PUSH型 PUSH型 PUSH型 PULL型 PULL型 の主体 トップダウン トップダウン トップダウン 現場主動 現場主動 ステップ、 工程、 バックログ、 バックログ、 マネージメ 工程、進捗 反復型 バッファー 見える化 タイムボックス ント マネージメント マネージメント マネージメント マネージメント マネージメント 35
- 36. ２．ウォーターフォール開発とアジャイル 開発の比較 ウォーターフォール アジャイル 管理対象 「作業」の分割統治 「成果」の分割統治 管理サイクル マイルストーン タイムボックス 工程表 バックログ 進捗管理 消化率 バーンダウン プロジェクトをコント 環境、条件を調整してメンバ PMの役割 ロール の活動を支援 事前に要求の範囲とレベ 都度状況に応じて要求の優先 顧客の役割 ルを明確にし、成果物を 順位を明確にし、その達成を 確認 確認 36
- 37. ３．ウォーターフォール開発のポイント 利点 • 実績、経験が豊富である • 工程管理の知見が活用できる • ドキュメントにより情報を形式知として 時空を超えて共有することを可能にする • 専門性による作業の効率化 37
- 38. ３．ウォーターフォール開発のポイント 難点 • 初期の要求がなかなか確定しない場合 • 後の工程になって要求が変更になる場合 • 事前に予見しきれない技術課題 • リスク管理とその運用の難しさ • コミュニケーションの質の悪化 • 官僚的な追加作業 38
- 39. ３．ウォーターフォール開発のポイント 典型的な失敗 • 要件定義、プロジェクト計画が終わらな い • 工程管理の無駄 – 予見的であるために「念のため」が積み重な る傾向がある • 使われないシステム – 当初の思惑と実際が異なる場合 – 長期開発では開発中に前提条件が変わる場合 がある 39
- 40. ４．アジャイル開発のポイント 利点 • 現場状況のリアルタイムな把握 • 打ち手の迅速な反映 • ベストエフォートで合理的な成果 • 主体性重視とモチベーション • 情報共有、コミュニケーションの質的充 実 40
- 41. ４．アジャイル開発のポイント 難点 • 委託業務上の課題 – 下請法 – 契約 • 品質保証基準の確立 – 品質基準の定義が統計的手法による場合には やり方が変わることにより指標の継続性が維 持できない 41
- 42. ４．アジャイル開発のポイント 難点 • パラダイムシフトに対応する意識の変化 – 受身から主体へ – 作業から成果へ – 個人主義からチームワークへ 42
- 43. ４．アジャイル開発のポイント 典型的な失敗 • やりっぱなし – バックログに「作業」を設定した場合に起こ る – 「成果」の妥当性評価と「ふりかえり」が重 要 43
- 44. ４．アジャイル開発のポイント 典型的な失敗 • 要求が定まらず、終わらない – 根本原因は要求として期待する「成果」の設 定とその優先順位づけにある – たとえ顧客の要望であったとしても達成感が 得られないプロジェクトはつらい – 主体的に顧客価値を考えた提案も重要 44
- 45. ５．ウォーターフォール開発とアジャイル 開発の使い分け • ウォーターフォール開発を適用する場合 – 経験豊富で予見性が高い場合 – 再現性の高い作業の集約で計画できる場合 – 大量な単純作業で労働集約的な場合 45
- 46. ５．ウォーターフォール開発とアジャイル 開発の使い分け • アジャイル開発を適用する場合 – 小規模、少人数の場合 – 不確定要素が多く予見性が低い場合 – リスクが高く従来のやり方が通用しないこと が明らかな場合 – 継続的に保守、拡張するシステムの場合 – チームメンバの知識や経験を持ち寄って探索 的な試行錯誤が必要な場合 46
- 47. ５．ウォーターフォール開発とアジャイル 開発の使い分け • 組み合わせて適用する場合 – アジャイル先行型 • 技術課題や曖昧な要求などの不確定要素について アジャイルチームが先行する • 課題や要求が具体的になったところから計画を立 ててウォーターフォールチームにより実現する 47
- 48. ５．ウォーターフォール開発とアジャイル 開発の使い分け – コンカレント型 • 大規模システム開発などにおいて、各チームの同 期が必要となるタイミングとなるマイルストーン を基準とするマスター計画を作成する • 各チームはマイルストーンをターゲットとしてそ れぞれの状況に応じてウォーターフォール、ア ジャイルを使い分ける – タスクフォース型 • 共通、フレームワーク、基幹部分など、調整要素 の大きい特定のミッションをアジャイルチームに する 48
- 49. Ⅲ.最後に 49
- 50. ３．まとめ • 良くわからないけどとにかくうまくいけ ば良いというのは当て物で学習効果が期 待できない • 自分にとっての解決するべき問題やその 前提条件を具体的に認知できれば対策は 見えてくるはず 50
- 51. ３．まとめ • 個人的には、やっぱり自分の基本のスタ イルはアジャイル – 最近になって積読になっていた「ライト、つ いてますか―問題発見の人間学」を読んだ – 真に受けると途方に暮れそうに思った – 教訓として考えても、やはり問題発見は永遠 に尽きないことを再認識した • とは言えとにかく状況に応じて結果を出 すことに集中する様に心がける 51
- 52. ご清聴、ありがとうございました。 52