人月とは？計算方法・人月単価の相場と発注者が見積もりの妥当性を見抜く方法

人月（にんげつ）とは、1人が1か月働いて生み出す作業量を1と数える工数の単位で、システム開発の見積書ではほぼ必ず登場します。「この機能は3人月」「開発全体で20人月」という言い方で規模と費用の土台になりますが、単位の意味を知らないまま見積書を受け取ると、金額の妥当性を判断できず、開発会社の提示をそのまま呑むしかありません。この記事では、1人月が何時間・何人日にあたるかという換算から、人月単価の相場、見積書の人月から総額を試算する計算方法、そして発注者が水増しを見抜く着眼点までを整理します。あわせて、人員を増やせば工期が縮むという誤解を戒めた「人月の神話」も、発注判断の材料として取り上げます。

まとめ：人月の意味と発注者が見積もりの妥当性で押さえる判断基準

人月は「人数×期間（月）」で稼働の総量を表す単位です。1人月はおおむね20営業日・約160時間の作業量を指し、5人が4か月動けば20人月になります。見積書の総額は、この人月に人月単価を掛けて積み上げるのが基本構造です。人月単価はスキルや職種で幅があり、実装中心の若手なら月60〜80万円、要件定義やプロジェクト管理を担う層なら月120万円を超えることも珍しくありません（2020年代半ば時点の一般的な相場帯）。

発注者がまず見るべきは、提示された人月が作業内容に対して膨らんでいないか、という一点です。機能一覧と人月の対応が示されず「一式」でまとまっている見積書は、内訳を開示してもらう必要があります。さらに、人月には根本的な限界があります。人を増やしても工期は比例して縮まりません。要員追加は教育とコミュニケーションのコストを生み、かえって遅れることさえある——これがブルックスの法則です。だからこそ、短納期を人月の積み増しで解決しようとする見積もりには注意が要ります。相場の細部はシステム開発の費用相場と人月単価の内訳で、人月で稼働を買う契約形態は準委任契約の仕組みと使い分けで確認できます。

人月とは何かという工数単位の意味と読み方・人日や人時との関係

まず言葉の定義と、人時・人日・人月という3つの単位のつながりから押さえます。ここを取り違えると、見積書の数字を10倍・20倍で読み違えてしまいます。

人月の定義と読み方および1人月が示す標準的な作業量と稼働時間

人月は「にんげつ」と読みます。定義はシンプルで、1人の作業者が1か月間フルタイムで働いたときの作業量が1人月です。ここでいう1か月は暦の30日ではなく、稼働できる営業日で数えるのが約束事です。多くの現場では月20営業日・1日8時間を基準に置き、1人月はおよそ160時間に相当します。企業によっては22営業日で計算する場合もあるため、見積書を比べるときは「1人月を何時間で計算しているか」を先に揃えると、単価の高い安いを正しく比較できます。なお「10人月」は10人が1か月でも1人が10か月でも同じ量を指し、投入の総量だけを表す単位です。

人時・人日・人月の換算関係と1人月がおよそ何時間・何人日にあたるか

工数の単位は、時間の粗さで人時・人日・人月の3段階に分かれます。小さなタスクは人時、数日規模は人日、プロジェクト全体は人月で表すのが実務の使い分けです。下の表が換算の目安になります。

この換算を使えば、たとえば「0.5人月」は約10人日・約80時間、「2人日」は約16時間、と読み替えられます。見積書で細かいタスクが人日、大きな塊が人月で書かれていても、160時間を基準に統一すれば一枚の物差しで見渡せるでしょう。工数を実績ベースで管理する側の考え方、たとえば予定工数と実工数の差をどう見るかは実工数の定義と予定工数・標準工数との違いにまとめています。

FTEと人月の違いと開発体制の稼働量を測る単位としての使い分け

人月と混同されやすいのがFTE（Full-Time Equivalent＝常勤換算）です。人月が「人数×月数」で期間全体の総稼働量を表すのに対し、FTEは「ある時点で常勤何人分が働いているか」を表します。週の半分だけ関わるエンジニアが2人いれば、稼働は1.0FTEです。プロジェクト全体の規模や費用を積み上げるなら人月、ある月にチームへ何人分の力が張り付いているかを見るならFTE、と役割が分かれます。ラボ型で「常時3FTEの体制を6か月」という契約なら、総量はおよそ18人月に相当する、という換算で費用感をつかめます。

人月による工数見積もりの手順と人月単価から総額を読み解く方法

次に、開発規模がどう人月に変わり、そこからどう金額が決まるのかを追います。計算の道筋が見えると、見積書のどこを質問すべきかが分かります。

開発規模を人月へ換算する工数見積もりの基本的な進め方と前提条件

人月見積もりは、大きく2つの道筋で作られます。1つは、機能を洗い出して1つずつ工数を積み上げるボトムアップ方式。もう1つは、過去の類似案件の規模から全体を先に置く類推方式です。実務では、まず機能一覧を作り、各機能に「設計・実装・テスト」の工数を人日で割り当て、合計を人月に丸めていきます。ここで前提になるのが、要件がどこまで固まっているかです。要件が曖昧なまま出された人月は、後から膨らむ前提の数字だと考えたほうが安全でしょう。工程ごとに何を決めるべきかはシステム開発の流れと各工程を押さえると、見積もりの粒度を判断しやすくなります。

人月単価を構成する費用の内訳と職種・スキル別に見た相場の目安帯

人月単価は、作業者の給与だけで決まるわけではありません。社会保険料などの人件費に、オフィスや機材の経費、開発会社の管理費と利益を乗せた金額が単価になります。だからスキルが同じでも、元請けか二次請けかで単価は変わります。開発拠点を海外に移すオフショア開発なら、同じ実装力をより低い人月単価で確保できる場合があり、これも単価が割れる一因です。職種・スキル別の目安は次のとおりです（時点や地域で変動するため、あくまで幅として捉えてください）。

単価の相場や、なぜ同じ機能でも会社によって金額が割れるのかという背景はシステム開発の費用相場と人月単価の内訳で詳しく扱っています。見積書の単価が相場帯から大きく外れているなら、その理由を尋ねる根拠になります。

見積書に並ぶ人月から開発総額を試算する具体的な計算例と注意点

計算の骨格は「人月×人月単価」の足し上げです。たとえば要件定義2人月・設計3人月・実装8人月・テスト3人月で合計16人月、平均単価を月100万円とすれば、開発費はおよそ1,600万円と試算できます。ここに、上級者が多い工程は単価を上げ、若手中心の工程は下げる、という重み付けを入れると精度が上がります。注意したいのは、見積書に「開発一式 20人月」としか書かれていないケースです。工程別・機能別に人月が割れていなければ、どこに費用が乗っているか検証できません。総額の大小より、人月の内訳が開示されているかを先に確認してください。

発注者が人月見積もりの妥当性を検証する着眼点と水増しの見抜き方

ここからは、競合の解説記事があまり踏み込まない発注実務の話です。人月見積もりは、作り手が数字をどう置くかで総額が動きます。発注者が確認すべき点は、はっきりしています。

人月の水増しを見抜くために発注者が見積書で確認する三つの項目

人月が過大かどうかは、次の3点を見れば見当がつきます。1つ目は内訳の粒度で、機能ごとに人月が割り当てられているか。2つ目はバッファの置き方で、各工程に一律で上乗せされた予備工数が積み重なって総額を押し上げていないか。3つ目は単価と役割の整合で、単純な実装工程に上級者の単価が当てられていないか。

• 機能・工程別に人月が分解されているか（「一式」でないか）
• 工程ごとのバッファが二重・三重に乗っていないか
• 作業内容と作業者のスキル層・単価が釣り合っているか

3点のうち最初に効くのは内訳の開示です。ここが崩れると残りの検証はできません。逆に、機能ごとの人月と単価が並んだ見積書なら、高いと感じた工程だけを名指しで質問でき、交渉の土台が整います。

準委任やラボ型開発で人月契約を結ぶ際に発注者が押さえる前提条件

人月は、稼働そのものを買う契約と相性が良い単位です。要件が固まりきらないアジャイル開発や、一定人数を一定期間確保するラボ型開発で選ばれるのは、成果物を完成義務で縛る請負ではなく、稼働に報酬を払う準委任です。この場合、費用は「何人月をいくらで確保するか」で決まるため、人月単価の妥当性がそのまま総額を左右します。人月契約で発注するなら、稼働報告の様式と頻度を契約時に決め、投入した工数が見えるようにしておくとよいでしょう。準委任と請負のどちらを選ぶべきかは準委任契約の仕組みと請負との使い分けで整理しています。要件が曖昧な段階から人月ベースで伴走してほしいなら、工程設計から相談できるWebシステム開発の依頼先を選ぶと、見積もりと契約のミスマッチを避けられます。

人月の神話が示す人員追加と工期短縮が比例しない仕組みと発注判断

人月には、数字を足し算できてしまうがゆえの落とし穴があります。「20人月なら10人で2か月」と考えたくなりますが、ソフトウェア開発ではそう単純にいきません。この点を古典的に指摘したのが『人月の神話』です。

ブルックスの法則が示す人月と開発期間の非線形な関係とその背景

『人月の神話（The Mythical Man-Month）』は、IBMのフレデリック・ブルックスが1975年に著した書籍で、1995年に20周年記念版が出ています。ここで示された「遅れているソフトウェアプロジェクトへの要員追加は、そのプロジェクトをさらに遅らせる」という経験則が、ブルックスの法則です。人と月は、単純作業なら交換できても、開発では交換できません。理由は2つあります。新しく入った人が戦力になるまでには教育の時間がかかること、そして人が増えるほど連携の経路が増えることです。5人なら意思疎通の経路は10本ですが、10人になると45本に跳ね上がり、調整コストが急増します。つまり人月は費用の見積もりには使えても、そのまま工期の短縮計算には使えない、という理解が発注側にも要ります。

人月商売や人月計算がおかしいと批判される背景と発注側の向き合い方

人月には「人月商売」「人月計算はおかしい」という批判がついて回ります。核心は、価格が成果ではなく投入時間で決まる点にあります。同じ機能を、生産性の高い技術者が半分の工数で作っても、人月単価×人月で計算すると報酬は減ってしまう——これでは高い技術力が評価されにくい、という指摘です。発注側がこの構造と向き合うには、人月を「投入量の目安」と割り切り、成果物の品質や納期の確実性は別の条件で契約に書き込むのが現実的でしょう。人月の多寡だけで発注先を選ばず、過去の実績や体制で判断を補うことで、人月商売の弱点を避けられます。安く見える人月見積もりが、経験の浅い体制を前提にしていないかを見極める目が、結局はコストを左右します。

よくある質問

人月について、発注担当者から実際に多い質問をまとめました。

人月の読み方は何ですか？

「にんげつ」と読みます。1人の作業者が1か月間フルタイムで働いた作業量を1人月と数える、工数の単位です。同じ系統の単位に「人日（にんにち）」「人時（にんじ）」があり、規模の大きさに応じて使い分けます。見積書では「3人月」のように、数字＋人月の形で開発規模と費用の土台を表します。

1人月は何時間・何人日にあたりますか？

多くの現場では、1人月を月20営業日・1日8時間として、約160時間・約20人日で計算します。ただし1か月を22営業日で数える会社もあり、その場合は約176時間です。見積書を比較するときは、各社が1人月を何時間で計算しているかを先に確認すると、単価の高低を正しく比べられます。

FTEと人月はどう違いますか？

人月は「人数×月数」でプロジェクト全体の総稼働量を表す単位、FTE（常勤換算）は「ある時点で常勤何人分が働いているか」を表す指標です。週の半分だけ関わる人が2人いれば1.0FTEになります。総費用の積み上げには人月、その月の投入体制を見るにはFTE、と目的で使い分けます。

人月単価の相場はいくらくらいですか？

スキルや職種で幅がありますが、実装中心の初級で月60〜80万円、設計も担う中級で月80〜120万円、要件定義や管理を担う上級・PM層で月120〜200万円あたりが一つの目安です（時点や地域で変動します）。元請けか下請けかでも単価は動くため、金額の内訳と相場の背景は費用相場の記事で確認してください。

人月計算はなぜおかしいと批判されるのですか？

価格が成果ではなく投入した時間で決まるため、生産性の高い技術者ほど報酬が減りやすく、技術力が評価されにくいという批判があります。また、人を増やせば工期が縮むという前提もブルックスの法則で否定されています。発注側は人月を投入量の目安と割り切り、品質や納期の確実性は別の契約条件で担保するのが現実的です。

関連記事

• システム開発の費用相場と人月単価の内訳：人月単価の相場帯や、同じ機能でも金額が割れる理由を数字で確認できます。
• 準委任契約とは？請負・派遣との違い：人月で稼働を買うラボ型・準委任の契約設計を押さえられます。
• 実工数の定義と予定工数・標準工数との違い：見積もった人月と実績の差を工数管理側からどう見るかがわかります。
• 受託とは？委託・請負・SESとの違い：人月見積もりが出てくる発注方式の全体像を整理できます。