本ガイドラインでは、リスク管理を行うための手順と各基準値を規定します。

リスクとは「起こるかもしれない悪い影響を与える事象あるいは状態」です。
プロジェクトにおけるリスクとは、もしそれが起これば、時間、コスト、スコープ、品質などの プロジェクトの目標にマイナスを与えるものということになります。

リスクを管理するということは、予定外の出来事によりプロジェクトが失敗する可能性を 最小限に抑えるということです。

しかし、リスクに関する活動に対してはコストが発生します。
また、発生するかもしれませんが、発生しない可能性もあります。
そのため、リスクに対して楽観的な見方をしてしまい、リスクを見ないといった 対応をしてしまうことがあります。
逆に、リスクに対応するために発生したコストがリスクが現実になった際にプロジェクトに 与える影響を上回ってしまっては意味がありません。
リスク管理ではこれらのバランスをうまくとっていくことが大切です。

リスクの特定とは、プロジェクトにおいて関連するリスクを洗い出すことです。
必要に応じてプロジェクトオーナー、プロジェクトチームメンバー、顧客、ドメインエキスパート、テクニカルメンターなどが参加します。

リスクの特定には様々な方法が存在します。

• ブレインストーミング、インタビューなどにより、リスクを洗い出す。
• プロジェクト関連の文書に関してレビューを行うことでリスクを特定する。
• 過去のプロジェクトにおけるリスクが今回のプロジェクトでも該当しないかを検討する。

過去のプロジェクトからのリスクの蓄積がない場合は、ソフトウェア開発における一般的なリスクが参考となります。

ソフトウェア開発における一般的なリスクおよび対処は以下のものがあります。

順位	リスク	軽減
1	技術力の高い人員の不足	初期の教育機関の費用を若干余裕を見て見積もる 余裕をみて追加資源を確保する プロジェクト特有の研修プログラムを規定する クロストレーニングセッションを実施する
2	要件変更が多すぎる	顧客からの最初の要件定義に対する承認を受ける 要件の変更がスケジュールに影響を与えることを顧客に理解してもらう 要件の変更を行う手続きを規定する 実際の工数に対して支払いが行われるよう交渉する
3	不明瞭な要件	経験と常識に基づき前提条件を設定しこ顧客の承認を得る プロトタイプを開発し、レビューを受ける
4	人員の減少	プロジェクトにおいて重要な領域には複数のリソースを割り当てる チーム作りのためのセッションを開く チームメンバー内でローテーションを行う 追加のリソースをバックアップとして確保しておく 各メンバーの作業を適切に文書化しておく 構成管理のプロセスおよびガイドラインを厳密に守る
5	外部からなされるプロジェクトへの指示・決定	事実やデータに基づいてデメリットを提示し、決定を強制する責任者と交渉する 強制が避けられない場合には、実際のリスクを特定し、その軽減計画を明確にする
6	性能要件を満たせない	性能基準を明確にし、顧客にレビューしてもらう 性能要件を満たすために従うべき標準を定義する 性能基準を満たせるように設計を行い、設計をレビューする クリティカルなトランザクションの性能を対象に、シミュレーションまたはプロトタイプ作成を行う 可能な場合には典型的なデータ量でテストする 可能な場合にはストレステストを実施する
7	非現実的なスケジュール	より現実的なスケジュールにするよう交渉する 並行タスクを特定する リソースを早めに準備する 自動化できるエリアを特定する クリティカルパスがスケジュールに収まらない場合には顧客と交渉する 実際の工数に基づいて支払いが行われるよう交渉する
8	新技術(ハードウェアおよびソフトウェア)での作業	フェーズごとの納入を検討する 重要モジュールから納入する 学習曲線のための時間をスケジュールに含める 新技術のトレーニングを実施する 概念を自称するアプリケーションを開発する
9	業務に対する知識の不足	顧客とのコミュニケーションを増やし、十分な知識移転が行われるようにする 当該分野の知識を獲得するためのトレーニングを実施する 顧客に対して業務トランザクションのシミュレーションまたはプロトタイピングを行い、承認を得る
10	性能不足	顧客とともに適切な期待値を設定する

プロジェクトのリスクが特定できたら、分析と評価に移ります。

リスクの分析と評価とは、それぞれのリスクの影響度、発生確率を検討し、そこから算出される重要度によりリスクにランク付けを行うことです。
影響度、発生確率については以下の基準で検討します。

影響度

リスクが現実になった際にプロジェクトに与える影響の大きさを表します。

プロジェクト 目標	非常に低い	低い	普通	高い	非常に高い
コスト	軽微なコスト増	コスト増5%未満	コスト増5-10%	コスト増10-20%	コスト増20%超
スケジュール	軽微なスケジュール遅延	スケジュール遅延5%未満	プロジェクト全体の遅延5-10%	プロジェクト全体の遅延10-20%	プロジェクト全体の遅延20%超
スコープ	軽微なスコープの縮小	スコープの非主要部分への影響	スコープの主要部分への影響	顧客が受容しないスコープの縮小	実用に耐えないプロジェクトの最終成果物
品質	軽微な品質劣化	非常に厳しい用途にのみ影響	顧客の承認が必要な品質低下	顧客が受容しない品質低下	実用に耐えないプロジェクトの最終成果物

発生確率

プロジェクトにおいて、リスクが顕在化する可能性をパーセントで表します。
COMPASS-ITSにおいては基準として10%、30%、50%、70%、90%の5段階で評価します。

重要度

リスクを総合的に評価するための値です。 影響度、発生確率を元に重要度を算出します。

重要度＝影響度×発生確率


重要度による分類は以下のとおりです。

		影響度
		非常に低い	低い	普通	高い	非常に高い
発生確率	0.90	0.05	0.09	0.18	0.36	0.72
	0.70	0.04	0.07	0.14	0.28	0.56
	0.50	0.03	0.05	0.10	0.20	0.40
	0.30	0.02	0.03	0.06	0.12	0.24
	0.10	0.01	0.01	0.02	0.04	0.08

重要度の分類に対して以下のように対応を行います。

分類 対応 高 優先的にアクションをとり積極的に対応を行う。 中 高よりも優先が低いが対応が必要。 低 監視対象とするか、発生に備えて、期間、コストなどを準備しておくが、それ以上のアクションは事前にとらない。

また、重要度の分類が同じリスクに対しては重要度の値が大きいリスクから優先して対応を行います。