Recommended
More Related Content
Similar to AgilePM読書会 #16 Risk Management 前半
Similar to AgilePM読書会 #16 Risk Management 前半 (20)
More from Tadatoshi Sekiguchi
AgilePM読書会 #16 Risk Management 前半
- 1. THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #16 : Risk Management 前半 株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO 会場提供: PMI日本支部様
- 2. 初めての方へのご紹介 • 本読書会は、PMI日本支部のアジャイルプロ ジェクトマネジメント研究会（正確には設立 準備中）のサブプロジェクトとして開始した ものです。 • アジャイルプロジェクトマネジメント研究会は PMI日本支部会員以外も参加可能です（当面） 興味のある方は → Facebook: “Agile_Study_Group”
- 4. ‒ PMBOK® 第四版 “プロジェクト・リスク・マネジメ ントの目標は、 プロジェクトに対してプラスとなる事象の発生確率 と影響度を増加させ、マイナスと なる事象の発生確 率と影響度を減少させることである。” ”
- 5. – Tom DeMarco and Tim Lister, Walzing with Bears （翻訳は筆者による） 信用できるものだけを信じるようにする、そういう仕 事をリスクマネジメントと呼ぶ
- 7. はじめに ∼ リスクとは ∼ • 従来型プロジェクトでは致命的に重要 • アジャイルに対して不安を覚える人の関心が高い • この章ではアジャイルプロジェクトでのリスク管理手 法について見ていきます • 最初にアジャイルフレームワークでのリスクの扱い • 次にPMBOK®Guide と対応させた形で確認
- 8. Organic Risk Management in Agile Chapter11
- 9. アジャイルプロジェクトでは • 継続的に製品、プロセス、計画のレビューを 行う • リスク対処は全てのメンバーが負う • リスク対処は開発サイクルのそこかしこに組 み込まれている
- 10. リスクの分類 • 本質的なスケジュールの欠陥 • 要件の破綻 • スコープ漏れ • 個人の退職 • 生産性の乖離 これらについて一つずつ確認していきます
- 11. 本質的なスケジュールの欠陥 • （私見）要するに最初っから無理なスケジュー ル • 予実管理観点では一番の問題 • 過小見積が原因 • Agileにしたからといって、過小見積の傾向は 変わらない!!
- 12. Agileでは・・・ • 早く発見できて、早く修正できる • イテレーション終了時にリリースプランを再 評価 • チームのVelocityを考えて、スコープの見直し • チーム全員による計画は、楽観的な予測に対 する有効な手段
- 13. Agileでは・・・ • 最初の見積は精度が低いかもしれない • 1∼2イテレーション後には、ヒストリカル データ（平均値）を使って、よりよい予測が できるようになる • PMBOKでいうところの、フィードバックを計 画に反映するということ
- 14. コラム: • みんなでやってもうまくいかないケースもあ る - 服従圧力 ・ある会社で、イテレーションプランニングのときに、この計画にコミットでき るかチームメンバーに聞くと、大半の人が3本指（協力できる）、4本指（いいア イディアだ。同意する）だった。 ! ・ところで、全員に顔を伏せてもらい、目を閉じた状態で同じ質問をすると、全 員が2本指（他に予定があって協力は難しい）だった。 ! ・この会社ではメンバーが安全に発言できると思っていないのだ。
- 15. 要件の破綻 • 複数のステークホルダーが最終的な製品について、異なるビジョン を持っている • 「何を作るか」に対する合意が困難 • ステークホルダー同士が争っている間は、開発者はリンボーを踊る しかない（= どっちの味方もしないということか?） • ステークホルダーと開発者の間のいざこざもある。どちらかが製品 のデザインに不満をこぼすことになる • ビジネスの方向性が見えないと、開発チーム内で何を作るかについ ていざこざも生まれる
- 16. Agileでは… • 一人の顧客、もしくはProduct Ownerが意思 決定を行う • 具体的にはフィーチャーの順序付け、バック ログの決定を行う ・開発者も顧客同様作りたい順番というものを持っているが、顧客と食い違いが あるときは、顧客が毎回必ず勝つ。 ・しかし、顧客も開発者からの情報（見積・前提・制約・代替案）無しには、順 序を決められない。 ・顧客が順序付けをできるように、情報を提供するのも開発者のつとめ。 - Mike Cohn User Stories Applied
- 17. Set Based Design • 「どうやって作るか」の破綻を防ぐ一つの方 法 • いくつかの選択肢を、その選択肢が不適切と わかるまで、生かしておく手法
- 18. Point Based Design • まず一つの方法を選択する • リリース出来るレベルになるまで、一つ一つ 改善を行っていく
- 19. Set Based vs Point Based
- 23. イテレーションレビュー • チームは下記をレビュー • 実現した機能 • 今までのプロセス • 変更要望（より顧客の要件に合致するようにするた め、業務の変化に対応するため） • 顧客はバックログを変更・更新し、次のイテレーショ ンは新しいバックログで進める
- 26. Agileでは… • 高いやる気 • 自己組織化 • 問題に集中できる環境を作る • 継続的な知識の共有 • 全てのメンバーがシステムのエキスパート
- 27. 退職に関する研究 • Agileに関する調査研究は見つからなかった • が、Waterfallでも同様にない • 仕事の満足度と退職には直接的な関係がある。 書籍の筆者は、Agileの全員参加という点につ いて、チームメンバーが最高の満足を得る機 会を作ると考えている。
- 28. 生産性の乖離 • 予実の差 • パフォーマンス（生産性） • 製品への期待 これが大きく乖離してしまうリスク
- 29. Agileでは… • イテレーションレビュー • コミットメントに対してどのくらい達成したか • 達成度が少なければ、次のイテレーションのコミットを減ら す • イテレーションデモ • 製品の期待がどのくらい実現できているか • 期待が満たされなければ、何がまずいか明らかにして、次の イテレーションに追加する
- 33. Risk Management Planning • プロジェクトのリスクマネジメント活動を実 行する方法を定義するプロセス • ステークホルダー、マネジャー、社長とミー ティングを実施し、リスクマネジメント計画 を作成する PMBOK
- 34. 公式リスクマネジメント文書 • リスク管理手法 • 役割・責任分担 • 予算 • リスクの分類 • 定義と測定方法 • 確率と影響度表 • 報告書式 • 追跡活動 全ての会社・チームでここまで公式に記載する必要はなく、 最低限「プロジェクトのリスクに対してどのように対処するか」が合意できていればよい。
- 35. リスクマネジメント計画の公式性 • 企業文化と（かけられる？）時間次第 ・起業したての独立独歩な組織では、もっと少ないステップが適当だ。 個人が自分の領域で最終的にどういうステップを踏むかを決定する権利があるよ うな（委譲されている）組織では。 ・プロセスを何故作るかといえば、、適切なリスクに対処するためだ。 ・プロセスは企業の文化や必要性を反映しつつ、企業の日々のオペレーションに くみこまれ、かつ所与の時間で完遂できるようなものが望ましい。 ! - Carl Pritchard Where do you start in Building a Risk Standard
- 36. Agileでは… • リスク管理はプロセスに組み込まれている • 継続的なインスペクション、適応 • （そのため）公式なドキュメントは必要とし ない • ただし、組織文化に応じてドキュメントを作 成することを否定するものではない
- 37. Risk Management Planning Traditional PM Agile PM リスク管理方法決定のため、マネジ ャーとミーティングを行う リスク管理アプローチをチームが決 める リスク管理プロセスの概要を書いた 公式ドキュメントを作成 プロセスに応じて ・少ないドキュメント ・もしくは、全くなし
- 38. Thanks ‣ 素材: https://openclipart.org/ ‣ Keynoteテンプレート: https://github.com/ sanographix/azusa-keynote