The Software Project Manager's Bridge to Agility 読書会

1. THE SOFTWARE PROJECT MANAGER’S
BRIDGE TO AGILITY 読書会 #1
株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO

2. #0 アジェンダ
• 簡単な自己紹介（1人2分以内で） - 参加者全員
• 読書会の進め方（資料のみ）
• 書籍紹介（資料のみ）
• 前回のサマリー
• 書籍 Chapter1 ∼ What is “Agile”?
• フィードバック & 次回設定

3. 協賛
• PMI日本支部様
• 会場をお貸し頂きました！ありがとうございます。

4. 自己紹介
• 現役PMの方）どんな分野のプロジェクト？
• アジャイルやってますか？
• PMBOK知っていますか？
• 英語大好き？
15min

5. 読書会のゴール
• 従来のProject Management と Agile Project Managementの違いを考える
• PMBOK / Agile プロジェクトの語彙が学べる
• （数少ない）プロジェクトマネージャーの輪を広げる
• インタラクティブな読書会に! - 全員参加型
• なんか大きい目標が欲しいですね

6. 読書会の進め方
• インタラクティブに
• 書籍の内容に沿った全員参加型グループ・ワーク
• 書籍の内容の紹介だけではなく、「考える」形で
• 書籍を読むのに助けが必要。そんなときは
• Facebook / Twitter

7. 書籍紹介
Waterfallにかける橋・・・

8. 著者（画像は、http://www.sligerconsulting.com/ より）
Michele Sliger
PMP,PMI-ACP, CST
Stacia Viscardi
PMP, CST

9. • Part I : An Agile Overview
• アジャイルの説明 / PMBOKの説明 / Agile Project lifecycle
• Part II : The Bridge: Relating PMBOK Guide Practices to Agile Practices
• PMBOKのプラクティス（知識エリア）とAgileプラクティスの対比
• Part III : Crossing the Bridge to Agile
• Q & A 集
書籍の構成

10. 前回 - 書籍のコンセプトについて考える
Traditional PM と Agile PMの違い

11. Traditional PM vs Agile PM

12. Traditional PM vs Agile PM
• Traditional PM
1. 計画重視
2. 工数見積
3. 進捗・品質レビュー
4. 人月単価・外注
5. 失敗が許されにくい
6. ステークホルダー管理
7. チームビルディング
• Agile PM
1. 柔軟・自由度が高い
2. 成果に価値
3. （該当なし）
4. 稟議通らなそう
5. 変更を受け入れる
6. チームへの貢献
7. 自主的、自律的
A. 良好な人間関係
B. 見える化
E. タイムボックス

13. #1 - Part I An Agile Overview : What is “Agile”?

14. Agile PMとダーウィン
• Traditional PMからAgile PMへの変化は、ビーグル号航海のようなもの
• 信条の揺らぎ
• 未知の探索
• 発見のプロセス
• 予想できない結果
• 新しい発見をどうしたらいいのか、既存のやり方とどう折り合いを付けるか

15. 新しい考え方への切替は容易ではない
• 常識、固定概念を捨て去ることは難しい
• 種の起源（1859）の公開が、ビーグル号航海（1836）のはるか後
• 進化論は相当の反発・議論を巻き起こした
• ダーウィンの死語125年以上にわたって、人類に影響を与えている
• Agileプロセスも、既存のソフトウェア開発のやり方とも、ビジネスのやり方
とも異なる
• → めげるなってことだと思います

16. Agileの歴史 ∼ ソフトウェア開発
• 1950年代 : DoD / NASA IID(Iterative and incremental development)
• 1960年代：Evo (Evolutionary project management) by Thomas Gilb
• 1970年代： Managing the Development of Large Software Systems
• Waterfallアプローチが初めて世に出た論文
• Waterfallはうまくいかない。7/9ページがWaterfallモデルの改善に費やされ
ている
• イテレーション開発は新しい概念ではない！！

17. Agileの歴史 ∼ ビジネスプロセスから
• 1986: The New New Product Development Game : 竹内、野中
• Dedicated
• Cross-Functional
• Self-Organizing
• Lean Product Development (TPS)
• eliminating waste through continuous improvement
• producing only what was requested by the customer

18. Agileの歴史 ∼ マネジメントスタイルから
• 1920年代：マネジメントの分離：ブルーカラーとホワイトカラー
（Frederick Taylor）
• 1960年代：「知識労働者」の出現 （Peter Drucker）
• 労働者は「ボランティア」へ ∼ 仕事に「意味」を見いだす

19. Agile Manifesto

20. Snowbird, Utah : 17のlightweight手法提唱者集合
Kent Bech XP
James Grenning
TDD
プランニングポーカー
Robert C. Martin XP
Mike Beedle Scrum
Jim Highsmith ASD, APM
Steve Mellor Executable UML
Arie van Bennekum DSDM
Andrew Hunt
The Pragmatic
Programmer
Ken Schwaber Scrum
Alistair Cockburn Crystal
Ron Jeffries XP
Jeff Sutherland Scrum
Ward Cunningham XP, CRC
Jon Kern FDD
Dave Thomas
The Pragmatic
Programmer
Martin Fowler XP, Refactoring
Brian Marick Agile Testing

21. http://agilemanifesto.org/iso/ja/ より引用。下線は筆者（関口）による

22. http://agilemanifesto.org/iso/ja/ より引用。

23. • アジャイルはドキュメント書かない
• 誤解！
• 書かないわけではなく、「価値を生まない活動はしない」
• 顧客価値があるドキュメントは、書く
• テストケース
• ハイレベル設計
• エンドユーザードキュメント
誤解！

24. Individuals and Interactions over Processes and
Tools
• 複雑なシステムは計画主導が難しい。Empirical Process Controlが必要。
• 複数の分野のエキスパートからなるチームと、顧客の共同作業
• 流れ作業とは異なる仕事のやり方
• アンチパターン
• ツールとプロセスの操り人形
• コミュニケーションをツールが代替できると思うのは間違い

25. Working software over comprehensive
documentation
• 進 率ではなく、動くソフトウェアとプロダクトレビューにする
• ソフトウェアは作っている最中にも仕様が変わるものである
• ドキュメントは書いてる側から陳腐化する
• Standish Groupの報告
• 60%の機能は使われていない
• 作るだけ無駄。その機能のドキュメントは更に無駄

26. Working software over comprehensive
documentation
• 「仕様書」を渡して仕事を頼むようなやり方では、優先すべき事柄や、着手
すべきポイントが分からない
• 無駄にドキュメントを作るだけではなく、無駄に作業をすることにもなって
しまう

27. Customer collaboration over Contract Negotiation
• 顧客の希望を全て記載し、支払いとスケジュールを確定する
• Fixed Price / Fixed Scope 型契約
• そもそもこれ、チームが決めてないからコミットがない
• 意味が無いと分かっていても、「契約だから」やらないといけない
• Target Cost契約 / 超過コストを顧客と折半
• Stage契約 / チェックポイント毎に go / no go を判断

28. Responding to change over following a plan
• 計画主導アプローチでは、ボトムアップでスケジュールとスコープが決まるの
で、タスクとスケジュールのコントロールが重要
• 誤解！： Agileは無計画
• 計画はAgileでも重要
• チームが計画を行うことで、コミットメントが生まれる
• Top down rolling wave アプローチである（後の章への布石）

29. Twelve Principles of Agile Software

30. Agile宣言の背後にある原則（１）
• 顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
• 要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
• 動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
• ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
http://agilemanifesto.org/iso/ja/principles.html より引用。

31. Agile宣言の背後にある原則（２）
• 意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
• 情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
• 動くソフトウェアこそが進 の最も重要な尺度です。
• アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
http://agilemanifesto.org/iso/ja/principles.html より引用。

32. Agile宣言の背後にある原則（３）
• 技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
• シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
• 最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
• チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
http://agilemanifesto.org/iso/ja/principles.html より引用。

33. Exercise - 水天宮サミット ∼
プロジェクトを成功させるためには

34. • 今までの経験から、プロジェクトを成功させるために重要な（できれば必須
な）プラクティス、メソッドを 3つ Post-itに書いて下さい
• それが終わったら、グルーピングして、Agile Principleとの比較をしてみま
す。
Exercise
5min 5min

35. • 先ほどのPost-it グループと、12 Principlesとの対応を付けます
• 理解しやすいPrinciple, 理解しにくい（考え方の転換が必要な）Principle はど
れでしょうか。
Exercise
5min 5min

36. 青で囲った部分がギャップの大きいところ

37. 次回 #2 - Chapter2 Mapping from the PMBOK
Guide to Agile

38. References
• Agile Manifesto, 12 Principles 日本語版
• http://agilemanifesto.org/iso/ja/manifesto.html
• Jon KernのAgile Manifestoの議論メモ
• http://jeffsutherland.com/AgileManifestoNotes2001.pdf