システム開発の費用は、その多くが「人が作業する時間」に対する費用です。サーバー代やライセンス代も含まれますが、中小企業向けの業務システムやWebシステムでは、人件費が見積額の大きな部分を占めることが一般的です。だからこそ、見積書に出てくる「人月単価」と「工数（人月）」をどう読むかが、金額の妥当性を判断するうえで重要になります。
本記事は連載第2回として、人月単価と工数の読み方を整理します。単価が高いか安いかという一点だけで判断するのではなく、役割との整合、工数の根拠、管理費の比率を合わせて見る考え方を紹介します。
まず結論
- 人月単価は、安いか高いかだけでは判断できません。単価、工数、担当役割の3点をセットで見る必要があります。
- 工数の根拠は、画面数、機能数、帳票数、連携本数、データ移行量など、数えられる単位で確認すると比較しやすくなります。
- PM費は「高い/安い」ではなく、進捗管理、課題管理、品質管理、会議運営のどこまでを担う費用かを確認します。
| 見る項目 | 判断のしかた | 発注前の確認ポイント |
|---|---|---|
| 単価 | 役割と難易度に合うか | PM/SE/PGの担当範囲を確認 |
| 工数 | 算出根拠があるか | 画面数・機能数・連携数で説明できるか |
| PM費 | 管理内容が明確か | 全体比率より作業内容を見る |
OUTCOME BLUEPRINT
AI/DX投資の前に、成果KPIと発注条件を整理しませんか？
補助金、SaaS選定、開発見積、PoCの前に、業務要件・費用レンジ・RFP・合格条件を成果起点で整理します。
この連載での位置づけ
- 前に読む記事：連載第1回：一式見積
- 次に読む記事：連載第3回：要件定義費
- 比較表で整理する：連載第11回：比較表
- 発注前の質問に落とし込む：連載第12回：開発会社への20問
人月・人月単価とは何か
「人月（にんげつ）」は、1人が1か月作業する量を1としてまとめた工数の単位です。「人月単価」は、その1人月あたりの費用を指します。
たとえば「開発 5人月 × 単価70万円 = 350万円」という見積は、「1か月分の作業を5人分積み上げ、1人月あたり70万円で計算した」という意味になります。総額だけを見ると350万円ですが、その内側には「工数（5人月）」と「単価（70万円）」という2つの要素があります。妥当性を読むには、この2つを分けて考えることが出発点です。
人月単価は、担当者の役割やスキルによって幅があります。一般的には、プロジェクトマネージャー（PM）やシステムエンジニア（SE）の単価は、プログラマー（PG）よりも高く設定されます。発注地域や開発会社の規模、技術領域によっても変わるため、相場は幅で捉えるのが現実的です。
単価が役割と整合しているか
人月単価を読むときの第一の観点は、「単価が役割の難易度・責任と整合しているか」です。一般的には、上流工程やマネジメントを担う役割ほど単価が高くなります。
| 役割 | 主な担当 | 単価の傾向 |
|---|---|---|
| プロジェクトマネージャー（PM） | 全体管理、進捗・品質・課題の統括 | 高め |
| システムエンジニア（SE） | 要件定義、設計、テスト設計 | 中〜高 |
| プログラマー（PG） | 実装、単体テスト | 中 |
ここで注意したいのは、単価の絶対額そのものよりも、役割の難易度と単価の並びが整合しているかです。たとえば実装担当の単価が管理担当より高くなっているような場合は、役割の定義や体制について説明を求める材料になります。なお、単価の水準は技術領域や会社の体制によって妥当な幅があるため、相場と異なるからといって直ちに不適切とは限りません。前提を確認することが目的です。
工数の根拠が示されているか
第二の観点は、工数（人月）の根拠です。「設計 3人月」とだけ書かれていても、その3人月がどこから出てきたのかが分からなければ、多いとも少ないとも判断できません。
工数の根拠は、たとえば次のような単位で説明できると読みやすくなります。
- 画面数（◯画面 × 1画面あたりの想定工数）
- 機能数・API数
- 帳票・レポートの種類数
- データ移行する対象テーブル数・データ量
- 外部システムとの連携本数
根拠が示されていれば、後から仕様が増えたときに「どこが増えたから工数が増えるのか」を双方で確認できます。逆に、根拠のない丸めた工数だけが並んでいる場合は、仕様変更時の追加工数の議論が難しくなりがちです。工数の妥当性をさらに詳しく見たい場合は、システム開発 見積書の内訳ガイドも参照してください。
PM費（プロジェクト管理費）の比率
第三の観点は、プロジェクト管理費（PM費）の比率です。PM費は、進捗管理・課題管理・会議運営・報告など、開発を計画通りに進めるための費用です。
GXOが見積レビューで確認する際は、PM費が全体の1〜2割程度に収まるかを一つの目安にします。比率が極端に小さい場合は管理が手薄になっていないか、極端に大きい場合は管理体制の内容を確認する材料になります。比率そのものに唯一の正解があるわけではなく、プロジェクトの規模・関係者数・難易度によって適切な水準は変わります。重要なのは「PM費が何の作業に対応しているか」を説明してもらえることです。
人月単価だけでは総額は決まらない
人月単価が安くても、必要な工数が多ければ総額は大きくなります。逆に単価が高くても、少ない工数で仕上がれば総額は抑えられます。単価と工数はセットで見るべきもので、単価の安さだけを基準にすると、結果的に総額や品質で見合わないことがあります。見積を比べるときは「単価 × 工数 = 総額」の3点を一緒に確認し、単価の数字だけに引きずられないことが大切です。
単価の背景には、その会社がどのような体制を組むか、上流工程にどこまで関与するか、間接費（管理費・インフラ費・教育費など）をどう配分しているか、といった要素が含まれます。単価が高い見積でも、要件定義から設計まで上流で関与するSEを豊富に配置し、品質管理を手厚くしているという前提であれば、総額と成果のバランスが取れていることがあります。単価の数字だけでなく、それが何を含んだ単価なのかを確認することが、比較の精度を上げます。
複数の見積を比べるときの落とし穴
相見積もりで複数社の見積を比べるとき、単価の数字だけを並べて比較すると、判断を誤りやすくなります。異なる会社の見積は、含まれる工程の範囲、前提としているシステム規模、体制、品質水準がそれぞれ異なることが多いためです。
たとえば「A社は単価が低いが、要件定義は含まれていない」「B社は単価が高いが、設計書から導入支援まで含まれている」という場合、単価だけで比べると判断を誤ります。比較の基準をそろえるには、まず各社の見積が「同じ範囲・同じ前提を対象にしているか」を確認してから、総額と単価の内訳を見るのが順序として正しいといえます。相見積もりの比較方法についてはシステム開発の相見積もりの比較方法も参考になります。
工数の単位を発注側でも持っておく
工数の妥当性を判断するには、発注側もおおよその目安を持っておくと対話がしやすくなります。たとえば「画面が何枚あるか」「帳票が何種類あるか」「外部連携が何本あるか」を自社で数えておくと、開発会社が示す工数が、その規模感と合っているかを確認できます。正確な数字でなくてかまいません。規模のオーダー（数十なのか数百なのか）が共有できるだけでも、工数の議論は具体的になります。
単価の幅は前提で変わる
人月単価には幅があり、担当者の経験、技術領域、開発会社の規模、契約形態によって変わります。相場より高いからといって直ちに割高とは限らず、難易度の高い領域や手厚い体制を前提にしていることもあります。逆に相場より安い場合は、どの前提でその単価が成り立っているのかを確認すると、後の認識のずれを防げます。重要なのは、単価の数字そのものより、その単価が何を含んだ前提なのかを共有できることです。
発注前チェックリスト（人月単価と工数）
- 工数（人月）と単価が、項目ごとに分かれて記載されているか
- 役割（PM・SE・PG等）ごとに単価が示されているか
- 単価の並びが、役割の難易度・責任と整合しているか
- 工数の根拠（画面数・機能数・連携数など）が説明されているか
- PM費が全体に占める比率と、その作業内容が分かるか
- 仕様が増えた場合に、工数がどう増えるかの考え方が共有されているか
- 体制図と、各メンバーの役割・想定稼働が示されているか
- 複数社を比べる場合、各社の見積が同じ範囲・同じ前提を対象にしているか確認したか
- 工数の前提となっている機能・画面・連携の数が、自社の想定規模と整合しているか
開発会社に確認する質問
- 「この工数は、何を基準に算出していますか（画面数・機能数など）」
- 「役割ごとの人月単価と、その役割の担当範囲を教えてください」
- 「PM費にはどのような作業が含まれていますか」
- 「仕様が増減した場合、工数はどのように見直されますか」
- 「実際にアサインされる方の役割と、想定稼働を教えてください」
- 「この工数の前提としている画面数・機能数・連携本数を教えてください」
- 「上流工程（要件定義・設計）の単価が、実装担当と異なる場合、それぞれの役割と担当範囲を教えてください」
工数の根拠と体制を具体的に説明できる相手は、後の仕様変更の議論でも前提を共有しやすい傾向があります。
相談前に整理しておくとよい情報
- 実現したい機能の一覧（画面・帳票・連携のイメージ）
- 想定する利用者数・データ量の規模感
- 連携が必要な既存システムやサービス
- 予算の上限・幅と、判断の決裁ルート
- すでに受け取っている見積の単価・工数の内訳
これらを整理しておくと、工数の根拠を確認する際に「自社の規模ではどの程度が妥当か」を相手と一緒に検討しやすくなります。
GXOの発注前レビューで見る実務メモ
GXOが見積書の相談を受けるときは、最初から「高い」「安い」を判定せず、見積の前提を分解します。まず初期費用、月額費用、追加費用、発注側作業、リスク項目の5区分に分けます。そのうえで、3社比較、5年TCO、社内稟議、契約条件の順に確認します。これにより、金額の差が価格差なのか、範囲差なのか、リスクの見込み方の差なのかを説明しやすくなります。
発注側で用意しておくとよいのは、完璧な要件定義書ではありません。現行業務の流れ、利用者数、画面・帳票・連携の数、希望時期、予算の幅、社内決裁者、止められない業務、個人情報や機密情報の有無です。これらが曖昧なまま見積を取ると、開発会社ごとに前提が変わり、相見積もりの比較が難しくなります。
| 確認領域 | 発注側が用意する情報 | 見積で確認すること |
|---|---|---|
| 業務範囲 | 対象部署、利用者数、現行フロー | どこまでが開発対象か |
| 機能規模 | 画面数、帳票数、API本数 | 工数の根拠が説明できるか |
| データ | 移行対象、件数、クレンジング要否 | 移行費・移行リハーサルの有無 |
| 運用 | 利用時間、障害時の影響、社内担当 | 保守範囲、SLA、月額費用 |
| 契約 | 請負/準委任、検収、知財、再委託 | 責任分界と追加費用の条件 |
| 稟議 | 予算上限、比較対象、判断基準 | 3社比較や5年TCOで説明できるか |
この整理を先に行うと、AI開発、セキュリティ要件、補助金活用を含む案件でも、見積の前提を同じ粒度にそろえやすくなります。特に補助金を使う場合は、対象経費と対象外経費、発注前着手の可否、証憑の残し方を見積段階で確認しておく必要があります。
参考にすべき一次情報・確認観点
見積書を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してください。特に契約形態、責任分界、DX投資の目的、セキュリティ要件は、見積金額より前にそろえるべき前提です。
- IPA「情報システム・モデル取引・契約書」：請負、準委任、成果物、検収、責任分界を確認する際の参考になります。
- 経済産業省「DX推進指標」：経営課題、ITシステム、組織体制を分けて、DX投資の目的を確認する際の参考になります。
- 自社の見積比較では、3社比較、5年TCO、月額5万円・10万円・15万円、画面20件、帳票10件、API3本、移行データ1000件、受入テスト5日、操作研修2回、障害受付24時間、初期予算500万円・1000万円など、仮でも数字を置いて前提をそろえます。
- AI開発、セキュリティ要件、補助金活用を含む案件では、機能要件だけでなく、ログ保管、個人情報、権限管理、証跡、補助対象経費の切り分けも見積条件に入れてください。
よくある質問
Q. 人月単価は安いほうがよいのですか。
A. 単価だけでは判断できません。単価が安くても、必要な工数が多ければ総額は大きくなります。「単価 × 工数 = 総額」の3点をセットで確認し、その単価が何を含んだ前提なのかを合わせて見ることが大切です。単価の数字だけに引きずられないことが、妥当性の判断につながります。
Q. 工数の根拠はどう確認すればよいですか。
A. 画面数・機能数・連携本数など、数えられる単位で説明してもらうとよいです。根拠が示されていれば、後で仕様が増えたときに、どこが増えて工数が変わるのかを双方で確認できます。根拠のない丸めた工数だけが並ぶ場合は、説明を求める材料になります。
Q. PM費（プロジェクト管理費）が高すぎないか心配です。
A. PM費は進捗・課題・品質を管理する費用です。GXOの見積レビューでは全体の1〜2割程度を一つの目安にしますが、比率だけでは判断しません。比率そのものより、その費用がどの作業に対応しているかを説明してもらえるかを確認するとよいです。
Q. 相見積もりで単価が大きく異なる場合は、どう見ればよいですか。
A. 単価の差が生まれる主な要因は、含まれる工程の範囲、担当者の役割・経験水準、体制の組み方、間接費の配分の違いです。単価の数字だけを比べるのではなく、各社の見積が「何を対象にした単価なのか」を確認してから、総額と含まれる内容を合わせて比較することが重要です。
まとめ
人月単価と工数は、見積額の根幹をなす要素です。単価の高い・安いという一点で判断するのではなく、単価が役割と整合しているか、工数の根拠が示されているか、PM費の比率と内容が説明できるか、という3つの観点で読むと妥当性を判断しやすくなります。次回は、上流工程である要件定義費が「高く見える」理由と、その内訳の読み方を扱います。
関連記事
システム開発の見積・相見積もりを整理しませんか
GXOでは、システム開発の見積書、相見積もり、要件定義、開発会社選定について、発注前の整理をご支援します。総額だけでなく、工数、保守範囲、追加費用、体制、契約条件まで確認し、自社に合う進め方を一緒に整理します。
※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。
