課題管理表を「管理」する

今回は課題管理表について触れたいと思います。

課題管理表を「管理」する。これは進捗管理やコスト管理と同様、
PMの重要なタスクです。

重要なタスクというのは、課題を解決することそのものよりも、
これが課題なのかどうかを見極めて、しかるべき対処の道筋を
つけることを指します。

この「課題」という言葉は汎用的すぎて人によって解釈が異なる
曲者です。

PMは課題管理表を作成するにあたり、まずこの「課題」の定義
を正確にメンバーに周知する必要があります。

「課題」の正しい意味ではなく、定義することが重要なのです。

この定義があいまいだと、課題管理表に備忘録やTODOリストが
紛れ込んだりします。
また、課題の粒度にもバラつきが出てくるでしょう。

このような状態になると数が膨大になり、管理コストが大幅に
増えてしまいます。挙句の果てには誰もメンテナンスをしない
お飾りになってしまいます。

メンバーの気持ちも分かります。何か忘れそうなタスク、
ちょっと心に引っかかった問題等を何かに書きとめておきたい。
そしてそれらがしっかりと共有されるよう、一元的に管理して
おきたい。そんな思いから課題管理表が膨れ上がってくるのです。

PMはプロジェクトを開始するにあたって、何を「課題」として
管理するか、その範囲と粒度を正確に定義する必要があるという
のはこのような理由からです。

では「課題」をどのように定義すればいいのでしょうか。

定義の仕方は人によってバラつきがあると思いますので、私が
プロジェクトで使用しているものを上げます。

課題とは、
プロジェクト計画の遂行に対して障壁となる顕在化した問題である。

計画とはスケジュール、スコープ、品質、コスト、リソースなどが
上げられます。

何らかの問題が生じ、これらの計画を予定通りに遂行すること
ができない。これを課題としています。

そしてこれらの課題がプロジェクト全体に影響するのか、
サブタスクもしくはサブシステム内で閉じる問題なのか
という影響範囲の点でも区別します。

そのため、私はチーム毎の課題管理表と全体課題管理表を
分けています。

各チームで上がった課題に対してプロジェクト全体に影響
するものは全体課題管理表に移行します。

課題管理表の項目は以下のようなものを用意しています。

カテゴリ（管理、技術、その他）

課題のタイトル

ステータス（Open、Close）

発生日

発生タスク

課題提起者

課題内容

重要度(高、中、低）

影響範囲（タスク、サブシステム）

対応方針

対応期限

対応結果

対応者

対応日時

備考

課題ではなく、タスクと思われるものはTODOリストに上げ、
顕在化していないが将来課題となりうる問題はリスク管理
シートに記載します。

一方でこのように定義すると、エスカレーションが適切に
行われない可能性が出てきます。
これが課題なのか？と判断に迷う場合、記載しない者が
出てくるのです。

そのため、日報の備考欄に感じたこと、疑問に思ったこと
など課題に載せるかどうか判断に迷うものを任意に記載
してもらっています。

たかが課題と言うなかれ。課題管理表はメンバーとPMを
つなぐ大変重要なコミュニケーションツールなのです。

今回はこの辺で。
リスク管理シートについては別途PMBOKのリスクマネジメント
知識エリアの紹介の際に触れます。