人月・人月単価とは？システム開発費用の仕組みをわかりやすく解説

システム開発の見積もりを見ると「人月」「人月単価」という言葉がよく出てきます。ここを理解すると、なぜ会社によって金額が数倍も違うのかが腑に落ちます。逆に言えば、人月の仕組みを知らないまま見積書を受け取ると、「この金額が高いのか安いのか」「削れる余地はあるのか」を判断できず、言い値を飲むしかなくなります。この記事では、人月・人月単価の意味と相場、見積もりが実際にどう作られるか、そこに潜む落とし穴と発注側の検算のしかた、そして人月の読みに振り回されない一律料金という選択肢までを、はじめての方にもわかるように順を追って解説します。

人月・人月単価とは

**人月（にんげつ）**とは「1人のエンジニアが1ヶ月働いた作業量」を表す単位で、工数（作業の総量）を「人数 × 期間（月）」で数える考え方です。時間や金額そのものではなく、あくまで「どれだけの人手がかかるか」を表す“ものさし”だと考えると分かりやすいです。

• 例：「3人月」＝1人で3ヶ月、または3人で1ヶ月かかる作業量
• 人月単価＝1人月あたりの費用（1人月は営業日で約20日・160時間が目安）
• 「人日（にんにち）」はその1/20の単位。8時間＝1人日、約20人日＝1人月と換算する

システム開発の見積もりは、多くの場合「必要な人月 × 人月単価」で計算されます。たとえば「5人月 × 100万円/人月 ＝ 500万円」といった具合です。見積書に「人日単価」で細かく書かれていても、時間あたりの人件費を積み上げているという考え方はまったく同じです。

ここで大事なのは、人月は「作業量の見込み」であって「確定した事実」ではないという点です。まだ作っていないものの手間を人が予想して数えているので、読みが甘ければ後で足りなくなり、多めに見れば発注側が余計に払うことになります。この“予想の幅”こそが、後述する会社ごとの金額差や追加費用の正体です。

人月計算の仕組み（見積もりの作られ方）

見積もりは、たいてい次のような順で組み立てられます。

1. 機能を洗い出す：ログイン、一覧画面、検索、通知…と作るものを列挙する
2. 各機能に工数を割り振る：「この画面は3人日」「この決済連携は10人日」と見積もる
3. 共通工程を上乗せする：要件定義・設計・テスト・プロジェクト管理の時間を足す
4. 合計を人月に換算する：総人日 ÷ 20 ＝ 人月
5. 単価を掛ける：人月 × 人月単価 ＝ 見積総額
6. バッファ（予備）を積む：不確実性に備えて1〜2割上乗せすることが多い

同じ機能一覧でも、②の工数見積もりと⑤の単価、⑥のバッファの積み方が会社ごとに違うため、最終金額は大きくばらつきます。「一式 ○○万円」としか書かれていない見積書は、この積み上げ過程が見えないため、発注側が妥当性を検算できません。

なぜ人月で見積もるのか

システム開発は一件ごとに違うものを人の手で作る受注生産で、原価のほとんどが人件費です。工場の大量生産のように「1個あたりいくら」と単価を決められないため、「何人が何ヶ月働くか」を数えるのが、もっとも計算しやすく、受発注の双方が納得しやすい見積もり方法になります。金額の根拠を「人件費の積み上げ」として説明できるので、受注側にとっては提示しやすいのです。

このとき発注側が見落としがちなのがプログラミング以外の工程です。開発費の内訳は目安として、次のような配分になります。

工程	全体に占める割合の目安	主な作業
要件定義・設計	30〜40%	やりたいことの整理、画面・データ設計
実装（コーディング）	30〜40%	実際にプログラムを書く
テスト・修正	20〜30%	不具合の洗い出しと手直し
管理・レビュー	10〜15%	進行管理、品質チェック、打ち合わせ

実際にコードを書く時間は全体の3〜4割にすぎません。「実装だけ頼めば安いはず」と思っても総額が大きく下がらないのは、この設計・テスト・管理の工数が、どんな案件でも必ずかかるためです。むしろ要件が曖昧なまま実装に入ると、後工程の手戻りで工数（＝人月＝費用）が膨らみます。上流の要件定義をていねいにやるほうが、結果的に総人月を抑えられることも多いのです。

人月単価の相場

人月単価は、担当エンジニアのスキルレベルと依頼する会社の規模の両方で変わります。まずスキルレベル別の目安です。

エンジニアのレベル	人月単価の目安	想定される担当範囲
初級（経験1〜3年）	40万〜60万円	指示に沿った実装、簡単な修正
中級（経験3〜7年）	60万〜100万円	設計から実装まで一人で回せる
上級・スペシャリスト	100万〜160万円	全体設計、難所の判断、若手の指導

単価はレベルが上がるほど高くなりますが、後述するように上級者ほど少ない人月で終わらせるため、単価が高い＝総額が高い、とは限らない点に注意してください。

次に、同じレベルの人でも「どこに頼むか」で単価が動きます。会社規模・業態別の目安です。

依頼先	人月単価の目安	特徴
大手・元請けSIer	100万〜200万円	管理費・営業費で高め。下請けへ再委託することも
中小・独立系開発会社	60万〜120万円	中間コストが少なく中位。実力の幅が大きい
フリーランス	50万〜100万円	安いが体制・リスク分散は弱く、離脱時の穴が大きい
オフショア（海外委託）	30万〜70万円	単価は安いが仕様伝達・品質管理・時差対応に手間

大手が高いのは、担当エンジニア本人の給料が高いからというより、営業・管理・間接部門のコストや、下請けに流す際のマージンが単価に乗るためです。逆にオフショアやフリーランスは中間コストが薄い分だけ単価が下がりますが、その代わりコミュニケーションや品質管理の手間を発注側が負担することになります。「安い単価」には必ずどこかにトレードオフがある、と考えておくのが安全です。

同じ機能でも、どのレベルが何人月かかると見積もるかと単価がいくらかの掛け算で総額が決まるため、会社によって数倍の差が出ます。単価だけ安くても人月が多ければ高くなり、逆に単価が高くても人月が少なければ安くつくこともあります。委託先ごとの違いはオフショア開発の実態やフリーランスと開発会社の比較もご覧ください。

人月見積もりの落とし穴

人月見積もりは計算しやすい反面、時間を売る商売であるがゆえに、発注側に不利になりやすい構造的な弱点があります。よく「人月商売」が批判されるのは、次のような点が理由です。

• 金額がブレる：「何人月か」の読みが主観的で、同じ要件でも会社によって見積もりが2〜3倍違うことも珍しくない。根拠を確かめないと高いのか安いのか判断できない。
• 成果でなく時間に課金される：早く終わらせても得をしにくく、むしろ請求が減る。発注側の「早く安く良いものを」と、受注側の「工数を確保したい」という利害が正面からぶつかる。
• 工数の水増しが見えにくい：「安全のためバッファを積む」「念のため人を厚めに」といった名目で人月が膨らんでも、専門外の発注側には妥当か判断しづらい。
• 不透明：「一式」でまとめられると、どの作業に何人月かかっているのかが見えない。中身が見えないから交渉もできない。
• 追加になりやすい：仕様が増えたり読みが外れたりすると追加費用が発生し、当初見積もりが実質「入口価格」になることも。安い見積もりで受注し、後から積み増すやり方も存在する。

これらは個々の会社が悪いというより、「時間に対してお金を払う」という料金モデルそのものが生む構造的な問題です。だからこそ発注側は、次章の検算で自衛する必要があります。

優秀な人ほど短工数という逆説

人月商売には根本的な矛盾があります。腕のいいエンジニアは同じ機能をより短い工数で、より高い品質で作れるのに、人月×単価だと「早く終わる＝請求が減る」ことになってしまいます。極端に言えば、1週間で終わる仕事を優秀な人が担当するほど、その会社の売上は下がるのです。

これはおかしな話です。本来なら発注側にとっては「短期間・高品質で仕上がる」ほど価値が高いはずなのに、料金は逆に安くなる。結果として、時間に課金する仕組みは「短く終わらせるインセンティブ」を受注側から奪ってしまいます。「時間をかけた見積もり」と「価値の高い成果物」は必ずしも一致しない——むしろ相反しうる、という点を押さえておきましょう。この矛盾を避けたいなら、時間ではなく“成果物”に対して料金を払う仕組みのほうが、発注側の利益と一致します。

発注側の検算チェックリスト

人月見積もりを受け取ったら、鵜呑みにせず次の点を確認しましょう。数字の根拠をきちんと説明できる会社かどうかも、そのまま信頼性の判断材料になります。

• 総工数（人月）の内訳を出してもらう：機能ごとに何人月か。「一式」でまとめられていたら分解を依頼する。
• 単価と人数の前提を確認する：何レベルが何人月入る想定か。上級単価で見積もりながら実作業は初級が担当、というズレを防ぐ。
• 設計・テスト・管理の工数が入っているか：実装だけの数字だと、後から必ず膨らむ。
• 他社見積もりと比べる：2〜3社取れば人月の妥当性が見える。極端に少ない人月はむしろ「後で追加」の前触れのこともある。
• 追加費用の発生条件を書面で確認する：何をもって「追加」になるのか、上限はあるのかを契約前に明文化しておく。

「何人月が妥当か」をざっくり検算する

内訳が出てきたら、規模感から逆算して“肌感”を持っておくと交渉しやすくなります。あくまで超概算ですが、次のような目安で「多すぎ／少なすぎ」を疑えます。

システムの規模イメージ	妥当な総工数の目安
画面数点の小さな業務ツール	2〜5人月
管理機能つきの中規模Webシステム	6〜15人月
外部連携・権限管理を含む本格システム	15〜40人月以上

たとえば「画面が10もない社内ツールに30人月」なら明らかに厚すぎ、逆に「決済・在庫連携つきのECを3人月」なら確実に後から膨らみます。金額そのものより、規模と人月のバランスを見るのがコツです。見積もり全体の読み方は見積もりの見方の記事で、費用の相場観は費用相場の記事で詳しく解説しています。

ミニ事例：同じ要件、3社で総額が2.4倍

「予約と会員管理ができる小さなWeb予約システム」を例に、一般化した架空のケースで見てみます。要件はまったく同じでも、見積もりはこう分かれます。

• A社（大手）：15人月 × 130万円 ＝ 約1,950万円。管理体制は厚いが、再委託分のマージンも乗る。
• B社（中小）：10人月 × 90万円 ＝ 約900万円。標準的な体制で中位の金額。
• C社（フリー中心）：8人月 × 100万円 ＝ 約800万円。単価は高めだが人月が少なく総額は下がる。

同じものを作るのに、総額はおよそ800万〜1,950万円と2.4倍ひらきます。差の正体は品質そのものよりも、**「何人月と読むか」「単価をいくらに置くか」**という前提の違いです。だからこそ、金額だけを並べて「一番安い会社」を選ぶのではなく、人月の内訳と前提をそろえて比べることが欠かせません。会社選びの視点は開発会社の選び方にまとめています。

人月積み上げと一律料金、どちらが得か

「人月積み上げ」と「一律（固定）料金」は、工数がブレたときのリスクを誰が持つかが正反対です。

項目	人月積み上げ	一律（固定）料金
総額の確定	進めながら確定	着手前に確定
工数が増えたとき	発注側が追加負担	受注側が吸収
人月の読み違いリスク	発注側が負う	受注側が負う
予算管理のしやすさ	読みにくい	最初から固定で立てやすい
交渉・検算の手間	内訳を毎回精査する必要	総額が決まっており不要
向くケース	仕様が流動的な大規模	予算を先に固めたい小〜中規模

どちらが得かは案件の性質で変わります。仕様が固まりきらない大規模開発で、走りながら要件を足していく前提なら、人月積み上げのほうが柔軟です。一方、作りたいものがある程度見えていて、**「予算をこれ以上出したくない」「総額が読めないのが不安」「追加費用の交渉を毎回したくない」**という小〜中規模の発注側にとっては、着手前に金額が固まる一律料金のほうが、精神的にも会計的にも圧倒的に楽です。

見落とされがちですが、一律料金は**「人月の読み違いリスクを受注側が引き受ける」**契約でもあります。工数が想定より膨らんでも追加請求されないということは、そのぶんの不確実性を受注側が飲み込んでいるということ。発注側は「早く終わっても損しない、長引いても払いすぎない」という、時間課金とは真逆の安心を得られます。

人月に左右されない「一律料金」という選択肢

D-oneAppは、人月×単価で積み上げる見積もりをやめ、総額を一律100万円（大規模なプロプランは一律200万円）に固定しました。「何人月かかるか」で金額が変わらないため、次のような、人月商売にありがちな不安がそもそも発生しません。

• 着手前に総額が確定：見積もりの人月をめぐる駆け引きが不要。予算をそのまま立てられる。
• 追加費用の不安がない：工数が想定より膨らんでも、上振れリスクは発注側でなく受注側が負う。
• 単価と人月の内訳を検算しなくていい：「上級単価で初級が担当」といったズレを疑う必要がない。
• 成果物の権利は顧客に渡す：完成したソースコードは顧客のもの。後々のベンダーロックインを避けられる。

これは「時間ではなく成果物に対して料金を払う」考え方であり、前述した“優秀な人ほど短工数で損をする”という人月商売の矛盾とも無縁です。早く良いものを作ることが、そのまま双方の利益になります。

料金の考え方は100万円でシステム開発の記事、「本当に100万円でできるのか」という疑問は100万円でできることの記事、費用の全体像は費用相場の記事にまとめています。

まとめ

人月とは「1人が1ヶ月働く作業量」で、システム開発費用は「人月×単価」で計算されるのが一般的です。だからこそ人月の読みと単価の掛け算で会社ごとに金額が数倍ブレ、時間に課金する仕組みゆえ成果物の価値と必ずしも一致しません。見積もりを受け取ったら内訳と前提を検算し、複数社で比べるのが安全です。人月の読みに振り回されたくない方は、総額が最初から決まる無料相談で「100万円でどこまでできるか」を整理するのが近道です。