プロジェクトの課題表には、多くの情報が並びます。
仕様が決まっていない、担当者から回答がない、スケジュールに影響が出そう、顧客の判断を待っている、他チームとの認識が合っていない。こうした問題を一覧にすると、状況を整理できたように見えます。
しかし、課題表に登録しただけでは、課題は解決しません。
内容が曖昧なまま、担当者も期限も決まらず、毎週の会議で「継続確認」と報告され続ける課題があります。何週間も同じ文章が残り、気付いた時にはスケジュールへ影響していることもあります。
PMOの課題管理で重要なのは、課題の数を集計することではありません。
何が問題で、誰が動き、いつまでに何を決めれば次へ進めるのかを明確にすることです。
この記事では、課題を登録したまま放置させないために、PMOが確認したい5つの項目を整理します。
課題表に載っているだけでは管理できていない
課題管理表があると、プロジェクトが管理されているように見えます。
課題番号、発生日、内容、担当者、期限、対応状況などの項目が並び、定例会議で件数も報告されます。
ただし、表が存在することと、課題が管理されていることは別です。
次のような状態では、課題表があっても実際には管理できていません。
- 課題の内容が抽象的で、何が問題か分からない
- 担当者が部署名だけになっている
- 対応期限が入っていない
- 誰が最終判断するのか分からない
- 対応状況が「確認中」のまま変わらない
- 解決条件が決まっていない
- 期限を過ぎても影響が整理されていない
- 毎回同じコメントだけが追記されている
この状態では、課題表は問題の一覧でしかありません。
管理するためには、それぞれの課題を具体的な行動につなげる必要があります。
1．何が問題なのか
最初に確認したいのは、課題の内容です。
課題名に「仕様について」「スケジュールの件」「環境確認」などと書かれていても、それだけでは何が問題なのか分かりません。
たとえば、次の記載では状況が曖昧です。
新システムの仕様について確認が必要
この文章だけでは、誰が何を確認するのか、確認できないと何が止まるのかが分かりません。
もう少し具体的にすると、課題として扱いやすくなります。
新システムから出力される売上データの項目定義が未確定のため、連携テストの設計を開始できない
これなら、未確定なのは項目定義であり、その影響で連携テストの設計が止まっていることが分かります。
課題を登録する際は、少なくとも次の内容を確認します。
- 現在どのような状態なのか
- 本来どのような状態であるべきか
- 何が決まっていない、または不足しているのか
- どの作業が止まっているのか
- 放置すると何に影響するのか
課題の文章を長くする必要はありません。
重要なのは、第三者が読んでも問題の内容を理解できることです。
担当者だけが分かる書き方では、その担当者が不在になった時に課題が止まります。
確認事項と課題を分けて考える
課題表には、まだ問題になっていない確認事項が混ざることがあります。
たとえば、次のような内容です。
- 来週の会議日程を確認する
- 資料の保存場所を確認する
- 担当者の連絡先を確認する
- 手順書の最新版を確認する
これらは必要な作業ですが、すべてがプロジェクト課題とは限りません。
課題として扱うべきなのは、放置するとスケジュール、品質、コスト、作業の継続などへ影響するものです。
確認事項や通常の作業まで課題表へ登録すると、件数が増え、本当に重要な課題が埋もれます。
私は次のように分けて考えると整理しやすいと思います。
- 通常作業：予定された手順として行うもの
- 確認事項：情報を確認すれば完了するもの
- 課題：対応や判断を行わなければ、プロジェクトへ影響するもの
- リスク：現時点では発生していないが、将来問題になる可能性があるもの
厳密な分類にこだわりすぎる必要はありません。
ただし、課題表に何でも入れるのではなく、何を重点的に管理する表なのかは決めておく必要があります。
2．誰が対応するのか
二つ目に確認したいのは、担当者です。
課題表に担当部署だけが書かれていることがあります。
たとえば、「開発チーム」「顧客側」「インフラ担当」といった記載です。
しかし、部署やチームは行動できません。実際に確認し、回答し、作業を進めるのは個人です。
担当者を明確にする際は、次の点を確認します。
- 次の行動を取る人は誰か
- 情報を集める人は誰か
- 回答を作成する人は誰か
- 関係者との調整を行う人は誰か
- 状況を報告する人は誰か
担当者を一人に絞れない場合もあります。
その場合でも、課題を前へ進める中心人物は決めておいた方がよいです。
複数の関係者を並べるだけでは、「誰かが対応するだろう」という状態になりやすいからです。
PMOが課題の担当者になることもありますが、注意が必要です。
PMOが確認や調整を行うとしても、仕様を決める人、予算を承認する人、技術的な判断を行う人までPMOになるわけではありません。
課題管理では、調整担当と判断担当を分けて考える必要があります。
担当者と判断者は同じとは限らない
課題が止まりやすい理由の一つが、担当者は決まっているものの、その人に決定権がないことです。
たとえば、担当者が仕様案を整理しても、最終承認は顧客責任者が行う場合があります。
現場担当者へ何度確認しても、承認者が判断しなければ課題は解決しません。
そのため、課題表では次の二つを分けておくと分かりやすくなります。
- 対応担当者：調査、資料作成、関係者調整などを行う人
- 判断者：選択肢の決定、承認、方針確定を行う人
すべての課題で両方を記載する必要はありません。
ただし、判断待ちで止まっている課題については、誰の判断を待っているのかを明確にする必要があります。
担当者だけを追い続けても進まない課題は、判断者へのエスカレーションが必要です。
3．いつまでに対応するのか
三つ目は期限です。
期限がない課題は、ほかの作業より後回しになりやすくなります。
課題表に「早急に対応」「できるだけ早く」「今週中を目安」と書かれていることもありますが、人によって受け取り方が異なります。
可能な限り、具体的な日付を設定した方が管理しやすくなります。
ただし、期限を入力するだけでは不十分です。
その日付が何を意味するのかも確認します。
- 調査結果を提出する期限
- 対応方針を決定する期限
- 作業を完了する期限
- 顧客の承認を得る期限
- 後工程へ影響を出さないための期限
一つの課題に複数の段階がある場合は、期限を分けた方がよいこともあります。
たとえば、次のような課題です。
店舗機器の対象機種が未確定のため、交換手順書を完成できない
この場合、課題解決までにはいくつかの段階があります。
- 対象機種の一覧を回収する
- 不明な機種を現場へ確認する
- 対象機種を確定する
- 手順書へ反映する
- 手順書をレビューする
最終期限だけを見ると、途中で遅れていても気付きにくくなります。
重要な課題では、中間期限を設定し、どの段階まで進んでいるかを確認する必要があります。
期限は後工程から逆算する
課題の期限は、担当者が回答できそうな日だけで決めるものではありません。
後工程へ影響を出さないために、いつまでに解決する必要があるかを基準に考えます。
たとえば、テスト開始日が8月20日で、テスト設計に10営業日必要なら、仕様確定日は少なくともその前でなければなりません。
仕様担当者が「8月19日なら回答できます」と言っても、それでは後工程に間に合いません。
PMOは、次の関係を確認します。
- 課題の解決後に何の作業が始まるか
- 後工程には何日必要か
- レビューや承認期間を含んでいるか
- 休日や予備日を考慮しているか
- 期限を過ぎた場合、どの作業へ影響するか
課題の期限は、単なる回答希望日ではありません。
プロジェクト全体のスケジュールを守るための判断期限です。
4．次に何をするのか
四つ目は、次の行動です。
課題表の対応状況に「確認中」「調整中」「検討中」とだけ書かれていることがあります。
これでは、現在誰が何をしているのか分かりません。
たとえば、「顧客確認中」という記載があっても、次の点は不明です。
- いつ顧客へ確認したのか
- 誰へ確認したのか
- 何を質問したのか
- いつ回答予定なのか
- 回答がない場合、次にどうするのか
課題を動かすためには、次の行動を具体的にします。
- 担当者Aが8月5日までに対象データを整理する
- 8月6日の定例会議で顧客責任者へ方針確認する
- ベンダーBへ見積もり条件を再提示する
- 技術チームが二つの対応案を比較する
- 回答がなければPMから責任者へエスカレーションする
課題管理では、過去に何をしたかだけでなく、次に何をするかが重要です。
経緯の記録が長くても、次の行動が書かれていなければ課題は動きません。
コメント欄を作業日記にしない
課題表のコメント欄へ、日付ごとの経緯を追加していくことがあります。
履歴を残すことは必要ですが、過去の記録が増えすぎると、最新状況が分かりにくくなります。
たとえば、次のような記載です。
7月10日：担当者へ確認
7月12日：回答待ち
7月15日：再確認
7月18日：顧客確認中
7月22日：引き続き確認
これでは、現在何を待っていて、次に誰が動くのかが分かりません。
履歴を残す場合でも、先頭や別項目に現在の状況を明記した方がよいです。
現在：顧客責任者による仕様承認待ち
次の行動：7月25日までに回答がなければPMから再依頼
影響：7月29日までに承認されない場合、テスト設計開始が遅延
これなら、課題表を開いた人がすぐに状況を理解できます。
課題表は作業日記ではなく、現在の状態と次の行動を判断するための資料です。
5．何をもって解決とするのか
五つ目は、解決条件です。
課題のステータスが「完了」になっていても、本当に問題が解消したとは限りません。
担当者から回答が来たことで完了とする場合もありますが、その回答内容が後工程で使用できる状態になっていなければ、課題は残っています。
たとえば、仕様未確定の課題であれば、次の状態には違いがあります。
- 担当者から口頭で回答があった
- 仕様案が作成された
- 関係者レビューが完了した
- 責任者が承認した
- 正式な仕様書へ反映された
- 後工程の担当者へ共有された
どこまで進めば課題解決なのかを明確にしておかないと、表面上は完了していても、後から同じ問題が再発します。
解決条件として確認したいのは、次のような点です。
- 必要な判断が確定したか
- 関係者の合意が取れているか
- 正式な資料へ反映されたか
- 後工程が開始できる状態か
- 必要な関係者へ共有されたか
- 再発防止や追加対応が必要ないか
課題を閉じることが目的ではありません。
問題の影響が解消され、次の作業へ進める状態になったことを確認する必要があります。
課題を閉じる前に影響先を確認する
課題の対応が完了した後も、関連する作業や資料の更新が必要な場合があります。
仕様変更が決まったなら、設計書、テスト項目、手順書、スケジュールなどへ反映しなければなりません。
一つの課題を解決しても、影響先への反映が漏れていれば、新しい問題が発生します。
課題を完了にする前に、次の点を確認します。
- 関連するスケジュールを更新したか
- 必要な資料へ反映したか
- 関係チームへ共有したか
- 別の課題を新規登録する必要はないか
- リスクとして継続管理する必要はないか
- 作業担当者が内容を理解しているか
課題管理では、判断が出た時点ではなく、その判断が現場へ反映された時点まで確認することが重要です。
長期間動かない課題をどう扱うか
課題表には、何週間も状況が変わらない項目が残ることがあります。
長期間動かない理由はさまざまです。
- 担当者が忙しく対応できていない
- 判断者が会議に参加していない
- 優先順位が低い
- 解決方法が分からない
- 外部ベンダーの回答を待っている
- 本当は課題ではなく、単なるメモになっている
- 解決不能だが、誰も終了判断をしていない
このような課題は、毎週同じ確認を繰り返すだけでは動きません。
一定期間動きがない場合は、次のいずれかを判断する必要があります。
- 担当者や期限を変更する
- 上位者へエスカレーションする
- 対応方法を分解する
- 重要度を見直す
- リスクとして別管理する
- 対応しないことを正式に決定する
- 課題として管理する必要がないため終了する
課題を放置することと、対応しないと判断することは違います。
対応しない場合でも、その理由と影響を確認し、責任者が判断した記録を残す必要があります。
課題の優先順位は件数では決まらない
課題管理の報告では、「未解決課題が20件あります」と件数を示すことがあります。
件数は全体量を把握する参考になりますが、多いから危険、少ないから安全とは限りません。
小さな確認事項が20件ある状態より、プロジェクト全体を止める課題が1件ある状態の方が深刻です。
課題の優先順位を考える際は、次のような点を確認します。
- スケジュールへの影響
- 品質への影響
- コストへの影響
- 顧客や利用者への影響
- 影響するチームや作業の範囲
- 解決までに必要な期間
- 対応できる期限までの余裕
- 代替手段の有無
重要度と緊急度を分けて考えることも有効です。
影響は大きいものの、対応期限まで余裕がある課題もあります。影響は限定的でも、明日までに判断しなければ作業が止まる課題もあります。
PMOは件数を報告するだけでなく、どの課題を今判断すべきかを整理する必要があります。
課題会議では全件を読み上げない
課題会議で、一覧表を上から順番に読み上げることがあります。
件数が少ないうちは確認できますが、課題が増えると会議時間の多くを状況報告に使うことになります。
重要な課題の議論時間が不足し、結局何も決まらないこともあります。
会議では、すべての課題を同じ深さで扱う必要はありません。
次のような課題を優先して取り上げます。
- 期限を過ぎている
- 次回会議までに判断が必要
- 重要工程へ影響する
- 担当者だけでは解決できない
- 複数チームに関係する
- 対応方針が決まっていない
- 前回から状況が変わっていない
- PMや顧客責任者の判断が必要
情報共有だけで済む課題は資料上で確認し、会議では判断や調整が必要なものに時間を使います。
課題会議の目的は、課題表を確認した証拠を残すことではありません。
会議に参加している人の判断や協力を使って、課題を前へ進めることです。
PMOが催促役だけにならないために
課題管理を担当すると、PMOは担当者へ期限を確認し続ける立場になりやすくなります。
「回答をお願いします」「期限を過ぎています」「状況はいかがでしょうか」と連絡するだけでは、単なる催促役になってしまいます。
もちろん、確認や催促は必要です。
ただし、課題が進まない原因によっては、催促しても解決しません。
PMOとして確認したいのは、次の点です。
- 担当者は何をすればよいか理解しているか
- 必要な情報はそろっているか
- 判断権限を持っているか
- 他の作業が優先されていないか
- 作業量が想定より大きくないか
- 期限を守れない理由は何か
- 上位者の判断や支援が必要ではないか
回答が来ないことを担当者の怠慢と決めつけず、何が対応を止めているのかを確認します。
必要であれば、課題を小さな作業へ分けたり、判断者を会議へ呼んだり、PMへ優先順位の調整を依頼したりします。
PMOの役割は、担当者を追い続けることではありません。
課題が動くための条件を整理し、適切な人へつなぐことです。
課題管理表に最低限入れたい項目
課題管理表の形式はプロジェクトによって異なります。
項目を増やしすぎると更新が負担になりますが、最低限、次の内容は確認できるようにしたいところです。
- 課題番号
- 課題名
- 課題の具体的な内容
- 発生日
- 影響範囲
- 重要度・優先度
- 対応担当者
- 判断者
- 対応期限
- 現在の状況
- 次の行動
- 次回確認日
- 解決条件
- 完了日
すべてを別々の列にする必要はありません。
プロジェクトの規模や運用方法に合わせて、必要な情報がすぐ分かる形にします。
重要なのは、管理表を精密にすることではなく、更新する人と確認する人が継続して使えることです。
課題を放置させないための確認方法
課題表を定期的に確認する際は、各項目について次のように見ると整理しやすくなります。
- 何が問題なのか
- 誰が次に動くのか
- いつまでに何をするのか
- 現在何を待っているのか
- 何をもって解決とするのか
この5点のどれかが欠けている課題は、止まりやすい状態です。
さらに、次の点も確認します。
- 期限を過ぎていないか
- 後工程への影響が変わっていないか
- 担当者や判断者は適切か
- 次回確認日が決まっているか
- 上位者の判断が必要ではないか
- 同じ課題が別の場所でも管理されていないか
課題管理では、すべての課題を毎日確認する必要はありません。
期限が近いもの、影響が大きいもの、状況が変わっていないものを中心に確認します。
まとめ
PMOが課題を放置させないために確認したいのは、次の5つです。
- 何が問題なのか
- 誰が対応するのか
- いつまでに対応するのか
- 次に何をするのか
- 何をもって解決とするのか
課題表へ登録しただけでは、課題は前へ進みません。
内容が曖昧で、担当者や期限がなく、次の行動も決まっていなければ、毎週同じ課題を確認し続けることになります。
PMOの課題管理は、未解決件数を集計する仕事ではありません。
問題を具体化し、担当者と判断者を整理し、期限と次の行動を決め、解決した状態まで確認する仕事です。
課題が止まっている時は、担当者を催促するだけでなく、何が対応を止めているのかを確認します。
情報が足りないのか、判断者が不明なのか、期限が現実的でないのか、他の作業を優先しているのか。原因によって、必要な対応は変わります。
課題表を更新することではなく、課題を判断や行動へつなげること。
それが、PMOが課題管理で担う役割だと思います。
PMOの実務については、次の記事でも整理しています。
【関連記事：課題管理は、表を更新する仕事ではなかった】
【関連記事：PMOが進捗率をそのまま信用してはいけない理由】
【関連記事：PMOがプロジェクト参画時に最初に確認したいこと】
【関連記事：48歳で転職活動をして感じた、PMO案件の難しさ】
コメント