みんなのプロジェクトマネジメント

メンバーが、リーダーが、マネージャーが、プロジェクトマネジメントを使いこなす。

プロジェクト・リスク・マネジメント

リスクは、プロジェクトに影響を与える可能性のある、不確実な事象
影響を受けないように、または最小限にするため、リスクを事前に洗い出し、
原因や影響を調べ、対応策を講じる。

<計画>
・リスク・マネジメント計画
 リスクへの取り組みや、処理方法の計画を立てる。
 リスク対策の行い方の「定義」、発生確率や影響度の「定義」を行う。

・リスク特定
 ブレーンストーミング、専門家へのアンケート、類似PJからの展開などより、
 リスクとなり得る事象を識別し、管理する。
 ここで、未知のリスクが既知のリスクとなる。
 一度だけではなく、プロジェクトを実施しながら、適宜見直しを行う。
 (リスクは、プロジェクトが進むにつれ、無くなったり増えたり、
  発生確率や影響度が変わったりするため。)

・定性的リスク分析
 抽出した全リスクに対して、対策を講じることは難しい。
 優先順位をつけるため、発生確率と影響度を検討する。
 リスク・スコア=発生確率×影響度
 ※この時点で、リスク・スコアの高いものは対応の検討を始める。

・定量的リスク分析
 さらに詳細に、発生した場合、コストやスケジュールにどのくらいの影響を与えるのか、定量的に分析を行う。
 ※定性的リスク分析で、対応するものが決まった場合、実施しないこともある。

・リスク対応計画
 優先順位をつけたら、各リスクへの対応戦略を考える。
 上述の通り、全てのリスクを完璧に防ぐことは難しいため、
 どこまで低減させるか? HSISE(How Safe Is Safe Enough?)が重要となる。
 リスクの特性を認識し、致命傷を与えないよう、対策を決める必要がある。
 プロアクティブ…発生前に積極的に対応
 リアクティブ…発生した後に対応

<監視・コントロール>
・リスクの監視・コントロール
 リスクが顕在化していないか、無くなっていないか、
 新たなリスクが発生していないか、を監視する。
 リスクは時間経過により常に変化する。
 当初、大きなリスクとしていたものが、時間経過により、影響がそうでもなくなっていることも多い。
 例:開発の未経験者が多いことにより、進捗が遅れる可能性があるというリスク
  →開発も後半に差し掛かり、その時点で遅れていなければ、リスクは顕在化しなかったとみなせる。