ソフトウェア開発について人月商売は悪であるという主張があります。「人月商売」で検索すると次のような記事が見つかります。
ITエンジニアの価値を貶める『人月商売』の功罪 – paiza開発日誌
記者の眼 – 木村の主張「人月商売や多重下請けは滅びの道」、読者はどう考えるか：ITpro
「人月商売」がソフトウェア開発の悪の根源のようです。
人月とは
人月とは、見積の単位です。５人で６カ月かかる仕事ならば、30人月となります。ならば、30人いれば１カ月でできるかというと、そうはなりません。その理由についてはここでは触れませんが、なんとなくわかると思います。
人月商売の何が悪いのか
人月商売とは人貸業の意味で使われています。５人の技術者を６カ月貸して、いくらだという商売のやり方です。技術者のスキルは、１人月あたりの単価に反映されます。
技術者の生み出す価値ではなく、労働時間に対して値段をつけることにより、知識集約型ではなく、労働集約型の仕事と扱われることになります。
時給で働いているアルバイトと同じ扱いになるため、長期間の教育と経験で培われた技術者のスキルがないがしろにされている感じになります。
技術者がどれだけの価値をお客様に提供したとしても、労働時間だけの報酬しか得られないことも、技術者のモチベーションに影響を与えます。
これらが、人月商売が悪だと言われる理由です。
ＩＴベンダーは請負開発に向かった
そのため、ＩＴベンダーは請負開発に向かいました。請負開発であれば、技術者の努力や創意工夫により生産性が向上し原価が下がれば、利益が増えるためです。大手のＩＴベンダーほど受託開発を指向しました。
受託開発であれば、お客様に提供する価値に見合う売り上げが得られれば、さらに利益の増加も見込まれます。
ところが、ソフトウェアの受託開発は非常に厳しい競争状態にあります。多くの競合が存在する状態では、どのベンダーもぎりぎりの金額でなくては受注できません。
各ベンダーが原価を計算するためには、技術者の人件費を計算するときの単位として人月を使います。これは、人貸業を人月商売と言うときの人月とは意味が違います。単なる原価を計算するときの単位です。
ソフトウェア開発の原価のほとんどは技術者の人件費です。そのため、ソフトウェア開発費を大まかに表すために○○人月という場合もあります。それが人月という言葉の意味するところにさらに混乱を与えています。
受託開発はうまくいかない
もうひとつ、ソフトウェアの受託開発には、大きな落とし穴があります。ソフトウェアは極めて複雑で、事前にすべての機能を決めることはできません。
利用者側も一部が出来上がってから、新しい要求に気づきます。そのため、仕様変更に伴う手戻りが当たり前のように発生します。
仕様変更により、費用やスケジュールの見直しがきちんと行われれば大きな問題は発生しません。ところが、発注者側は仕様変更とは認めたくなく、当初の金額やスケジュールの維持を望みます。
ベンダー側は少しでも仕様変更を認めてもらい、金額やスケジュールの見直しを図ろうとします。そこには、発注者側とベンダー側に大きな利害の対決が発生します。どのように決まったとしてもお互いに不満が残ります。
ソフトウェアは複雑すぎるため、受託開発は発注者側とベンダー側に利害の対立を引き起こします。
そこでまた人月に戻ってくる
この問題の解決策は、技術顧問契約です。コンサルティング契約に近い契約です。その見積もりの単位はやはり人月になります。
そこでは、総額の予算や納期は契約では決まっていません。プロジェクトの主導は発注者側で行います。これまでの成果を確認し、これからの作業内容を決めながらプロジェクトを進めていきます。
この方法をとっている人にとっては、人月商売は決して悪ではありません。
まとめ
ソフトウェア開発における人貸業の意味では、人月商売は悪です。技術者のモチベーションを毀損します。
それを避けるためにソフトウェアの受託開発をするとき、原価の計算に人月を使います。この人月は単なる単位です。
ソフトウェアの受託開発はうまくいきません。ソフトウェアは複雑すぎ、事前にすべての機能を洗い出すことなどできないためです。
技術顧問契約における人月は、悪ではありません。
【関連記事】
