フレームワーク活用ガイドひとことで言うと#
プロジェクトで発生した課題を**「発見→記録→分類→担当割当→解決→確認→完了」の標準プロセスで管理**する手法。課題を放置せず、優先度に応じて迅速に解決することで、プロジェクトへの影響を最小化する。
押さえておきたい用語#
- イシューログ（Issue Log）
- プロジェクトの課題を一元的に記録・追跡する台帳のこと。課題管理の「唯一の情報源」として機能する。
- エスカレーション（Escalation）
- 担当者レベルでは解決できない課題を上位の権限者に引き上げて判断を仰ぐこと。期限超過や重大課題で発動する。
- 課題（Issue）
- プロジェクト中にすでに発生している問題を指す。「将来起きるかもしれない」リスクとは区別する。
- SSOT（Single Source of Truth）
- チーム全員が参照する唯一の正しい情報源のこと。課題管理台帳はSSOTでなければならない。
課題管理の全体像#
こんな悩みに効く#
- 課題が口頭でやりとりされ、誰が何を対応中かわからない
- 同じ課題が何度も議題に上がるが解決しない
- 小さな課題が積み重なって大きな問題に発展する
基本の使い方#
課題を一元管理する台帳（イシューログ）を整備する。
- 管理項目: ID、タイトル、詳細説明、発見日、報告者、優先度、担当者、期限、ステータス
- ツールはスプレッドシート、Jira、Backlogなど何でもOK
- チーム全員がアクセス・更新できる場所に置く
ポイント: 課題管理台帳は「唯一の情報源（Single Source of Truth）」。口頭で共有された課題も必ず台帳に記録する。
課題の影響度と緊急度に基づいて優先度を設定する。
- 影響度: プロジェクトのスコープ・スケジュール・コスト・品質への影響の大きさ
- 緊急度: いつまでに解決しないとプロジェクトに支障が出るか
- 優先度を3〜4段階（Critical / High / Medium / Low）で分類する
ポイント: すべてを「High」にすると優先度の意味がなくなる。全体の10〜20%がHigh以上になるのが適正な目安。
各課題に対して「誰が・いつまでに・何をするか」を明確にする。
- 担当者は1名に絞る（複数名だと責任が曖昧になる）
- 期限は具体的な日付で設定する
- 解決のためのアクションプランを記載する
ポイント: 担当者のいない課題は解決しない。発見した時点で必ず担当者を割り当てる。
課題管理台帳を定期的にレビューし、進捗を確認・更新する。
- 毎日のスタンドアップや週次ミーティングで課題の進捗を確認する
- 期限超過の課題にはエスカレーション対応を行う
- 解決済み課題はクローズし、教訓を記録する
ポイント: 課題管理台帳は「生きたドキュメント」。定期レビューがなければ台帳はすぐに陳腐化する。
具体例#
状況: 従業員50名のスタートアップ。開発チーム10名でWebアプリを開発中。課題がSlackの各チャンネルに散在し、「あの件どうなった？」が頻発。
課題管理台帳の運用: Jiraで課題管理ボードを作成。チーム10名全員がアクセス可能。課題の起票は誰でも可能、優先度の設定はPMが実施。
分類・優先度付け: 第2スプリント開始時に15件の課題が起票。内訳: Critical 1件（決済APIの仕様変更）、High 3件、Medium 7件、Low 4件。
定期レビュー: 毎朝のスタンドアップで課題ボードを確認。Criticalの決済API問題は1日で解決。
| 指標 | 導入前 | 導入3ヶ月後 |
|---|---|---|
| 課題の平均解決日数 | 8日 | 2.5日 |
| 放置課題数（月末時点） | 12件 | 1件 |
| 「あの件どうなった」の発生 | 日10回以上 | ほぼゼロ |
課題管理をJiraに一元化したことで、平均解決日数が8日から2.5日に短縮。放置課題もほぼゼロになった。
状況: 従業員500名のゼネコン。商業施設の新築工事（12ヶ月・予算8億円）。現場監督、設計事務所、サブコン15社が関わり、課題が口頭で飛び交う状態。
課題管理台帳: Google スプレッドシートで全関係者がアクセスできる台帳を作成。週次の工程会議で全課題をレビュー。
運用例（抜粋）:
| ID | 課題 | 優先度 | 担当 | 期限 | ステータス |
|---|---|---|---|---|---|
| 001 | 鉄骨納期2週遅延 | Critical | 田中 | 3/15 | 対応中 |
| 005 | 電気設備図面の不整合 | High | 佐藤 | 3/20 | 解決済み |
| 012 | 近隣クレーム対応 | Medium | 鈴木 | 3/25 | 対応中 |
結果:
| 指標 | 前回プロジェクト | 今回 |
|---|---|---|
| 工期遅延 | 2ヶ月 | 0日 |
| 未解決課題の繰越（月次） | 平均15件 | 平均3件 |
| 手戻り工事の発生 | 8回 | 1回 |
この取り組みが示すように、50名規模のプロジェクトでも、シンプルなスプレッドシートの課題台帳と週次レビューで課題の放置を防ぎ、工期遅延ゼロを達成した。
状況: 従業員80名の中小企業。経理DXプロジェクトを社内3名で推進。専任ではなく通常業務と兼務。課題が口頭でやりとりされ、週次の報告書で初めて「あれ未解決だった」と判明するパターンが続いていた。
軽量な課題管理: Notionのデータベースを使い、最小限の項目（タイトル・担当・期限・ステータス）で運用。起票のハードルを下げるため、Slackのコマンドから直接起票できる仕組みを構築。
ルール:
- 課題に気づいたら即起票（3分以内）
- 毎週月曜の30分ミーティングで全課題をレビュー
- 2週間以上オープンの課題はマネージャーにエスカレーション
| 指標 | 導入前 | 導入2ヶ月後 |
|---|---|---|
| 課題の見落とし | 月3〜4件 | 月0件 |
| 週次報告での「初めて知った」 | 毎週あり | なし |
| プロジェクト進捗の可視化 | 不透明 | 透明 |
少人数チームでも「即起票・週次レビュー・2週間エスカレーション」の3ルールで課題の見落としをゼロにし、プロジェクトの透明性を確保できた。
やりがちな失敗パターン#
- 課題とリスクを混同する — 課題は「すでに発生している問題」、リスクは「将来発生する可能性がある問題」。それぞれ別の台帳で管理する
- 課題を起票するだけで放置する — 記録しただけで安心してしまう。担当者・期限・アクションの3点セットが揃って初めて管理と言える
- すべての課題を同じ重みで扱う — 優先度なしでは対応順が決まらない。影響度と緊急度で優先度を設定し、リソースを集中投下する
- 課題管理台帳を複数持つ — Slack、メール、会議メモに課題が分散すると追跡不能になる。唯一の情報源（SSOT）に一元化する
まとめ#
課題管理は、プロジェクトで発生する問題を台帳で一元管理し、優先度に応じて迅速に解決する手法。課題管理台帳の整備・優先度設定・担当割当・定期レビューの4ステップをシンプルに回すことが重要。「担当者・期限・アクション」の3点セットを徹底し、放置課題をゼロにすることがプロジェクト成功への近道。