プロジェクト管理の場で、必ずと言って良いほど耳にするのが〝人月〟という言葉です。これは「開発者一人の仕事量何ヶ月分か」を表した単位で、全体を把握しにくいSEの業務を分かりやすく可視化した、画期的な概念でした。
しかし近年、「この〝人月〟という考え方は危険だ」、という意見も現れ始めました。
いったい人月にはどのような弱点があるのか、検討してみましょう。

受注側のデメリット

• 計算方法

人月という考え方の最大の弱点は、計算方法にあります。大きなプロジェクトであれば、開発者が何十人といるのは珍しくありません。
しかし人月を見積もるためには、その中の誰か一人を基準にして計算しなければなりませんよね。当然、個人の技術力には大きな差異があるため、その見極めは非常に難しいものになります。
よって人月とは、想像で作った「標準的な技術者」を頭に浮かべて決めなければならない、何とも曖昧な数字だと言わざるを得ないのです。

• 「人」と「月」の置き換えが出来るように見えてしまう

見積りを出した際、クライアントにほぼ必ずと言って良いほど言われるのが、納期の短縮です。
「早く開発して欲しい。資金は出すから人を増やして対応してくれ」
という要求は、一見妥当なように見えるものの、加減を間違えるとスケジュールが破綻してしまうことを忘れてはいけません。

分かりやすく、極端な例を挙げてみましょう。

「1人月の仕事を、30人投入すれば1日でプログラムが完成するか？」ということです。プログラムはモジュールを細分化し、細かく作っていくものですので、人を増やせば解決するようなものではないのです。
さすがにこれは酷い例ですが、「人」と「月」の置き換えの危険性については、納得して頂けるのではないでしょうか。

発注側のデメリット

• 見積りの妥当性の不確かさ

これは受注側と同じく、「基準とする技術者」を想像で決めなければならないことで起こる問題です。ベンダーの提出した見積もりについて、その妥当性は、どのように判断すればよいのでしょうか？
ベンダーが考える「基準となる技術者」とは、どういったレベルの人を指しているのかが、発注側には分かりません。どんなに高い見積もりを提示されても、それが誤りだと指摘することが出来ないのです。

• 作業時間で費用が発生する

人月とはその名の通り、「人」×「月」で現された単位です。見積もりの金額はこの数字を使って計算されるので、つまりは「時間」がそのまま費用になるのです。
これの何が問題かと言えば、成果物に対する代金ではないため、プロジェクトが炎上した方がベンダーは儲かる、という不思議な契約になってしまうのです。

ハードルは成果物主義の難しさ

これまで述べてきたように、人月という考え方の問題点は明白です。視覚的に分かりやすいからと安易に採用するのは避けたいところですが、しかし「ではどうすれば良いのか？」というと、簡単には答えられません。

「人月」の対となるのは「成果物」での費用の決め方ですが、日本ではそうした契約が交わされることはほとんどなく、そのため実例が少ないことがネックになります。前例がなければ、そうした契約に踏み切るのには、勇気がいりますよね。

とは言え、それを理由にいつまでも人月での見積もりをし続けることに、メリットはありません。少しずつでも、成果物での契約を行えるよう、見積りの際には意識してみると良いのではないでしょうか。