プロジェクト管理

課題管理（Issue管理）かだいかんり

課題管理Issue管理問題管理トラッキングプロジェクト管理課題票

課題管理（Issue管理）について教えて

簡単に言うとこんな感じ！

プロジェクトで「困ったこと・解決すべきこと」が出たら、放置せずに番号付きで登録して、担当・期限・状態を追いかける仕組みだよ。口頭だけだと「あの問題どうなった？」が繰り返されるから、全部ログに残しておくルールなんだ！

課題管理とは

課題管理（Issue Management） とは、プロジェクトの進行中に発生した問題・障害・未解決事項（課題 / Issue）を識別・登録・追跡・解決・記録するプロセスです。課題は「すでに発生している問題」であり、「まだ発生していないかもしれない問題」であるリスクとは明確に区別されます。

課題管理の核は課題管理表（Issue Log） です。課題を番号で管理し、担当者・期限・優先度・対応状況を一覧できるようにすることで、「誰かが対応してくれると思っていた」「いつの間にか忘れられていた」という事態を防ぎます。例えば「A社APIの仕様書が届かない」「ユーザー確認が取れない設計箇所がある」などが典型的な課題です。

発注者側にとっては、課題管理表を定期的に確認することが重要です。課題は放置されるとプロジェクト遅延・品質劣化・追加コストに直結します。「未対応の課題が多すぎる」「長期間解決されない課題がある」場合は、ベンダーへの催促や意思決定の加速が必要なサインです。

課題管理のプロセスとステータス

ステータス	意味	アクション
新規（Open）	課題が登録されたばかり	担当者・優先度・期限を決める
対応中（In Progress）	担当者が解決に取り組んでいる	進捗確認・サポート
保留（On Hold）	外部要因や意思決定待ちで一時停止	待ち事項の解消を促進
解決済み（Resolved）	対応完了・確認待ち	発注者・PMが確認
完了（Closed）	確認済みでクローズ	教訓として記録
却下（Rejected）	対応不要と判断	理由を記録して合意

課題管理表の記載例

【課題管理表（Issue Log）抜粋】

No. | 登録日    | 概要                   | 優先度 | 担当者  | 期限    | 状態
----|-----------|----------------------|--------|---------|---------|--------
I01 | 2025-09-01| A社APIの仕様書未受領    | 高     | PM/田中  | 09-08   | 対応中
I02 | 2025-09-03| 画面XYZの確認が取れない  | 中     | 発注者/鈴木| 09-10 | 保留
I03 | 2025-08-28| ステージング環境が起動しない| 高   | ベンダー  | 08-30   | 完了
I04 | 2025-09-05| パフォーマンス要件の再確認 | 低    | PM      | 09-15   | 新規

歴史と背景

1960〜70年代: ソフトウェア開発の複雑化とともに「バグトラッキング」の概念が生まれる
1992年: Bugzillaの前身となるシステムがNetscape社内で開発される。オープンなバグ追跡の先駆け
1996年: PMBOKが課題管理（Issue Management）を正式なプロセスとして定義
2002年: Jira（アトラシアン）がリリース。課題管理・バグトラッキングのデファクトスタンダードへ
2010年代: GitHub Issues・Trello・Asanaなど多様なツールが普及。アジャイル開発と融合
現在: 課題管理とリスク管理・タスク管理を統合したプロジェクト管理ツールが主流になっている

リスクと課題の違い

課題管理ツールの比較

ツール	特徴	向いているプロジェクト
Jira	高機能・アジャイル対応・ワークフロー設定豊富	中〜大規模開発プロジェクト
GitHub Issues	コードと連動・シンプル	開発者チーム中心のプロジェクト
Backlog（ヌーラボ）	日本語対応・ガントチャート付き	日本企業の受発注プロジェクト
Redmine	オープンソース・高カスタマイズ	自社運用・コスト重視
Excel/スプレッドシート	導入不要・誰でも使える	小規模・ツール導入困難な場合

規格・番号	内容
PMBOK 第7版（PMI）	課題管理を統合管理プロセスの一部として定義
ITIL v4	インシデント管理・問題管理として詳細に体系化
ISO/IEC 20000	ITサービスマネジメントの国際規格。インシデント・問題管理を要求事項として規定