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

#16 : Risk Management 前半株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO

会場提供: PMI日本支部様

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

• アジャイルプロジェクトマネジメント研究会はPMI日本支部会員以外も参加可能です（当面）

興味のある方は → Facebook: “Agile_Study_Group”

Risk Management

Chapter11

‒ PMBOK® 第四版

“プロジェクト・リスク・マネジメ ントの目標は、プロジェクトに対してプラスとなる事象の発生確率と影響度を増加させ、マイナスと なる事象の発生確

率と影響度を減少させることである。”

”

– Tom DeMarco and Tim Lister, Walzing with Bears （翻訳は筆者による）

“信用できるものだけを信じるようにする、そういう仕事をリスクマネジメントと呼ぶ”

– Peter Drucker

“リスクを取らない人は一般に年二回は大きな失敗をする。リスクを取る人も一般に年に二回は

大きな失敗をする。”

はじめに ～ リスクとは ～• 従来型プロジェクトでは致命的に重要

• アジャイルに対して不安を覚える人の関心が高い

• この章ではアジャイルプロジェクトでのリスク管理手法について見ていきます

• 最初にアジャイルフレームワークでのリスクの扱い

• 次にPMBOK®Guide と対応させた形で確認

Organic Risk Management in Agile

Chapter11

アジャイルプロジェクトでは• 継続的に製品、プロセス、計画のレビューを行う

• リスク対処は全てのメンバーが負う

• リスク対処は開発サイクルのそこかしこに組み込まれている

リスクの分類• 本質的なスケジュールの欠陥

• 要件の破綻

• スコープ漏れ

• 個人の退職

• 生産性の乖離

これらについて一つずつ確認していきます

本質的なスケジュールの欠陥• （私見）要するに最初っから無理なスケジュール

• 予実管理観点では一番の問題

• 過小見積が原因

• Agileにしたからといって、過小見積の傾向は変わらない!!

Agileでは・・・• 早く発見できて、早く修正できる

• イテレーション終了時にリリースプランを再評価

• チームのVelocityを考えて、スコープの見直し

• チーム全員による計画は、楽観的な予測に対する有効な手段

Agileでは・・・• 最初の見積は精度が低いかもしれない

• 1～2イテレーション後には、ヒストリカルデータ（平均値）を使って、よりよい予測ができるようになる

• PMBOKでいうところの、フィードバックを計画に反映するということ

コラム: • みんなでやってもうまくいかないケースもある - 服従圧力

・ある会社で、イテレーションプランニングのときに、この計画にコミットできるかチームメンバーに聞くと、大半の人が3本指（協力できる）、4本指（いいアイディアだ。同意する）だった。 !・ところで、全員に顔を伏せてもらい、目を閉じた状態で同じ質問をすると、全員が2本指（他に予定があって協力は難しい）だった。 !・この会社ではメンバーが安全に発言できると思っていないのだ。

要件の破綻• 複数のステークホルダーが最終的な製品について、異なるビジョンを持っている

• 「何を作るか」に対する合意が困難

• ステークホルダー同士が争っている間は、開発者はリンボーを踊るしかない（= どっちの味方もしないということか?）

• ステークホルダーと開発者の間のいざこざもある。どちらかが製品のデザインに不満をこぼすことになる

• ビジネスの方向性が見えないと、開発チーム内で何を作るかについていざこざも生まれる

Agileでは…

• 一人の顧客、もしくはProduct Ownerが意思決定を行う

• 具体的にはフィーチャーの順序付け、バックログの決定を行う

・開発者も顧客同様作りたい順番というものを持っているが、顧客と食い違いがあるときは、顧客が毎回必ず勝つ。 ・しかし、顧客も開発者からの情報（見積・前提・制約・代替案）無しには、順序を決められない。 ・顧客が順序付けをできるように、情報を提供するのも開発者のつとめ。 - Mike Cohn “User Stories Applied”

Set Based Design• 「どうやって作るか」の破綻を防ぐ一つの方法

• いくつかの選択肢を、その選択肢が不適切とわかるまで、生かしておく手法

Point Based Design• まず一つの方法を選択する

• リリース出来るレベルになるまで、一つ一つ改善を行っていく

Set Based vs Point Based

コラム: • プロダクトオーナーは一人がいい・とあるチームでは、Scrumを採用しているにもかかわらず、多すぎるProduct Ownerの問題に取り組んでいた。 ・POの意見がまとまらず、声が大きかったり、政治的に強い人の機能ばかりが開発チームの前におかれた。 ・多すぎるボスへの回答は開発チームにとっても不利だし、コラボレーションも効率的に行えない。 ・この会社ではWaterfallプロセスだったときも同じ問題が起きていた。Scrumを採用した今でも起きている。 ・Scrumにしてから、このような問題は全ステークホルダーに見えるようになった。しかし、今や、最後はマネジメントに決断してもらおうかと思うようになってしまっている。

スコープ漏れ• 又の名をスコープインフレーション

• スコープの増加、変更が積み上がるほど、デリバリーサイクルは延びる

Agileでは… • 変更は開発サイクルに組み込まれている

• 変更に対応するポイントも用意されている

イテレーションレビュー• チームは下記をレビュー

• 実現した機能

• 今までのプロセス

• 変更要望（より顧客の要件に合致するようにするため、業務の変化に対応するため）

• 顧客はバックログを変更・更新し、次のイテレーションは新しいバックログで進める

コラム: • リリースプランを常に見えるように

・ある顧客は新しいやり方を非常に喜んで、「いいね、これもやってよ」的な変更を3イテレーションにわたって、立て続けに依頼した。 ・出来たところまでの製品をいじり回すことが、かえってチームをフル機能を実装した最終リリースから遠ざけていることが分かったのはその後のことだ。 !こういったことが、リリースプランを常に全員に見えるようにしておき、イテレーションの終わりに必ず再確認をするようにする理由だ。 全てのメンバーに最終的なゴールを思い出させる必要がある。

個人の退職• 人の入れ替わりは必ずある。（デスマーチでは頻繁）

Agileでは… • 高いやる気

• 自己組織化

• 問題に集中できる環境を作る

• 継続的な知識の共有

• 全てのメンバーがシステムのエキスパート

退職に関する研究• Agileに関する調査研究は見つからなかった

• が、Waterfallでも同様にない

• 仕事の満足度と退職には直接的な関係がある。書籍の筆者は、Agileの全員参加という点について、チームメンバーが最高の満足を得る機会を作ると考えている。

生産性の乖離• 予実の差

• パフォーマンス（生産性）

• 製品への期待

これが大きく乖離してしまうリスク

Agileでは… • イテレーションレビュー

• コミットメントに対してどのくらい達成したか

• 達成度が少なければ、次のイテレーションのコミットを減らす

• イテレーションデモ

• 製品の期待がどのくらい実現できているか

• 期待が満たされなければ、何がまずいか明らかにして、次のイテレーションに追加する

乖離を避けるには• Velocityを使う

• 2-3イテレーションくらいすれば現実的な見積（これがVelocity）ができるようになっている

• 100%アサインで作業する

グループワーク• 5つのリスク分類に対して、Agileではこうするという例が示されました

• 5つのリスク分類それぞれに対して、追加の対応案、もしくは対応案の反例を挙げて下さい

Risk Management Planning

Chapter11

Risk Management Planning• プロジェクトのリスクマネジメント活動を実行する方法を定義するプロセス

• ステークホルダー、マネジャー、社長とミーティングを実施し、リスクマネジメント計画を作成する

PMBOK

公式リスクマネジメント文書• リスク管理手法

• 役割・責任分担

• 予算

• リスクの分類

• 定義と測定方法

• 確率と影響度表

• 報告書式

• 追跡活動

全ての会社・チームでここまで公式に記載する必要はなく、

最低限「プロジェクトのリスクに対してどのように対処するか」が合意できていればよい。

リスクマネジメント計画の公式性• 企業文化と（かけられる？）時間次第

・起業したての独立独歩な組織では、もっと少ないステップが適当だ。 個人が自分の領域で最終的にどういうステップを踏むかを決定する権利があるような（委譲されている）組織では。 ・プロセスを何故作るかといえば、、適切なリスクに対処するためだ。 ・プロセスは企業の文化や必要性を反映しつつ、企業の日々のオペレーションにくみこまれ、かつ所与の時間で完遂できるようなものが望ましい。 !- Carl Pritchard “Where do you start in Building a Risk Standard”

Agileでは… • リスク管理はプロセスに組み込まれている

• 継続的なインスペクション、適応

• （そのため）公式なドキュメントは必要としない

• ただし、組織文化に応じてドキュメントを作成することを否定するものではない

Risk Management Planning

Traditional PM Agile PM

リスク管理方法決定のため、マネジャーとミーティングを行う

リスク管理アプローチをチームが決める

リスク管理プロセスの概要を書いた公式ドキュメントを作成

プロセスに応じて・少ないドキュメント・もしくは、全くなし

Thanks

‣素材: https://openclipart.org/

‣ Keynoteテンプレート: https://github.com/

sanographix/azusa-keynote