シンプルな解法

結局のところ、プロジェクトを遅れないようにするためには、
役割分担をせず、タスクの分担をする、ということに尽きる。

もう少し具体的に言うと、「役割分担」という名のもと、あらかじめ
タスクを全部分担してしまうから、「自分の分だけやればいい」という
余計なセクショナリズムが発生するのだ。
タスクは、最初は誰にも割り当てず、日々進捗を管理し、終わった人から
順番に次の仕事をやればいい。
そして、予想以上に大変であったタスクには、応援をつければいい。
ただ、それだけだ。


このように書くと、いろいろな反論が聞こえてくるようだ。
・仕事量に差が発生し、特定の人に負荷が集中する
・納期が実質ないので、サボりたければ完了報告をしなければよいので、スケジュール管理ができない
・実際のプロジェクトでは、いろいろな専門スキルがあるので、タスクを融通などできない
まあ、このような感じではないかと思う。


私も、このやり方を最初にやったときには、
「結局できない人の後始末をできる人がやる仕組みなんですね」
「ほかの人のために、残業なんてしたくありません」
「どこまで仕事をすればいいのか、見当がつきません」
という反応をうけた。いわゆる非難轟々というヤツである。


しかし、このような批判は的を得ているだろうか？
前回の日記の内容をベースに考えれば、普通のやり方に比べての仕事量は、そんなに差はないのだ。


まず、
・仕事量に差が発生し、特定の人に負荷が集中する
「結局できない人の後始末をできる人がやる仕組みなんですね」
「ほかの人のために、残業なんてしたくありません」
という、まあ、自然な反応に対する答えだが・・・
結局普通のやり方をしても、「できない」人（これは、個人がいくら気をつけていても発生し、
誰になるかは、ロシアンルーレットのようなものである。なぜかは昨日の日記を参照）の遅れを、
ほかの人でキャッチアップしていること自体は変わらない。
どころか、そのキャッチアップしなければいけない度合いは、
普通のやり方のほうが激しくなる。
「できない人」ができるまでの待ち時間が、そのまんま、
できる人の待ち時間になっているため、より短い工期で、キャッチアップを余儀なくされるのだ。
できる人の待ち時間を減らせば、結果としてプロジェクト全体の工期は早まるのである。


そのほかの反論への答えは、明日以降にすることにしよう。