課題管理表は、すでに起きていて解決が必要な問題を1件1行で記録し、「何が起きたか」「何にどれだけ影響するか」「誰が解決を進め、誰が判断するか」「いつまでに決めるか」「どう決着したか」までを追う表です。まだ起きていないが起きると困る事態は、リスク管理表として別に持ち、実際に起きた時点で課題管理表へ移します。この2つを1つの表に混ぜると、「起きるかもしれない話」の議論に時間を取られ、すでに起きている問題の判断が遅れます。この記事では、課題管理表の項目の見本と記入例、リスク管理表との分け方を示したうえで、表を作っても課題が閉じない理由と直し方を説明します。
課題とリスクの違い
デジタル庁の「デジタル・ガバメント推進標準ガイドライン 解説書」（2026年）は、リスクを「プロジェクトの目標達成を阻害する要因を生み出す可能性がある事態」と説明し、顕在化する前から要因や影響、起きる確率を評価して予防策を考えるものとしています。課題管理については、プロジェクトの遂行や目的の達成を妨げる問題の発生状況をつかみ、解決の方針を定めて「解決すべき課題」として整理し、優先順位を付けて対策を検討・実施するものとし、その内容を課題管理簿にまとめて関係者で共有し、未解決の課題は継続して状況をつかむよう求めています。
この説明をもとに、似たものとの違いを整理すると次のようになります。
| 種類 | 状態 | 表で追うこと | 例 |
|---|---|---|---|
| 課題 | すでに起きていて、解決の方針や判断が要る | 影響・担当・判断者・期限・結論 | 移行するデータに重複が見つかり、どちらを正とするか決まっていない |
| リスク | まだ起きていないが、起きると目標に響く | 起きる見込み・影響の大きさ・予防策・予兆 | 担当者の退職で、検証の人手が足りなくなるおそれ |
| 宿題 | やることと担当が決まっている | 担当・期限・完了 | 議事録を関係者に送る |
| 不具合 | 作ったものが決めた仕様どおりに動かない | 再現手順・修正・確認 | 帳票の合計欄が1円ずれる |
宿題はタスク管理表や会議の決定事項の台帳で、不具合は不具合の一覧で追えば足ります。課題管理表に載せるのは、「どうするか」がまだ決まっていないものだけです。
課題管理表のテンプレート（項目の見本）
| 項目 | 書くこと | 書き方のポイント |
|---|---|---|
| 課題No | 番号 | 連番。取り下げた課題も番号を残す |
| 起票日・起票者 | いつ誰が挙げたか | 起票した人が担当になるとは限らない |
| 件名 | 一言で何の問題か | 「〇〇が決まっていない」のように状態で書く |
| 内容 | 起きている事実 | 推測や意見は分けて書く |
| 影響 | 何に、いつ、どの程度響くか | 「10/15の検証開始に間に合わない」のように日程や作業で書く |
| 優先度 | 高・中・低 | 影響の大きさと、決める期限の近さで決める |
| 担当 | 解決を進める1人 | 情報を集め、選択肢をまとめる人 |
| 判断者 | 結論を決める1人 | 担当と同じでもよいが、必ず書く |
| 期限 | いつまでに決めるか | 「解決」ではなく「方針を決める」期限を書く |
| 状態 | 今の段階 | 新規・対応中・判断待ち・解決・取り下げ |
| 経過 | 調べたこと・話し合ったこと | 日付を付けて追記する |
| 結論・解決日 | どう決めたか、いつ閉じたか | 決めた理由も1行残す |
| 関連 | 関係するリスクや変更の番号 | 計画や仕様の変更につながる場合は変更の番号を書く |
記入例は次のとおりです。
| No | 件名 | 影響 | 優先度 | 担当 | 判断者 | 期限 | 状態 | 結論 |
|---|---|---|---|---|---|---|---|---|
| 7 | 顧客データに重複があり、どちらを正とするか決まっていない | 10/15の移行リハーサルに使うデータが作れない | 高 | 田中 | 営業部長 | 10/3 | 判断待ち | |
| 8 | 旧システムの帳票のうち、使っていないものが分からない | 帳票の作り直しの範囲が決まらない | 中 | 佐藤 | 情報システム課長 | 10/10 | 対応中 | |
| 5 | 利用部門の説明会の会場が取れない | 説明会が1週遅れる | 低 | 鈴木 | 鈴木 | 9/26 | 解決 | オンラインに切り替え（9/25決定） |
リスク管理表の項目の見本
リスク管理表は、課題管理表と同じファイルの別シートに置くと、顕在化したときに行を移しやすくなります。
| 項目 | 書くこと |
|---|---|
| リスクNo | 番号 |
| 内容 | 何が起きるおそれがあるか |
| 原因 | なぜ起きうるか |
| 起きる見込み | 高・中・低 |
| 影響の大きさ | 高・中・低（何に響くかも書く） |
| 対応の方針 | 避ける・小さくする・ほかへ移す・受け入れる のどれか |
| 予防策 | 起きる前にしておくこと |
| 予兆 | 起き始めたことを示すサイン |
| 担当 | 見張る1人 |
| 見直し日 | 次に評価し直す日 |
| 顕在化 | 起きた日と、移した課題No |
自社の課題管理を点検するチェックリスト
- 課題管理表に、宿題や質問、不具合が混ざっていない
- すべての課題に、判断者が1人書かれている
- 期限が「解決する日」ではなく「方針を決める日」になっている
- 「判断待ち」の課題を、判断者が定期的に見る場がある
- 解決した課題に、結論と決めた理由が残っている
- まだ起きていない事態は、別のリスクの一覧で管理している
課題管理表が回らなくなる理由と直し方
何でも載せて件数が膨らむ
気になることを何でも課題として起票すると、件数が百件を超え、どれが重要なのかが分からなくなります。起票の段階で「宿題なら宿題の一覧へ」「不具合なら不具合の一覧へ」と振り分け、課題管理表には方針や判断が要るものだけを残します。振り分けは、定例会議の冒頭などで取りまとめ役が行います。
判断待ちのまま止まる
課題が閉じない原因としてよく見られるのは、担当者は選択肢をまとめ終えているのに、誰が決めるのかが決まっていないことです。判断者の列を必須にし、「判断待ち」の課題だけを判断者が見る時間を会議の中に作ります。会議で決まったことを台帳に残して追う方法は、会議の決定事項の共有方法で扱っています。判断を誰に上げるかの基準は、案件の最初に決めておくと迷いません（プロジェクト立ち上げの手順を参照してください）。
課題とリスクが混ざる
まだ起きていないリスクが課題の一覧に並ぶと、会議ではそれぞれについて「本当に起きるのか」という議論が始まり、すでに起きている問題の判断が後回しになります。リスクは別の一覧で見張り、予兆が出たときや実際に起きたときに課題へ移す、という流れを決めておきます。
結論が計画に反映されない
課題の結論が「スケジュールを1週後ろにずらす」「対象の帳票を減らす」のように計画や仕様を変えるものであれば、課題管理表で閉じるだけでは足りません。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（2026年）は、プロジェクト管理要領にリスク管理・課題管理・変更管理をそれぞれ定めるよう求めています。課題の結論が計画を変えるときは、変更の手続きに回して記録を残します（仕様変更の進め方を参照してください）。
実行時の落とし穴
- 起票者に担当を押し付ける：問題を挙げた人が必ず担当になる運用にすると、誰も課題を挙げなくなります。担当は取りまとめ役が決めます
- 経過を上書きする：経過の欄を書き換えていくと、なぜその結論に至ったのかが後から分かりません。日付を付けて追記します
- 件名を原因で書く：「〇〇さんの確認漏れ」のような件名は、責任の追及に話を向けます。件名は「〇〇が決まっていない」のように状態で書きます
- 表を会議の場でしか開かない：会議の直前に更新する運用だと、課題の発生から起票までに時間がかかります。起きたらその日のうちに起票することを決まりにします
意思決定の責任の所在を先に決める考え方は責任の所在を明確にした決断の仕組みも参考になります。意思決定に関するほかの記事は意思決定・リーダーシップからご覧いただけます。
出典
- デジタル庁「デジタル・ガバメント推進標準ガイドライン 解説書（DS-110）」（2026年）：https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf
- デジタル庁「デジタル・ガバメント推進標準ガイドライン（DS-100）」（2026年）：https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf
