工数管理で用いられるビジネス用語「人月」の意味と見積もり時の注意点

「人月」は専門的な言葉で、日常的には使われないため、初めて聞いた人もいるでしょう。言葉自体は聞いたことがあっても、表面的な理解だけでは損する恐れがあります。人月の意味や使うシーン、特徴に加えて、注意点を解説します。

人月とは

まずは人月の意味を解説します。同様のケースで用いられる人日にも触れます。

工数管理で用いられる単位

業務をこなすに当たって、どれだけの人員と時間を割く必要があるか、あらかじめ把握しておくことが大切です。ある作業を完了させるのに必要な人数とかかる時間を工数といいます。そして事前に立てた計画を基にして、作業完了までの進捗（しんちょく）を管理することを工数管理と呼びます。

工数管理をする上で用いられる作業量の単位が『人月（にんげつ）』です。人月は1人が1カ月間働いた場合の作業量を表しシステム開発の見積もりでよく用いられます。「人数×時間（月）」として計算しますので、例えば100人が1カ月働いた場合の作業量は100人月、20人が5カ月働いた場合の作業量も100人月です。さらに発注額を人月で割り、人月単位として単価を確認するのも珍しくありません。

人日が使われるケースも

工数管理をするときの単位として、『人日（にんにち）』が使われるケースもあります。人日は1人が1日働いたときの作業量です。20人が5日間働けば100人日、3人が10日間働けば30人日です。人月と同じように人日単位を用いて、単価の比較が行われます。

人月ではなく人日が用いられるのは、開発するシステムの規模が小さいときです。数カ月から数年規模での開発が必要な場合は人月が用いられますが、数週間や1〜2カ月で完了する作業なら人日の方が規模感を把握しやすくなるでしょう。

人月による工数管理の特徴

人月の意味や使い方が分かっても、まだ具体的なイメージは湧いてこないでしょう。イメージを膨らませるために、続いて人月を用いた工数管理の特徴を解説します。

1人月当たりの仕事量は会社による

1人月は具体的にどれだけの仕事量を表すのでしょうか。実は1人月当たりの作業時間に統一された基準はありません。例えば同じ1人月でも、A社では1日8時間労働で1カ月の勤務日が20日でも、B社では1日5時間労働で1カ月の勤務日が12日である可能性が考えられます。

システム開発の業界でしばしば用いられる単位とはいえ、作業時間の定義が曖昧なのは人月の大きな欠点といえます。同じ10人月の仕事を頼んだとしても、A社では1,600時間分の働きをしてくれるのに対して、B社ではわずか600時間分の働きしかしてもらえません。

人を増やせば納期が縮まるわけではない

10人で6カ月にわたって作業したときの工数は60人月で、20人で3カ月作業したときも同じく60人月になります。したがって同じ作業を要するシステム開発の場合、人員を増やせば納期を早くできるように考えられます。しかし人数と時間を反比例の関係で捉えるのは誤りです。

確かに人数と時間の掛け算で必要な工数を表すのは、システム開発にかかるコストを算出する上で非常に便利です。一方でシステム開発の現場は、人月で表せるほどシンプルなものではありません。

人員が増えれば、それだけ管理の手間が増えるため、意思疎通に障害が生まれて、むしろ納期が遅くなる可能性も否めません。簡略化された数値だけではなく、システム開発の実態を把握することが重要です。

熟練者も素人も同じ1人月

人月で工数を表すのには、もう一つ問題があります。人月からは個人のスキルや経験が分からないことです。同じ10人月の仕事でも、20年以上もエンジニアとしてシステム開発に携わっている人が10人集まっている場合もあれば、10人のうち2〜3人しかまともなスキルを持ったエンジニアがいない場合も想定されます。

もちろん一人一人の熟練度が違えば、同じ時間を与えられたときにできる作業の量および質は異なります。悪質なシステム開発会社では、作業が終わっているのに社員を残業させたり、頭数をそろえるためにエンジニアの知識が不十分な人を配置したりするケースも見られるほどです。

人月で見積もりしてもらうメリット

(出典) photo-ac.com

人月でシステム開発に必要な工数とコストの見積もりを出してもらうのには、数多くの問題点があります。しかし日本では人月で作業量を表すのが一般的です。問題点に目をつぶってでも人月を使うのは、人月で作業量を示すのに大きなメリットがあるからです。人月で見積もりを出してもらうメリットを解説します。

見積額が分かりやすい

システム開発の見積もりで人月が用いられる最大の理由は、作業量を数値で示せて分かりやすいことでしょう。システム開発に関する知識が十分になければ、具体的にどのような作業を行うのか、各作業にいくらの費用がかかるのか理解するのは困難です。

人月は人件費を基準としてコストを見積もりしているため、システム開発に精通していない人でも一目見るだけで、どれだけのコストを要するのか分かります。専門性の壁が邪魔せずに、あらゆる分野の人が見積額に納得感を示し、複数の見積もりを比較できるのは大きなメリットです。

進捗状況を把握しやすい

人月による工数管理では、いつまでにどれだけの作業を終わらせる必要があるのか、ポイントごとに明確な期日が設けられています。そのため人月で工数管理をしている会社にシステム開発の発注をすれば、依頼後も進捗状況を逐一確認できます。予定より遅れていれば、ペースアップするように途中で口を挟めるので、最終的な締め切りに遅れる心配がありません。

システム開発会社にとっても、人月での工数管理にはメリットがあります。あらかじめ計画を立てているため、作業に入ってからは集中して作業に取り組めるほか、想定外のトラブルへも落ち着いて対応できるでしょう。繰り返しているうちに費用感がつかめてきて、見積もりの精度が上がるのも大きなメリットです。

人月で見積もりしてもらうデメリット

(出典) photo-ac.com

人月で見積もりしてもらうのにはデメリットもあります。見積もりの結果を見るときには、デメリットを踏まえた上で十分に注意が必要です。

見積額を誤魔化される

人月での見積もりにはさまざまな問題点があります。1人月当たりの仕事量が異なることに加えて、人数と時間は単純な反比例関係ではなく、個人の力量は反映されません。さらに同じ人月単価で複数の会社を比較できるほど単純でもありません。

人月の問題点を十分に把握していればきちんと判断できますが、知識がなければ適正な見積もりかどうか判断がつきません。人月単価だけを見て発注先を選ぶと、いつまでたっても納期が定まらず、トータルでは相場以上のコストがかかってしまうケースもあるでしょう。

人月による見積もりが分かりやすいのは、作業を極端に単純化しているからです。単純化する過程で省かれたポイントにも気を配らなければ、見積額を誤魔化されて損をしてしまう恐れがあります。

柔軟に対応してもらえない

システム開発に取り組んでいると、最初の契約時点では把握しきれていなかった問題点も、次々に浮かび上がってきます。途中で気付いた問題が実は重要なポイントで、システムの根幹に関わる問題であるケースも珍しくありません。本来であれば、十分な時間を割いて対応する必要のあるポイントです。

しかし人月で出した見積額を基に契約を交わしていると、途中で浮かび上がった問題には対応してもらえない可能性があります。なぜなら当初に想定していなかった問題に対処していると、納期が間に合わなくなって契約違反になってしまうからです。柔軟な対応が望めないのも人月による見積もりの欠点です。

IT業界への悪影響も

(出典) photo-ac.com

人月で見積もりを出す文化は、発注元に大きなデメリットがあるだけではなく、システム開発を担うIT業界にも悪い影響が及んでいます。

ITエンジニアの価値が下がる

システム開発の最初に労力をかければ後に大きなリターンが望めるのが、ITビジネスの大きな魅力です。またIT業界の成長が著しい昨今ではITエンジニアの需要が大きく、高収入や高単価の仕事が狙えます。

しかし人月で工数管理をする会社で働いた場合、ITエンジニアもほかの社員と同様に働いた時間に対して給与が支払われる形になります。知識集約型のはずのIT業界が、労働集約型の労働形態になるわけです。

労働集約型の働き方では、長時間働くほどに収入が増える仕組みです。労働時間と収入が比例する環境では、ITエンジニアに見合った給与が与えられる見込みは低く、低賃金労働の温床になります。

必要なスキルが身に付かない

人月商売では納期に間に合うように納品することが何より重要です。途中で新たな問題が判明しても、対応する必要はありません。中身がなくても、最初の契約内容にさえ沿っていれば何も問題がないといえます。

ゴールありきの仕事では常に質的水準が低く設定されてしまい、ITエンジニアは最低限の作業しか求められません。問題に対処して新しい知見を得ることにこそ、成長のチャンスが隠れています。人月商売をしている会社では問題に対処する過程を踏まないため、ITエンジニアにとって成長が見込めないでしょう。

個々のITエンジニアが成長できる環境になければ、日本全体としてもIT産業のクオリティが落ちていきます。一人一人のITエンジニアを大切にできないことで、全体に悪影響が及んでしまうといえるでしょう。

構成／編集部