期間と人月
投稿日:2008年05月23日 作成者:yasunaka
工数を求める際、一般には「何人月」とか「何人日」といった単位で工数を求めることが多いと思います。これは対象の仕事の担当者だったら、どのくらいの期間でタスクを完了できるのか、という見積です。一人の人がすべての仕事をしている場合には、単純合計すれば全体のタスク量になることは明白ですよね。
でもこれが2人の人が担当する、という話だったらどうでしょうか？ 例えば2人のプログラマー（Aさん、Bさん）が同じアプリケーションを作っていて、Aさんが担当の機能をBさんが利用しているような場合には、Bさんの都合でAさん側の機能の見直しをお願いする、なんてことは日常茶飯事に発生します。こんな場合にも、AさんとBさんで話し合って決めるための（コミュニケーション）時間や、BさんによってAさんのタスクが中断する時間、BさんはAさんが空くまでBさん側の該当するタスクを止めなければならない時間など、いろいろなオーバーヘッドが発生することになります。
1人で順次こなしていく場合に比べ、上記のオーバーヘッドが余計にかかるので、一般には1人で2人月かかる仕事を2人でやったも１ヶ月では終わりません。これがきれいに成り立つのは、2人の間のタスク間に互いに依存する部分がなくて、そのまま突っ走れるような仕事の場合のみです。
でも不思議なことにプロジェクトの見積を行う場合には、そのタスクを何人でやるか、ということをあまり気にせずに、何人月とか何人日だけで換算していると思います。これは上記のようなオーバーヘッドが実際にはどの程度なのかが見積もれないために、とりあえず無視しているからでしょう。
確かに2人程度ではそのようなオーバーヘッドはあまり大きくないと思いますが、これがもっと大人数で、しかも互いに絡み合っていたら、どうなのでしょうか？ 当然このオーバーヘッドが非常に大きな値になってくるのは想像できますよね。
複雑な、絡み合ったものを対象とする場合、100人の人が1か月でできる作業量は100人月、1人の人が100か月かかってやる作業量も100人月ですが、実際にできることがどれだけ違うかはすぐ想像がつくと思います。おそらく後者の方は前者の数十倍の成果物をつくり出せるでしょう。逆に前者は出来上がったものの、使い物にならない代物になっている可能性すらあります。
上記の例は極端ですが、実際のプロジェクトでも同じようなことが良く起こっているのではないでしょうか？ もちろん実際のプロジェクトでは限られた時間の中で成果を求めらるので、やっぱり多くの人を投入せざるを得ないのですが、もし時間が許すならば、むしろ少ないメンバーでじっくり時間をかけたほうが非常に経済的に仕上げることができることになります。
少数精鋭のチーム、いいですよね。