第 3 章 リスクマネジメントの現状と課題
3.2. 製品開発組織におけるリスクマネジメント
製品開発を取り巻く環境の不確実性が増す中で、プロジェクト・リスクマネジメン トの重要性は広く認識されており、さまざまな取り組みが⾏われている。多くの製品 開発組織ではPMBOKや国際規格などを参考として部⾨内の規程や標準プロセスが定 められ、プロジェクトを対象とするリスクマネジメントが実施されている。製品開発 組織におけるリスクマネジメントの特徴として、必ず、全体のプロジェクトマネジメ ントの進⾏に同期する形でリスクマネジメントが実⾏されるという点が挙げられる。
図 3.1は、プロジェクトマネジメントに同期したリスクマネジメント・プロセスを 表している。図の左側は、⼀般的なプロジェクトマネジメント・プロセスであり、⽴
上げ、計画、実⾏、コントロール、終結の５つのステップからなる。コントロールか ら計画へのフィードバック・ループは、是正措置に基づく計画の修正に対応している。
⼀⽅、図の右側は、リスクマネジメントの中核ステップであるリスクの特定、リスク 分析、対応計画策定を表す。本来のリスクマネジメント・プロセスは、マネジメント 計画、リスクの監視、振り返りなどのステップを含んでいるが、それぞれ、プロジェ クトマネジメント・プロセスの⽴上げ、コントロール、終結へ統合可能であるため、
図から省いている。２つのプロセスをつなぐ⽮印は、プロセス間の制御の移⾏を⽰し ている。
図 3.1：製品開発組織におけるリスクマネジメント・プロセス
以下、各ステップの中⾝を詳しく述べる。
1. まず、プロジェクトマネジメントの“⽴上げ”のステップでは、プロジェクトの⽬
的・⽬標を明確化した上で、活動のスコープを定める。その際、何を「やらない」
かを決定することも重要である。そして、主要メンバーのアサインなど、プロジ ェクト体制を確⽴して、前提条件や制約条件を洗い出し、プロジェクトマネジメ ントの全体計画を実施する。リスクマネジメントのプロセスや帳票4、リスク区分、
役割分担などを決定するリスクマネジメント計画も、本ステップで実⾏される。
2. 続く“計画”のステップでは、プロジェクトに含まれる作業を分解してWBS（work
4 通常は、組織標準のプロセスや帳票などが存在するので、それをそのまま使⽤するか、または テーラリングして使⽤するかを決定すればよい．
3.2製品開発組織におけるリスクマネジメント 47
breakdown structure）を作成し、それに基づいてスケジュール計画やリソース計画、
コスト計画などを策定する。WBSは、プロジェクトで実⾏することが“確定”した タスクの階層的リストであり、すべての活動計画の基本になる。
3. プロジェクトマネジメント・プロセスと並⾏して、リスクマネジメント・プロセ スが起動する。すなわち、WBSをインプットとして、“リスクの特定”が実⾏され る。プロジェクトメンバーが主体となり、可能であれば経験豊富な有識者（ベテ ラン技術者など）を加えて、プロジェクトで発⽣する可能性があるリスクをなる べく多く洗い出す。このステップにおける主要なツールはブレインストーミング であり、なるべく限定せずに想定できるリスクは何でも議論の場に乗せることが 重要である。典型的なリスクのカテゴリーとしては、例えば、顧客関係、要求仕 様、プロジェクト体制、メンバーのスキル、技術的な課題、調達品の品質などが ある。特定したリスクは、リスク帳票に記録しておく。
4. “リスク分析”では、帳票に記録されたリスクに対して、その発⽣確率と影響度を 評価し、対応計画策定のためのリスクの優先度付けを⾏う。その際、発⽣確率と 影響度を２次元で評価したリスクマップや、FMEA（failure mode and effects analysis）
などのツールが使⽤される。こうした分析は、定性的リスク分析と呼ばれる。ま た、⼀部の先⾏組織では、モンテカルロ・シミュレーションなどを⽤いた定量的 リスク分析が実施されることもある。ただし、⼀般に、定量的リスク分析は⾮常 に労⼒がかかるため、重要な案件など、特別な場合の評価に限定しているケース が多い。
5. リスクマネジメントの“対応計画策定”では、リスクの優先度に基づいて、すぐに 対応策を実施するべきか、または、判断を保留して経過観察するべきかを決定す る。リスク対応計画としては、例えば、リスクの回避、影響の軽減、第三者への 移転などがある。不測の事態に備えて、代替案を検討したり予備の予算やスケジ ュールを確保することも重要である。対応計画策定の結果はプロジェクト計画に フィードバックされ、追加タスクまたは修正タスクとしてWBSに反映される。
6. プロジェクトマネジメント・プロセスに戻ると、確定したWBSに基づいてスケジ ュールが作成され、順次タスクが実⾏される。各タスクの担当者は、プロジェク トが定めたルールにしたがって作業の進捗や結果をプロジェクトリーダーに報告 する。WBSに反映されたリスク対応策についても、他のタスクと同様に担当者や
期限が設定されて順次実⾏される。
7. 続く“コントロール”のステップでは、報告に基づいて作業の実績を監視する。計 画との差異を分析した上で、必要に応じて是正措置を検討する。結果は“計画”の ステップにフィードバックされて、追加タスクまたは修正タスクとして WBS に 反映される。なお、リスクはプロジェクトの進⾏にともなって時々刻々と変化す るものであるため、継続的な“リスクの監視”が必要となる。また、リスクマネジ メントは最初の１回だけ実施すればよいプロセスではなく、リスクの変化に応じ て、プロジェクト期間中、繰り返し実⾏する必要がある。図中の“コントロール”
から“リスクの特定”への複数の⽮印、および、“対応計画策定”から“コントロール”
への複数の⽮印は、リスクマネジメント・プロセスの繰り返し実⾏の可能性を⽰
している。
8. 最後の“終結”のステップでは、プロジェクト全体の実⾏結果を整理し、メンバー による振り返りを実施する。そこには、リスクマネジメントの振り返りも含まれ る。プロジェクトの知⾒と反省点を将来のプロジェクトに伝えることは、継続的 な組織改善という観点からも⾮常に重要である。