はじめに
プロジェクトの現場で、「リスク」と「課題（イシュー）」という言葉が、きちんと区別されずに使われている場面をよく見かけます。言葉の違いを曖昧にしたまま管理表だけ別々に用意しても、実際の運用では両者がごちゃ混ぜになり、管理表そのものが機能しなくなってしまいます。リスクと課題の違いを整理します。
リスクと課題は「時間軸」が違う
リスクと課題の最も本質的な違いは、まだ起きていないことか、すでに起きていることかという時間軸の違いです。
リスクとは、将来起こる「かもしれない」不確実な事象です。「ベンダーのキーマンが離任するかもしれない」「要件定義が長引くかもしれない」といった、発生が確定していない潜在的な問題です。
課題（イシュー）とは、すでに顕在化し、対応が必要になっている事象です。「ベンダーのキーマンが実際に離任した」「要件定義が実際に長引いている」というように、リスクが現実になった（あるいは最初から確定事象として発生した）状態です。
混同するとマネジメントが機能しなくなる理由
この違いを曖昧にしたまま運用すると、次のような問題が起きます。
- 対応の優先順位がつけられない：「まだ起きていないかもしれないこと」と「すでに起きていて今すぐ対応が必要なこと」を同じ表で並べて見てしまうと、どちらを優先すべきかの判断軸がぼやけます
- リスク管理表が形骸化する：すでに顕在化した課題をリスク管理表に書き続けてしまうと、「発生確率」「影響度」といったリスク特有の評価軸が意味を持たなくなります
- 対応のタイミングを誤る：リスクは「予防策」と「発生時の対応策（コンティンジェンシープラン）」を事前に準備しておくものですが、課題は「今すぐの対応」が求められます。両者を混同すると、本来すぐ対応すべき課題への着手が遅れることがあります
リスク管理表の作り方と運用｜発注側が知っておくべき3つのポイント、課題管理表は「起票してからが本番」｜リスク管理表との使い分けでそれぞれの管理表について触れていますが、まず前提として、この時間軸の違いを関係者全員が正しく理解しておくことが、どちらの管理表も機能させるための土台になります。
リスクが「顕在化」したら、課題に転記する
実務上の運用としては、リスク管理表で監視していた事象が実際に発生した時点で、課題管理表に新規起票し直すという流れが基本になります。リスク管理表側は「発生した」というステータスに更新し、以降の実際の対応は課題管理表で追跡します。
この転記のタイミングを曖昧にしないため、「誰が、どういう基準で、リスクが顕在化したと判断するのか」をプロジェクト開始時に決めておくことをおすすめします。判断基準が曖昧だと、顕在化しているのにリスク管理表に放置されたままになる、という事態が起きやすくなります。
実際に使っているリスク管理表・課題管理表のテンプレートは、noteで配布しています。リスクから課題への転記も含めた運用のイメージがつかみやすい構成にしています。
まとめ
リスクと課題の違いは、「まだ起きていないか、すでに起きているか」という時間軸にあります。この違いを曖昧にしたまま管理すると、対応の優先順位がつけられず、管理表そのものが形骸化してしまいます。リスクが顕在化した時点で課題として転記する運用ルールを事前に決めておくことが、両方の管理表を機能させるための鍵です。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント