 |
|
| ユーザ納得のWin - Winプロジェクト管理 |
第３回：中身の濃い進捗報告会を作るには〜前編〜
著者：ウルシステムズ 村田 修作 2007/8/29
|
|
|
| 前のページ 1 2 3 次のページ
|
|
| 課題管理の3つのポイント
|
弁田氏「え……と、何を管理したいか？ あまり具体的に考えていませんでしたが……。課題を管理する、だと答えになってませんね……（課題管理って何をどうするのか、リアリティのある管理手順をまだ考えていなかったな。反省）」
T氏「ふむ。では、わかりやすいところから考えてみよう。まずは、何でも課題と呼ぶのではなく、ToDoと課題に分ける。ToDoというのは、やることが明確に決まっていて悩まずにすぐやれるもの。ここでいうと『5.R社メンバーの座席を準備する』とか『6.現行システム仕様書を結佐氏から受領する』などは、やれば終わりなのでToDoになる。一方、課題というのは、解決しなければならない事柄のことであって、何をしなければいけないかを表現するものではない。ここでいうと『1.インフラ構成をどのように決めていくか明確になっていない』や『2.業務部Yさんが忙しく検討会へ参加できないことが多い』といったものが課題となる」
弁田氏「なるほど。ToDoと課題は明確に違うものなんですね。ということは当然管理の方法も違うってことですか？」
T氏「そのとおり。ToDoは担当者、期限、完了条件を明確に決めることが重要で、後は消化状況、つまりやったかどうかだけをみていくだけでよい。一方、課題は、解決までに多くの時間やアクションが必要になることが多いので検討状況を随時把握していかなければならない。その分、あまり固く期限ややり方を管理してもうまくいかないこともある。ずるずる期限が延びていったり、いつのまにか前提が変わって、もはや課題ではなくなっていたりする」
この点が第1のポイントとなる。ここで重要なのは「課題とToDoを区別し、管理の方法を変える」ということだ。
弁田氏は課題とToDoを2つの管理表に分けることにした。T氏は、新しく分けた課題管理表をチェックしている。
T氏「これ、課題としてわざわざ管理する必要のないものまであがっちゃってるね。例えば『4.開発環境が決まっていない』という課題があがっているが、開発環境検討というタスクが確かWBSにも存在していたよね。この場合、開発環境検討タスクで開発環境は粛々と決まっていくわけだから、わざわざ課題として管理する必要はない。確かに、課題をあげろといわれれば『開発環境決まってないなあ……』と考える気持ちもわかる。しかしこのような、放っておいてもプロジェクトとして解決できることがわかっているものは課題管理表で扱う必要はないということなんだ」
弁田氏「なるほど……。それから、いま気付いたんですが、この課題管理表にあがっている課題には、このままだと先々困るだろうという『リスク』の話と、今まさにあるタスクが進まないという『問題』の話が混じっているのではないでしょうか」
T氏「いい観点だね。それも分けて管理したほうがよいこともあるし、そもそも分けるべきだとよくいわれている。だが、個人的な経験でいうと、リスク管理表は最初に一度作ったきり、振り返られないで死んでしまうことが多かった。理由を考えてみたが、そもそもほとんど起こらないことばかりあげてあるので、みるのがばからしかったり、逆に起こりそうなリスクは最初に対策をタスク化しておくので日々管理しなくてもよかったり、というところだと思っている。まあ、必要に応じて分けて管理する、かな」
さらにT氏は続ける。
T氏「問題とリスクの区別は大切だが、あまり管理の方法に凝っても、その『課題』はリスクだ、いや問題だ、とかいう管理のための議論になって、リアリティのある議論にならない。弁田君なりの基準で区別はしておくが、わざわざ課題管理表には書かない、というのも1つの管理上のコツかもしれない。いくらしっかり課題の意味を定義したって、課題管理表をみる人が全員それを覚えていてくれることも、まずないからね」
弁田氏「たしかに、課題とかリスクとか問題とかを最初は区別していても、だんだんみなくなっていくことが多いです。気になるものは課題としてひとくくりにする、でももう対処が決まっている物はあげなくてよい、ということですね」
T氏「その通り！」
この点が第2のポイントとなる。重要なのは「新しく検討をはじめなくても解決するものは課題管理表にあげない」ということだ。
T氏「最後に、課題を解決していくコツを教えよう。それは、課題は必ず何かのToDoに落とすことだ。課題は、そのまま人に『解決お願いします』と振っても思ったように解決がはかどらないことが多い。なので、すぐにその課題解決を進めることのできる何かしらのToDo、つまり悩まずにすぐやれるもの、に落として、それを人に振るようにするんだ」
そしてT氏は次のように締めくくった。
T氏「そのToDoが終わったら、その結果を踏まえて別のToDoを起こし、これを実行する。最初のToDoの時点では、解決までのゴールがみえていなくてもよい。繰り返していけば、課題は確実に解決へ近づいていくことになる。弁田くんも、課題とToDoを上手く使い分けて、プロジェクトを成功に導いてくれ」
これが第3のポイント「課題は必ずToDoに落とす」だ。
弁田氏「うーん、いわれてみると、どれも当たり前のことにも聞こえますね……。でも、実際、この課題管理表をみるとその当たり前のことができていないし、自分もそれをきちんと認識していなかったことがわかりました。当たり前に思えることほど、意外にきちんとわかってないってことですね」
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
ウルシステムズ株式会社 村田 修作
シニアコンサルタント。「少しでも顧客の役に立つことをする」をモットーに日々コンサルティング活動に奮闘中。「どのようにすれば会議での議論を空中分解しないようファシリテートできるか」が現在の最大の研究テーマ。
|
|
|
|
|
|
