今週、エンジニアのアナタは幾つタスクを完了したか

次の質問に答えてください。

Q1　昨年末の2013年12月23日週から幾つのタスクを今週まで持ち越していましたか。
Q2　2014年1月6日週に幾つのタスクを担当しましたか。
Q3　2014年1月10日までに幾つのタスクを完了しましたか。

思い出しながらでも、ざっくりでも回答できます？多分、ざっくりと今抱えているタスクの数は応えられると思います。不思議なことにホールドしているタスクの数は言えるんですよ。

でも、「いくつ完了したか？」と尋ねると、意外と答えられなかったり。なんでなんでしょうね。

WBSを管理できる“適度”な粒度
仕事柄、様々なプロジェクトのWBSを見る機会があるのですが、プロジェクトマネージャごとにWBSの期間の粒度、つまり、日数がバラバラだったりします。傾向として1週間以内に設定されていることが多いのですが、経験が浅いとか技量的にどうかな？と感じるプロジェクトマネージャのWBSはその期間がとっても長いもので溢れていたりして理解に苦しむものです。

ワタシの経験から、WBSの一つのタスクの日数の長さは、その粒度の単位を“5営業日以内に設定する”とした方が管理がし易いです。言い換えれば、最長でもその週にタスクが終わる様にする、とも言えます。

なぜ5営業日なのか、と言えば、多くのプロジェクトの進捗管理のスパンが「週次だから。」です。

実は、タスクは長いスパンで期間を設定してはいけない
最近、タスクの日程、予定開始日と予定完了日は

“長いスパンで設定してはいけない”

と感じるようになりました。これまで、自分自身のガイドラインとしても5営業日、その週でタスクが完了する期間であればよしとしてきたんですね。ところが、あるプロジェクトの進捗が捗々しくないことを事情聴取したり、過去の経験を重ね合わせてみたりしたとき、

“5営業日を越えることは言語道断だけれど、5営業日でも長すぎる”

と思うようになったのです。

そもそも、タスクの作業期間を5営業日を越える定義をしてアサインする状態ということは、タスクの成果物やタスクの完了のイメージができていないのですよ。だから、ざっくりとしか日程を引けないんです。その上、長く日程を引いているということは、その予定完了日が本当にその日に終わらないといけないのかもあやふやだったりするのです。

そのタスクにアサインする方も、アサインされる方も、お互いその曖昧なままタスクを扱うから内心は「そんなに実作業はかからない。」と思っているんですね。だから、別のタスクもアサインしちゃう。

曖昧なタスクは終わらない
曖昧なまま5営業日を越えるタスクを抱えると、ちょっとずつ仕事を進めるとだんだんと曖昧さがはっきりしてくるからそれで曖昧さがはっきりすることでやらないといけない作業が増えてくるんですね。

それが積み重なる。

積み重なる度に“予定完了日”が伸びちゃう。だから、終わらない。

いや、終わらないんじゃないんです。終わらす気がないんですね。えっ？その表現ひどいですって？いや、だったら終わらせましょうよ。タスクは終わらすために作業するんですから。

どうやって終わらすか
一旦、その終わらない作業は今の状態で整理しましょう。何がインプットでどこまで仕掛になっているかを。そして、作業の手順でタスクを設定し直すんです。

そう、タスクをバラす。バラして一つひとつのタスクにする。で、それをアサインし直すんです。理想は1つのタスクを1日程度に。で、毎日終わらす。

え？それでタスクが終わるのかって？終わります。だって、手順に分解するから何をすればタスクが終わるか具体的になっているでしょう？だから、結果的に作業の予定完了日の見積もり精度が上がるんですよ。

そして、具体的なタスクになっているので本当に終わったかどうか、現物で確認しても確認しやすいんです。例えばレビューを完了する、なら、レビューアの指摘を反映していることを確認出来ているかどうか、deliverableを見ればいいんですから。

タスクは予定完了日に終わらせられるように設定しましょう。