工数・人月とは?発注者が知るべき計算方法と見積もりの読み方

開発会社から見積もりを受け取ったとき、「工数:10人月」「要件定義:2人月、設計:3人月、開発:5人月」といった記載を目にすることがあります。しかし、「人月って何?」「10人月は多いのか少ないのか?」と疑問を持ちながら、担当者に聞くのが気後れして、そのまま発注してしまった経験はないでしょうか。
工数・人月はシステム開発の見積もりで頻繁に登場する概念ですが、エンジニア以外の方には馴染みが薄い用語です。意味を理解しないまま発注すると、「工数が増えたので追加費用が発生します」という連絡を受けたときに、適切な判断ができなくなるリスクがあります。
しかし安心してください。工数・人月の考え方は、一度理解してしまえばシンプルです。この記事では、工数と人月の基礎知識を丁寧に解説するとともに、発注者として見積もりを正しく読み活用するための実践的なポイントをお伝えします。
この記事を読み終えた後は、見積もり書の工数表記の意味を理解し、「この見積もりは妥当か」を自分で確認する視点が身についた状態になっているはずです。ぜひ最後まで読み進めてください。

目次
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き

この資料でわかること
こんな方におすすめです
工数とは?システム開発で使われる「作業量」の単位

工数の定義と使われ方
工数(こうすう)とは、ある作業を完了するために必要な「人数 × 時間」の総量を表す概念です。「Man-Hours(マンアワーズ)」とも呼ばれ、日本のシステム開発現場では日常的に使われています。
工数の基本的な計算式は次のとおりです。
工数 = 人数 × 期間
たとえば、1人のエンジニアが3ヶ月かかる作業の工数は「3人月」です。3人のエンジニアが1ヶ月かかる作業も同じく「3人月」と表現します。人数と期間をかけ算するだけですので、理解しやすい指標です。
工数が使われる理由
では、なぜシステム開発では工数という単位が使われるのでしょうか。
システム開発のプロジェクトでは、1つの作業を複数のエンジニアが分担して行うことが一般的です。たとえば「設計」という工程を、1人が6ヶ月かけて行う場合と、3人が2ヶ月で行う場合では、かかる合計の作業量は同じ「6人月」です。しかし「期間だけ」を見ると前者は6ヶ月、後者は2ヶ月と見え方が異なります。
工数(人月)という単位を使うことで、チームの人数が変わっても、プロジェクト全体の作業量を一貫した指標で表せるのが利点です。発注者が複数の開発会社から見積もりを取り寄せたときも、「何人月かかるか」という軸で比較できます。
人日・人月・人時の違い——工数の3つの単位を整理する
人時・人日・人月の定義と標準値
工数の単位には「人時」「人日」「人月」の3種類があります。それぞれの標準値と変換の目安は以下の通りです。
単位 |
定義 |
標準稼働 |
|---|---|---|
人時(にんじ) |
1人が1時間で行える作業量 |
1時間 |
人日(にんにち) |
1人が1日で行える作業量 |
8時間(= 8人時) |
人月(にんげつ) |
1人が1ヶ月で行える作業量 |
20日(= 160時間) |
システム開発の世界では「1日8時間・月20営業日」が標準稼働として広く使われています。そのため、1人月 = 20人日 = 160人時という換算が一般的です。
単位の使い分け
プロジェクト規模 |
主に使われる単位 |
理由 |
|---|---|---|
小規模(1週間〜1ヶ月未満) |
人日・人時 |
細かい粒度の見積もりが必要 |
中規模(1〜6ヶ月程度) |
人月 |
月単位で管理するため |
大規模(6ヶ月以上) |
人月 |
大きな単位でスコープを把握するため |
発注者が受け取る見積もり書では、ほとんどの場合「人月」が使われています。中規模以上のシステム開発プロジェクトでは、人月が最も直感的にわかりやすい単位だからです。
工数の計算方法——人月を使った計算例で理解する

工数の計算式と基本例
工数の計算式はシンプルです。
工数(人月)= 人数 × 期間(月)
いくつか具体例で確認してみましょう。
状況 |
計算 |
工数 |
|---|---|---|
1人のエンジニアが5ヶ月かけて開発 |
1人 × 5ヶ月 |
5人月 |
3人のエンジニアが4ヶ月かけて開発 |
3人 × 4ヶ月 |
12人月 |
5人のエンジニアが3ヶ月かけて開発 |
5人 × 3ヶ月 |
15人月 |
「5人のエンジニアが3ヶ月かけるプロジェクト」と「3人のエンジニアが5ヶ月かけるプロジェクト」では、期間や人数は違いますが、工数(= 作業量)は異なります。実際には後者が多くなる点に注意が必要です。
工数から開発費用を計算する仕組み
工数がわかれば、開発費用の概算を計算できます。計算式は次のとおりです。
開発費用 = 工数(人月)× 人月単価
人月単価の目安(2026年現在の相場):
エンジニアのスキルレベル |
人月単価の目安 |
|---|---|
ジュニア(経験1〜2年) |
40〜65万円 |
ミドル(経験3〜5年) |
65〜90万円 |
シニア(経験5年以上) |
90〜120万円以上 |
(出典:レバテック「人月単価の相場」。スキルや技術領域によって変動します)
たとえば、「10人月の開発案件」に対して、人月単価80万円のエンジニアが担当する場合、概算費用は 10人月 × 80万円 = 800万円 となります。
複数のエンジニアが異なるスキルレベルで関わる場合は、それぞれの人月数 × 各人月単価を積み上げて計算します。
工程別の工数配分の目安
システム開発のプロジェクトは複数の工程から構成されており、各工程に対して工数が配分されます。一般的な目安は以下の通りです(IPA「ソフトウェアメトリクス調査」・JUAS「ソフトウェア・メトリクス調査2025」をもとにした業界標準値)。
工程 |
工数比率の目安 |
|---|---|
要件定義 |
10〜15% |
基本設計・詳細設計 |
20〜30% |
プログラミング(実装) |
30〜40% |
テスト(単体・結合・総合) |
20〜30% |
リリース・移行作業 |
5〜10% |
これらの比率はプロジェクトの性質によって変わりますが、見積もりの工程別工数がこの目安から大きく外れている場合は、根拠を確認することが重要です。たとえば「テスト工程の工数が3%しかない」という見積もりは、品質確保の面でリスクがある可能性があります。
発注者として工数・人月を活用する3つのポイント

ここからが、この記事の核心です。工数・人月の知識を、発注者として実際にどう活用すればよいかを説明します。
ポイント1:工数の妥当性を確認する3つの視点
見積もりを受け取ったとき、工数が妥当かどうかを確認するには次の3つの視点が有効です。
視点1:工程間のバランスを確認する
前述の工程別工数比率の目安と比較してみてください。たとえば「テスト工程の工数が全体の5%しかない」という見積もりは、テストが軽視されているか、テスト工数が別途見積もられていない可能性があります。開発会社に「テスト工程の内訳を教えてください」と確認することが重要です。
視点2:複数社の見積もりを比較する
同一の要件定義書(RFP)を複数社に送付し、工数を比較することが効果的です。工数に2倍以上の差がある場合は、「その差はどこから来るのか」を各社に説明を求めることができます。「A社は15人月、B社は8人月」という差があれば、「どのような前提の違いがあるか」を聞くことで、見積もりの根拠が透明になります。
視点3:類似プロジェクトの実績値を参照する
開発会社に「同規模・同業種の類似プロジェクトの実績工数を教えていただけますか」と尋ねることも有効です。過去の実績と大きく乖離した見積もりには、理由があるはずです。
ポイント2:工数追加で追加費用が発生する仕組み——請負と準委任の違い
「工数が増えたので追加費用が発生します」という連絡を受けて困惑した経験がある方もいるかもしれません。これは契約形態の違いが深く関係しています。
請負契約(かいうけけいやく)とは、「成果物の完成を約束する」契約形態です。原則として、工数が増えても費用は変わりません。仮に開発が想定より長引いても、開発会社側の負担で完成させる義務があります。発注者にとっては費用が固定されるメリットがある一方、要件の途中変更が難しくなります。
準委任契約(じゅんいにんけいやく)とは、「作業プロセスを委任する」契約形態です。工数に応じて費用が発生するため、仕様変更や追加要件に柔軟に対応できる反面、工数が増えると費用も増加します。アジャイル開発やスクラム開発では、この準委任契約が多く採用されています。
項目 |
請負契約 |
準委任契約 |
|---|---|---|
成果責任 |
完成責任あり |
なし(作業プロセスへの責任) |
追加費用 |
原則発生しない |
工数増加に応じて発生 |
途中の仕様変更 |
難しい(別途交渉が必要) |
比較的柔軟 |
向いているケース |
要件が固まっている案件 |
要件が変わりやすい、AI活用・アジャイル開発 |
見積もりを受け取った段階で「どちらの契約形態か」「工数が増えた場合の費用はどうなるか」を確認しておくことが、発注者として非常に重要です。
ポイント3:工数見積もりの「落とし穴」——発注者が知っておくべき3つの注意点
注意点1:バッファ(余裕工数)の扱いを確認する
開発会社の見積もりには、リスクや不確実性に備えた「バッファ(余裕工数)」が含まれている場合があります。通常は10〜20%程度のバッファが含まれることが多いですが、過大なバッファが含まれていることもあります。「このバッファはどのようなリスクを想定していますか?」と確認することで、見積もりの根拠を把握できます。
注意点2:スキルレベルと人月単価のギャップ
人月の「単価」は担当エンジニアのスキルレベルによって大きく異なります。「人月単価80万円×10人月 = 800万円」という見積もりでも、担当するエンジニアがジュニアエンジニア主体であれば、人月単価は実態より高い可能性があります。「担当エンジニアのスキルレベルと人月単価の根拠」を確認することが有効です。
注意点3:管理工数(PM工数)の含まれ方
大規模なプロジェクトでは、プロジェクトマネージャー(PM)の管理工数が別途計上されることがあります。「見積もりにPM工数は含まれていますか?」と確認することで、想定外の追加見積もりを防げます。
まとめ——工数・人月を理解して、開発会社と対等に向き合おう
この記事では、工数・人月の基礎知識から、発注者として見積もりを読む実践的なポイントまでを解説しました。最後に重要なポイントを整理します。
工数・人月の基礎
- 工数 = 人数 × 期間。作業の総量を表す概念
- 1人月 = 1人が1ヶ月(20日・160時間)で行える作業量
- 開発費用 = 工数(人月)× 人月単価
発注者として活用する3つのポイント
- 工程別の工数比率の目安と照らし合わせて、バランスを確認する
- 複数社の見積もりを比較し、差の理由を確認する
- 請負 vs 準委任の違いを理解し、工数追加時の費用発生ルールを事前に確認する
工数・人月を理解することは、「開発会社との信頼関係を築く第一歩」でもあります。専門用語を理解することで、開発会社とより対等な立場で会話でき、プロジェクトの成功確率が高まります。
見積もりをもらったら、ぜひこの記事の内容を思い出しながら確認してみてください。さらに詳しく見積もりの比較方法を知りたい場合は、システム開発の費用相場も参考にしてください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き










