プロジェクトの進捗を阻害する課題を片付けるためのヒント

プロジェクトの課題って何だろう
アジャイルのスクラムとか、XPとかより断然多いウォーターフォールの開発手法では、

進捗管理
変更管理
問題管理
品質管理

などの管理手法を取り入れるけれど、そのほかに課題管理がある。

で、“課題”って何だろう。端的に言うと、“プロジェクトの進捗を阻害する事象”になるだろう。
ウォーターフォールなら、プロジェクトはWBSベースで作業を進めることになるけれど、そのWBSの作業をしている中である事象、例えば、パッケージ製品のトラブルの地雷を踏んで、それを解決しないと作業の進捗が進まなくなるようなことである。
事象は、

人的リソース

顧客の情報提供

顧客の意思決定

パッケージ製品の仕様調査

システム構成の検証

の他、それこそプロジェクト毎に様々ある。

どう書いたらいいの？
では、課題は何をどう書いたらよいのだろうか。それは、何を何時までに誰が解決したいのか、に拠る。
excelでもチケットでも管理ツールは何でも良いけれど、必要な情報を情報が更新される都度、メンテナンスする必要がある。

項目	内容	ヒント
通番	課題を一元的に管理するための識別番号	ユニークにつける。工程などで分けると大変なので一気通貫の方が楽
標題	課題を端的に表す。1-2行でプロジェクト関係者が見ればわかるように	タイトルなので短く且つわかるように。難しいよ
起票日	いつ、課題としたか、その期日
起票者	起票した人
解決希望日	何時までに解決したいか。その期日	プロジェクトのスケジュールを睨み、決して最遅に設定しない
担当	課題を解決する担当者名	一度任せて担当が替わるとき、新たに起票するか履歴を残して担当を変更する
課題内容	課題の詳細	事実と意思決定の記録を残す。
解決日	解決した日にち	プロジェクトで課題解決したとオーソライズした期日

この他にもプロジェクトごとに、組織から記録することを求められる項目もあるだろうが、それはプロジェクト毎に取捨選択する必要がある。ただ、あまりにも多くしないことが肝心で、もし、「○○の項目を追加して」と求められたら、“管理のための管理になっていないか”、その項目を追加すると“プロジェクトメンバがうれしいか”の観点で考えるといい。

どう管理したらいいの？
課題管理は、“プロジェクトの進捗を阻害する事象”をステークホルダを交え、プロジェクト全体で共有し、解決するものだから、プロジェクトのミーティングで正しい人たちが出てくる場で共有し、意思判断のために使用する必要がある。ここで言う“正しい”とは、プロジェクトを構成するメンバとして必要な知見を持った人かどうか、ということだ。門外漢の人まで広げてはいけない。スコープを広げられてしまい、プロジェクトが頓挫することと同じ結果になりかねないから。

課題は、予定したWBSの作業以外の作業をすることであって、それは、いったいどれだけ見積もり工数やプロジェクト計画時の工数として見込んでいたかを気にして欲しい。WBSを片付けなければ作業は進まず、課題も片付けなければWBSが進まないのでだから。
WBSも課題もプロジェクトメンバが片付けると言うことは、同じ人的リソースを消費することであって、同時に片付けることはできないということを予め認識しておかないと、課題が溜まりに溜まった状態を見上げたとき、進捗も同じようにスタックしていることに絶望するから。

課題は怖いのだ。

どう使ったらいいの？
さきにちらっと書いたように、

課題管理は、“プロジェクトの進捗を阻害する事象”をステークホルダを交え、プロジェクト全体で共有し、解決するものだから、プロジェクトのミーティングで正しい人たちが出てくる場で共有し、意思判断のために使用する必要がある。

適切な場、普通は進捗を報告するタイミングだろう。顧客の責任者もシステムの連携があればそのリーダも出てくる場で、課題の状況の共有とその場のあとのToDoを誰が何時までにアクションするか、意思判断していく。
その場で、意見集約し、その場で課題管理の情報を更新し、更新内容を確認して、関係者へ展開する。課題にのんびりした課題はないものだ。だから、わざわざ管理しているのだから。

課題管理は、上記の認識合わせや意思判断のベースとなっていることからも、コミュニケーションツールとなっていることがわかるだろう。上手く使ってプロジェクトを進めよう。