はじめに
プロジェクトマネージャー試験に出てくるリスクについて残していきます。
リスクとは
IPAでは、リスクの定義として、「発生確率を持ち、最終的に損失または利益になること」とあります。
設計工程での顧客要望のよる仕様変更、機能の追加等もリスクにあたります。
リスクの対応はいつから考えているか
問題の発生後に作成するものではなく、事前に作っておくもので、プロジェクト計画段階で作成します。
プロジェクト開始前、要件定義時、設計工程時、開発工程時、テスト工程時、システム移行時等で考える必要があります。
リスクの例としてプロジェクト開始前では、人員確保、顧客の不確定要素がリスクとして上げられます。
人員確保
ほかの仕事との兼ね合いや時期などにより社内、社外から要員を決めます。開発を行う要員が確保できない場合、リスクとなります。
顧客の不確定要素
顧客側のプロジェクト推進体制についても、リスクとなる要素の一つになります。
マイナスのリスクに対する対応の基本的な考え方
マイナスリスク例
要件変更のリスク
顧客の要求が途中で変更される可能性がある。
市場環境の変化により、製品・サービスの仕様を変更する必要がある可能性がある。
技術的な問題のリスク
予期せぬバグが発生する可能性がある。
マイナスリスクの考え方
後で記載するプラスのリスクの考え方でもありますが以下の考え方があります。
エスカレーション
対応策がプロジェクトマネージャーの権限を越えると判断した場合や、プロジェクトのスコープ外である場合にとられる。
プログラムレベルなどの上位権限などで対応される。
転嫁
リスクそのものを第三者へ移すこと。
軽減
リスクの発生確率と発生した場合の影響の大きさを受容可能なレベルまで低下させること。
受容
リスクへの対策を何もとらず、リスクが発生した場合、そのリスクの発生による影響を受け入れること。
許容範囲内としてリスクを容認すること。
プラスのリスクに対する対応の基本的な考え方
プラスのリスク例
開発コストの削減
オープンソースソフトウェアやライブラリを活用することで、開発期間を短縮できる可能性がある。アジャイル開発手法を採用することで、開発の無駄を減らすことができる可能性がある。
プラスリスクの考え方
エスカレーション
マイナスリスクと同じ。
活用
プラスのリスクを確実にするために対応をすること。
共有
プラスのリスクの実行権限を第三者に割り当てること。
強化
プラスのリスクの生じる確率を増加させたり、影響度合いを大きくするための策を講じること。