システム開発の見積もりを人月・人日から読み解く｜1人月は何時間？発注側の確認手順【2026年】

2026-07-29 2026-10-04

システム開発の見積書を受け取ると、金額の前に「3人月」「0.5人月」といった数字が掲載されていることがあります。この数字が何を表しているのかが分からないまま、末尾の合計金額だけを見て判断してしまうということは、発注側ではよくある場面です。

「人月」は、開発に必要な作業量を示す単位です。人月の意味と内訳が分かると、提示された金額が何に対する対価なのか、どの前提が置かれているのか、どこを削ると何が起きるのかが見えてきます。分からないままだと、2社の見積もりを並べても総額を比べることしかできません。

この記事では、1人月が実際には何時間を指しているのか、人日や人時とどう換算するのか、そして受け取った見積もりの前提と抜けを確かめる手順を整理します。なお、これで適正価格そのものを判定できるわけではありません。確かめられるのは、見積もりが何を前提に組まれ、何が入っていて何が入っていないか、スケジュールと体制が噛み合っているかまでです。価格そのものの妥当性は、複数社の前提をそろえて比べたうえでの判断になります。Enlyt（エンライト）が見積もりを出す前に何を確認しているかにも触れます。

見積書の「1人月」が指しているもの

「人月（にんげつ）」は、作業量を表す単位です。1人月は、1人が1か月間この作業に専念したときにこなせる量を1とした数え方になります。「3人月」であれば、1人で3か月、あるいは3人で1か月分の作業量という意味です。

注意したいのは、人月が「期間」ではなく「作業量」だという点です。3人月の見積もりが3か月で終わるとは限りません。単純換算では1人なら3か月、3人なら1か月ですが、後で触れるとおり、人数を増やせばそのぶん短くなるという単純な話にはなりません。

人月・人日・人時の関係

工数の単位は3段階あります。小さいほうから人時、人日、人月です。

• 人時（にんじ）　1人が1時間作業する量
• 人日（にんにち）　1人が1日作業する量。1日を8時間とするのが一般的です
• 人月（にんげつ）　1人が1か月作業する量

小さな改修の見積もりは「人日」や「人時」で、まとまった開発は「人月」で書かれることが多くなります。同じ見積書のなかで単位が混在していることもあるので、合計を自分で検算するときは単位をそろえてから足します。

1人月を何時間とするかは、会社によって違う

1人月を時間に直すには、1日の作業時間と、1か月の営業日数を決める必要があります。1日8時間、月20営業日で計算すると160時間になります。この置き方が広く使われています。

ただし、この前提は法律で決まっているものではありません。月の営業日数は実際には18日の月もあれば22日の月もあります。会社によっては1人月を150時間として扱っていたり、168時間（21営業日分）としていたりします。同じ「2人月」という表記でも、片方が300時間、もう片方が336時間を指していることがあり得ます。

2社の見積もりを比べていて、工数が同じなのに金額が違う、あるいは金額が近いのに工数が違う。そうしたときは、まずこの前提時間を聞いてみると、違いの意味や根拠が分かることがあります。

人工（にんく）という言い方

建設業や製造業の見積書では、人月や人日ではなく「人工（にんく）」という単位が使われます。1人工は1人が1日作業する量で、意味としては人日とほぼ同じです。システム開発の見積書に出てくることは少ないものの、設備工事やハードウェアの設置が絡む案件では、ソフトウェア部分が人月、工事部分が人工という形で混在することがあります。

工数の単位換算早見表

1日8時間、月20営業日を前提にした場合の換算です。前提が違えば数字も変わるので、見積書の前提を確認したうえで使ってください。

見積書に「0.1人月」と書かれていたら2日分、「0.5人月」なら10日分の作業という読み方になります。細かい改修の見積もりを受け取ったとき、この換算を頭に入れておくと、提示された作業量が感覚と合っているかを確かめやすくなります。

人月単価と工数から見積金額を読み解く

受託開発では、設計・実装・テストなどに必要な人の作業が、費用の大きな部分を占めます。人月で積算する場合は、作業量に人月単価を掛けて開発作業費を求めます。サーバー代やライセンス料は、これとは別に加算されることがあります。

計算式と、当てはめ方

基本の形はこうなります。

• 開発作業費 ＝ 各職種・各工程の「人月単価 × 工数」の合計
• 工数（人月）＝ 必要な作業時間 ÷ 1人月あたりの時間
• 期間の目安 ＝ 工数（人月）÷ 投入する人数（全員が専任で関わると仮定した単純換算）

3つめの式は、全員が同じ稼働率で専任で関わり、作業を分担できると仮定した単純換算です。実際には工程に順序があり、調整の手間もかかるため、この計算どおりにはなりません。この点はあとで詳しく触れます。

計算の形を示すために、仮に単価を80万円、工数を4人月として当てはめてみます。80万円 × 4人月で320万円。これが開発作業費にあたります。2人体制で進めるなら、4人月 ÷ 2人で2か月という計算です。実際の単価は会社や職種によって幅があるので、ここでは形だけ見てください。

見積書が1行で「システム開発一式　320万円」とだけ書かれていると、この分解ができません。工数と単価が分けて書かれているかどうかが、見積書の読みやすさを決めます。

人月単価が職種で変わる理由

見積書に複数の単価が並んでいることがあります。プロジェクトマネージャー、システムエンジニア、プログラマー、テスターといった職種ごとに、1人月あたりの単価が設定されているためです。

単価の差は、担う責任の範囲と、代わりがきくかどうかで生まれます。要件を整理して設計に落とし込む工程や、プロジェクト全体の進行を見る役割は、単価が高めに設定されます。決まった手順にそって進める作業は、そのぶん低くなります。

そのため、同じ工数でも職種の配分が違えば金額は変わります。上流に厚く人を置く見積もりは総額が上がりますが、要件のずれによる手戻りは減りやすくなります。逆に上流を薄くした見積もりは安く見えて、後から追加費用が発生する形になることがあります。どちらが良いかは案件によりますが、配分が見えないと比較のしようがありません。

職種ごとの単価がおおよそいくらなのか、規模ごとの総額がどれくらいになるのかは、システム開発の費用相場【2026年】｜規模別・種類別の目安と見積もりの見方にまとめています。金額の目安を知りたい場合はそちらをご覧ください。

単価に含まれているもの、含まれていないもの

人月単価は、その人の給与そのものではありません。会社が負担している社会保険料、開発用の機材やライセンス、オフィスの費用、管理部門の人件費、そして利益が乗っています。本人に支払われる給与に、これらの間接費と利益を乗せた額が単価になります。どこまでを間接費として乗せるかは会社によって違うため、単価の水準だけを並べても比べきれない部分があります。

一方で、単価に含まれていないものもあります。サーバーやクラウドの利用料、外部サービスの月額利用料、アプリストアの登録料、ドメインやSSL証明書の費用などは、工数とは別立てになっていることが多くなります。見積書の工数部分だけを見て予算を組むと、公開してから想定していなかった請求が出てくることがあります。別立ての項目があるかどうかは、最初に確認しておきたいところです。

受け取った見積もりを確かめる4つの手順

ここからが本題です。見積書を受け取ったあと、その見積もりが何を前提に組まれているか、抜けている工程はないか、体制とスケジュールが噛み合っているかを確かめる手順を4つに分けます。専門知識がなくても進められる順番にしてあります。

手順1　工数が工程ごとに分かれているか見る

まず、見積書が何行で書かれているかを見ます。「開発一式」の1行だけなら、妥当性を判断する材料がありません。

最低限、要件定義、設計、実装、テスト、リリース作業、プロジェクト管理くらいには分かれていてほしいところです。さらに実装が機能ごとに分かれていれば、「この機能は今回やめる」という判断ができるようになります。逆に1行にまとまっていると、予算が合わなかったときに、何を減らせば費用がどれだけ下がるのかを発注側が判断しにくく、交渉が総額の値引き交渉になりがちです。

分かれていない場合は、内訳を出してもらえるか聞いてみてください。出せない理由が「まだ要件が固まっていないから」であれば、それは正直な回答です。その場合は、要件を固める工程だけを先に切り出して契約する進め方もあります。

手順2　1人月を何時間として計算しているか聞く

前半で触れたとおり、1人月の前提時間は会社によって違います。これを聞いておかないと、2社の工数を並べても同じものさしになりません。

聞き方はそのままで構いません。「御社では1人月を何時間として計算されていますか」と確認します。各社に前提時間を確認し、それぞれの工数に、その会社が定める1人月あたりの時間を掛けて比較します。

この質問は、相手の見積もりの作り方を見る質問でもあります。見たいのは回答の速さではなく、どういう前提で、どう積算しているのかを説明できるかどうかです。

ひとつ注意があります。時間に換算すると、各社が想定している作業量の違いは確認できますが、同じ時間で同じ成果が得られるとは限りません。担当者の経験、既存部品をどこまで使うか、テストの範囲が違えば、同じ時間で仕上がる内容は変わります。工数が多い会社が非効率とも限りません。対象とする機能、品質の条件、担当者の役割を合わせて見てください。

手順3　テスト・管理・修正対応の工数が入っているか見る

比較するときに見落としやすいのが、実装以外の工程です。とくに次の項目は、入っていないと後から問題になりやすいところです。

• テストの工数。開発者自身の動作確認だけでなく、要件どおりに動くかを通して確認する工程が別に積まれているか
• プロジェクト管理の工数。進捗の管理、打ち合わせ、議事録、報告にかかる時間。比率の目安は体制や関係者の多さで変わるため、何割という数字を当てにするより、どの作業にどれだけの時間を見ているのかを聞くほうが確かです
• 不具合を直す工数。当初合意した仕様を満たしていない部分を直す時間が、どこまで金額に含まれるのか
• 仕様変更が起きたときの進め方。発注側が仕様や画面を変えたい場合に、見積もりと承認の手順が決まっているか。変更は起きるかどうかが読めないので、最初から工数を積むより、手順が決まっているかを見ます。不具合修正とは費用の扱いが変わる部分なので、分けて確認します

テストや管理の項目が見当たらなくても、ほかの工程に含めて計上されている場合があります。項目がないことだけで判断せず、どこに含まれているのか、追加費用になる条件は何かを確認してください。

手順4　工数・期間・人数の3つが噛み合っているか計算する

最後に、提示された工数とスケジュールを突き合わせます。工数を人数で割った数字が、提示されている期間と合っているかを見る作業です。

たとえば工数が合計12人月で、スケジュールが3か月と書かれていたとします。12人月 ÷ 3か月で、期間全体では平均4人分の稼働を見込んでいる計算になります。常に同じ4人を専任で置くという意味ではありません。要件定義の時期は2人、実装の時期は6人というように、工程ごとに人数や稼働率は変わります。

確認したいのは、どの時期に、どの役割の人が、どの程度関わる予定なのかです。そのうえで、山になる時期の人員を確保できる見込みがあるのかを聞きます。

逆に、工数が2人月なのに期間が6か月と書かれているケースもあります。平均すると3分の1程度の稼働ですが、中身は一様ではありません。複数の人が部分的に関わる形かもしれませんし、発注側の確認待ちの期間が見込まれているのかもしれません。悪いことではないので、どういう進め方を想定しているのかを聞いて、こちらが何をいつまでに返す必要があるのかを確かめます。

この割り算は単純換算なので、計算どおりに割り切れたから妥当、という意味ではありません。数字が噛み合わないときに質問の糸口にする、という使い方になります。

人月で見積もると合わなくなる場面

人月は分かりやすい単位ですが、万能ではありません。人月で考えると説明がつかなくなる場面があり、そこを知らないと交渉が噛み合わなくなります。

人数を倍にしても、期間は半分にならない

人月の計算式だけを見ると、6人月の作業は6人で1か月で終わるように見えます。ただし、実際に1か月で終えられるとは限りません。

人が増えると、その人に仕様を伝える時間、作業を分担するための調整、互いの成果物を突き合わせる確認が増えます。コミュニケーションの経路は人数が増えるほど急に増えていくため、増員によって、追加した人が進められる作業よりも、説明や調整にかかる負担が大きくなる場合があります。

また、作業には順番があります。設計が終わらないと実装に入れない部分は、人を増やしても前倒しできません。遅れている段階で人を追加すると、既存メンバーが引き継ぎに時間を取られて、かえって遅くなることもあります。

この点は、納期を縮めたいという相談に対して開発会社が難しいと説明する理由でもあります。その場合は、人を増やす以外の選択肢、つまり今回作る範囲を減らして段階的に出す方法を一緒に検討するほうが、品質や体制に無理のない調整になりやすいと考えています。

準委任契約の精算幅（下限と上限）

人月単価で月額の報酬を定める契約では、「1人月いくら」という金額に加えて、精算幅という取り決めが置かれることがあります。法律で決まった制度ではなく、当事者間の取り決めです。

精算幅は、月の稼働時間に下限と上限を設ける仕組みです。1日8時間、月20営業日の160時間を中心に、前後20時間の幅を取って140時間から180時間と設定するのが一般的な形です。この範囲に収まっていれば、実際の稼働が145時間でも175時間でも、金額は取り決めた月額のままになります。

範囲を外れたときの扱いは、契約によって分かれます。よく使われる方式は次の3つです。

発注する側として確認しておきたいのは、下限に届かなかったときに金額が下がるのかどうかです。月額固定の場合でも、こちらの都合で作業を止めたときの支払いは契約条件によって変わります。作業停止や中途解約、待機の扱いについて条項があるかどうかを合わせて見ておきます。月の途中から参画してもらう場合に、精算幅が日数に応じて按分されるのかも確認しておく項目です。

請負と準委任で、人月の意味が変わる

同じ「3人月」でも、契約の形が違えば約束している内容が変わります。

請負契約は、決めた成果物を完成させることを約束する契約です。この場合の人月は、完成までにかかると見込んだ作業量の見積もりになります。契約金額が固定されていて、合意した開発範囲が変わらなければ、実際にそれ以上かかっても金額は変わらないのが原則です。開発会社がその見込み違いのリスクを負う形になるため、見積もりには余裕が乗りやすくなります。

準委任契約は、決めた業務を行うことを約束する契約で、仕事の完成義務を当然に負うものではありません。要件が動く前提の開発や、長く運用改善を続ける体制では、こちらの形が選ばれることが多くなります。

準委任には2つの型があります。業務の履行そのものに対して報酬を払う履行割合型と、合意した成果に対して報酬を払う成果報酬型（成果完成型とも呼ばれます。民法648条の2）です。

人月単価で月額の報酬を定める契約は、履行割合型で組まれることが多く、その人月は想定する稼働量や体制を示します。ただし履行割合型の報酬の決め方は月額に限らず、定額や時間を基準にする形もあります。成果報酬型では、合意した成果に対して報酬が発生します。成果の引き渡しが支払いの条件になるのは、その成果が引き渡しを要する場合です。

どちらの型でも、受任者は善管注意義務を負います。完成を約束しないことと、作業の質が問われないことは別の話です。

見積書に人月とだけ書かれていて契約形態が書かれていない場合は、請負なのか準委任なのか、準委任ならどちらの型なのかまで確認しておきます。同じ金額でも、何を約束している契約かで中身が変わります。なお、ここで触れたのは一般的な整理です。実際の扱いは契約書の条項で決まるので、個別の案件では契約書の文言と突き合わせてください。

同じ要件なのに見積もりが数倍違うとき、何が起きているか

複数社に同じ資料を渡したのに、戻ってきた金額が大きく開いている。発注側が判断に困りやすい場面です。見積もりの作り方を知っていると、この開きの原因をいくつかに分けて考えられます。

ひとつは、要件の読み取り方の違いです。資料に書かれていない部分を、各社がそれぞれの経験で補って見積もっています。例えば、「ユーザー管理機能」という一行を、ログインとパスワード再発行だけと読む会社と、権限設定や組織階層まで含めて読む会社では、工数が何倍も変わります。これは相手が不誠実なのではなく、資料から読み取れる範囲が同じでないために起きます。

もうひとつは、含まれている工程の範囲です。要件定義から入る見積もりと、仕様が確定している前提の実装だけの見積もりは、そもそも対象が違います。テスト、データ移行、公開後の初期サポートが入っているかどうかでも開きます。

そして、体制の違いがあります。国内の人員だけで組む体制、国内外の開発拠点を組み合わせる体制、必要な人数を継続的に確保する体制では、人月単価の水準が変わります。Enlytでは、国内のプロジェクトマネージャー・ディレクターと国内外の開発チームを組み合わせています。プロジェクトマネージャー・ディレクターは、プロジェクトの曖昧さを減らし、期待値を揃え、事後発生を防ぎながら、プロジェクトを前に進める役割をしています。AIも活用して作業の効率化を図り、品質を保ちながら開発費用を抑えることを目指しています。

ここまでは工数と単価の計算を中心に見てきましたが、見積書に並ぶのは手を動かす人の工数だけではありません。要件を整理する役割と、進行を管理する役割も、プロジェクトの進み方に効いてきます。

要件がまとまらないまま実装に入ると、作り直した分の工数が積み上がります。関係者の認識が揃っていなければ、確認のたびに手戻りが出ます。上流を整理する役割と進行を管理する役割は、こうした増え方を抑えるために置かれるものです。Enlytでは、プロジェクトマネージャーとディレクターが、言葉になっていない要望や見えにくい業務の流れを整理し、関係者の認識が食い違わないように進め方を調整しています。

見積もりを比べるときは、実装の人日や人月だけでなく、ディレクションとマネジメントがどう置かれているかも合わせて見てください。誰がその役割を担い、どれだけの時間を見ているのか。ここが見積書に出ていないと、開発が動き出してから発注側がその役割を引き受けることになる場合があります。

工数を減らす方向で考えられること

予算が合わないとき、単価の値引きを求めるより、工数そのものを減らすほうが無理が出にくくなります。作業量を変えずに値下げだけを求めると、品質や体制に無理が生じることがあります。

今回作る範囲を分ける

すべての機能を最初のリリースに入れる必要があるかを見直します。業務が回る最小の形で出して、使いながら足していく進め方です。最終的な優先順位は、開発会社の説明を踏まえたうえで発注側が決めます。ここが整理されていると、見積もりの精度も上がります。

すでにあるものを変換して使う

ゼロから作り直すのではなく、手元にある資産を活かせないかを検討します。Enlytが担当したBtoBマッチングサービスの案件では、他社が制作済みだったデザインのHTMLを抽出して別の形式に変換することで、デザイン工程を作り直さずに済ませています。途中まで進んだ状態から引き継ぐ案件でも、使えるものを見極めれば工数を抑えられる場合があります。詳しくはBtoBマッチングサービスの開発事例をご覧ください。

対応する環境を絞る

対応する端末やブラウザの種類は、実装とテストの両方に効いてきます。対応先が増えれば、その分だけ作る対象と確認する対象が増えるためです。

どこまで広げるかは、利用者が誰かによって決まります。Enlytが構築した動画配信サービスでは、Web、iOS、Android、Android TV、Fire TVに対応しています。多様な環境に向けて配信する場合の実例として、動画配信プラットフォームの開発事例をご覧ください。社内で使う業務システムのように利用環境が限られている場合は、対応先を実際に使う範囲に絞ることで、工数を抑えられることがあります。

見積もりを依頼する前に、社内で決めておくこと

見積もりの精度は、渡す情報の精度も重要です。次のような項目が整理されていると、各社から比較できる見積もりが返ってきやすくなります。

• 解決したい業務課題　→「効率化したい」ではなく、どの作業に誰が何時間かけているかまで書けると、開発会社が業務の課題を把握し、必要な機能を検討しやすくなります
• 使う人と人数　→社内だけか、取引先や一般の利用者も使うのか。人数の桁によって必要な構成が変わります
• 既存システムとの連携範囲　→連携する相手、やりとりするデータ、連携の頻度。ここは工数が大きく動く項目です
• 優先順位　→今回外せない機能と、あとから足してよい機能の線引き
• 予算の上限と、公開したい時期　→伝えると足元を見られると考える方もいますが、伝えないと範囲の調整ができず、実現できない見積もりが返ってくることがあります
• 社内の体制　→誰が窓口になり、誰が仕様を決裁するか

整理が難しい段階でも、開発会社と相談しながら、要件や予算、スケジュールを具体化できます。曖昧なまま金額だけを出すと、後から双方が困るためです。

外注の進め方そのものについては、Webシステム開発を外注する前に知っておきたい5つの手順と落とし穴でも触れています。依頼先の選び方の基準を知りたい場合は、システム開発会社の選び方をご覧ください。

よくある質問

1人月は何時間ですか

1日8時間、月20営業日として160時間と置くのが一般的です。ただしこれは慣習であり、会社によって150時間や168時間としている場合もあります。見積もりを比べるときは、各社の前提時間を確認してから時間ベースにそろえてください。なお、記事中で触れた精算幅の上限に出てくる180時間は、1人月の前提時間とは別の取り決めです。

0.5人月はどれくらいの作業量ですか

1人月を160時間とした場合、0.5人月は80時間、人日に直すと10人日です。1人が10営業日かけて進める作業量にあたります。

人日と人月はどちらで見積もってもらうべきですか

数日から数週間で終わる改修なら人日、数か月にわたる開発なら人月のほうが扱いやすくなります。重要なのは単位そのものより、工程ごとに分かれているかどうかです。単位が混在していても、工程別に書かれていれば読み解けます。

人月単価が安い会社を選べば費用は下がりますか

人月単価が安くても、必要な工数が多ければ、総額が安くなるとは限りません。要件の整理が甘いまま進むと手戻りが発生し、結果として工数が膨らむこともあります。単価と工数の両方を見て、総額と、追加費用が発生する条件まで合わせて比べるのが現実的です。

見積もりは何社から取るのがよいですか

3社程度が扱いやすい数です。それ以上になると、各社に同じ説明をする手間と、返ってきた見積もりを並べて比べる手間が大きくなります。社数を増やすより、同じ資料を渡して前提をそろえるほうが比較の精度は上がります。

見積もりの工数は、あとから変わりますか

要件が変われば変わります。契約時に、どこまでが当初の範囲で、何が起きたら追加になるのかを文書で決めておくと、途中の判断がしやすくなります。変更そのものを禁じるより、変更が起きたときの手順を決めておく考え方です。

Enlytの見積もりの出し方

Enlytでは、見積もりを出す前の段階に時間をかけています。受注前の無料コンサルティングとして業務の流れを伺い、必要な要件、画面構成、スケジュールを一緒に可視化します。ここで何を作るかが見えてから、工数を積み上げる順番です。

体制は、国内のプロジェクトマネージャーが窓口と設計を担い、国内外の開発チームと組む形です。AIも活用して作業の効率化を図り、品質を保ちながら開発費用を抑えることを目指しています。「きれいに作る」ことより「使われる形になっているか」を基準にしており、どの機能に開発時間をかけるかを判断する際にも、この考え方を使います。

これまでに手がけた開発の内容と進め方は開発実績の一覧に、対応範囲と進め方はサービス紹介ページにまとめています。進め方や費用の考え方を先に知りたい場合は、お役立ち資料もご利用ください。

まとめ

見積書の人月は、開発に必要な作業量を示す単位です。1人月を何時間として計算しているかは会社によって違うので、まずは前提時間を確認するところから始めてみてください。ただし時間をそろえても、同じ時間で同じ成果が得られるとは限りません。対象とする機能や品質の条件も合わせて見る必要があります。

受け取った見積もりを確かめる手順は4つです。工程ごとに分かれているかを見る、1人月の前提時間を聞く、テストと管理と修正の工数が入っているかを見る、工数と期間と人数が噛み合っているかを計算する。この4つを通すと、総額だけを見ていたときには見えなかった前提の違いや抜けが浮かび上がってきます。そこから先は、開発会社に説明を求めながら判断していく部分です。

そして、人月は作業量の単位であって、人を増やせば期間が縮む保証にはなりません。予算や納期が合わないときは、単価の値引きより、作る範囲や対応する環境を見直すほうが、品質や体制に無理をかけずに進めやすくなります。

Webシステム開発そのものの進め方や種類についてはWebシステム開発とは？で、規模別や種類別の金額の目安についてはシステム開発の費用相場【2026年】で扱っています。

関連記事

• Webシステム開発とは？種類・流れ・依頼前に決めておきたいこと
• システム開発の費用相場【2026年】｜規模別・種類別の目安と見積もりの見方
• システム開発会社の選び方
• システム保守費用の相場
• オフショア開発費用の完全ガイド2026
• 仕様書とは？書き方と落とし穴
• Webシステム開発を外注する前に知っておきたい5つの手順と落とし穴

岡山 拳大

Enlytにて、UI/UXデザイン、コーディング、開発ディレクションを担当。 ユーザー視点を重視したUI設計と、開発実装を見据えた現実的なデザイン提案を得意とし、プロジェクト全体の品質・一貫性向上に貢献。 クライアント・エンジニア双方と密に連携しながら、スムーズな開発進行を支えている。

View More