人日計算の危険性

作業量を見積もる場合、ソフトウェアでは、ソフトウェア規模から工数に換算した値を用いることが多い。ソフトウェア規模は、Step 数や、Function Point など、いろいろな測定方法があるが、それらは、専門の書籍を確認いただきたい。ここで述べたいのは、工数＝人日or 人月を用いて算出することの難しさである。この工数の値は、要員計画に用いられることになるが、そのままの値では、実質的な値ではないと考える。人がチームを組とゆうことは、おのずとコミュニケーションが生まれる。コミュニケーションは、人数が多くなれば多くなるほど、そのコミュニケーションの経路が増えることは、下記の図から理解してもらえると思う。
要するに、少人数のチームであればコミュニケーションに要する影響は少ないが、大きなチームになればなるほど、コミュニケーションに要する時間の影響度は、見捨てて置けなくなる。それを、そのまま、作業量を一人当たりの作業量で割ることにより、工数を算出してしまうと、大きく作業量の差分が生じることになる。大規模プロジェクトになると、進捗遅れが生じるのは、作業工数の見積もりに、このような問題があるからと考えられる。このことを考慮し、適切な工数の見積もりを行うべきである。

また、ソフトウェア規模による点も見逃せない。ソフトウェアは、近年さらに肥大化し、現在では、考えられないくらいのサイズにまで拡張してきている。規模が増大するとゆうことは、機能が増え、機能の内容が複雑化してくる。このことは、単にステップ数が、倍加するだけではなく、複雑な関係が多く発生し、難易度も高くなり、検証作業にも多くの時間を要するようになる。要するに、ソフトウェア規模が増えるとゆうことは、指数倍的に作業量・工数が増加していくことに、注意しなければならない。このことを考慮せず、過去の実績から算出すると、大きな間違いを犯すことになる。

上記のことから、ソフトウェアの巨大化、チームの巨大化は、プロジェクト運営の弊害になる。よりシンプルに、効率的な分割を行った少数精鋭のチームで、開発できるようなスケジュールの確保が、よりよい製品を作るうえで必要となるであろう。

vol.39

チームが大きくなってくるとおのずと出てくるのが「そんなの聞いてないよ！」という情報の共有の問題です。人はチームで活動することにより連帯感が生まれ責任感を持つようになって人数以上のパワーを発揮しますが、大所帯になると先のようなマイナス面が出てきます。これらの問題はプロジェクトマネジメントのコミュニケーションマネジメントで扱うものですが、それ以前に最適なチームサイズは大事だと思います。