【管理表テンプレ付】プロジェクト課題管理の鉄則｜塩漬けを防ぎゴールへ導く4ステップ
「課題と進捗、それにバグ（欠陥）の違いがいまいち分からない……」 「課題がいつまでも解決されず、気がつけばプロジェクトが止まってしまっている」
プロジェクトを進めていると、当初の計画にはなかった検討事項や、進行を妨げるトラブルが必ず発生します。これらを「課題」として切り出し、誰が・いつまでに解決するかを管理するのが「課題管理」です。
課題が誰のボール（担当）か分からないまま放置されると、最終的にスケジュールや予算の大きな遅延を招きます。この記事では、課題を「塩漬け」にせず確実に解消するための運用術と、現場ですぐに使える管理表のテンプレートを解説します。
課題管理とは？ 進捗・欠陥・リスクとの「決定的な違い」
現場でよく混同される用語との違いを整理しました。ここを明確にすることが、正しい管理の第一歩です。
4つの管理手法の違い
| 管理手法 | 扱う対象 | 役割・目的 |
|---|---|---|
| 進捗管理 | 予定していた「作業（タスク）」 | 計画通りに作業が進んでいるかを確認する。 |
| 欠陥管理（バグ管理） | プログラムの「不具合（バグ）」 | 見つかった不具合を修正し、品質を確保する。 |
| リスク管理 | まだ起きていない「未来の懸念事項」 | 未来のトラブルを予測し、事前に対策を打つ。 |
| 課題管理 | 今すでに起きている「問題・未決定事項」 | 進行を妨げる要因や未決定事項を解消する。 |
課題管理が必要な3つの理由
課題管理を適切に行わないと、プロジェクトは「待ち」の状態が増え、最終的に納期直前でパニックに陥ります。
- 意思決定の遅れを防ぐため： 「誰かが決めるだろう」という曖昧さを排除し、期限（デッドライン）を設定することで、関係者に迅速な判断を促します。
- 状況を「見える化」して共有するため： 「何がプロジェクトの足を引っ張っているか」を全員で共有します。特定の担当者が抱え込むのを防ぎ、周囲がサポートできる体制を作ります。
- 解決の履歴を「資産」にするため： なぜその決定に至ったのかという「経緯」を残します。後から「なぜこうなったの？」と蒸し返されるのを防ぎます。
【失敗事例】「なんとかする」を信じた結果招いた、テスト延期の悲劇
お客様の受入テスト直前、マスターデータ担当の小野さんと、お客様（高田さん）のやり取りです。
マスター担当
小野さん
商品マスターの準備はどうですか？ 3日後のテスト開始に間に合いますか？
注文業務課
高田さん
最近忙しくて……まだ3割くらいかな。なんとかするから待ってて！
3日後（テスト当日）……
マスター担当
小野さん
データを受け取りに来ました！
注文業務課
高田さん
ごめん、半分しかできてない。できないものはできないわよ……
マスター担当
小野さん
ええっ！ 今日からテストなのに……（もっと早くリーダーに相談しておけばよかった）
小野さんは高田さんの「なんとかする」という言葉を信じ、課題を自分だけで抱え込んでしまいました。その結果、リーダーが動くのが遅れ、テスト開始の延期という最悪の事態（炎上）を招いたのです。
塩漬けを許さない「課題管理プロセス」4つのステップ
課題を「塩漬け」にせず、確実にクローズ（解決）するためのフローです。
- ステップ1：課題の抽出と登録（ゴールを明確にする）
- 問題に気づいた人が、速やかに「課題管理表」に登録します。「何が問題か」だけでなく、「何が決まれば解決か（ゴール）」をセットで記述するのがポイントです。
- ステップ2：担当者と期限の割り当て（ボールを持たせる）
PMやリーダーが内容を確認し、「解決の担当者（いまボールを持っている人）」と「解決期限」を割り振ります。期限は後続の作業から逆算して設定します。 - ステップ3：対策の検討と実施
担当者が中心となり、関係者と調整します。検討プロセスや「暫定回答」も管理表に随時記録し、進捗を誰でも追えるようにします。 - ステップ4：解決の確認とクローズ
ゴールを満たしたことを確認し、課題をクローズします。決定事項は必ず設計書や計画書などの「成果物」へ反映させます。
【図解】課題管理フローと「誰がボールを持つか」の役割定義
課題が停滞する最大の原因は、「誰がボールを持っているか（誰が決めるか）」が不明確なことです。
課題管理における各担当者の役割
| 職務名称 | 課題管理における役割 | 目的 |
|---|---|---|
| 統括責任者（お客様） | 重大課題の最終意思決定 | 予算や業務方針に関わる判断を下す。 |
| PM（両者） | 優先順位の判断と監視 | 停滞している課題を察知し、解決を促す。 |
| PL / リーダー | 課題の抽出と調整 | 現場の課題を管理表に載せ、解決案を練る。 |
| QA（品質保証） | 停滞課題へのアドバイス | 第三者の視点でリスクを指摘し、停滞を防ぐ。 |
課題管理フロー（お客様とシステム会社の対応手順）
| 手順（図の番号） | 担当 | 実施内容 |
|---|---|---|
| 1. 課題発生（①②） | 両者 | 課題が発生したら、プロジェクト担当者へ連絡する。 |
| 2. 記録・共有（③） | 開発側 | 課題内容をヒアリングし、管理表へ記録する。お客様へも通知し共有する。 |
| 3. 調査・検討（④） | 開発側 | 課題内容を調査し、対策を検討する。 |
| 4. 整合・承認（⑤⑥） | 両者 | 単独で解決しない場合や全体に影響する場合は、両者で対策を整合し、責任者の承認を得る。 |
| 5. 対応実施（⑦） | 両者 | 決定した対策に基づき、課題の対応を行う。 |
| 6. 変更管理へ（⑧） | 開発側 | 対策が「仕様変更」に係わる場合は、変更管理プロセスへ移行・記録する。 |
そのまま使える！「課題管理表」の必須項目一覧
そのままExcelやスプレッドシートの列名として使えるよう、記録すべき項目を整理しました。
| 分類 | 記録項目 | 項目内容 |
| 課題内容 | 発生日 | 課題の報告を受け付けた日 |
| 課題内容 | 課題の内容 | |
| 対応希望日 | 課題の対応を希望する日 | |
| 課題報告者 | 課題を報告した担当者 | |
| 状況 | 「受付」「調査中」「対策検討中」「承認済」「対策実施中」「却下」「完了」などの状態 | |
| 調査結果 | 課題原因 | 課題の原因（業務面の課題、システム面の課題、インフラ面の課題、プロジェクト運営上の課題、質問事項など） |
| 発生工程 | 課題が見つかった工程（概要設計、詳細設計、開発、結合テスト、システムテストなど） | |
| 対策内容 | 課題の対策内容（対応内容やポイント、注意事項など） | |
| 調査担当者 | 調査をした担当者 | |
| 対策判定 | 採否判定 | 対策を承認するか、却下とするか |
| 採否確定日 | 採否が決定した日 | |
| 優先度 | すぐに対策が必要か、後工程で対策すればいいか等の優先度合い | |
| 承認者（お客様） | お客様側の責任者 | |
| 承認者（システム会社） | システム会社側の責任者 | |
| 対応完了 | 対応担当者 | 対応した担当者 |
| 対応完了日 | 対応が完了した日 |
【プロの視点】停滞（塩漬け）をゼロにする3つの運用テクニック
最後に、課題管理表を「ただのリスト」で終わらせず、プロジェクトを前に進めるための極意をお伝えします。
① 「質問（QA）」と「課題」を明確に切り分ける
管理表が「この仕様はどうなっていますか？」という質問で埋め尽くされると、本当に重要な課題（＝決めなければならないこと）が埋もれてしまいます。 単なる確認事項は「QA表」へ、プロジェクトを止める決定事項は「課題管理表」へと明確に切り分けましょう。
② 「期限切れ」は自動的にエスカレーションする
「期限を過ぎても解決しない課題」は、現場担当者の手には負えない（＝ボールが重すぎる）可能性が高いです。 「期限超過は即リーダーへ報告」というルールを徹底することで、先ほどの小野さんのような「一人で抱え込んで炎上するケース」を防げます。
③ 定期的な「棚卸し」で不要な課題を却下する
「検討した結果、対応不要になった」課題が「未解決（調査中）」のまま残ると、管理の精度が落ちます。 週に一度は管理表を棚卸しし、不要なものは「却下（クローズ）」、仕様変更になるものは「変更管理」へと整理し、常に最新の「対応すべき課題」だけが見える状態を保ちましょう。
まとめ：課題管理表はプロジェクトの「健康診断書」である
課題管理表に並ぶ項目の数や解決のスピードは、プロジェクトの健康状態を映し出す鏡です。
- どんなに小さな課題も、即座に登録して「見える化」する。
- 「誰のボールか（担当者）」と「期限」のない課題を絶対に作らない。
- 「質問（QA）」と「課題」を分け、重要な決定を優先する。
課題一つひとつを丁寧かつ迅速に解消していくことが、プロジェクトを停滞させず、ゴールへと導く唯一の道です。
次回は、プロジェクトを脅かす不確実性に先手を打つ「リスク管理」について解説します。ぜひ併せてお読みください。
