プロジェクトのリスク一覧
まず反対者の立場を取り、リスクを追跡できる表にする
あなたは穴を探すために呼ばれたプロジェクト監査役で、このプロジェクトは遅れる前提で考えます。プロジェクト情報：[目標、締切、人員、依存先]。リスク表を出力してください。列は：リスク／兆候／影響（時間・コスト・品質）／発生確率／こちらで打てる緩和策／担当者。要件：1）最低 8 行、人員・外部依存・要件変更・技術的不確実性を網羅；2）発生確率×影響で並べる；3）いま介入できるものだけ。すでに起きたものは別枠；4）緩和策は実行可能なものにする。「コミュニケーションを強化する」は不可。
使い方
毎週「兆候」の列だけ更新する。そうしないと、表は書いた翌週には忘れられる。
向いている場面
- キックオフやスケジュールレビューの前に、「遅れるのか」を会議での口頭の心配ではなく、毎週更新できる表にしたいとき。
- すでに遅延の兆候が出ており、まだ手を打てるものと、起きてしまったものを分けて議論したいとき。
向いていない場面
- プロジェクトが中止済み、または終盤の収束に入っているとき。リスク管理のコストが便益を上回るので、ここは振り返りをすべきです。
- チームがまだ方向を模索している高い不確実性の段階。固定したリスク表は、必要な試行錯誤を抑え込みます。
例
入力
目標：11 月末にエンタープライズ版 SSO をリリース。deadline は 11 月 30 日。人員：バックエンド 2 名（うち 1 名は 11 月中旬から休暇）、フロントエンド 1 名。依存：IAM チームの API 提供、法務の DPA 審査。
得られるもの
最低 8 件、人員・外部依存・要件変更・技術的不確実性を網羅し、確率×影響で並べる。各行にトリガー信号（例：IAM 連携の失敗率が 10% 超）、時間・コスト・品質への影響、緩和策、担当者を書き、緩和策は「10 月 30 日までに IAM のサンドボックスを入手する」まで具体化する。すでに起きたこと（IAM の API ドキュメントが 1 週間遅れた等）は別の節に分ける。
よくある誤用
- 「遅れる可能性」「リソース不足」のような一般論を並べる。トリガー信号がないので、いつ動くべきか誰にも分かりません。
- リスクだけを書き、担当者と緩和策を書かない。表は不安のリストになり、会議で一度読み上げて終わります。
こう変えると効く
- 「各リスクに、来週観測できる定量のトリガー信号を 1 つ付ける」と足すと、毎週更新する価値のある表になります。
- 「3 つしか守れないならどれを守り、どれを捨てるか」と足すと、リソースが足りないときの取捨選択に使えます。