Common mistakes and pitfalls for Agile

1. THE SOFTWARE PROJECT MANAGER’S
BRIDGE TO AGILITY 読書会
#21 : Common Mistakes
株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO
会場提供: PMI日本支部様

2. 初めての方へのご紹介
• 本読書会は、PMI日本支部のアジャイルプロ
ジェクトマネジメント研究会（正確には設立
準備中）のサブプロジェクトとして開始した
ものです。
• アジャイルプロジェクトマネジメント研究会は
PMI日本支部会員のみ参加可能です。会員の参
加もご検討ください！！
ご興味のある支部会員の方は → Facebook: “Agile_Study_Group”

3. Common Mistakes
Chapter17

4. ‒ Warren Buffett
“間違いを犯さない意思決定などできない”
”

5. – H. G. Born, Hand-Book of Proverbs 514
地獄への道は善意で敷き詰められている

6. まえがき
• この章では筆者らができるだけ客観的によくある誤解、落
とし穴について記載している。
• この例をみて、Agileマニフェストに書かれている価値を思
い出して欲しい。
• ただし、その解釈は、会社によっても異なる。
• Agileマニフェストの解釈はわざと多様性をもたせている。
それゆえ、Agileがすぐ使えるような方法論になり得ない。

7. Common Mistakes一覧
1. Agileはドキュメントを作らない、
カウボーイコーディング
7. 直近の計画しか作らないチーム
2. Agileプラクティスは個別に採用して
も、メリットは享受できる
8. 「自分で考えろ」と言うリーダー
3. Agileの採用は開発チームだけ
会社のその他の組織には影響がない
9. ビジネスメンバー不在
4. 擁護者不在 10. いい加減なレトロスペクティブ
5. 不適切な人物がAgile導入／チームを
リード
11. 価値観の相違
6. デスマーチをソリューションにする

8. 誤解
Agileはドキュメントを作らない
カウボーイコーディング
Cowboy “Curly” Palance by enidmabadger / CC BY NC SA

9. ドキュメントを再考せよ
• アジャイルではドキュメントを作らないのではない。
価値のないドキュメントを作らない
• どのようなドキュメントなら顧客は対価を払うか
• どのようなドキュメントがデプロイ後のプロセス
に価値を加えるか
• また、契約の規模やプロセス上、ドキュメントに
意味がないと納得させるのが困難なケースもある。

10. 価値あるドキュメントを見つける
1. プロダクトチームと話し合いを持つ
ドキュメントを列挙し、3つのカテゴリに分ける
• 納品物（Deliverable）
• プロジェクト内部ドキュメント（WBS、etc.）
• 製品内部ドキュメント（設計メモ、etc.）
2. ドキュメントを顧客価値順にソートする
3. リスト中の高位のドキュメントについて、何が開発に必須なのかを明確
にする

11. 顧客価値
• Agileは開発チームが興味の赴くままに作る手法ではな
く、イテレーション毎に顧客に価値を届けるという厳
格な規律である。
• また、バックログの完成を優先して、内部品質をおろ
そかにしてはなならない。Agileは、無駄を省くこと
で、作業を少なくする。
• 顧客価値はコードとドキュメントの両方によって評価
される。

12. 無価値な作業
• 顧客価値のないドキュメントを作成すること
• Hack（技術的負債）による手戻り

13. 誤解
Agileプラクティスは個別に採用して
も、メリットは享受できる
day 46: piecemeal bridge by Thomas Hopkins / CC BY NC SA

14. Agileプラクティス
• Agileのプラクティスの一つを実施して、
Agileのメリットのすべてを享受することはで
きない（そのような効果を期待してはいけな
い）
• すべてのプラクティスは、Agileという大きな
システムの一部であり、それぞれ関係がある

15. 例: デイリースタンドアップ
• 上記の狙い抜きでプラクティスのみを実践しても、メンバーにとって有益なミーティング
にならず、不満がでる。
• イテレーションやプロダクトオーナーのフィードバックとともに採用しなければならない。
• レトロスペクティブを行わなければ、軌道に乗っているのかの確認や、継続的な改良もで
きない。
• 優先順位のついたバックログがなければ、正しくない作業に時間を費やしてしまう。
• 短いフィードバックサイクルがなければ、小さいタイムボックスで成果を出すのは難しい。
デイリースタンドアップは、チームメンバーを支援し、
日次で状況に適応していくためのプラクティスである。

16. Agileプラクティス
• 選択したAgile方法論に従い、まずはそのやり方にそっ
てやってみる。
• プロセスにすべての問題の解決を期待するのは非現実的
• Agileは障害を明らかにし、取り除くことを可能とす
る。障害を消すわけではない。
• すべてのメンバーにハードワークと規律が必要である！

17. 誤解
Agileの採用は開発チームだけ
会社の他の組織には影響がない
Waiting for a train, in Baltimore Amtrak station by Ed Yourdon / CC BY NC SA

18. 組織の転換点
• Agileチームが成長し、組織という温室の天井
にぶつかったら、他の組織に広めることを考
えるべき
アジャイルチームをサポート
し、組織を変える
アジャイルチームを失い
ウォーターフォールに戻る
VS
サイロ組織の人々をつなぎ
顧客のための製品を作る
従来型の部分最適
（サイロ組織の中のメトリク
スによる評価）

19. 落とし穴
擁護者不在

20. 擁護者の役割
• 擁護者がいなければ、どんな優秀なアジャイルチー
ムも、政治／予算の都合で簡単に脱落する。
• 擁護者は、新しいことへの挑戦に伴うスローダウ
ンを許容し、チームの学び、漸進的な成長を促す。
• 組織の変革も促す役割を担う。プロセスやアプロー
チの変化よりも、根本的に価値観が変わることを
エクゼクティブ／中間管理職に認識させる

21. 擁護者の不在
最高責任者／経営層が担うのが理想だが・・・
• まずは開発リードがその役割を担う。
• すぐに業務側の擁護者も必要となる。
• この二種類の擁護者が存在することで、成果
物と製品とを効率的に結びつけることができ
る。

22. 落とし穴
不適切な人物がAgileの導入／チーム
をリード
Commander Neyo by Andrew Becraft / CC BY NC SA

23. 不適切なリーダー像
• 命令型
• チームの創造性を阻害する
• 恐怖政治型
• チームメンバーを奴隷のように扱う
• どちらも、失敗はAgileという方法論のせいにする。
個人的な快適さ
職業倫理
「顧客に価値をもたらす」＞
上記のような価値観のリーダーの元ではうまくいかない

24. 落とし穴
デスマーチをソリューションに
する
Bataan Memorial Death March by US Air Force / CC BY NC

25. デスマーチソリューション
• 夏休みの宿題型プロジェクト運営法。
• アジャイルの場合、イテレーション毎にこれを
実施すると、すぐに燃え尽きてしまうことにな
る。
• 持続的なペースで開発できていることが重要

26. マネージャーの役割
• 問題の分類
• 進 状況の可視化
• レトロスペクティブのファシリテーション
• 乱れたペースの原因を根絶する
とはいえ、チームが正しく進められるようになる
には、数イテレーションを我慢する必要がある。

27. 落とし穴
直近の計画しか作らないチーム
Consultation Process: A Roadmap by @resultsjunkie / CC BY NC SA

28. いつ動くか？ 動いたときだよ！
• チームは、ビジョンや製品ロードマップにも
とづき、リリース計画や品質計画を建てる必
要がある。
計画レベル 内容
ビジネス
（顧客）
戦略レベル
全体の複雑さ
ハイレベルプラン
チーム 戦術レベル
期間見積り
バーンダウン
素早く開始
するために、
複雑な見積
りはしない

29. 落とし穴
「自分で考えろ」と言うリーダー
The Next Day by Bart / CC BY NC

30. リーダーの役割
• メンバーが自分で考えなければいけないのは確かだが、気持
よく考えられる環境を整える必要がある。
• 安全
• 自由に意見が言える
• 分析／調査の余裕がある
• メンバーの反論／意見を聞く
メンバーにコンフリクトから合意に至る方法を学ばせること

31. 落とし穴
ビジネスメンバー不在
Absent printer: by Mónica Pinheiro / CC BY NC

32. ビジネスメンバーの不在
• チームが顧客要望を満たせるかどうかの判断がつ
かない。どんな技術的に優秀なチームであっても、
正しいものを作っているかの判断ができない。
• Product Ownerは必須
• チームも、「俺らとアイツら」という考えを捨て
る
すぐエスカレーションすべき深刻なビジネスリスク

33. 落とし穴
いい加減なレトロスペクティブ
Retrospective: Getting Fat (May 23rd, 2004) by Theo Curmudgeon / CC BY NC SA

34. レトロスペクティブの役割
• 検査と適応が継続的な成功の要
• レトロスペクティブがないと…
• チームが停滞する
• 以前の楽な方法に逆戻り
チームこそが自己組織化の担い手であり、
責任があることを思い出させるセレモニー

35. 落とし穴
価値観の相違
Mismatch by Tudor Barker / CC BY NC SA

36. 価値観の相違
VS
顧客満足度による評価
サイロ組織の中のメトリクス
による評価
Agileの価値観（実施内容は企業により異なる）
• 顧客と協業して要求を理解する
• 品質のよい製品を素早く、頻繁にデリバリーする
• 無駄を削除する

37. 企業変革のための戦い
• 価値観が異なると、一方が他方に変化を促す
• 勝つこともあれば、負けることもある。どち
らが正しいというものではない。
唯一の誤りは、過去の栄光にしがみつき、
何もしないこと