『課題が「対応待ち」のまま止まる・誰も拾わない』を防ぐ課題管理：課題管理表（イシューログ）テンプレートとエスカレーション基準の型

型：課題管理表（イシューログ）テンプレート

課題が「対応待ち」のまま止まり、誰も拾わない現場には共通する手前の状態があります。課題管理表（イシューログ）に「対応待ち」という独立した区分がなく、誰かの返答や承認を待っている課題が「対応中」のまま埋もれています。最終更新日の欄もなく、いつから止まっているのかを誰も数えられません。

下の10項目は、課題を登録した瞬間にこの状態を終わらせるための1枚です。課題が発生したら、この用紙を埋めることが最初の作業になります。

課題管理表の項目構成と「書くときの基準」は、Backlog公式ヘルプが示す課題の標準状態（未対応・処理中・処理済み・完了）の確認と、Atlassianの自動化ルールが示す期限超過の検知方法（出典参照）を踏まえて、編集部が実務運用として構成したものです。

型：放置期間ベースのエスカレーション基準

エスカレーションは、現場で解決できない課題や判断を上位者へ引き上げることです。コミュニケーション管理の実務手順が示すレベル1〜3の判定基準は、課題が新しく発生した瞬間に、影響度と緊急度から初回の重要度を決めるためのものでした。本記事の基準表はその先にある話で、重要度がついたあと課題管理表に登録された課題が「対応待ち」のまま何日止まったら上に引き上げるかを決めるためのものです。初回の重要度判定と、放置を検知する判定は、別の軸として両方持つ必要があります。

基準は重要度ごとに営業日数で置きます。日数はあくまで目安で、定例の頻度やプロジェクトの規模に合わせて調整してください。重要なのは、日数という機械的な基準を先に決め、「まだ大丈夫そう」という感覚で棚卸しをすり抜けさせないことです。

型：週次棚卸しチェックリスト（経過日数を数える→エスカレーション対象を確定する）

課題管理表とエスカレーション基準ができたら、週次の定例で例外なく回す5段階のチェックリストです。この5段階のどこかを省略すると、「対応待ち」の課題は基準表があっても拾われません。

なぜ課題は「対応待ち」のまま誰にも拾われないのか

Backlog公式ヘルプが示す課題の標準状態は、未対応・処理中・処理済み・完了の4区分です（出典参照）。この4区分には、誰かの返答や承認を待っている状態を示す専用の区分がありません。担当者が「自分の番ではない」と分かっていても、ステータスを更新する先がないため、その課題は「処理中」のまま残り続けます。これは特定のツールの欠陥ではなく、汎用的なステータス設計が「作業中かどうか」しか区別していないために起きる、構造的な見落としです。

もう1つの原因は、最終更新日を記録する欄がないことです。「処理中」という状態は分かっても、いつからその状態なのかが分からなければ、10日止まっている課題と今日止まった課題を区別できません。棚卸しをしても「また処理中か」で流され、放置は発見されません。

3つ目は、所有権の空白です。「対応待ち」は相手の動きを待つ状態なので、課題管理表の担当者欄に名前があっても、その人は「自分のボールではない」と考えがちです。督促する責任が誰にあるかを決めておかないと、担当者も、相手も、PMも、誰も動かないまま時間だけが進みます。課題管理表の「対応状況」欄に「対応待ち」を独立させ、最終更新日を必ず置くのは、この3つの空白を塞ぐためです。

項目ごとに迷うところ：重要度と緊急度を分ける・担当者は個人名で置く

実務でもっとも書き間違えやすいのは、重要度の欄です。起票者が「急いでいるから高」と書いてしまうと、締切が近いだけの軽微な課題まで「高」になり、本当に影響が大きい課題と区別できなくなります。重要度はプロジェクトへの影響の大きさで判定し、どれだけ急いで対応すべきかという緊急度は、放置期間ベースの基準表（何営業日でエスカレーションするか）のほうで吸収します。2つの軸を1つの欄に混ぜないことが、基準表を機能させる前提になります。

担当者欄も見落としやすい項目です。「開発チーム」「ベンダー」と組織名で書くと、誰も個人として監視しないまま時間が過ぎます。対応待ちで止まっている相手側の担当者が分かっているなら、その名前も合わせて書いておくと、棚卸しのときに誰に連絡すべきかが一目で分かります。

対応状況を「対応待ち」に変更するタイミングも決めておきます。自分の作業を終えて相手の返答を待つ状態になった時点で、その日のうちに「対応中」から「対応待ち」へ変更し、最終更新日を入れます。変更を後回しにすると、実際の放置期間より短く見えてしまいます。

SLA的な発火点という考え方：期限ではなく『経過時間』を基準にする

カスタマーサポートの運用では、課題そのものの期限ではなく、あるステータスに入ってからの経過時間（SLAの残り時間）を基準に、それが超過（Breached）した時点で課題を自動的に遷移させたり、担当者に通知したりする仕組みが使われています（出典参照）。トリガーになっているのは「期限が来たか」ではなく「その状態に入ってから一定の時間が経過したか」です。

プロジェクトの課題管理表でも、同じ考え方を手動の棚卸しに落とし込めます。期限が設定されていない課題や、期限を過ぎても誰も気づいていない課題は、期限だけを基準にしていると拾えません。「対応待ちに入ってから何営業日経過したか」を棚卸しの基準にすれば、期限の有無にかかわらず、止まっている課題を機械的に拾い上げられます。放置期間ベースのエスカレーション基準表が、期限ではなく経過日数を軸にしているのはこのためです。

リスク管理・コミュニケーション管理との役割分担

リスク管理の実務手順は、リスクと課題を区別し、リスクが顕在化した時点でリスク登録簿の当該行をクローズし、課題管理表に新しい行を起こす運用を示しています。本記事の課題管理表は、その受け渡し先そのものの型です。リスク登録簿に書いてあった対応策が、課題管理表の「内容」や「対応状況」の初動になります。

コミュニケーション管理の実務手順は、エスカレーション判定の結果を課題ログに記録し、エスカレーション済みかどうかを示す状態欄を持たせることまでを示しています。本記事の課題管理表の「対応状況」欄は、この状態欄を未着手・対応中・対応待ち・エスカレーション済み・クローズという具体的な5区分まで分解し、さらに「対応待ち」が何日続いたら次のレベルに引き上げるかという判定基準を加えたものです。3つの記事は競合するものではなく、リスク管理が「まだ起きていないものへの備え」を、コミュニケーション管理が「誰に・どの経路で伝えるか」を、本記事が「登録された課題を放置させずに拾い続ける運用」を担う関係にあります。

現場で繰り返される5つの失敗

第1に、「対応待ち」を「対応中」のまま記録し続けることです。専用の区分がなければ、相手の返答を待っているだけの課題と、自分が実際に作業している課題が同じ見た目になり、棚卸しで区別できません。

第2に、最終更新日を更新しないことです。棚卸しのたびに状況を確認しても、変化がないからと日付欄をそのままにしておくと、経過日数の起点がずれ、実際より放置期間が短く見えます。

第3に、担当者欄が組織名のままになっていることです。督促する責任を負う個人が決まっていないと、誰も相手に働きかけず、ただ時間が過ぎます。

第4に、重要度と緊急度を混同し、起票者の自己申告でほとんどの課題が「高」になることです。基準表の閾値が機能しなくなり、本当に優先すべき課題が埋もれます。

第5に、エスカレーション済みに区分変更したあと、引き取り先を決めずに放置することです。「上げた」という行為で安心してしまい、引き取った側が対応を始めたかを誰も確認しないままになります。

まとめ：明日やる3つ

まず、いま使っている課題管理表を開き、「対応待ち」の専用区分と最終更新日の欄があるかを確認します。無ければ、この2つをまず追加してください。

次に、重要度ごとの放置期間ベースのエスカレーション基準を1枚の表にまとめ、次の定例の棚卸しに組み込みます。日数は目安でよいので、まず仮の値を置いて動かし始めます。

最後に、いま「対応中」のまま動いていない課題を1つ選び、最終更新日からの経過日数を数えてください。そのうえで、誰の返答を待っているのかを今日中に確認します。この3つが揃えば、次に止まる課題は、気づかれないまま埋もれる前に、基準で拾われるようになります。