ブログ一覧へ戻る

課題管理表テンプレート|書き方と、放置されない運用ルールの作り方

プロジェクトが遅れる原因の多くは、想定外の事故ではなく「気づいていたのに誰も動かさなかった課題」です。課題管理表は、その放置を防ぐための最小限の仕組みです。この記事では、そのまま使える列構成と書き方のルール、優先度のつけ方、そして最大の難関である「表が放置されないための運用ルール」の作り方までを解説します。

課題管理表とは?タスク・リスクとの違い

課題管理表(Issue Log)は、プロジェクト進行中に発生した課題を一覧化し、担当者・期限・ステータスを紐づけて解決まで追跡するための表です。混同されやすい3つを整理しておきます。

  • タスク:やることが決まっている作業。WBSガントチャートで管理する
  • 課題(Issue):すでに発生していて、解決策や判断がまだ決まっていないもの
  • リスク:まだ発生していないが、発生すればプロジェクトに影響が出るもの

境界線は「解決策が決まっているか」です。「入稿データを作る」はタスク、「入稿データの権利確認先が分からず着手できない」は課題。ここを分けずに1つの表へ混ぜると、タスクの量に埋もれて課題が見えなくなります。リスクが顕在化したら課題管理表へ移す、という運用にしておくと、2つの表の関係も整理されます。

課題管理表の列構成

最低限必要なのは次の12列です。項目を増やすほど更新されなくなるため、これ以上は足さないことをおすすめします。

  • ID―連番。会議やチャットで「課題12の件」と呼べるようにするためのもの
  • 起票日―放置の検知に使う。これがないと「いつからある課題か」が分からなくなる
  • 起票者―詳細を聞ける相手を明確にする
  • 分類―仕様/スケジュール/体制・リソース/コスト/外部要因の5つで足ります
  • 課題の内容―後述のルールに沿って記述する
  • 影響―これが解決しないと何が止まるのか。優先度の根拠になる列
  • 優先度―高/中/低
  • 対応方針―現時点で考えている打ち手。決まっていなければ「未定」と書く
  • 担当者―1名
  • 期限―次のアクションの期限
  • ステータス―未着手/対応中/確認待ち/完了/保留
  • 完了日・結果―どう決着したかを一行で残す

省略されやすいのが「影響」列ですが、これを落とした課題管理表はほぼ確実に形骸化します。優先度が主観になり、全部が「高」になるからです。

書き方の4つのルール

1. 課題は「決めるべきこと」の形で書く

悪い例は「トップページのデザインについて」。良い例は「トップページのファーストビューをA案・B案どちらで進めるか決定する」。一行読んで次に何をすればいいかが分かる粒度まで書きます。「〜について」で終わる課題は、ほぼ確実に放置されます。

2. 影響を必ず書く

「決まらないと実装に着手できず、公開日が3営業日ずれる」のように、止まる作業と日数で書きます。ここが具体的だと、優先度の議論が主観の言い合いにならず、そのままエスカレーションの材料としても使えます。

3. 担当者は必ず1名にする

「関係者全員」「制作チーム」は、誰も動かないのと同じです。判断そのものが他部署にある場合でも、その部署から回答を引き出す担当を自チームに1名立てます。担当者欄に書くのは「解決する人」ではなく「動かす責任を持つ人」です。

4. 期限は「次のアクションの期限」を入れる

見通しが立たない課題ほど、解決期限は入れられません。だからこそ空欄になり、放置されます。代わりに「8日までに法務へ確認を投げる」といった次の一手の期限を入れます。これなら未確定の課題にも必ず期限が入り、遅延を機械的に検知できるようになります。

優先度のつけ方

優先度は影響度と緊急度の2軸で決めますが、判断軸をひとつに絞るなら「クリティカルパス上の作業を止めるかどうか」です。

  • :すでに止まっている作業がある、または期日が動く
  • :今は迂回できるが、特定の日までに解決しないと止まる
  • :解決しなくても進行はできる

運用時のチェックポイントとして、「高」が全体の3割を超えたら優先度が機能していないサインです。基準を厳しくするか、そもそも課題を切り分けきれていないことを疑ってください。

放置されない運用ルールの作り方

課題管理表の失敗は、ほぼすべて「作ったが更新されない」に集約されます。表のフォーマットより、運用ルールのほうが重要です。

1. 見る場を先に決める

週次定例の冒頭10分を課題レビューに固定します。表を作った日に、この時間をカレンダーへ入れてしまってください。「気づいた人が更新する」は運用ルールではありません。

2. 期限切れと停滞を自動で目立たせる

条件付き書式で、期限を過ぎた未完了行を赤くします。起票日がB列、期限がJ列、ステータスがK列の場合の式です。

=AND($J2<>"", $J2<TODAY(), $K2<>"完了")

起票から30日以上動いていない行を検知するなら、次の式を別ルールとして追加します。

=AND($B2<>"", TODAY()-$B2>30, $K2<>"完了")

3. 「保留」に必ず再検討日を持たせる

最も危険なステータスは「保留」です。判断を先送りしたまま忘れられる、典型的な置き場所になります。保留にするときは期限列へ再検討日を入れることを必須にしてください。期限が空欄の保留は、実質的に「消えた課題」です。

4. クローズ条件を決めておく

「対応した」ではなく「影響がなくなった」をクローズ条件にします。対応したつもりで影響が残っている状態は、同じ課題が別の名前で再発する原因になります。完了日と結果を一行残しておけば、再発時に経緯を辿れます。

5. エスカレーションの基準を先に決める

「期限を1週間超過した優先度・高の課題は、次の定例で意思決定者に上げる」といった基準を、運用開始時に決めておきます。基準がないと、エスカレーションするかどうかが担当者の心理的なハードルの問題になり、必ず遅れます。

よくある失敗3つ

課題が多すぎて誰も見なくなる

起票基準がないと、雑談レベルの懸念まで並びます。「担当者が自分の判断だけでは前に進められないもの」を起票基準にすると、量が適正化されます。

ステータスだけが更新される

「対応中」のまま2ヶ月動いていない行は、実質的に未着手です。ステータスは進捗の証拠になりません。期限と起票日で管理してください。

会議のときしか更新されない

定例が1回飛ぶと、そのまま2週間止まります。気づいた時点で誰でも起票できるよう、表は共有ドライブに置き、全員が編集できる状態にしておきます。

スプレッドシート管理の限界

課題管理表は、単一プロジェクトであればスプレッドシートで十分に機能します。ただし次の状況になると、管理コストが跳ね上がります。

  • 施策が並行して走り、課題がファイルごとに分散している
  • 課題がスケジュールや予算にどう影響したのかを、後から追えない
  • 過去の課題と決着内容がファイルの海に埋もれ、同じ議論を繰り返している

Xtrategyでは、施策のスケジュール・予算・KPIと課題を同じ場所で管理できるため、「何が原因で計画からずれたのか」を後から辿れます。キャンペーン単位の管理方法についてはマーケティングキャンペーン管理テンプレートも併せてご覧ください。

まとめ

  • 課題はタスクとリスクから切り分ける。境界は「解決策が決まっているか」
  • 列の要は、影響・優先度・担当者1名・期限・ステータスの5つ
  • 期限には解決期限ではなく「次のアクションの期限」を入れる
  • 期限切れと停滞は条件付き書式で自動的に目立たせる
  • 「保留」には必ず再検討日を持たせる。期限のない保留は消えた課題と同じ
ブログ一覧へ戻る