続・プログラマは誰でも同じ？

システム開発の業界では、１人の人間が、１ヶ月で行うことのできる仕事の量を、１人月（いちにんげつ）という。同様に、１日分の仕事量なら１人日（いちにんにち）である。

この単位は、システム開発の規模を見積もる場合や、プログラマなどの要員を作業に割り振る場合に使われる。例えば、10人日の作業量として見積もられた仕事に、２人のプログラマを投入すると、５日で出来るだろうというわけだ。

この「人月」という考え方は、今でも多くの場面で使われているが、昔からいろいろな問題点が指摘されており、非常に取り扱いが難しいものである。普段、「人月」という単位を何気なく使っている人も多いと思うが、一度、立ち止まって考えてみることも必要だろう。

★
「人月」の問題点を全てここで述べることはできないが、以前に書いた「プログラマは誰でも同じ？」という題材に関して、「人月」という観点から再び考えてみようと思う。

１人月、１人日という単位は、「平均的」な生産能力をもつプログラマが作業した場合の時間を基準にしている（※１）。

もし、プログラマが誰でもほとんど同じ能力を持っているのであれば、見積の「人月」とプログラマの人数が一致するように、プロジェクトのメンバーを集めればよいはずだ。しかし、実際には、同じ１人月という仕事量でも、５日で終わらせてしまうプログラマもいれば、３ヶ月掛かるプログラマもいる。プログラマの生産能力の個人差は、非常に大きいのである。

まず、プログラムを作る速さが人によって違う。このことは生産性に直結するのはもちろんである。しかし、それ以上に、生産性に大きく影響を及ぼすのは、出来上がったプログラムの品質の差である。

品質の悪いプログラムは、良いプログラムに比べて、何倍もの時間を掛けてテストやデバッグ（※２）を繰り返さなければならないため、全体的な作業量が爆発的に増加するのである。

また、品質があまりに悪い場合には、いったん完成していたものを破棄して、最初から作り直すようなことも珍しくない。

このような粗悪なプログラムしか作れないプログラマの生産能力は「マイナス」だといってもいいだろう。平たく言えば、「足を引っ張っている」ということだ。

★
作業量の見積が正確だと仮定すると、開発プロジェクトに参加している全員の能力の平均が、見積時に想定した「平均値」以上の能力にならなければ、納期に間に合わないという理屈になる。

大人数のプロジェクトであれば、無作為にプログラマを集めてきても、結果的には全体のスキルが「平均値」に近づくかもしれない。しかし、少人数のプロジェクトになるほど、「平均値」から外れるリスクが高くなり、プログラマの能力を考慮した上での要員確保がより重要となってくる。

現実には、明らかに生産力が不足しているプロジェクトを見かけることもある。会社全体の人材不足など、やむをえない事情もあるのかもしれないが、プログラマの能力を考慮しなかった結果としてそうなってしまった場合もあるようだ。

例えば、「有能なプログラマが１人いるから、あとは全員が新人プログラマでも大丈夫だろう」とか、「新人プログラマ２人では心配だから、３人にしておこう」といった判断がなされた場合は危険だ（※３）。こうした発言を聞いたとしたら、「マイナス」の生産能力という考え方が存在していないことの証拠であり、要注意である。

応援のクリックお願いします →

※１
平均の母体は、色々と考えられるが、見積の時点で開発に参加するメンバーが決まっている場合は、そのメンバーの実際の平均スキル（らしきもの）を元に見積を行うことができるので、見積の精度が高くなる（はずである）。

※２
デバッグは、プログラムの間違い（バグ）を修正すること。

※３
ここでは新人プログラマを生産性が低いプログラマの代表として扱っているが、もちろん、現実には有能な新人プログラマもいる。

■関連記事
・プログラマは誰でも同じ？
・簡単な仕事を探す難しさ