人日、人月とはなんなのか？

システムを開発会社に発注しようとすると耳慣れない単位を聞くことがあります。
それが｢人日（にんにち）｣、｢人月（にんげつ）｣です。

この機能は簡単なので｢1人日｣ですね。
このシステムは概算で「10人月」ほどですね。

このような感じで使われます。

私も過去3回の記事の中で特に断りなく使ってしまったのですが、この人日、人月とはなんでしょうか？

それは簡単に言えば｢作業日数｣｢作業月数｣のことです。

1人の作業員が1日で終わる作業量のことを｢1人日｣、1ヶ月かかる作業量のことを｢1人月｣と呼んでいます。

非常に単純な話なのですが、この人日、人月の話は突き詰めていけば1つの矛盾があることがわかります。

それは腕の立つエンジニアほど人月、人日は少なくなり、開発費は安くなるということです。

「作業時間が短くて済むのであれば、開発費が安くなるのは当然でしょう」

と思われるかもしれません。しかし、それを逆に言えば、腕の悪いエンジニアがゴテゴテと冗漫に書いたプログラムの方が高くなり、高給取りになってしまいます。

それはさすがにおかしいと思うでしょう？

プログラムというのはセンスとノウハウの固まりであり、それらが豊富なベテランエンジニアほどささっとシステムを組んでしまいます。そういうシステムは後々に渡ってメンテナンスがしやすく動作も軽快で細かいところまで配慮が行き届いていて、価値が高いのです。

その意味で昨今、特に力のある開発会社を中心に、この「人日」「人月」で見積るのをやめましょうという動きが出てきています。

人日、人月ではない2つのアプローチ

そこで登場するのが、｢獲得便益による見積り｣と｢準委任契約｣の2つのアプローチです。

｢獲得便益による見積り｣とは、発注者が今から開発を依頼するシステムを導入することによっていくらの利益を得ることができるかを計算して、その中から開発予算を割り当てていただくというものです。

たとえばシステム導入によって、3年間で1億円の純利益が見込まれるのであれば、その3割くらいはかけてもよいか、ということで3000万円の予算を確定します。開発会社は発注者の求める内容を吟味し、その予算内で提案を考えます。もちろんどれくらいの作業量が発生するのか見込めないところがありますので、期間やレビュー回数などに上限を持たせる提案にはなるかと思います。

その提案内容で納得がいけば、契約締結となるというスタイルです。

この方法であれば、腕のよいエンジニアも予算の範囲内でとことん手腕を発揮することができます。持てる能力を出し切ってUI・UX的に優れたシステムを組み、洗練された書き方をして、コード量を少なくし、将来のシステム拡張に耐えやすくするようなことも可能でしょう。

開発会社にはずるずると開発期間を引き延ばすインセンティブはないので、クオリティの高い成果物を目指しつつも、リリースも早くなる可能性が高まります。