狠狠撸

なぜアジャイルなのですか？
改めて考察するウォーターフォールとの違い

2012年9月25日
株式会社ジャムズ
玉牧陽一
@Jamzz

Ⅰ.ウォーターフォール开発

2

１．ウォーターフォール开発
歴史的背景と現状

? 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

２．ウォーターフォール开発
W.W.Royceの論文から

? 最もシンプルなプロセス
– 基本的なステップ

ANALYSIS

CODING

4


? ANALYSIS
– どんなものを作るのかを決める
– ドメイン分析
? CODING
– ソフトウェアを実装し、設計者の意図通り機
能することを確認する
– 実装
– デバッグ

5


? 小規模で自らが利用する様なソフトウェ
ア開発には十分かつ合理的
– すべての工程が最終成果に直接かかわる内容
である
– オーバーヘッドとなるコストや時間は発生し
ない
しかし、、、

6


? 大規模なシステム開発ではうまくゆかな
い
? 直接的には最終成果に関わらない追加的
な工程が要求される
– 管理のオーバーヘッド（コスト、納期）が必
要
– さもなければ失敗する

7


? 壮大なプロセス
SYSTEM
REQUIREMENTS

SOFTWARE
REQUIREMENTS

ANALYSIS

PROGRAM
DESIGN

CODING

TESTING

OPERATIONS

8


? SYSTEM REQUIREMENTS
– システム要件を定義する
– ソフトウェアだけでなく人間系を含む業務な
どの全体をシステムとして考える

9


? SOFTWARE REQUIREMENTS
– ソフトウェア要件を定義する
– 開発対象となるソフトウェアについて考える
? 機能要件
? 性能要件
? 品質要件

10


? PROGRAM DESIGN
– ソフトウェア実装設計
– ドメイン分析結果に基づいて実装レベルの設
計を行う
? 構造設計
? 実装モデル

11


? TESTING
– テスト
– 要件を満たしているか確認する
– 運用上問題がないか検証する

12


? OPERATIONS
– フィールド運用
– ソフトウェアのリリースと導入を含む
– 運用マニュアルなどの設計を含む

13


? 望ましい工程の反復
SYSTEM
REQUIREMENTS

SOFTWARE
REQUIREMENTS

ANALYSIS

PROGRAM
DESIGN

CODING

TESTING

OPERATIONS

14


– 下流工程で上流工程における問題が発見され
た場合には該当する工程に戻って再検討を行
う
– 連続する工程間の反復により成果物は洗練さ
れる
? これはより良い成果のために意図している

15


? このコンセプトにおける最大のリスク
– 工程の反復が局所に限定されない場合
SYSTEM
REQUIREMENTS

SOFTWARE
REQUIREMENTS

ANALYSIS

PROGRAM
DESIGN

CODING

TESTING

16


? 最後の工程であるテストで問題が現実の
ものとなる
– 分析、設計工程における机上の検証には限界
がある
– 問題が制約や前提条件に関わる場合には仕様
変更が必要になり、納期やコストの予定超過
は免れなくなる

17


? リスクを限定するために必要となる５つ
のステップ
– 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


? STEP 1 : PROGRAM DESIGN COMES FIRST
– 上流設計工程の追加
SYSTEM
REQUIREMENTS
SOFTWARE
REQUIREMENTS

PRELIMINARY
PROGRAM
DESIGN

ANALYSIS

PROGRAM
DESIGN

CODING

TESTING

OPERATIONS

19


? PRELIMINARY PROGRAM DESIGN
– アーキテクチャ設計
? DOCUMENT SYSTEM OVERVIEW
? DESIGN DATA BASE AND PROCESSORS
? ALLOCATE SUBROUTINE STORAGE
? ALLOCATE SUBROUTINE EXECUTION TIME
? DESCRIBE OPERATING PROCEDURES

20


? STEP 2 : DOCUMENT THE DESIGN
– 仕掛の見える化
? 進捗の見える化
– コミュニケーションの媒体
? 工程間の引継ぎ
? 保守を含むチーム間の引継ぎ
? マニュアルなど運用への引継ぎ
– 品質の見える化
? 実現する要件とその検証結果

21


– 規模に応じて相当多くのドキュメントが必要
? 規模が小さかったり内部使用目的の場合にはそれ
ほど多くなくても良い
– ドキュメントの種類
? 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


? STEP 3 : DO IT TWICE
– 開発工程を２度行う
– PRELIMINARY PROGRAM DESIGN工程でプロトタ
イピングを行う
– 経験をフィードフォワードする

23


? STEP 4 : PLAN, CONTROL AND MONITOR
TESTING
– プロジェクトの中で最も多くのリソースを消
費し、かつ、最後であるために最大のリスク
となるのがテスト工程

24


– テストを計画し、状況を把握し、品質をコン
トロールする
? ドキュメントに基づいてテストスペシャリストが
実施する
? 単純なミスの検出にはテストは不経済
– レビューが効果的
? テストのカバレッジは１００％を目指すべき
? 受入検査をどのタイミングで誰が実施するのかが
マネージメント重要な判断である

25


? STEP 5 : INVOLVE THE CUSTOMER
– 事前に合意があったとしても設計が進むにつ
れて様々な解釈が行われるものである
– リリース前の早い時点に公式で承認を得た形
で顧客を巻き込むことが重要
– 要求や運用に関して請け負った側が勝手に定
義することは問題を招く

26


? 顧客によるレビューと承認のポイント
– PSR : PRELIMINARY SOFTWARE REVIEW
? アーキテクチャ設計レビュー
– 顧客にはアーキテクチャ評価は難しい
– せいぜいドメイン分析結果のレビュー
– CSR : CRITICAL SOFTWARE REVIEW
? 実装設計レビュー
– 顧客には実装設計レビューは難しい
– FSAR : FINAL SOFTWARE ACCEPTANCE REVIEW
? 受け取り検査
27


? 結局Winston Royceが言いたかったこと
– 大規模ソフトウェア開発特有の課題
– 管理強化を目的とする工程の追加と細分化
– 管理のためのオーバーヘッドを担保する追加
のコストと時間の必要性
? 管理コストと時間を過小評価して失敗し
た場合に損害が甚大なものとなること

28

３．ウォーターフォール開発
誤解と偏見

? 上流工程への逆流は何としてでも避けな
ければならない
– 前後の工程での反復を想定しており、成果物
の洗練のためには必要だと考えられていた
– 工程を飛び越える逆流のリスクは指摘されて
おり、このリスクを限定するための手法が提
案されている

29

誤解と偏見

? 生産性や品質を向上させるためのもので
ある
– 失敗による損害のリスクを限定するためのも
のである
– リスクに対してコストや時間の追加の必要性
を具体化したものである

30

誤解と偏見

? 極めて官僚的なプロセスである
– ウォーターフォールはそもそも大規模開発の
リスク対策でありリスクを無視するような官
僚的な実践は意図しない
– 誰が、なぜ官僚的なプロセスを望むのか？

31

４．なぜウォーターフォール開発に対する
支持は根強いのか

? 建設、インフラ開発のアナロジー
? 生産工程のアナロジー
– コンベア方式
– 供給主導の大量生産のモデル
? 成功体験
– それまで有効なプロセスがなかった
– 初めてのプロセス導入であった

32

４．なぜウォーターフォール開発に対する
支持は根強いのか

? 水の流れのメタファ
– 必ずいつかはゴールへ辿り着くという安心感
がある
– このメタファは心理的に強力

33

Ⅱ.ウォーターフォール開発とアジャ
イル開発

34

１．パラダイムとコンテキスト

ウォーター
スパイラル CCPM かんばんアジャイル
フォール

問題領域前提的前提的前提的前提的発見的

解決手段前提的前提的発見的発見的発見的

問題?解決 PUSH型 PUSH型 PUSH型 PULL型 PULL型
の主体トップダウントップダウントップダウン現場主動現場主動

ステップ、工程、バックログ、バックログ、
マネージメ工程、進捗
反復型バッファー見える化タイムボックス
ントマネージメント
マネージメントマネージメントマネージメントマネージメント

35

２．ウォーターフォール开発とアジャイル
開発の比較

ウォーターフォールアジャイル

管理対象「作業」の分割統治「成果」の分割統治

管理サイクルマイルストーンタイムボックス

工程表バックログ
進捗管理消化率バーンダウン

プロジェクトをコント環境、条件を調整してメンバ
PMの役割ロールの活動を支援

事前に要求の範囲とレベ都度状況に応じて要求の優先
顧客の役割ルを明確にし、成果物を順位を明確にし、その達成を
確認確認

36

３．ウォーターフォール開発のポイント
利点

? 実績、経験が豊富である
? 工程管理の知見が活用できる
? ドキュメントにより情報を形式知として
時空を超えて共有することを可能にする
? 専門性による作業の効率化

37

難点

? 初期の要求がなかなか確定しない場合
? 後の工程になって要求が変更になる場合
? 事前に予見しきれない技術課題
? リスク管理とその運用の難しさ
? コミュニケーションの質の悪化
? 官僚的な追加作業

38

典型的な失敗

? 要件定義、プロジェクト計画が終わらな
い
? 工程管理の無駄
– 予見的であるために「念のため」が積み重な
る傾向がある
? 使われないシステム
– 当初の思惑と実際が異なる場合
– 長期開発では開発中に前提条件が変わる場合
がある
39

４．アジャイル开発のポイント
利点

? 現場状況のリアルタイムな把握
? 打ち手の迅速な反映
? ベストエフォートで合理的な成果
? 主体性重視とモチベーション
? 情報共有、コミュニケーションの質的充
実

40

難点

? 委託業務上の課題
– 下請法
– 契約
? 品質保証基準の確立
– 品質基準の定義が統計的手法による場合には
やり方が変わることにより指標の継続性が維
持できない

41

難点

? パラダイムシフトに対応する意識の変化
– 受身から主体へ
– 作業から成果へ
– 個人主義からチームワークへ

42

典型的な失敗

? やりっぱなし
– バックログに「作業」を設定した場合に起こ
る
– 「成果」の妥当性評価と「ふりかえり」が重
要

43

典型的な失敗

? 要求が定まらず、終わらない
– 根本原因は要求として期待する「成果」の設
定とその優先順位づけにある
– たとえ顧客の要望であったとしても達成感が
得られないプロジェクトはつらい
– 主体的に顧客価値を考えた提案も重要

44

５．ウォーターフォール開発とアジャイル
開発の使い分け

? ウォーターフォール開発を適用する場合
– 経験豊富で予見性が高い場合
– 再現性の高い作業の集約で計画できる場合
– 大量な単純作業で労働集約的な場合

45


? アジャイル開発を適用する場合
– 小規模、少人数の場合
– 不確定要素が多く予見性が低い場合
– リスクが高く従来のやり方が通用しないこと
が明らかな場合
– 継続的に保守、拡張するシステムの場合
– チームメンバの知識や経験を持ち寄って探索
的な試行錯誤が必要な場合

46


? 組み合わせて適用する場合
– アジャイル先行型
? 技術課題や曖昧な要求などの不確定要素について
アジャイルチームが先行する
? 課題や要求が具体的になったところから計画を立
ててウォーターフォールチームにより実現する

47


– コンカレント型
? 大規模システム開発などにおいて、各チームの同
期が必要となるタイミングとなるマイルストーン
を基準とするマスター計画を作成する
? 各チームはマイルストーンをターゲットとしてそ
れぞれの状況に応じてウォーターフォール、ア
ジャイルを使い分ける
– タスクフォース型
? 共通、フレームワーク、基幹部分など、調整要素
の大きい特定のミッションをアジャイルチームに
する
48

３．まとめ

? 良くわからないけどとにかくうまくいけ
ば良いというのは当て物で学習効果が期
待できない
? 自分にとっての解決するべき問題やその
前提条件を具体的に認知できれば対策は
見えてくるはず

50

３．まとめ

? 個人的には、やっぱり自分の基本のスタ
イルはアジャイル
– 最近になって積読になっていた「ライト、つ
いてますか―問題発見の人間学」を読んだ
– 真に受けると途方に暮れそうに思った
– 教訓として考えても、やはり問題発見は永遠
に尽きないことを再認識した
? とは言えとにかく状況に応じて結果を出
すことに集中する様に心がける
51

ご清聴、ありがとうございました。

52

狠狠撸

なぜアジャイルなのですか？改めて考察するウォーターフォールとの违い

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to なぜアジャイルなのですか？改めて考察するウォーターフォールとの违い (20)

Recently uploaded (11)

なぜアジャイルなのですか？改めて考察するウォーターフォールとの违い