課題管理とリスク管理の実務|課題管理表・リスク登録簿の『回し方』
課題管理表が更新されず形骸化するプロジェクトは多い。リスク(未来の不確実性)と課題(顕在化した事象)の違い、起票の粒度、優先度の付け方、ステータスの回し方、定例での棚卸しまで、現役コンサルマネージャーが実践する『止まらない管理表』の運用を解説する。
※ 本記事はアフィリエイト広告(Amazon アソシエイト等)を含みます
課題管理表とリスク登録簿は、PM の生命線です。 しかし現場では「作ったが更新されない」「100 行たまって誰も見ない」と形骸化しがち。本記事は、止まらずに回り続ける管理表の運用を、リスクと課題の違いから実務の型まで整理します。理論面はリスクマネジメントも併読を。
この記事の要点
- 🔮 リスク=未来の不確実性、課題=すでに起きた/顕在化した事象。分けて管理する
- ✍️ 起票は1事象1行、原因と影響を分けて書く
- 🎯 優先度は**影響度 × 緊急度(or 発生確率)**で機械的に付ける
- 🔁 ステータスはOpen → 対応中 → Closeをシンプルに回す
- 🗓️ 定例で棚卸しし、放置 Open を炙り出す
1. リスクと課題は別物
混同されがちですが、扱いが異なります。
| リスク | 課題(Issue) | |
|---|---|---|
| 時制 | これから起こるかも(未来) | すでに起きている(現在) |
| 管理簿 | リスク登録簿 | 課題管理表 |
| 主な対応 | 予防・軽減・回避・転嫁 | 解決・是正・エスカレーション |
| キー項目 | 発生確率・影響度・対応策 | 原因・影響・期限・担当 |
2. 起票の粒度と書き方
管理表が死ぬ最大の原因は「曖昧な起票」です。次を守ります。
- 1事象=1行(複数論点を1行に混ぜない)
- 原因と影響を分けて書く(「○○が原因で、△△に影響」)
- 対応の出口を書く(誰が・何を・いつまでに)
- タイトルは読んで内容が分かる一文に(「要確認」はNG)
3. 優先度は機械的に付ける
「全部高優先」では管理になりません。**影響度 × 緊急度(リスクは発生確率)**のマトリクスで機械的に決めます。
| 緊急度・高 | 緊急度・低 | |
|---|---|---|
| 影響度・高 | 最優先(即対応) | 計画的に対応 |
| 影響度・低 | すきま時間で対応 | 監視のみ/棚上げ |
この基準を関係者で共有しておくと、優先度の主観論争が消えます。
4. ステータスはシンプルに回す
回る管理表
- Open → 対応中 → Close の3状態でシンプル
- 1事象1行・原因と影響が分かれている
- 影響度×緊急度で優先度が機械的に決まる
- 定例で棚卸しし、放置 Open を炙り出す
死ぬ管理表
- ステータスが10種類あって誰も更新しない
- 1行に複数論点が混ざり追えない
- 全部『高』優先で実質ノー優先度
- 起票しっぱなしで Close されない
5. 定例での棚卸しが命
管理表は「作る」より「回す」が9割。週次の定例で次を確認します。
- 期限超過の Open … なぜ動いていないか、エスカレーション要否
- 長期 Open … 放置されている論点の蒸し返し
- 新規起票 … 粒度・優先度のチェック
- Close 候補 … 解決したものを確実に閉じる(表を軽く保つ)
棚卸しで上がった重要案件はステコミへエスカレーションし、経営判断・障害除去を引き出します。
まとめ
- リスク(未来)と課題(現在)を分け、顕在化したら受け渡す
- 起票は1事象1行・原因と影響を分離、出口を書く
- 優先度は影響度 × 緊急度で機械的に
- 定例の棚卸しで放置 Open を炙り出し、重要案件はステコミへ
「止まらない管理表」を持つ PM は、トラブルの初動が速い。これが炎上を未然に防ぎます。
出典・参考情報
関連記事
- EVM(出来高管理)入門|SPI・CPI で進捗と予算を1枚で読む実務
『進捗 80%』が信用できないのは、出来高で測っていないから。EVM の PV・EV・AC の3点と、SPI・CPI・EAC の使い方を、現役コンサルマネージャーが現場目線で解説。難しい計算抜きで『遅れているのか・予算は持つのか』を1枚で判断できるようになる入門記事。
- PMO の役割と立ち上げ|何をする/しないか、現場で機能させる型
PMO を置いたのに『資料を集めるだけの事務局』で終わる組織は多い。支援型・コントロール型・指揮型の違い、PMO がやること/やらないこと、立ち上げ 90 日の進め方を、現役コンサルマネージャーが現場目線で解説。PM と PMO の役割分担まで具体化する。
- ステアリングコミッティ(ステコミ)運営の実務|意思決定を引き出す資料と進め方
ステコミが『報告会』で終わると、決めるべきことが決まらずプロジェクトは停滞する。現役コンサルマネージャーが実践する、意思決定を引き出すステコミの設計——アジェンダ構成、論点の出し方、資料の型、議事と宿題の回し方を、ありがちな失敗とセットで解説する。
- WBS の作り方|現場で破綻しない『分解の粒度』と MECE の実務
プロジェクトの WBS が炎上の火種になるのは、粒度がバラバラで MECE になっていないから。100% ルール・成果物ベース分解・1〜2 週間の粒度・コントロールアカウントなど、現役コンサルマネージャーが現場で使う WBS 設計の型を、よくある失敗とセットで解説する。