正しい人月見積もりのやり方

ちょっと釣り気味のタイトルですが、大真面目です。
もう少し正確にタイトルを付けるとするなら、「一番マシな人月契約のやり方」といったところでしょうか。

さて、IT業界の受託開発において、人月見積もりはダメだという事はいまさら説明する必要もないと思いますが、それでも難しい大人の事情もあり、人月でやらざるを得ない場合があると思います。

そんなとき、どんな方法で見積もり（契約）するのがよいのかを考えてみました。

一番ダメなパターン

一番ダメなのは、発注元によって人月単価が決まっていて、下請け業者に工数だけを見積もらせるようなやり方です。*1

これはダメですよ。

ダメすぎます。

なぜなら、優秀なエンジニア（開発会社）ほど工数が少なくなり、逆に無能なエンジニア（開発会社）ほど工数が大きくなるので、前者の方が損をして後者のほうが得をする仕組みだからです。

こんな馬鹿な話ないですよね。

実際にこのやり方をしている発注元はすぐにやり方を見なおすべきです。でないと優秀なエンジニア（開発会社）ほど離れていってしまいますよ。契約してくれるのは、パフォーマンスに自信がないエンジニア（開発会社）ばかりとなってしまいます。

こういったやり方を時間請けとか人月契約などと言って、労働時間に対価を支払うような考え方に基づいています。建設業界などの人工（にんく）という概念と全く同じです。*2

そうじゃないやり方として、作成請けとか請負契約などと呼ばれる*3方法があります。これは、成果物に対価を支払うという考え方です。
その成果物の価値は、それを作るのに必要な人月を想定して発注元が決めます。*4

では、作成請けでやるにはどうすればよいのでしょうか。

ここからは、私が普段から実践している作成請けの考え方を簡単に紹介します。

※ここで書いているやり方が100%正解だとは思っていません。現状、こうすればうまく行きましたよ、みたいなレベルの参考情報として受け止めて下さい。

まずはじめに、基本概念となる工数の説明をします。

工数とは

工数の計算式は、単純な考え方をするなら

工数 ＝ 規模 ÷ 生産力

です。
ここで、

• 規模とは、ソフトウェアの開発の大きさ、ボリュームのことです。規模見積もりには色んな方法論があります。例えばステップ数、COCOMO法、FP、カン等です。とりあえず従来のやり方で見積もればいいでしょう。また、リスクを見込んで定量的に規模をいくらか増やしたりする事もあります。
• 生産力とは、簡単に言うとソフトウェアの開発力です。これは担当者ごとに開発力が変わります。新人は開発力が低いし、優秀な人だと開発力が高いです。余談ですがまれに生産力がマイナスの人もいます。

例えば、規模 6000、生産力 2000/人月 とすると、工数は 3人月 です。

作成請けでの見積もり方法

前提として、発注元はどんなものを作って欲しいのかを明確に定義できる必要があります。不確定要素がある程度あってもいいですが、それが多すぎると、作成請けにしづらいと思います。

【発注元】

発注元はまず、想定工数をあらかじめ算出しておく必要があります。これはどんなやり方でもいいと思います。規模見積もりをして生産力で割ってもいいし、他のやり方でもいいでしょう。
そして求めた想定工数に基準単価をかけて、基準金額とします。

基準金額 = 想定工数 × 基準単価

【請け負う側】

請け負う側は、どんなものを作るのかを理解し、どれくらいの開発規模があるかを見積もります。ここで間違えてはいけないのは、見積もるのは規模であって、工数ではありません。
この工程を規模見積もりと呼んでいます。ここで見積もった規模が、すべての基準になります。

次に、規模見積もりで求めた規模に、実際に担当する要員を想定して生産力で割って工数を計算します。
複数人で分担する場合は、誰がどこを担当するかまで決められるなら、担当ごとに工数を出して、総和を求めます。
これを社内工数と呼んでいます。

社内工数 ＝ 規模 ÷ 実際の生産力

ここでもよくある間違いとして、この社内工数をベースに見積書を作成してしまうやり方が見受けられます。
これをベースにしてはいけません。これはあくまで社内のマネジメント用の工数です。*5

では、見積もり金額はどう計算するのでしょうか。
こうです。

見積もり工数 ＝ 規模 ÷ 一般的な生産力
見積もり金額 ＝ 見積もり工数 × 基準単価 ＋ α

これが見積書に記載する金額（のベース）となります。αの部分は、管理工数や諸経費などが入ります。基準単価は、社内規定や業界の相場を基準に決定したりします。
見積書には、見積もり工数を記載してもしなくてもどっちでも構わないと思います。記載しなくとも、単価を仮定して工数を逆算したりできるので。

また、様々なビジネス要因により見積もり金額にさらにいくらか儲けを上乗せする場合もあるでしょう。商習慣によって値引き要求が当たり前になっているような業界もあったりするからです。
逆に、戦略的に見積もり金額を下げて安く出すこともあるかもしれません。

見積もり検討

発注元は、見積もり金額をベースに基準金額と比較しながら、妥当かどうかを検討すればよいわけです。
見積書に工数の記載があれば、参考にすればよいと思いますが、あくまで参考です。実際にはそれより工数が小さいかもしれませんが、それは開発会社の頑張り次第ですので、値引きの余地はありません。

これで金額が折り合わなければ、

• 発注側の想定工数が甘い
• 受注側の規模見積もりに相違がある（要件に不確定要素が多いためリスクを多くとられている等）
• 単価の相場感が食い違っている

のどれかです。

金額が折り合えば、発注側・受注側どちらもお互い気持よく契約できます。
受注側は工数を気にすることなく、早く完成させれば別の仕事を受注することが出来ます。
（アメリカでは、プロジェクトの成果が良かった場合に報奨金を出す場合もあります。そうやって開発会社の生産力を向上させていくわけです。アーンドバリューマネジメントと言います。）
逆に、定められた納期に間に合わなかった場合でも発注側は追加料金を支払う必要はないので、時間請けとは異なります。

要点は、実際の生産力と、見積もり計算に使用する一般的な生産力を分けて考えることです。人月見積もりでは、労働時間に価値基準があるため、生産力の概念を明確に分けて考えておかないと、生産力が高い人ほど儲からなくなってしまいます。

納期について

納期も実は見積もりに影響します。

発注元が短納期を求める場合は、見積金額が高くなります。
理由は、請け負った方の事情を考えれば分かります。納期を短縮するには、優秀なエンジニアを何人も投入する必要があるからです。それでも、希望納期にモノが出来上がることに価値があると思うなら、通常よりも高いお金を払ってでも欲しいと思うはずです。

逆に納期を長くしても良いなら、値下げ交渉の余地があります。
なぜなら、納期が長くてもよいなら、優秀なエンジニアを注力する必要がなくなり、新人エンジニアでも仕事を終わらせることができるからです。
※誤解してはいけないのは、マネジメントや品質管理はキチンとしなくてはなりません。新人が担当したから成果物の品質が低い、というようではお話になりません。

人月契約って

ホント、早くなくなってほしいです。
誰も幸せにならない仕組みです。
IT受託開発（いわゆるSI）の業界は疲弊しきっています。
発注側がもっと賢くなって、このダメな習慣を変えないといけないと思っています。

*1:工数どころかステップ数を見積もりとして提出させるところも未だにあります

*2:SES: System Engineering Service とか言われるエンジニア派遣契約もほとんど同じ考え方ですね

*3:呼び方にはいくつか流儀があるようです

*4:本来であれば、人月基準ではなく実際の価値を基準にするべきですが、いきなりそのような考え方に変わらないだろうという想定で書いています

*5:実はここまでは価値基準見積もりでやる場合でも同じです。マネジメント用の工数は結局人月が必要となるからです