TOP
＞
情報セキュリティ
＞ リスクマネジメントが論じられる分野
トピックと手法から学ぶリスクマネジメント
第６回：プロジェクトマネジメントにおけるリスクアセスメント
著者：
プライド 三澤 正司
2006/10/05
前のページ
1
2
3
次のページ
リスクマネジメントが論じられる分野
PMBOKガイドでは、プロジェクトとは「独自のプロダクト、サービス、所産を創造するために実施される有期性の業務」と定義されている。有期性とは、どのプロジェクトにも明確な始まりと終わりがあることを意味している。
このことからプロジェクトマネジメントとは「一定の時間と制約の中で目標を達成するべく、資源を有効に適用する機能」と定義できる。
プロジェクトにおけるリスク
プロジェクトにおけるリスクを確認する前に、リスク対策が省かれてしまう状況を確認する。
確かにリスクを識別し、評価し、対策を立てるには労力がかかる。ポール・S・ロイヤーは、著書「プロジェクト・リスクマネジメント」の中で、リスク対策が省かれてしまう状況に対し、リスクに対する以下の事柄をあげている。
リスクを定量化しても、直接プロジェクトの資金化にはつながらない。
ステークホルダーは、時間と労力を無駄にしたくない。
ステークホルダーは、リスクが現実のものになるとは思わない。
ステークホルダーは、シンプルな計画を求める。
表3：「プロジェクト・リスクマネジメント」で挙げられている状況
それでは、プロジェクトにおけるリスクを確認する。
PMBOKガイドでは、体系的にリスクを識別するために「11.1リスク・マネジメント計画」の段階でリスクブレークダウンストラクチャー（RBS）を作成する。RBSは、典型的なプロジェクトで発生する恐れのあるリスクの区分とその下位区分を示す。
異なる種類のプロジェクトや組織では、それぞれ適したRBSが必要である。このアプローチの利点には、リスク識別を行う者がリスクの原因の多くに気づくことができることにある。次の図はRBSの例である。
図3：リスクブレークダウンストラクチャーの例
（画像をクリックすると別ウィンドウに拡大図を表示します）
次に、いくつかのリスク例を挙げる。
区分
下位区分
リスク例
技術
要求事項
プロジェクトの成果物が明確になっていない。
技術
新技術に依存し、プロジェクト成功が左右される。
複雑さと
インタフェース
標準的なインタフェースを採用しないため拡張性がない。
性能と信頼性
期待した性能がでない。
品質
品質を検証する手法が確立されていない。
外部
サブコンストラクターと
サプライヤー
プロジェクトの成功やルール、手順について十分な確約のない第三者的な請負業者のパフォーマンスに負うところがある。
顧客
ユーザが要求事項に対し知識不足である。
組織
要員
提案されている技術に対し要員の経験が不足している。
資金
プロジェクトを成功裡に完成させるために必要な資金が不足している。
プロジェクト
マネジメント
見積り
スコープの定義が不明確なため見積りの精度が十分でない。
計画
標準WBSが未整備で、精度の高い計画が策定できない。
コントロール
進捗を把握する手法が確立されていない。
コミュニケーション
悪い情報が報告されない。
表4：リスクが発生する区分とその下位区分の例
上記以外にも、適切な救済措置がされていない契約や妥当性のない仮説など、様々なリスクが想定される。
前のページ
1
2
3
次のページ
著者プロフィール
株式会社プライド 三澤 正司
ITコーディネータ
プラント会社勤務時に、情報システム分野およびシステム開発方法論に興味を持ち、株式会社プライドに入社。主としてプロジェクト支援、標準化支援、教育に従事するが、ここ数年は、情報セキュリティ、管理業務に関わる支援の比重が大きくなってきている。
INDEX
第6回：プロジェクトマネジメントにおけるリスクアセスメント
はじめに
プロジェクトおよびプロジェクトマネジメント
リスクアセスメント手法の説明
