プロジェクトマネジメントのテーマ（知識エリア）の1つにリスク・マネジメントがある。
リスクという用語は、プロジェクトマネジメントに限らず、財務や投資、保険など、様々な分野で使われており、やっかいなことには、その定義（概念）は必ずしも同一ではない。従って、PMBOK等で定義されているリスクの概念が唯一のものだとは思わない方が良い。
PMBOKなどでは、「少なくとも1つのプロジェクト目標に影響を与える不確実な事象」をリスクと定義している。プロジェクト目標とは、スコープや、スケジュール、コスト、品質などの目標である。
例えば、スケジュールに影響を与える不確実な事象は、（スケジュール）リスクである。
ここで注意が必要なのは、リスクが発現した場合にもたらす結果として、必ずしもマイナスの結果だけが想定されているわけではない点である。
例えば、開発エンジニアが優秀で、且つ顧客との関係も良好なため、予定よりも前倒しで作業が進捗している、といったプラスの結果をもたらす事象もリスクに含まれている。
一般に、マイナスのリスクが「脅威」で、プラスのリスクが「好機／機会」である。
PMBOKでは、リスクの特定、定性的リスク分析、定量的リスク分析、リスク対応計画などのプロセスが定義されており、概ねこの順番で進めることになっている。
実際のプロジェクトでどこまでリスクマネジメントが行われているかは、（スケジュールや品質、コストに比べ）プロジェクト毎の温度差が大きいと思われる。
また、教科書通りにリスクマネジメントを実施しているプロジェクトというのは決して多くないと思われる。これは、リスクマネジメントを真面目に行っていないということではない。
プロジェクト管理の経験者であれば、一般的なプロジェクト・リスクの幾つかを経験的に知っているだろうし、実際に推進しているプロジェクトについて、そのプロジェクト固有のリスクと、その影響度や発生確率などをおおよそ把握しているものである。
リスクを体系的に整理し、優先順位を付け、計画書として見える化するのが理想であろうが、費用対効果を考えて、どこまでやるのかを決めるのが現実的だと思われる。
PMBOKでは、リスクを既知のリスクと未知のリスクに分けている。
既知のリスクとは、既に、リスクの特定と分析を行ったリスクのことであり、このリスクに対しては対応計画を立てることができる。
一方、未知のリスクとは、事前にマネジメントすることができないリスクであり、この種のリスクに対しては、コンティンジェンシー計画を作成する。
教科書的にはこのような分類になるが、実際の適用を考えると、既知なのか未知なのか良く分からないケースもある。
例えば、世間にインフルエンザ流行の兆候があり、今後担当プロジェクト内でも感染者が広まり、スケジュールが遅延するリスクがあったとする。この場合、インフルエンザの感染を予防する、即ち事前にマネジメントできる対策は無くはないが、完全に回避することはできない。
リスクを軽減する対策を実施しつつ、スケジュール遅延のコンティンジェンシー計画も準備することになるだろう。
一般に、リスクのうち脅威に対する戦略は、以下の4つといわれている。
-
回避：リスクそのものを取り除く
-
転嫁：リスクを第３者に移転する（保険に加入する、など）
-
軽減：リスクの発生確率や影響度を受容可能な範囲まで低減させる
-
受容：能動的受容：リスク発生に備えコンティンジェンシー予備を設ける
受動的受容：リスクが発生するまで何もしない
経営財務の分野でも、リスクと言う用語が様々な意味で使われている。
例えば、投資リスクとは資産や証券が生み出す「収益率の変動性」のことであり、収益率の期待値の標準偏差として定量化（数式化）されている。即ち、投資リスクとは、期待収益率の標準偏差のことであり、これは収益率のバラつきの程度（=変動性）を数値化したものである。
この他にも、事業リスクや財務リスクなどの用語がある。
事業リスクとは、企業が生み出す「利益の変動性」のうち、企業の資産内容（すなわちバランスシートの左側）に起因するものである。一般的には、流動資産に比べて固定資産の割合が高いほど事業リスクは高まる。
一方、財務リスクとは、資本構成（バランスシートの右側）が「利益の変動性」に与える影響である。具体的には、自己資本に比べて負債の利用度が高くなるほど（=負債比率が高いほど）財務リスクは高まる。
企業は資金調達の目的で社債を発行することがある。事業リスクや財務リスクが高い企業は、経済環境など外部環境が悪化すると、社債の利息や元本を払えなくなることがある。これが貸し倒れリスク（デフォルトリスク）である。社債の格付けとは、この貸し倒れリスクを評価するものである。
話をプロジェクトマネジメントにおけるリスクに戻す。プロジェクトのリスク・マネジメントに、上記の経営財務の考え方を援用することも可能だと思われる。
例えば、品質指標の一つにエラー密度（単位規模あたりのバグ件数）がある。いま、システム要件定義が終わった段階で、システムテスト工程の品質リスクを評価すると仮定する。
品質リスクは、経営財務に倣って、エラー密度の期待値と、期待値のばらつき（標準偏差）とする。
システムテスト工程の品質に影響を与える因子には、要件の詳細化の度合い（粒度）、要件のＦＩＸ度合（または今後の要件変更の発生確率）、担当ベンダーの仕様理解度、担当ベンダーの業界経験度合、などが考えられる。
これらの要因から、
が導出できれば、期待値とばらつきを示す標準偏差を求めることが可能になる。（これはあくまで1つの案であり、算出式は他にも考えられるであろう）
工程が進んで、基本設計が終了した段階では、システムテスト工程の品質に影響を与える因子が増えるかもしれないし、同じ因子（例えば今後の要件変更の発生確率）であっても、その予測確度が高まるので、より高い精度で期待値と標準偏差を算出できるかもしれない。
|
