リスクの管理

リスクは、実際の結果が意図した結果とは (場合によっては大幅に) 異なる可能性があることを意味します。 この相違が生じる確率、および実際の結果と意図した結果の相違の程度は、"リスク" という言葉にまとめられます。リスクを管理するときは、期待する結果と実際の結果の間の相違を戦略的に最小限に抑えます。

リスクを特定、分類、分析、および管理する能力は、レベル 3 の SCAMPI (Standard CMMI Appraisal Method for Process Improvement) 評定を実現するために必要な組織能力です。 CMMI の詳細については、「CMMI の背景」を参照してください。

このようなイベント ドリブン リスクを管理することで、プロジェクト、ポートフォリオ、および組織の各レベルでリスクを管理するという全体的な目標に大きく貢献します。 適切なイベント ドリブン リスク管理によって、すべての関係者が満足する、最初に意図した結果とほとんど変わらない結果が得られるようになります。 このような管理が、"驚くに当たらない" という予想につながります。

リスクの定義

このようにリスクについて考察することは、イベント ドリブン リスク モデルとも呼ばれます。 これは、リスクの一覧が将来発生する可能性があるイベントの一覧であることを意味します。 各リスクは、将来発生する可能性があるイベントを示します。 これには、発生の可能性に関する情報が含まれる場合があります。 このようなイベントの発生がプロジェクト計画に与える影響の説明を含める必要があります。 イベント発生の可能性および影響を軽減する方法の説明を含める場合もあります。 また、イベント発生後に推奨される回復の形式を含める場合もあります。

特定されるリスクごとに、チーム プロジェクトでリスク作業項目を作成します。

リスク作業項目

CMMI のリスク管理 (RSKM: Risk Management) プロセス領域では、このようなイベント関連のリスクの管理に重点を置いています。 MSF for CMMI Process Improvement および Visual Studio Team Foundation Server にはリスク作業項目の種類が用意されているので、この管理を簡単に実行できます。 リスク作業項目の種類を使用すると、リスクの一覧を定義および追跡できます。 これには、リスクおよび発生の可能性について記述するフィールドが用意されています。 また、イベント発生の可能性の軽減、影響の軽減、およびイベント発生時における回復のコンティンジェンシー計画の実装のために実行できるアクションのフィールドも用意されています。

初期のプロジェクト リスクは、プロジェクトの計画中に特定する必要があります。 リスク一覧は、各プロジェクト イテレーションの開始時のイテレーション計画中に見直す必要があります。

リスク作業項目フォームは、次の図に示すフィールドにデータを保存します。

実行する必要のあるアクションの選択

リスクの一覧を作成して十分に分析したら、これらのリスクを管理するために実行するアクション (存在する場合) を決定します。 今すぐ実行するかイテレーション計画に記述する必要がある、イベント発生の可能性を軽減するアクションはあるでしょうか。 今すぐ実行するかイテレーション計画に記述する必要がある、イベント発生の影響を軽減するアクションはあるでしょうか。 アクションを実行してリスクを軽減するには、時間とリソースが必要です。 リスクの軽減を取るか、これらのリソースや使用可能な作業時間を活用してプロジェクト作業を進めたりスコープを正しく機能するソフトウェアにしたりすることを取るかについての比較検討を行う必要があります。 リスクの [軽減策] タブで、予定しているリスク軽減アクションを文書化します。

リスクの可能性または影響を軽減するためのアクションを実行するタイミングを決定する際に、プロジェクトの全体的なリスク プロファイルについて考慮する必要があります。 リスク プロファイルに "人命の損失は許容できない" と示されている場合、人命の損失の原因となる可能性があるリスクを管理して、軽減アクションを計画および実行する必要があります。

リスクがプロジェクト ガバナンス制約に従って、使用できる作業時間および予算内ですべての付加価値作業を納品する必要性とのバランスが適切な状態で管理されていることを確認する必要があります。

リスクが可能性または影響を軽減するために選択された場合は、タスク作業項目に分割してこのアクティビティを計画し、それぞれをリスク作業項目にリンクします。

リスクの監視

プロジェクト リスクは、定期的に監視する必要があります。

リスク クエリを使用してリスクを監視します。 一覧のアクティブな各リスクをスキャンして、発生の可能性が増えているかどうか、発生する可能性がある影響が変化しているかどうか、および軽減トリガー イベントが発生したかどうかを検討します。 リスクとしてキャプチャされた情報に重大な変更がある場合は、作業項目を更新します。 また、さらにアクションを実行してリスクまたはその影響を軽減する必要があるかどうかも検討します。

プロジェクトの現在のリスクの状態を伝える必要があります。 レポートには、最近検出されたリスク、進行中の軽減アクション、およびリスクの初期評価が変更される原因となる状態の変化に関する情報を含める必要があります。

代替計画の策定

回復アクションが定義されているリスクについては、イベントが発生した場合にコンティンジェンシーを実装する計画を策定する必要があります。 たとえば、サーバーが障害を起こす可能性があるというリスクがあり、コンティンジェンシーは別の部門からハードウェアを借りることである場合は、サーバーが障害を起こした場合にこれを実行する計画が必要です。 事前に計画を策定すると、イベントが発生した場合に調整するという課題が軽減されます。 リスク管理能力の高い成熟した組織はコンティンジェンシー計画を策定しており、他のプロジェクトのアクティビティに大きな影響を与えずにその計画を実行する方法を把握しています。 成熟度の低い組織は、予期しないイベントから回復しようとする間にパニックと混乱に陥ります。 レベル 3 の SCAMPI 評定を求める組織は、コンティンジェンシー計画が策定されており、必要に応じて実行されていることを示す証拠を文書化しておく必要があります。

コンティンジェンシー計画を、実行する一連のタスクまたはアクションに分割します。 各タスクを見積もります。 スケジュールおよび割り当てられる従業員の推奨一覧を作成します。 コンティンジェンシー計画の実行に必要なすべてのリソースを記述します。

[代替計画] タブでコンティンジェンシー計画をリスク作業項目に追加するか、計画を添付ファイルとして追加します。