人材育成、講師の視点から（4）
これまでの記事はコチラ↓
こんにちは、天野勝です。
わたしは、コンサルタントという職業柄、人にものを教える「講師」という仕事をすることが多いです。現場カイゼンの導入教育や、C言語でのテスト駆動開発と、かなり多岐にわたっています。
この連載では「講師」として気付いたことを、わたしの視点で発信していきます。
■タスクを2時間以下に分割する
現場カイゼンの導入教育の中で、やるべきタスクをふせんに書きだして、タスクボードで管理する方法を教えています。この管理方法の中で、もっとも効果があり、けれど受講者からもっとも不評なのが「タスクを2時間以下に分割する」というものです。以下のような反応がかえってくることが多々あります。
- 細かくタスクを分けるのは時間がかかる
- 見積もり精度を高くできない
- 10分程度のタスクばかりだと、貼るところがない
たしかに「タスクを2時間以下に分割する」という文面だけ見れば、当然の反応だと思います。しかし、分割してもらうのにはそれなりの理由があるのです。
■基礎知識
必要となる考え方を紹介しておきます。
◇バッファはマイルストンの前に置く
TOCのCCPM（Critical Chain Project Management）は、プロジェクトのマネジメント手法であり、その中のいくつかの考え方はチーム運営に大いに役に立ちます。その最たるものが、バッファ管理の手法です。詳しくは参考書籍をご覧ください。[*1]
ごく大ざっぱに、この管理手法を説明すると、各タスクの作業予定工数を50％の確率で完了する工数で見積もり、マイルストンの前にバッファとなる工数を用意するというものです。
◇完全Done
タスクには完了条件が決められており、完了条件を満たせばそのタスクは完了とします。さらに、仕掛中のタスクの中間的な進ちょくは管理しません。つまり「このタスクは30％完了している」という言い方はせずに、終わっているか、終わっていないかだけで進ちょくを管理します。詳しくは参考書籍をご覧ください。[*2]
◇残時間による進ちょく把握
タスクが完了していない場合、その進ちょく状況を確認したい場合があります。このような場合は、どれだけタスクを行ったかではなく、そのタスクを完了させるのに、あとどれだけの時間がかかるか把握します。どれだけやったかではなく、どれだけ残っているかを把握するという考えです。
■2時間にこだわる必要はない
仕事のサイクルは1週間を基準に、これをマイルストンとします。アジャイル開発のイテレーションととらえていただいても問題ありません。そして1日に仕事に費やせる時間は最大6時間とします。
見積もり精度についてですが、1/2～2倍(－50～＋100％)のぶれがあるとします。つまり、2時間と見積もったタスクは、実際には1時間～4時間になってしまいます。もしみっちり3日間、18時間かかると見積もったタスクの場合、2倍の36時間かかるとなると、6日間かかってしまいます。週の最初からそのタスクに着手しても、マイルストンには間に合わなくなります。「完全Done」の考え方に沿えば、タスクは未完了です。何％終わっていようが、未完了と考えます。
もし、完全に終わった時点を判断できるならば、タスクはもう少し細かく分けられるのではないでしょうか。
反対に、18時間の想定が9時間で完了することもあります。これはこれでハッピーですが、よく発生するのが「早期完了の未報告」です。早く終わったら、次のタスクに取り掛かるのが理想的ですが、もともとの18時間というのは、「タスクに費やしてもよい時間」ととらえ、結局18時間ぎりぎりまで作業をしてしまうことがあります。
バッファの時間として、週の終わりにどれだけの時間を用意しておくのが妥当でしょうか？ 2倍まで時間が増えると考えると、タスクが6時間なら前日にタスクに着手して、最終日はまるまる1日バッファの時間にするのがよいでしょう。一方で、タスクが2時間であれば、バッファの時間も2時間となります。このバッファの時間は、使わない時間かもしれません。ですから、マネジメントの視点で見れば、この時間は短いほどうれしいはずです。
では、バッファの時間を短くするにはどうすればよいでしょうか？ 単純な答えとしては、タスクの時間を短くすればよいのです。そして、バッファとして積む予定の時間を計画の時間に回せばよいのです。
上記の話は、見積もり精度が－50～＋100％の場合ですので、もっと見積もり精度が向上してくればこの限りではありません。また、1日に働ける最大時間の増減によっても、適切なタスクのサイズは変えたほうがよいでしょう。
■細かく分けることの副次的効果
チームごとに週に1回計画時間を取り、その中でタスクを細かく分けます。ポイントは、複数人で分けるということです。分割時間を複数人で共有することで、仕事の内容だけではなく、進め方も共有できます。知識伝承が行えます。
タスクを細かく分けるのは良いのですが、やりすぎは禁物です。細かく分けすぎてしまうとそれはそれでデメリットが出てきます。例えば、冒頭の受講者の反応のように、タスクボードに貼りきれなくなる場合もありますし、細かく分けるとかかる時間も長くなってしまいます。タスクボードで運用している場合は、複数のタスクをまとめて1枚のふせんに羅列するという運用がよいでしょう。
発見的な仕事の場合は、この限りではありません。研究や調査など、完了条件やかかる時間が見積もれない仕事とは相性はよくありません。しかし、このような発見的な仕事であっても、その中には完了条件が明確で、作業時間を見積もれるタスクがあるはずです。そこだけでも切り出しておくと、ほかの人が手伝いやすくなります。そうすれば、結果として、発見的な仕事に費やせる時間を増やすことができます。
■まとめ
最初に挙げた、受講者の反応に対する解はこのようになります。
- 細かくタスクを分けるのは時間がかかる
→時間がかかるのは致し方ありません。進ちょくが遅れるリスクを考えると、時間をかけてでもタスクを細かく分けるべきです。また、分けることで知識伝承が行われるという副次的効果も期待できます。また、慣れてくればタスクを分ける時間は短くなります。 - 見積もり精度は高くできない
→見積もり精度が高くないからこそ、2時間程度に分けるのです。見積もり精度が高くなれば、大きいタスクでも問題ありません。また、慣れてくれば見積もり精度が高くなります。 - 10分程度のタスクばかりだと、貼るところがない
→小さいタスクを寄せ集めて、ひとまとめに管理するのをお勧めします。
皆さまのお仕事を進める際のヒントになれば幸いです。
■参考資料
[*1]『 TOC/CCPM標準ハンドブック』
[*2] 『アート・オブ・アジャイル デベロップメント』
この他にも、システム開発にかかわる人をイキイキさせるヒントをご紹介しております。ぜひご覧ください。
ブログはこちら
Twitterはこちら