課題管理表の作り方と書き方｜項目の決め方と運用のコツ

課題管理表は、プロジェクトで起きている問題を一覧にして、誰がいつまでに解決するのかを揃えて追いかけるための表です。項目を絞って一つの課題を一行で書き、担当と期限を必ず入れれば、特別なツールがなくても回ります。

この記事では、課題管理表の目的とリスク・タスクとの違い、入れるべき項目、書き方のポイント、システム導入と業務改善の記載例、定例での運用方法、うまく回らないときの見直し方を順に解説します。本文の項目一覧と記載例をそのまま写せば、自分で課題管理表を作れる状態を目指します。若手のPMOやプロジェクトメンバーが、初めて表を任されたときの手引きとしてお使いください。

課題管理表とは

課題管理表とは、すでに発生している問題を記録し、解決まで担当者と期限を管理するための一覧表です。起きてしまった問題を放置せず、関係者全員が同じ情報を見て動けるようにすることが役割です。

目的

課題管理表の目的は、問題を見える状態にして、解決の責任者と期限を決めることです。口頭やチャットだけで課題をやり取りすると、誰が引き取ったのかが曖昧になり、数週間後に同じ問題が再燃します。

課題を一覧にしておくと、定例会議で全員が同じ画面を見ながら優先順位を話し合えます。プロジェクトを引き継ぐ人が経緯を追える点も利点です。一般的な課題ログには、管理番号、起票日、内容の説明、優先度、担当者、状況、期限、対応結果といった項目が含まれるとされています（PM Study Circle「What is an Issue Log in Project Management?」参照）。

リスク・タスクとの違い

課題は「すでに起きている問題」、リスクは「これから起きるかもしれない問題」、タスクは「やると決まっている作業」という違いがあります。三つを同じ表に混ぜると、期限の意味がそれぞれ変わってしまい、管理が崩れます。

実務では、リスクが現実になった時点で課題へ移し替えます。「担当者が離脱するかもしれない」というリスクが「担当者が離脱した」という課題に変わった瞬間に、課題管理表へ起票する流れです。課題の解決策が複数の作業に分かれる場合は、課題は一行のまま残し、作業はタスク管理側で追いかけると表が膨らみません。

入れるべき項目

課題管理表に入れる項目は、起票日、起票者、内容、影響度、担当、期限、状況、対応履歴の八つが基本です。項目を増やしすぎると記入が負担になり、更新が止まるため、まずはこの範囲から始めるのが現実的です。

起票日と起票者

起票日と起票者は、その課題がいつ誰から上がったのかを残すための項目です。経過日数が分かると放置されている課題を見つけやすくなり、起票者が分かれば確認や追加のヒアリングを誰にすればよいかが明確になります。

起票日は「10/01」のように月日で十分です。起票者は個人名だけでなく部署名も添えると、部門をまたぐプロジェクトで連絡先を探す手間が減ります。

内容と影響度

内容は「何がどうなっているか」を一文で書き、影響度は「放置するとプロジェクトにどの程度響くか」を高・中・低の三段階で示します。影響度を数値の細かい点数にすると、判定のたびに議論が起きて運用が重くなります。

• 高：スケジュールや品質に直ちに影響し、責任者の判断が必要
• 中：対応が遅れると影響が出るが、現場の判断で進められる
• 低：すぐの影響はなく、余力のあるときに対応できる

担当・期限

担当は課題を解決する責任者を一人、期限は解決する日付を一つ書きます。複数人の名前を並べると全員が「ほかの人がやる」と考えがちなので、共同で動く場合も代表の一人を決めます。

期限は「来週中」ではなく「10/18」のように日付で書きます。調整に時間がかかる課題は、解決期限とは別に「方針を決める日」を期限にして、段階を分けると遅れに早く気づけます。

状況と対応履歴

状況は「未着手」「対応中」「確認待ち」「完了」の四つ程度に絞り、対応履歴には日付とともに何をしたかを追記します。履歴を上書きせず積み重ねると、あとから経緯を説明するときの根拠になります。

履歴は「10/10 ベンダーへ見積を依頼」「10/14 回答受領、費用は想定内」のように短く書きます。状況の言葉は担当者ごとに表現が割れやすいため、選択式にしておくと集計もしやすくなります。

書き方のポイント

課題の書き方で押さえるのは、一つの課題を一行で書くことと、期限と担当を必ず入れることの二点です。この二つが守られていれば、表は読みやすく、更新も続きます。

一つの課題を一行で書く

一つの課題は一行にまとめ、複数の問題が混ざっていたら行を分けて起票します。一行に二つ以上の問題が入ると、片方が解決しても状況を「完了」にできず、課題が塞がったまま残ってしまいます。

書き方の型として、「何が」「どうなっている」を一文にすると整います。たとえば「顧客データの重複が多く、移行の準備が進まない」という書き方です。「データの件」「テスト環境」のような名詞だけの書き方は、読む人によって解釈が分かれるため避けます。原因や解決策の候補は、内容の欄ではなく対応履歴に書くと一行に収まります。

期限と担当を必ず入れる

期限と担当が空の課題は、表の上では課題として扱いません。起票の時点で入れられない場合は、「担当を決める」こと自体を定例の議題にして、次の定例までに埋めます。

実務では、誰の課題か分からないまま起票だけされる行が、表の中で最も長く残ります。起票者が「自分が担当するか、誰に頼むか」をその場で一言添えるルールにすると、空欄が減ります。担当を決められる立場の人が定例にいるかどうかも、運用の成否を分ける点です。

記載例を見てみよう

記載例は、システム導入と業務改善の二つの架空のプロジェクトで示します。項目の粒度と書き方の温度感をつかむ手がかりとして使ってください。

システム導入プロジェクトの例

システム導入では、データ移行や環境準備など、他部署やベンダーとの調整にかかわる課題が中心です。次の表は、旧システムから新システムへの切り替えプロジェクトを想定した記載例です。

No.1は移行の可否を左右するため影響度を「高」とし、期限も近く設定しています。No.3のようにすぐの影響がない課題は「低」にして、優先度の高い課題に定例の時間を使えるようにします。

業務改善プロジェクトの例

業務改善では、現場の運用や関係者の合意にかかわる課題が多く、「誰が決めるか」を明確にすることがポイントです。次の表は、受発注業務の見直しを想定した記載例です。

こちらは対応履歴を厚めに書き、経緯を追える形にしています。同じ課題でも、システム導入の例は状況、業務改善の例は履歴を重視するなど、プロジェクトの性質に合わせて列を入れ替えて構いません。

運用のコツ

課題管理表の運用では、定例で全件を確認する時間を固定し、完了の基準を事前に決めておくことが要になります。作って終わりではなく、更新される仕組みを先に用意します。

定例での確認方法

定例では、期限が近い課題と期限を過ぎた課題から順に、担当者へ進み具合を確認します。全件を同じ重さで読み上げると時間が足りなくなるため、影響度が高いものと期限超過のものに絞って話すのが現実的です。

1. 期限を過ぎた課題について、遅れの理由と新しい期限を確認する
2. 影響度が高い課題について、必要な判断や支援を決める
3. 新しく起票された課題に、担当と期限を割り当てる
4. 完了した課題を確認し、クローズする

こうした課題管理の運営は、PMOの中心的な仕事のひとつです。フリーランスのPMOの月額単価は80〜150万円が標準とされ、課題の整理と推進を任される役割によって幅があります（ドメイン知識ベース「PMOフリーランスの月額単価相場と役割別レンジ」）。経験を積んだ後に案件を探すときは、大手企業は個人と直接契約せず、エージェントを挟んだ契約になるケースが多いため、まず2〜3社に登録して選択肢を広げる進め方が基本とされています（ドメイン知識ベース「案件獲得の基本ルート」）。PMOの役割や進め方はPMOとは何かを解説した記事、案件の探し方はPMOフリーランスの案件獲得を解説した記事もあわせてご覧ください。

クローズの基準

課題をクローズする基準は、「原因への対応が終わり、再発しないことを担当者と起票者の双方が確認できた時点」にそろえます。担当者が「対応しました」と申告しただけでは、起票者の困りごとが解消されていない場合があるためです。

クローズの際は、完了日と結果を対応履歴に一行残します。解決せずに取り下げる課題は、取り下げる理由と判断した人を必ず記録し、「完了」とは別の状況として扱います。そうすると、あとから「なぜこの課題は対応しなかったのか」と聞かれたときに説明できます。

うまく回らないときの見直し

課題管理表が回らなくなる原因の多くは、課題が放置されることと、起票が増えすぎて追えなくなることのどちらかです。症状ごとに見直す点を整理しておくと、立て直しが早くなります。

放置される課題

課題が放置される主な原因は、担当が曖昧であること、期限が遠すぎること、定例で話題にならないことの三つです。まず、放置されている行の担当と期限が埋まっているかを確認します。

担当が決まっているのに動かない場合は、担当者が「自分だけでは解決できない」と感じているのかもしれません。その場合は、課題を小さく分けるか、判断できる立場の人を巻き込むことが必要です。起票から一定の日数が過ぎた課題を、定例の冒頭で必ず読み上げるルールにすると、放置が目に見えるようになります。

起票が増えすぎる場合

起票が増えすぎるときは、課題の定義が広がり、課題・リスク・タスクが混ざっている可能性があります。まずは課題・リスク・タスクの三つを分け直し、課題として残すものを「すでに起きている問題」に限ります。

それでも件数が減らない場合は、影響度が「低」のものを別の表やバックログに移し、定例では扱わない運用にします。件数が多いこと自体は悪くありませんが、全件を定例で追うと時間が足りず、重要な課題が埋もれます。課題管理表は「追いかけられる件数に絞ること」が続けるための条件です。

より広い視点で進め方を整理したい場合は、課題管理表の作り方を扱った記事や、PMBOKの考え方で課題管理表を解説した記事も参考になります。作業の分解についてはWBSの作成手順、役割分担の整理についてはRACI図の作り方も、課題の担当を決める場面で役立ちます。

出典・参考情報

1. PM Study Circle「What is an Issue Log in Project Management?」（2026-10-07参照）：課題ログに含まれる一般的な項目
2. ドメイン知識ベース「PMOフリーランスの月額単価相場と役割別レンジ」（2026年時点）
3. ドメイン知識ベース「案件獲得の基本ルート」（2026年時点）

最終更新日：2026年10月7日。記載例は説明用の架空の内容です。プロジェクトの規模や契約条件により運用は異なるため、個別の判断は関係者や専門家にご相談ください。