プロジェクトの各タスクの〆切ってどう設定するか悩むなーって8年くらいプロジェクトマネジメントの仕事してます。

後輩から、「プロジェクト全体のWBS(Work Breakdown Structure)作るときのそれぞれのタスクの〆切ってどう設定してますか？」と相談を受けました。（参考）

ヒアリングしてみると、原因はいくつかありそうですが、設定した納期通りにタスクをやってもらえないことが多く気になっているようです。

作業期間設定って参加するメンバーの癖によって変えたりしますが、重要なポイントは３つかなと思っています。

①担当する人が「やらなきゃ！」って思えるタイミングか？

②実施するタスクをちょうどよい粒度に分解しているか？

③バッファ（予備）は混ぜずに取り除いて期間設定しているか？

ちなみに、今回の後輩の相談では、③が一番の影響に見えました。

①担当する人が「やらなきゃ！」って思えるタイミングか？

プロジェクトに参加するメンバーは高確率で他PJのタスクや、PJ以外のタスクを抱えています。

その場合、緊急度が高い仕事以外は基本的に後回しにしたいのが本音です。

プロジェクトをマネジメントする側は、安全にプロジェクトを進めたいので、前倒ししたタスク設計にしようとする力学が強いですが、アサインされるメンバーは後回しにしようとする力学が強いです。

そのため、予定より後ろ倒しでタスクが進む可能性が高くなります。

つまり、緊急度が高い（ここでやらないとプロジェクトが遅れてしまう！）と思えるタイミングでタスクをおいてあげることが非常に重要になります。

前すぎると「後でいいでしょ」と思ってやってもらえないですし、

後ろすぎると「いやいやギリギリすぎてできなかったよ」と言われてしまいます。

そのため、まぁここだよね、っていうタイミングからスタートするのが一番よい置き方です。

※じゃあ、そのいいタイミングってどこだよ！というのは後日書いていこうと思います笑

②実施するタスクをちょうどよい粒度に分解しているか？

①でスタート地点が決められたら、次はスピードのコントロール、つまり、この期間内でやってくださいね、を伝える必要があります。

これも人によって変えるとよりフィットしますが、基本的には、「３〜５日で実施できる量」程度に砕いて設定します。

例えば、「ある課題Aを２週間後の会議で決議する必要がある」だとすると、

悪い例でいえば、

課題Aの解決策の決定　→　１０日

という設定の仕方はざっくりしすぎています。

原案を作る必要がありますし、チームでレビューが必要かもしれません、また、会議で否決されるリスクもあります。

担当の方が細かく指定せずともやってくださる人であれば、よいですが、そうでない場合、コケるリスクが高くなります。

そのため、以下のように３〜５日程度に砕いたタスクの設計を行います。

課題Aの解決策の決定　→　合計１０日

　課題Aの状態と解決方針の原案作成　→　５日

　原案のレビュー　→　３日

　会議への起案　　→　１日

　会議での承認　→　１日

③バッファ（予備）は混ぜずに取り除いて期間設定しているか？

最後の注意点は、バッファを入れない、もしくは、入れる場合にはバッファを見える形にしておくことです。

「バッファを見せると食いつぶすから見せないほうがいい」という話もあるのですが、基本はバッファを見せておいて「共通認識」を取るほうがうまくいくというのが個人的な感想です。

例えば、先程の２週間のタスクを「否決されるリスクがあるから３週間で伝えてやってもらおう」と思い、３週間で提示したとします。

３週間で提示された側の心理としては、「３週間あるから最初の１週間は何もやらなくても間に合うな」と思う場合がほとんどです。

一方で、他のプロジェクトメンバーがこのタスクを開始した１週間後の進捗を確認したときに「未着手です」という報告を受けた場合を考えてみましょう。

少し不安になる人もいると思います。そうすると、「次のタスクは大丈夫かな？」「あの人はタスクをすぐやらない人だ」というプロジェクトメンバー内で信頼関係の悪化が生まれます。

小さい悪化かもしれませんが、プロジェクトは長期間のことが多いです。タスクの遅れが通常になると、「私も遅れても大丈夫だろう」というムードが伝染し取り返しがつかなくなるリスクが高くなります。

つまり、バッファを見せないことで、不要な信頼関係の悪化やプロジェクト失敗リスクを高めることがあるので、私はバッファは可視化したほうがいいと考えています。

そのため、先程のタスクをバッファ込みで３週間で提示する場合には、

課題Aの解決策の決定　→　合計１５日

　課題Aの状態と解決方針の原案作成　→　５日

　原案のレビュー　→　３日

　会議への起案　　→　１日

　会議での承認　→　１日

　バッファ　→　５日

と伝えるべきだと思います。

こうすることで、チーム全体でバッファを認識し、遅れても安心感があるプロジェクトづくりができると思います。

一方で、「バッファがあるから遅れても大丈夫でしょ？」と思うメンバーもいる場合もありますのでッファの扱い方はチーム内でしっかり認識をあわせることをオススメします。

※例えば、「バッファを使う場合にはタスク開始前のタイミングで必ず申請してください！」などとすることで、本人の稼働を考慮しつつ、タスクに対するコミット感をだしてもらうこともできます。

プロジェクトを管理する側は、１つ１つのタスクにバッファいれまくると、バッファマネジメントが非常に煩雑になり、いつの間にかバッファとして入れていたものがただの遅延になっていた、ということもあるので、気をつけてください笑

以上となります。

今回の記事では、プロジェクトの各タスクの作業期間設定で大事なことを３つお伝えしました。

①担当する人が「やらなきゃ！」って思えるタイミングか？

②実施するタスクをちょうどよい粒度に分解しているか？

③バッファ（予備）は混ぜずに取り除いて期間設定しているか？

参考になればと思います。