THE SOFTWARE PROJECT MANAGER’SBRIDGE TO AGILITY 読書会 #1

株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO

#0 アジェンダ

• 簡単な自己紹介（1人2分以内で） - 参加者全員

• 読書会の進め方（資料のみ）

• 書籍紹介（資料のみ）

• 前回のサマリー

• 書籍 Chapter1 ～ What is “Agile”?

• フィードバック & 次回設定

協賛

• PMI日本支部様

• 会場をお貸し頂きました！ありがとうございます。

自己紹介

• 現役PMの方）どんな分野のプロジェクト？

• アジャイルやってますか？

• PMBOK知っていますか？

• 英語大好き？

15min

読書会のゴール

• 従来のProject Management と Agile Project Managementの違いを考える

• PMBOK / Agile プロジェクトの語彙が学べる

• （数少ない）プロジェクトマネージャーの輪を広げる

• インタラクティブな読書会に! - 全員参加型

• なんか大きい目標が欲しいですね

読書会の進め方

• インタラクティブに

• 書籍の内容に沿った全員参加型グループ・ワーク

• 書籍の内容の紹介だけではなく、「考える」形で

• 書籍を読むのに助けが必要。そんなときは

• Facebook / Twitter

書籍紹介

Waterfallにかける橋・・・

著者（画像は、http://www.sligerconsulting.com/ より）

Michele SligerPMP,PMI-ACP, CST

Stacia ViscardiPMP, CST

• 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 集

書籍の構成

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

Traditional PM vs Agile PM

Traditional PM vs Agile PM• Traditional PM1. 計画重視2. 工数見積3. 進捗・品質レビュー4. 人月単価・外注5. 失敗が許されにくい6. ステークホルダー管理7. チームビルディング

• Agile PM1. 柔軟・自由度が高い2. 成果に価値3. （該当なし）4. 稟議通らなそう5. 変更を受け入れる6. チームへの貢献7. 自主的、自律的A. 良好な人間関係B. 見える化E. タイムボックス

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

Agile PMとダーウィン

• Traditional PMからAgile PMへの変化は、ビーグル号航海のようなもの

• 信条の揺らぎ

• 未知の探索

• 発見のプロセス

• 予想できない結果

• 新しい発見をどうしたらいいのか、既存のやり方とどう折り合いを付けるか

新しい考え方への切替は容易ではない

• 常識、固定概念を捨て去ることは難しい

• 種の起源（1859）の公開が、ビーグル号航海（1836）のはるか後

• 進化論は相当の反発・議論を巻き起こした

• ダーウィンの死語125年以上にわたって、人類に影響を与えている

• Agileプロセスも、既存のソフトウェア開発のやり方とも、ビジネスのやり方とも異なる

• → めげるなってことだと思います

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モデルの改善に費やされている

• イテレーション開発は新しい概念ではない！！

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

Agileの歴史 ～ マネジメントスタイルから

• 1920年代：マネジメントの分離：ブルーカラーとホワイトカラー （Frederick Taylor）

• 1960年代：「知識労働者」の出現 （Peter Drucker）

• 労働者は「ボランティア」へ ～ 仕事に「意味」を見いだす

Agile Manifesto

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

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

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

• アジャイルはドキュメント書かない

• 誤解！

• 書かないわけではなく、「価値を生まない活動はしない」

• 顧客価値があるドキュメントは、書く

• テストケース

• ハイレベル設計

• エンドユーザードキュメント

誤解！

Individuals and Interactions over Processes and Tools

• 複雑なシステムは計画主導が難しい。Empirical Process Controlが必要。

• 複数の分野のエキスパートからなるチームと、顧客の共同作業

• 流れ作業とは異なる仕事のやり方

• アンチパターン

• ツールとプロセスの操り人形

• コミュニケーションをツールが代替できると思うのは間違い

Working software over comprehensive documentation

• 進捗率ではなく、動くソフトウェアとプロダクトレビューにする

• ソフトウェアは作っている最中にも仕様が変わるものである

• ドキュメントは書いてる側から陳腐化する

• Standish Groupの報告

• 60%の機能は使われていない

• 作るだけ無駄。その機能のドキュメントは更に無駄

Working software over comprehensive documentation

• 「仕様書」を渡して仕事を頼むようなやり方では、優先すべき事柄や、着手すべきポイントが分からない

• 無駄にドキュメントを作るだけではなく、無駄に作業をすることにもなってしまう

Customer collaboration over Contract Negotiation

• 顧客の希望を全て記載し、支払いとスケジュールを確定する

• Fixed Price / Fixed Scope 型契約

• そもそもこれ、チームが決めてないからコミットがない

• 意味が無いと分かっていても、「契約だから」やらないといけない

• Target Cost契約 / 超過コストを顧客と折半

• Stage契約 / チェックポイント毎に go / no go を判断

Responding to change over following a plan

• 計画主導アプローチでは、ボトムアップでスケジュールとスコープが決まるので、タスクとスケジュールのコントロールが重要

• 誤解！： Agileは無計画

• 計画はAgileでも重要

• チームが計画を行うことで、コミットメントが生まれる

• Top down rolling wave アプローチである（後の章への布石）

Twelve Principles of Agile Software

Agile宣言の背後にある原則（１）

• 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

• 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

• 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

• ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

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

Agile宣言の背後にある原則（２）

• 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

• 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

• 動くソフトウェアこそが進捗の最も重要な尺度です。

• アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

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

Agile宣言の背後にある原則（３）

• 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

• シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

• 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

• チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

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

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

• 今までの経験から、プロジェクトを成功させるために重要な（できれば必須な）プラクティス、メソッドを 3つ Post-itに書いて下さい

• それが終わったら、グルーピングして、Agile Principleとの比較をしてみます。

Exercise

5min 5min

• 先ほどのPost-it グループと、12 Principlesとの対応を付けます

• 理解しやすいPrinciple, 理解しにくい（考え方の転換が必要な）Principle はどれでしょうか。

Exercise

5min 5min

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

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

References

• Agile Manifesto, 12 Principles 日本語版

• http://agilemanifesto.org/iso/ja/manifesto.html

• Jon KernのAgile Manifestoの議論メモ

• http://jeffsutherland.com/AgileManifestoNotes2001.pdf