課題管理とはなにか？プロジェクト推進の妨げと加速を表に載せ、完了条件で閉じる一連の流れ

私はいろいろな現場で課題管理表を見てきました。Excel のこともあれば Backlog のこともありますが、形は違っても、どの現場にも必ずあります。

最近、AI と一緒にプロジェクトを進めるために、課題管理の道具そのものを作ろうとして、手が止まりました。課題管理とは何をすることか、自分の言葉で説明できなかったからです。

そこで、言葉の定義を調べ、似た言葉との関係を整理し、課題管理を自分なりに再定義することにしました。

現場の課題管理表には、たとえばこんな行が並びます。

起きてしまった不具合、計画すべき作業、いつかやりたい改善。種類の違うものが同じ列に並んでいます。この表を出発点にします。

「課題」は何を指す言葉か

まず、言葉から確かめます。「課題」が世の中で何を指しているかを並べます。

プロジェクト管理の体系では、課題は「起きてしまったこと」です。

• PMBOK（第 7 版）は、課題（issue）を「プロジェクト目標に影響し得る、現在の状況」と定義します。リスクとの違いは不確実性で、リスクは「起きるかもしれないが、まだ起きていないこと」、課題は「すでに存在すること」です。
• PRINCE2 は、課題を「起きた、計画になかった、管理判断を要する出来事」とし、変更要求・仕様逸脱・問題／懸念の類型に分けます。正式に扱う課題には、記述・影響評価・推奨をまとめた課題報告書を作ります。

運用の体系には、「課題」に当たる言葉がそもそもありません。

• ITIL 4 に登場するのは問題（problem）で、「1 つ以上のインシデントの原因、または潜在的な原因」と定義されます。管理するのは出来事そのものではなく、その原因です。

一方、日本のビジネスの言葉づかいでは、課題は「これから取り組むこと」です。

• 問題解決の教科書は、問題を「あるべき姿と現状のギャップ」、課題を「そのギャップを埋めるために設定した取り組みのテーマ」と区別します。「目標体重より 10kg 重い」が問題で、「半年で 10kg 減らす」が課題です。
• この使い方では、課題は未来形で、前向きな言葉です。プロジェクト管理の体系が「起きてしまったこと」と定義するのとは、時間の向きが逆です。

並べると、「課題」という言葉には時間の向きが逆の二つの意味があることが分かります。プロジェクト管理の体系が言う「起きてしまったこと」と、日本語のビジネス文脈が言う「これから取り組むこと」。英語の issue log は「課題管理表」と訳されたので、この表の名前には、最初から二つの意味が乗っています。

課題と似た言葉を見分ける

現場の表には、課題のほかにも似た言葉が出入りします。まず、それぞれの一般的な意味を確かめます。

• リスク：まだ起きていない懸念。プロジェクト管理の体系では、課題（すでに起きたこと）と対になる言葉です
• TODO：計画に載っている作業。やることリストの 1 行です
• アクションアイテム：会議の決定や課題への対応から生まれた、担当者と期限つきの個別の行動です
• 改善：今は誰も困っていないが、やると良くなる取り組み。前の節の「これから取り組むこと」にあたる言葉です
• 未決：決めるべきことが、まだ決まっていないもの。体系に対応する言葉が見当たらない、現場の言葉です

なお「問題」は、現場では課題と同義に使われるので、この記事では区別しません（ITIL だけが原因を指す言葉として使います）。

冒頭の表に戻ります。三つの行は、閉じ方が違います。

①の文字化けは、調査して対応の方針を決めないと閉じられません。②の手順書は、方針に迷う余地はなく、書き終われば閉じます。③の改善は、期限も担当も無いまま「保留」に置かれていて、そもそも閉じ方が決まっていません。

三つの行の違いは、担当や期限ではなく、「何が起きたら閉じられるか」の違いです。これをこの記事では完了条件と呼びます。完了条件の型で分けると、課題のまわりの言葉は三つのグループに分かれます。

• 方針が決まったら閉じる：課題、未決
• 実行が終わったら閉じる：アクションアイテム、TODO
• そしてまだ表の外にいる言葉が二つ：リスク（起きたら課題になる）、改善（取り組むと決めたら課題になる）

関係は一枚の図になります。

図の読み方を三つだけ補います。

• 事象は表に載る前の出来事です。図中の問い（次の節で説明します）に答えられるなら、表に載せて課題という 1 件にします
• 課題は二つの流れの合流点です。左から「起きてしまったこと」、右から「これから取り組むこと」が流れ込みます
• アクションアイテムと TODO は同じ作業です。計画に載せる前をアクションアイテム、載せた後を TODO と呼び分けているだけです

そして、どのグループにも属さない横断的な考え方がペンディング（進められない状態）です。詳しくは次の節で見ます。

関係を整理すると、分かることが四つあります。課題は、「起きてしまったこと」と「これから取り組むこと」という二つの流れの合流点であること。表の 1 件 1 件は、完了条件の型 — 方針が決まったら閉じるのか、実行が終わったら閉じるのか — で見分けられること。ペンディングは行の種類ではなく、どの行にも当てはまる横断的な考え方であること。アクションアイテムと TODO は、同じ作業の計画に載せる前と後の呼び分けであること。

ここまでは「課題」という言葉の話です。では、それを「管理する」とは、何をすることなのか。次はそちらを見ます。

管理するとは、何をすることか

先ほどの図には、四つの動きが矢印として出てきていました。載せる、決める、組み込む、閉じる。管理とは、この四つを回すことです。順に見ます。

載せる

表に載せるとき、問うことは二つです。

• 放置すると、いつ、何が起きるか
• やると、いつ、何が生まれるか

どちらかに答えられるものだけを載せます。冒頭で説明したとおり、課題には「起きてしまったこと」と「これから取り組むこと」の二つの流れがありました。最初の問いは前者を、二つ目の問いは後者を拾うための問いです。答えから、期限・優先度・完了条件が決まります。

• 期限 ＝ 影響が現れる日・価値を受け取りたい日。担当者がいつやるかではありません
• 優先度 ＝ 影響の大きさ × その日の近さ。高・中・低を勘で選ぶ列ではなくなります
• 完了条件 ＝ 書いた弊害が起きない、または書いた価値が実現したと確かめられた状態

決める

載せた行には、対応を決めます。やるのか、やらないのか。「対応しない」と決めた行は、方針が決まった時点で完了条件が満たされるので、ここで閉じます。

組み込む

実行が必要な対応は、アクションアイテムに分解して WBS に組み込みます。組み込んだ後は計画側の作業（TODO）です。課題管理表が持つのは「何を、なぜ」、WBS が持つのは「いつ、誰が、どうやって」。同じことを両方に書きません。

閉じる

アクションアイテムが全部終わっても、元の課題はまだ閉じません。アクションアイテムは課題の子で、子が全部終わることと、親の完了条件が満たされることは別だからです。対処を入れたのに翌週も同じエラーが出るなら、課題は開いたままです。完了条件が満たされたことを確かめて、閉じます。

もう一つ、何もしていないのに期限が過ぎて、何も起きなかった行があります。リスク管理には、リスクを「発生せず」と閉じる考え方があります。それと同じように、この行も「発生せず」として閉じます。消したのではなく、影響が出なかった事実を残す閉じ方です。

進められない行（ペンディング）

理由は三つで、打ち手が違います。

• 決まっていない → 決められる人に持ち込む
• 揃っていない（人・モノ・情報・時期）→ 足りないものの相手に催促する
• 止めている → 再開条件を書いて寝かせる

理由が書かれていないペンディングは、打ち手を選べないので、そのまま止まり続けやすい行です。

1 件の課題で通す — 移行作業の例

システム移行の現場を例に、いま述べた一連の流れ — 載せる、決める、組み込む、閉じる — を 1 件の課題で最初から最後まで通してみます。

妨げる側の例

• きっかけ：移行テストで、文字コードに起因するエラーが大量に出た
• 放置すると、いつ、何が起きるか：本番の切替で同じエラーが起き、移行が失敗する。影響が出るのは本番切替日
• 載せる：答えられたので表に載る。期限＝本番前のリハーサル（そこでエラーが出ないことを確かめるため）、完了条件＝リハーサルで一連の移行手順を通して、エラーが出ないこと
• 決める・組み込む：原因調査と変換処理の修正をアクションアイテムに分解し、WBS に割り込ませる
• 閉じる：リハーサルでエラーが出ないことを確かめて閉じる。作業が終わってもエラーが残れば、開いたまま

加速させる側の例

• きっかけ：移行作業は時間枠に収まっている。ただ、並列化すればもっと短くできそうだと気づいた
• 放置すると、いつ、何が起きるか：何も起きない（このままでも本番は成立する）
• やると、いつ、何が生まれるか：停止時間が縮まり、サービスの再開が早まる。価値を受け取る期限は本番切替日
• 以降は同じ流れで、載せて、決めて、組み込み、短縮できたことを確かめて閉じる

片方は放置すると本番が失敗する行、もう片方は放置しても何も起きない行です。それでも、二つの問いに答えれば、同じ表で管理できます。

まとめ

課題管理とは、プロジェクトを妨げるもの、または加速させるものを表に載せ、対応を決めて WBS に組み込み、完了条件が満たされたことを確かめて閉じる、一連の流れです。

冒頭の、課題も TODO も問題も一括りになった課題管理表は、間違ってはいません。種類ごとに表を分ける必要もありません。1 件ごとに、二つの問いの答えと完了条件が書いてあれば、その行が「方針が決まったら閉じる」のか、「実行が終わったら閉じる」のか、なぜ進められないのかを読み分けられます。

出典

• 本人の経験則。2026-09-05〜06 の壁打ちで言語化した
• PMI: You've got way too many issues! ／ Project Risks and Issues – What's the Difference? — PMBOK 7 の issue 定義
• PeopleCert: PRINCE2 7 Issues ／ PRINCE2 wiki: Issues — PRINCE2 の issue と類型
• ManageEngine: ITIL 4 Glossary — problem の定義
• GLOBIS: 問題解決のアプローチ ／ Enablers: 問題と課題の違い — 問題＝ギャップ、課題＝取り組みテーマ

関連

• 仕事の進め方_INDEX（未公開） — 働き方と仕事の進め方のノート群の目次