前のトピック: リスク、問題、変更依頼、およびアクション アイテム次のトピック: 変更依頼の作成


プロジェクト リスクの管理方法

リスク管理プロセスにはリスクの識別、分析、計画、追跡、および通信が含まれます。 リスク管理にはリスク、問題、および変更依頼が含まれます。 潜在的な問題や問題の及ぼす影響の重大性を意識した上で評価し、情報に基づいて決定を行うことが、プロジェクトのリスク管理において最も重要です。

プロジェクト マネージャはリスクを識別し分析した後にリスクが及ぼす影響に基づいてリスクまたは問題を作成します。

リスクは、プロジェクトのライフ サイクルを通じていつでも特定できます。 リスクを問題へエスカレートするのは、プロジェクトに重大な影響を与えると思われる場合です。 変更依頼は問題の結果行われ、変更依頼により効果的な解決が促されます。

以下の図およびこのシナリオでは、プロジェクト リスク管理の 1 つの方法について説明します。 プロジェクト リスク管理するその他の方法の詳細については、「プロジェクト管理ユーザ ガイド」を参照してください。

この図は、プロジェクト リスクを管理するためのワークフローを示しています。

例: プロジェクト リスクの作成と管理

この例では、Forward 社のプロジェクト チームは、ニッチな技術を使用して新製品を開発しています。 この技術を使用した経験を持つ組織内のリソースは限定されるため、チームは、プロジェクトを完了するために外部リソースを使用する必要があります。 さらに、その製品には、法的な承認が必要なサードパーティ API がバンドルされます。

チームは、分析のため、それらのプロジェクトに重大な影響を与える以下の 2 つのリスクを識別します。

分析の後、プロジェクトへのリスクの影響に基づいて、プロジェクト マネージャは、限定されたリソースに対するリスクおよび依存関係の問題を作成します。

プロジェクト リスクを管理するには、以下の手順に従います。

  1. 前提条件の作成
  2. リスクの分析。

前提条件の確認

このシナリオ内のタスクをすべて完了するには、以下のアクセス権を必要とします。

リスクの作成

リスクは、プロジェクト目標に正か負の影響を及ぼす潜在的な将来のイベントです。 リスクをプロジェクトの初期に識別することで、プロジェクトのスコープ、スケジュール、予算および他の要因上の潜在的な影響を認識することができます。 このシナリオで、チームは、外部資源を使用することで、リソースが限定されていることによるリスクを緩和することを決定します。 プロジェクト マネージャは、情報をすべて提供する詳細なリスクを作成し、[カテゴリ]ドロップダウン リストから[リソース利用可能時間]を選択します。

詳細なリスクに対する総合スコアが、割り当てた評価と異なる場合、2 つのリスク管理コンポーネントは影響し合います。 詳細なリスクのスコアが、ユーザが割り当てた評価を上書きします。 評価を割り当てずにリスクの詳細を作成すると、リスク入力のスコアがリストのしかるべき要因に色を付けます。 リスクの詳細を削除すると、プロジェクト全体のリスク スコアと特定のリスク カテゴリを組み合わせたリスク スコアが変更されます。

以下の手順に従います。

  1. プロジェクトを開き、[リスク/問題/変更]をクリックします。
  2. [新規]をクリックします。
  3. [概要]セクションのフィールドに入力します。 以下のフィールドには説明が必要です。
    カテゴリ

    リスクが属するカテゴリを定義します。

    値:

    • 柔軟性 - プロジェクトが簡単に適応できません。
    • 資金調達 - プロジェクトの資金調達が割り当てられていない、または制約を付けて使用可能です。
    • ヒューマン インターフェース - ユーザ インターフェース(UI)は明確に定義されていません。
    • 実装 - 実装工数とユーザ受諾に不安があります。
    • 相互依存性 - プロジェクトは他のプロジェクトに依存しています。
    • 目標 - 要件、目標、スコープおよび利益は妥当性がなく、明確な定義を欠き、測定と検証ができません。
    • 組織文化 - プロジェクトには、社風、業務過程、手続、または方針の変更が必要です。
    • リソース利用可能時間 - 内部リソース利用可能時間が明確でなく、外部リソースが必要です。
    • スポンサーシップ - スポンサーシップは明白に指定されず、確定していません。
    • サポート性 - プロジェクトは将来サポートが容易でなく、大幅な更新が必要です。
    • 技術 - プロジェクトの技術は未実証で、内外の専門家が新たに必要とされます。

    注: リスクカテゴリを指定した場合、そのリスクの総合スコアは、リスク カテゴリまたは要因に対して行う異なるステータス選択を無視します。

    オーナー

    リスクを管理しているリソースの名前を定義します。 このリソースは、リスクのライフ サイクルを通じて、リスクの適切な管理および追跡を確認することに責任を持ちます。

    既定値:現在ログインしているリソース

  4. [詳細]セクションのフィールドに値を入力します。 以下のフィールドには説明が必要です。
    影響日

    プロジェクトにこのリスクの影響が及ぶ日付を定義します。 影響日を特定したら、[解決予定日]フィールドに日付を入力します。

    既定値: 現在の日付

    想定

    この項目がリスクとなりうると決定するための想定を定義します。 これらの想定を検証することにより、リスクのライフサイクルを通じてこれらの想定が有効であり続けるかどうかを確認することができます。 想定が変更された場合、リスクの影響または可能性も変更されます。

    関連リスク

    このリスクと関連するプロジェクトのリスクを定義します。 リスクを関連付けられるのは、このプロジェクト内のリスクのみです。

    関連問題

    このリスクと関連するプロジェクト内の問題を定義します。 リスクを関連付けられるのは、このプロジェクト内の問題のみです。

    対応タイプ

    このリスクに対する対応のタイプを定義します。

    値:

    • 監視。 リスクに対応を行いません。 このタイプは、通常は算出リスクのスコアが低いリスクに対して割り当てられます。 アクションを実行するほどリスクの可能性または影響は大きくないが、リスクを未処理のままとし、監視したい場合です。
    • 受諾。 リスク顕在化が受諾され、場合によってはリスクを解消する意図が見られません。
    • 転移。 別のプロジェクトにリスクを転送します。 転移したリスクは終了できます。
    • 軽減。 リスク対応方法を適用しリスクを解決します。

      既定値: 監視

    注: このシナリオで、[軽減]を選択します。

  5. [リスク評価]セクションのフィールドに値を入力します。 以下のフィールドには説明が必要です。
    可能性

    リスクが発生する可能性を定義します。 リスクの可能性は、リスク顕在化の計算に使用されます。

    値: (1)、(2)、(3)

    既定値:

    算出リスク

    [可能性][影響]フィールドで選択した値に基づいて計算されたスコアを表示します。

    値:

    • 1 ~ 3 (緑)。 算出されたリスクは低程度です。
    • 4 ~ 6 (黄)。 算出されたリスクは中程度です。
    • 7 ~ 9 (赤)。 算出されたリスクは高程度です。
    影響

    このリスクがプロジェクトに与える影響を定義します。 リスクがプロジェクトに及ぼす影響は、パフォーマンス、サポート性、コスト、およびスケジュールによって決定されます。 この値は、リスク顕在化の計算に使用されます。

    既定値:

  6. [添付]セクションに入力がある場合は、有用なリスクの背景、リスクの軽減、またはプロジェクトへの影響の情報を提供するドキュメントを添付します。
  7. [解決]セクションの以下のフィールドに値を入力します。 以下のフィールドには説明が必要です。
    解決

    リスクが軽減された後の、このリスクの最終的な解決方法を定義します。 解決データは、将来プロジェクトのリスクに対して計画または対策を立てる場合に、リスク対応方法の結果を再考するのに役に立ちます。

    注: リスクの作成中または終了前に、解決を定義できます。

    残存リスク

    リスクを解決するための緩和策の結果としてプロジェクト内で発生または作成されたリスクを指定します。 関連リスクとは異なり、残存リスクは結果がさまざまですが、リスクを解決するために行った措置の結果生じます。

  8. 変更を保存します。

対応方法の作成

リスク軽減の意思決定が行われると、プロジェクト マネージャは、リスクのオーナーを作成し、対応方法の策定に割り当てます。 リスク対応方法は、アクション、追跡要件、その他リスクの可能性と影響を排除するのに必要なサポート情報を文書化します。

誰がリスクを所有しているかにかかわらず、個々の応答方法を別のリソースに割り当て、応答方法ごとに個別に期限を設定できます。 これらの日付および名前は、リスク オーナーに通知および事前通知を送信するプロセスに使用できます。 通常、対応のタイプとして[軽減]を選択した場合に、リスク対応方法を作成します。

リスクの可能性を認め、リスクの解消を求めない場合もあります。

以下の手順に従います。

  1. プロジェクトを開き、[リスク/問題/変更]をクリックします。
  2. リスクを開きます。
  3. [プロパティ]メニューを開き、[対応方法]をクリックします。
  4. フィールドに入力して、変更を保存するために[追加]クリックします。

リスクの終了

リスクの軽減に成功したら、リスクのステータスを[クローズ]に変更し、最終的な解決策を入力します。 解決を詳細に記録しておくと、将来プロジェクトのリスクに対して計画または対策を立てる際、リスク対応方法の最終結果について再考するのに役に立ちます。

以下の手順に従います。

  1. プロジェクトを開き、[リスク/問題/変更]をクリックします。
  2. リスクを開きます。
  3. [ステータス][クローズ]に変更します。
  4. [解決]セクションに、どのようにリスクが軽減されたかを入力します。
  5. 変更を保存します。

問題の作成およびリスクの終了

問題はプロジェクトに影響を与えたイベントです。 リスク緩和計画が失敗した場合、リスクを問題へエスカレートできます。 既存のリスクから問題を作成し、次に、リスクを終了します。 新たに作成された問題は、リスクの名前と説明、および[ステータス]([オープン])や[作成日](現在のカレンダ日付)などの値を継承します。 常に元のリスクにリンクによって戻ることができます。 問題をリスクから作成することで、プロジェクト チームが結論を下すための問題に関する認識、アクション、タスクが生じます。 また、このような作成方法により、チームが問題とその結果を継続的に記録し、プロジェクトの終了時および将来のプロジェクトの計画時に分析を行うことができます。

また、この問題に関連した他のリスクまたは問題を連携させることもできます。 関連する問題およびリスクを連携させることは、依存関係を追跡し、かつ将来の分析および監査におけるトレンドを認識することに役立ちます。

このシナリオでは、緩和計画の一部として、外部契約業者がプロジェクトを完了するために雇用されます。 ただし、雇用された契約業者は、プロジェクトの納品の進捗ステータスに影響を与える、要求される経験レベルを持っていません。 この段階でリスクが問題になります。また、プロジェクト マネージャは次にこのリスクから問題を作成し、リスクを終了します。

以下の手順に従います。

  1. プロジェクトを開き、[リスク/問題/変更]をクリックします。
  2. リスクを開きます。
  3. [問題の作成]をクリックします。
  4. [概要]セクションのフィールドに入力します。 以下のフィールドには説明が必要です。
    カテゴリ

    問題が属するエンティティを定義します。

    値:

    • 柔軟性 - プロジェクトが簡単に適応できません。
    • 資金調達 - プロジェクトの資金調達が割り当てられていない、または制約を付けて使用可能です。
    • ヒューマン インターフェース - ユーザ インターフェース(UI)は明確に定義されていません。
    • 実装 - 実装工数とユーザ受諾に不安があります。
    • 相互依存性 - プロジェクトは他のプロジェクトに依存しています。
    • 目標 - 要件、目標、スコープおよび利益は妥当性がなく、明確な定義を欠き、測定と検証ができません。
    • 組織文化 - プロジェクトには、社風、業務過程、手続、または方針の変更が必要です。
    • リソース利用可能時間 - 内部リソース利用可能時間が明確でなく、外部リソースが必要です。
    • スポンサーシップ - スポンサーシップは明白に指定されず、確定していません。
    • サポート性 - プロジェクトは将来サポートが容易でなく、大幅な更新が必要です。
    • 技術 - プロジェクトの技術は未実証で、内外の専門家が新たに必要とされます。
    オーナー

    問題を管理しているリソースの名前を定義します。 このリソースは、問題のライフ サイクルにおいて、問題の適切な管理および追跡を確認することに責任を持ちます。

    既定値:現在ログインしているリソース

  5. [詳細]セクションのフィールドに値を入力します。
  6. [添付]セクションに入力がある場合は、有用な問題の背景、問題の解決、またはプロジェクトへの影響の情報を提供するドキュメントを添付します。
  7. 問題が解決された後、[解決]セクションを完了します。
  8. [保存して戻る]をクリックして、リスクを終了するために[リスクのプロパティ]ページに移動します。
  9. [ステータス][クローズ]に変更します。
  10. 変更を保存します。

問題の作成

リスクが重大な影響をプロジェクトに与える場合、問題を作成します。 承認プロセスの遅延が予想されるので、プロジェクト マネージャは問題を作成し、依存関係としてカテゴリを割り当てます。

以下の手順に従います。

  1. プロジェクトを開き、[リスク/問題/変更]をクリックします。
  2. [リスク/問題/変更]メニューを開き、[問題]をクリックします。
  3. [新規]をクリックします。
  4. [概要]セクションのフィールドに入力します。 以下のフィールドには説明が必要です。
    ID

    問題の一意の識別子を定義します。 問題の保存後は、識別子を変更することはできません。

    カテゴリ

    問題が属するカテゴリを定義します。

    値:

    • 柔軟性 - プロジェクトが簡単に適応できません。
    • 資金調達 - プロジェクトの資金調達が割り当てられていない、または制約を付けて使用可能です。
    • ヒューマン インターフェース - ユーザ インターフェース(UI)は明確に定義されていません。
    • 実装 - 実装工数とユーザ受諾に不安があります。
    • 相互依存性 - プロジェクトは他のプロジェクトに依存しています。
    • 目標 - 要件、目標、スコープおよび利益は妥当性がなく、明確な定義を欠き、測定と検証ができません。
    • 組織文化 - プロジェクトには、社風、業務過程、手続、または方針の変更が必要です。
    • リソース利用可能時間 - 内部リソース利用可能時間が明確でなく、外部リソースが必要です。
    • スポンサーシップ - スポンサーシップは明白に指定されず、確定していません。
    • サポート性 - プロジェクトは将来サポートが容易でなく、大幅な更新が必要です。
    • 技術 - プロジェクトの技術は未実証で、内外の専門家が新たに必要とされます。
    オーナー

    問題を管理しているリソースの名前を定義します。 このリソースは、問題のライフ サイクルにおいて、問題の適切な管理および追跡を確認することに責任を持ちます。

    既定値:現在ログインしているリソース

    作成者

    問題を作成したリソースの名前が表示されます。

    既定値:現在ログインしているリソース

  5. [詳細]セクションのフィールドに値を入力します。
  6. [添付]セクションに入力がある場合は、有用な問題の背景、問題の解決、またはプロジェクトへの影響の情報を提供するドキュメントを添付します。
  7. 問題が解決された後、[解決]セクションを完了します。
  8. 変更を保存します。

問題の終了。

問題が解決したら、ステータスを[クローズ]に変更し、最終的な解決方法を入力します。 解決を詳細に記録しておくと、将来プロジェクトの問題に対して計画または対策を立てる際、問題の結果を振り返るのに役立ちます。

以下の手順に従います。

  1. プロジェクトを開き、[リスク/問題/変更]をクリックします。
  2. [リスク/問題/変更]メニューを開き、[問題]をクリックします。
  3. 問題を開きます。
  4. [ステータス][クローズ]に変更します。
  5. [解決]セクションに、どのように問題が解決されたかを入力します。
  6. 変更を保存します。