THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会

#21 : Common Mistakes株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO

会場提供: PMI日本支部様

初めての方へのご紹介• 本読書会は、PMI日本支部のアジャイルプロジェクトマネジメント研究会（正確には設立準備中）のサブプロジェクトとして開始したものです。

• アジャイルプロジェクトマネジメント研究会はPMI日本支部会員のみ参加可能です。会員の参加もご検討ください！！

ご興味のある支部会員の方は → Facebook: “Agile_Study_Group”

Common Mistakes

Chapter17

‒ Warren Buffett

“間違いを犯さない意思決定などできない”

”

– H. G. Born, Hand-Book of Proverbs 514

“地獄への道は善意で敷き詰められている”

まえがき• この章では筆者らができるだけ客観的によくある誤解、落とし穴について記載している。

• この例をみて、Agileマニフェストに書かれている価値を思い出して欲しい。

• ただし、その解釈は、会社によっても異なる。

• Agileマニフェストの解釈はわざと多様性をもたせている。それゆえ、Agileがすぐ使えるような方法論になり得ない。

Common Mistakes一覧1. Agileはドキュメントを作らない、カウボーイコーディング 7. 直近の計画しか作らないチーム

2. Agileプラクティスは個別に採用しても、メリットは享受できる 8. 「自分で考えろ」と言うリーダー

3. Agileの採用は開発チームだけ 会社のその他の組織には影響がない 9. ビジネスメンバー不在

4. 擁護者不在 10. いい加減なレトロスペクティブ

5. 不適切な人物がAgile導入／チームをリード 11. 価値観の相違

6. デスマーチをソリューションにする

誤解 Agileはドキュメントを作らない カウボーイコーディング

Cowboy “Curly” Palance by enidmabadger / CC BY NC SA

ドキュメントを再考せよ• アジャイルではドキュメントを作らないのではない。価値のないドキュメントを作らない

• どのようなドキュメントなら顧客は対価を払うか

• どのようなドキュメントがデプロイ後のプロセスに価値を加えるか

• また、契約の規模やプロセス上、ドキュメントに意味がないと納得させるのが困難なケースもある。

価値あるドキュメントを見つける1. プロダクトチームと話し合いを持つ

ドキュメントを列挙し、3つのカテゴリに分ける

• 納品物（Deliverable）

• プロジェクト内部ドキュメント（WBS、etc.）

• 製品内部ドキュメント（設計メモ、etc.）

2. ドキュメントを顧客価値順にソートする

3. リスト中の高位のドキュメントについて、何が開発に必須なのかを明確にする

顧客価値• Agileは開発チームが興味の赴くままに作る手法ではなく、イテレーション毎に顧客に価値を届けるという厳格な規律である。

• また、バックログの完成を優先して、内部品質をおろそかにしてはなならない。Agileは、無駄を省くことで、作業を少なくする。

• 顧客価値はコードとドキュメントの両方によって評価される。

無価値な作業• 顧客価値のないドキュメントを作成すること

• Hack（技術的負債）による手戻り

誤解 Agileプラクティスは個別に採用して

も、メリットは享受できる

day 46: piecemeal bridge by Thomas Hopkins / CC BY NC SA

Agileプラクティス• Agileのプラクティスの一つを実施して、

Agileのメリットのすべてを享受することはできない（そのような効果を期待してはいけない）

• すべてのプラクティスは、Agileという大きなシステムの一部であり、それぞれ関係がある

例: デイリースタンドアップ

• 上記の狙い抜きでプラクティスのみを実践しても、メンバーにとって有益なミーティングにならず、不満がでる。

• イテレーションやプロダクトオーナーのフィードバックとともに採用しなければならない。

• レトロスペクティブを行わなければ、軌道に乗っているのかの確認や、継続的な改良もできない。

• 優先順位のついたバックログがなければ、正しくない作業に時間を費やしてしまう。

• 短いフィードバックサイクルがなければ、小さいタイムボックスで成果を出すのは難しい。

デイリースタンドアップは、チームメンバーを支援し、 日次で状況に適応していくためのプラクティスである。

Agileプラクティス• 選択したAgile方法論に従い、まずはそのやり方にそってやってみる。

• プロセスにすべての問題の解決を期待するのは非現実的

• Agileは障害を明らかにし、取り除くことを可能とする。障害を消すわけではない。

• すべてのメンバーにハードワークと規律が必要である！

誤解 Agileの採用は開発チームだけ 会社の他の組織には影響がない

Waiting for a train, in Baltimore Amtrak station by Ed Yourdon / CC BY NC SA

組織の転換点• Agileチームが成長し、組織という温室の天井にぶつかったら、他の組織に広めることを考えるべき

アジャイルチームをサポートし、組織を変える

アジャイルチームを失い ウォーターフォールに戻る

VSサイロ組織の人々をつなぎ 顧客のための製品を作る

従来型の部分最適 （サイロ組織の中のメトリク

スによる評価）

落とし穴 擁護者不在

擁護者の役割• 擁護者がいなければ、どんな優秀なアジャイルチームも、政治／予算の都合で簡単に脱落する。

• 擁護者は、新しいことへの挑戦に伴うスローダウンを許容し、チームの学び、漸進的な成長を促す。

• 組織の変革も促す役割を担う。プロセスやアプローチの変化よりも、根本的に価値観が変わることをエクゼクティブ／中間管理職に認識させる

擁護者の不在最高責任者／経営層が担うのが理想だが・・・

• まずは開発リードがその役割を担う。

• すぐに業務側の擁護者も必要となる。

• この二種類の擁護者が存在することで、成果物と製品とを効率的に結びつけることができる。

落とし穴 不適切な人物がAgileの導入／チーム

をリード

Commander Neyo by Andrew Becraft / CC BY NC SA

不適切なリーダー像• 命令型

• チームの創造性を阻害する

• 恐怖政治型

• チームメンバーを奴隷のように扱う

• どちらも、失敗はAgileという方法論のせいにする。

個人的な快適さ 職業倫理 「顧客に価値をもたらす」＞

上記のような価値観のリーダーの元ではうまくいかない

落とし穴 デスマーチをソリューションに

する

Bataan Memorial Death March by US Air Force / CC BY NC

デスマーチソリューション• 夏休みの宿題型プロジェクト運営法。

• アジャイルの場合、イテレーション毎にこれを実施すると、すぐに燃え尽きてしまうことになる。

• 持続的なペースで開発できていることが重要

マネージャーの役割• 問題の分類

• 進捗状況の可視化

• レトロスペクティブのファシリテーション

• 乱れたペースの原因を根絶する

とはいえ、チームが正しく進められるようになるには、数イテレーションを我慢する必要がある。

落とし穴 直近の計画しか作らないチーム

Consultation Process: A Roadmap by @resultsjunkie / CC BY NC SA

いつ動くか？ 動いたときだよ！• チームは、ビジョンや製品ロードマップにもとづき、リリース計画や品質計画を建てる必要がある。

計画レベル 内容

ビジネス （顧客）

戦略レベル 全体の複雑さ ハイレベルプラン

チーム 戦術レベル 期間見積り バーンダウン

素早く開始するために、複雑な見積りはしない

落とし穴 「自分で考えろ」と言うリーダー

The Next Day by Bart / CC BY NC

リーダーの役割

• メンバーが自分で考えなければいけないのは確かだが、気持よく考えられる環境を整える必要がある。

• 安全

• 自由に意見が言える

• 分析／調査の余裕がある

• メンバーの反論／意見を聞く

メンバーにコンフリクトから合意に至る方法を学ばせること

落とし穴 ビジネスメンバー不在

Absent printer: by Mónica Pinheiro / CC BY NC

ビジネスメンバーの不在• チームが顧客要望を満たせるかどうかの判断がつかない。どんな技術的に優秀なチームであっても、正しいものを作っているかの判断ができない。

• Product Ownerは必須

• チームも、「俺らとアイツら」という考えを捨てる

すぐエスカレーションすべき深刻なビジネスリスク

落とし穴 いい加減なレトロスペクティブ

Retrospective: Getting Fat (May 23rd, 2004) by Theo Curmudgeon / CC BY NC SA

レトロスペクティブの役割

• 検査と適応が継続的な成功の要

• レトロスペクティブがないと…

• チームが停滞する

• 以前の楽な方法に逆戻り

チームこそが自己組織化の担い手であり、 責任があることを思い出させるセレモニー

落とし穴 価値観の相違

Mismatch by Tudor Barker / CC BY NC SA

価値観の相違

VS

顧客満足度による評価 サイロ組織の中のメトリクスによる評価

Agileの価値観（実施内容は企業により異なる）

• 顧客と協業して要求を理解する

• 品質のよい製品を素早く、頻繁にデリバリーする

• 無駄を削除する

企業変革のための戦い• 価値観が異なると、一方が他方に変化を促す

• 勝つこともあれば、負けることもある。どちらが正しいというものではない。

唯一の誤りは、過去の栄光にしがみつき、 何もしないこと