💣
はじめてのリスクマネジメント
What is this?
- 社内でプロジェクトリーダーを育成するにあたって、リスクマネジメントに関する簡単な講座を実施
- その際にまとめた内容を公開
- 初めてプロジェクトマネジメント・リスクマネジメントに触れる人が対象
- 抑えておくことで効果が出そうな最低限のポイントだけに絞って説明
そもそも「プロジェクト」とは？
定義
PMBOK(Project Management Body Of Knowledge)からの引用
独自のプロダクト、サービス、所産を創造するために実施される有期的な業務
ポイント
- 期限が決められている
- 独自の目的がある（目的: Cost, Schedule, Scope, Quality）
リスクマネジメント
- プロジェクトを遂行するために欠かせないのがリスクマネジメント
- プロジェクトマネジメントには多くの項目があるが、プロジェクトマネジメント入門として、まずリスクマネジメントを抑えることがダイレクトにパフォーマンスに繋がりやすい（と考えている）
リスクとは？
こちらもPMBOKからの引用
もし発生すれば、プロジェクト目標にプラスあるいはマイナスの影響を及ぼす、不確実な事象あるいは状態。
リスクの評価
- リスクの「発生確率」(Probability of Risk Occurrence)、「影響度」(Risk Impact)からリスクの重大性を評価
- さらにリスク対応への「緊急性」(いつ起こりうるか？)を評価することで、「優先度」を決定する
重大度のマッピング
| 発生確率(高) | 発生確率(中) | 発生確率(低) | |
|---|---|---|---|
| 影響度(高) | 重大度(最高) | 重大度(高) | 重大度(中) |
| 影響度(中) | 重大度(高) | 重大度(中) | 重大度(低) |
| 影響度(低) | 重大度(低) | 重大度(低) | 重大度(低) |
- 影響度が高いものは、発生確率が低くても重大度はあまり下がらない
- 逆に、発生確率は高いが、影響度が小さいものは受容(後述)できるので重大度が下がる
リスクのカテゴリ
| カテゴリ | 内容 |
|---|---|
| 技術 | 技術的要求・I/F接続・パフォーマンス・品質 |
| 外部 | 顧客・契約・マーケット・サプライヤー |
| 組織 | プロジェクトの従属性・物流・各種リソース・予算 |
| プロジェクトマネジメント | スケジュール・見積もり精度・コミュニケーション |
- リスクを洗い出す際に、カテゴリごとに考えると考えやすい
リスクへの対策
| 種類 | 説明 |
|---|---|
| 回避 | 脅威を完全に排除し、リスクをゼロにする対策 |
| 転嫁 | リスクの影響を責任とともに第三者に移管することで、リスクをほぼゼロにする対策 |
| 軽減 | リスクを受容可能な限界まで下げる対策＝リスクはゼロにならない |
| 受容 | 事前に何もせず、リスクが具現化したときに初めて対処する対策 |
- 脅威・好機に対するリスク対策があるが、上記では脅威に関するもののみ掲載
- 実際のプロジェクトマネジメントでは「軽減」を意識しがちだが、「回避」「転嫁」のほうがリスクをより低下できるため後者の２つを優先的に検討するべき
- すべてのリスクには対策しきれないので、「受容」できるリスクを見極めることも大切
具体的な進め方
| No. | カテゴリ | 内容 |
|---|---|---|
| 1. | 識別 | 考えられるリスクをすべて洗い出す（書き出す） |
| 2. | 評価 | 各リスクの重大性を評価 |
| 3. | 対処 | それぞれのリスクに対して対応策を検討 |
| 4. | 対処 | 緊急性を評価し、優先順位を決定 |
| 5. | 制御 | 優先順位に従って具体的な施策・対策を実施していく |
| 6. | 制御 | 定期的にリスク環境が変化していないか、見直しをする |
- 理想的には「優先順位付け」→「対策検討」の順序が効率的
- しかし、実際は対策の難しさを理解することで、影響度が変化してくるので、上記プロセスのほうが現実的
- プロジェクト環境は変わり続けるため、定期的に見直すことが重要
蛇足：システム開発プロジェクトの難しさ
https://www.zsite.net/download/tree-swing-pm-cartoon-93.html
- 上記の有名な図からわかるように、システム開発プロジェクトは同時にマネジメントする要素が数多くあり、非常に難しい
- この記事が数多あるプロジェクトが無事遂行されることに少しでも寄与されれば非常に嬉しく思う
Discussion