課題管理とリスク管理は何が違うのか
プロジェクトの会議で「これは課題です」「いや、リスクでしょう」というやり取りが起きることがあります。言葉の定義の話に見えますが、実務上はもっと重要な違いがあります。どちらに分類するかで、次に打つ手が変わるからです。
■ 分ける基準は「もう起きたかどうか」
リスクは、まだ起きていない出来事です。起きるかもしれないし、起きないかもしれない。だから発生確率という概念があり、対応は「起こさないようにする」「起きても小さく済ませる」方向になります。
課題（イシュー）は、すでに起きている出来事です。確率は100%で、議論の余地はありません。残っているのは「いつまでに、誰が、どう解決するか」だけです。
この区別が曖昧なまま一つの表で管理すると、対応が中途半端になります。すでに起きていることに「発生確率：中」と書いても意味がなく、まだ起きていないことに「解決期限」を設定しても動きようがありません。
■ リスク台帳に書くこと
リスクを扱う表には、次の項目が必要です。
リスク事象：「〜が原因で、〜が起きる可能性がある」の形で書く。「人員不足」ではなく「キーメンバーの離任により、設計工程が2週間遅延する可能性がある」
発生確率と影響度：高中低の3段階で十分。掛け合わせて優先順位を出す
対応方針：回避（やり方を変えて起きなくする）、軽減（確率や影響を下げる）、転嫁（保険や契約で移す）、受容（受け入れて備える）の4つから選ぶ
兆候（トリガー）：何が見えたら「起きかけている」と判断するか
リスクオーナー：監視する担当者
このうち、実務で最も効くのに最も書かれていないのが兆候です。兆候が決まっていないリスクは、監視のしようがありません。「毎週見る」と決めても、何を見るかが決まっていなければ形骸化します。
■ 課題管理表に書くこと
課題を扱う表は、もっと単純です。
課題の内容：何が起きているか
影響：放置するとどうなるか
解決責任者：一人に決める。複数人にすると誰も動かない
期限：いつまでに解決するか
状態：未着手／対応中／解決済み／エスカレーション済み
課題管理表で失敗する原因は、ほぼ2つに絞られます。担当が「関係者一同」のように曖昧なこと、そして期限が空欄のままになっていることです。この2つが埋まっていない行は、実質的に管理されていません。
■ リスクから課題への移行
リスクが現実になったら、課題に移します。このとき、リスク台帳の行を消さずに「顕在化」として残しておくと、後から振り返れます。
振り返りで見るべきは2点です。兆候を捉えられていたか。捉えていたのに手を打たなかったのであれば、監視ではなく意思決定の問題です。兆候そのものを設定していなかったのであれば、リスクの洗い出しの精度の問題です。原因が違えば、次に直すところも違います。
■ 台帳の状態から分かること
2つの表の状態は、プロジェクトの健康状態を映します。
課題ばかりが増え、リスクが数件しかない：先を読めていない。起きてから対応する運用になっている
リスクが50件以上ある：優先順位がついていない。全部見ようとして、結局どれも見ていない状態になりやすい
何か月も状態が変わらない行がある：担当が実質的に不在。棚卸しが必要
解決済みばかりで新規が出てこない：報告しにくい空気ができている可能性がある
最後の項目は見落とされがちです。課題が出てこないことは、良い兆候とは限りません。報告すると責められる環境では、問題は表に出ずに水面下で進行します。
■ エスカレーションの基準を決めておく
課題の中には、プロジェクト内では解決できないものがあります。他部署の協力が必要、追加予算が必要、方針そのものの変更が必要、といった場合です。
こうした課題をPMが抱え続けると、解決しないまま期限だけが過ぎます。あらかじめ「1週間動かなければ上位に上げる」「◯万円を超える判断は持ち込む」といった基準を決めておくと、エスカレーションが個人の判断ではなくルールになり、上げやすくなります。
■ チェックリスト
リスクと課題を別々の表で管理しているか
リスクに兆候（何が見えたら動くか）が書かれているか
課題の担当者が一人に特定されているか
課題の期限が全件埋まっているか
顕在化したリスクを振り返る機会があるか
エスカレーションの基準が決まっているか
リスク管理と課題管理は、どちらも「表を作ること」が目的ではありません。リスク台帳は先を読むための道具、課題管理表は今を動かすための道具です。持っている表がどちらの役割も果たしていないと感じたら、まず2つに分けるところから始めるのが早道です。