プロジェクトのリスク (RAID) をどのように特定・管理しますか?

Question

Accepted Answer

**リスク**は*起こるかもしれない*ことで、起きればプロジェクトに害をもたらします。**リスク管理**は、そうした脅威を早期に特定し、*それが問題になる前に*対処方法を決めることです。シンプルな洞察：問題は事前に考えておけば、はるかに対処しやすくなります。

## なぜ重要なのか

プロジェクトの脅威と項目を追跡するための、シンプルで広く使われているツール：

```text
R — RISKS        → might happen, would cause harm (manage proactively)
A — ASSUMPTIONS  → things we're taking as true (validate them)
I — ISSUES       → risks that have already materialized (deal with now)
D — DEPENDENCIES → things we rely on from others (track them)
```

## 各リスクを評価する

```text
For each risk, score:
  LIKELIHOOD (how probable?) × IMPACT (how bad?)
→ focus effort on high-likelihood, high-impact risks
```

## 対応方法を選択する

```text
AVOID    → change the plan so the risk can't occur
MITIGATE → reduce its likelihood or impact
TRANSFER → shift it (insurance, vendor SLA)
ACCEPT   → live with it, but have a fallback ready
```

## 具体例

あるプロジェクトが、新しく実績のないサードパーティ API に依存しています。リスク：パフォーマンスが低い可能性があります。可能性は中程度、影響は高い。軽減策：早期にスパイク調査を行い、プロバイダを切り替えられるよう抽象化を構築し、フォールバック案を用意します。今、未知のものは計画を伴う管理されたリスクになりました。

## よくある落とし穴

リスク管理を1回限りのキックオフ チェックリストとして扱うこと。リスクは進化します。RAID ログを定期的に見直し、新たなリスクが現れたら追加してください。

## なぜ重要なのか

管理されていないリスクは危機に変わります。通常、締切の直前という最悪のタイミングで。

早期にリスクを処理するコストは、それが起きた後に対応するコストに比べると微々たるものです。

リスクを声に出して挙げることで、信頼も築きます。ステークホルダーは「以下の問題が起こる可能性があり、対応計画がある」という説明を、自信たっぷりの沈黙の後の悪いサプライズよりも好みます。