工数とは？単位・計算方法・見積もり手法を解説【2026年版】人時・人日・人月の換算と数え漏れ7カ所

「見積書に『96人月』と書いてあるが、これは多いのか少ないのか」——システム開発の発注を担当する方から、こうした相談をよく受けます。もう1社の見積書には「140人日」とあり、単位が違うので並べることすらできない。社内では「工数を出して」と言われるが、何をどう数えればよいのか分からない。工数という言葉は日常的に飛び交うのに、意味を説明できる人は意外と少ないものです。

結論から言うと、工数とは、作業を終えるために必要な作業量を「人数×時間」で数値化したものです。単位は人時・人日・人月の3つで、1人日や1人月を何時間とするかは法令にも規格にも定めがなく、見積書と契約書で決める前提値です。そして工数が分かれば、費用は「工数×単価」、工期は「工数÷人数」で概算できます。工数は、金額と期間の両方を支える土台の数字です。

ただし、工数は測れば決まる絶対量ではありません。会議やレビュー、手戻りを数えるかどうかで総量は変わり、1人月を何時間とするかの前提も会社によって違います。だから、単位を揃えずに2社の見積もりを比べても意味がなく、工数を人数で割っただけの工期も現実にはそのとおりになりません。工数を扱うということは、数字そのものより前提を扱うということです。

本記事では、工数の定義と費用・工期との関係、人時・人日・人月の単位と換算、数え方と計算方法(数値例3つ)、見積もりの4手法(類推・パラメトリック・ボトムアップ・三点見積もり)、工数と工期の違いと提示された工数を検算する3つの角度、よくある質問の順に解説します。単価の相場や見積書の項目別の読み方は別記事に譲り、本記事は「数え方」に集中します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。そこで繰り返し見てきたのは、工数そのものより「何を数えているか」の食い違いが、あとで費用と納期の揉めごとになるという事実です。この記事を読み終えるころには、受け取った見積もりの工数を自分の言葉で検算できるようになるはずです。

工数とは——作業量を「人数×時間」で数えた単位。費用と工期はここから決まる

工数(こうすう)は、システム開発や製造、建設の現場で日常的に使われる言葉ですが、「時間」とも「人件費」とも違う独自の考え方です。まずは定義と、工数が何のために存在するのかを押さえてください。ここが曖昧なまま見積書を読むと、数字だけが独り歩きします。

工数の定義と、1工数が指すもの

工数とは、ある作業やプロジェクトを完了させるために必要な作業量を、人数と時間の組み合わせで数値化したものです。英語では man-hour(マンアワー)などと表記します。

「1工数」とは、1人が単位期間にこなす作業量を1と数えたものです。単位期間が1時間なら1人時、1日なら1人日、1か月なら1人月になります。たとえば1人で8時間かかる作業は8人時、2人で3時間かかる作業は6人時です。ここで重要なのは、工数が延べの作業量であって、経過時間ではないという点です。2人で3時間の作業は、時計の上では3時間で終わりますが、工数は6人時です。

工数はもともと製造業の生産管理で使われてきた概念で、現在はシステム開発、建設、広告制作、コールセンターの要員計画まで広く使われています。作業の大きさを、担当者の感覚ではなく共通の数字で表すための道具だと考えてください。

工数から費用と工期が決まる——「費用=工数×単価」「工期=工数÷人数」の2本の掛け算

私は説明するとき、必ず要素に分解することにしています。工数が重要なのは、それ自体が答えだからではなく、費用と工期という2つの答えを導く共通の入力値だからです。

見積書に並ぶ金額も、提示される納期も、元をたどればこの表に行き着きます。裏返すと、工数が変われば金額と納期の両方が同時に動くということです。「予算を2割下げたい」という要望が「機能を減らすか、単価の安い体制にするか」の二択になるのは、この式から必然的に導かれます。単価そのものの相場と決まり方は「人月単価」の記事で詳しく扱っていますので、金額の妥当性を確かめたい方はそちらをご覧ください。

工数は絶対量ではない——「何を数えるか」を決めてはじめて確定する

工数を初めて扱う方が戸惑うのは、同じ作業なのに人によって出てくる数字が違うことです。これは誰かが間違っているからではなく、工数が測れば決まる量ではないからです。

工数を確定させるには、少なくとも3つの取り決めが要ります。1つ目は「1人日を何時間とするか」という単位の前提。2つ目は「どこまでを作業に数えるか」という範囲の取り決めで、打ち合わせ、レビュー、手戻り、環境構築を含めるかどうかで総量は3割前後変わります。3つ目は「誰が作業する前提か」というスキルの前提で、経験10年と3年では同じ機能でも所要が2倍違うことは珍しくありません。

つまり工数とは、前提とセットで初めて意味を持つ数字です。「96人月」という数字だけを受け取って多いか少ないかを判断しようとするのは、単位の書かれていない目盛りを読むようなもので、失敗のもとです。次章では、その前提の第一歩である単位と換算から見ていきます。

工数の単位と換算——人時・人日・人月、そして一人工(にんく)

工数の単位は、作業の粒度に合わせて使い分けます。1日で終わる作業を人月で表しても粗すぎますし、半年のプロジェクトを人時で表せば桁が大きすぎて扱えません。ここでは3つの基本単位と換算の前提、そして業界固有の単位を整理します。

3つの単位の意味と英語表記

計算式はいずれも「作業時間 × 作業人数」で共通です。3人で5時間なら15人時、10人で5日なら50人日、10人で3か月なら30人月になります。人日は分野によって「人工(にんく)」とも呼ばれます。

換算早見表——1人日・1人月の前提時間は契約で決める

3つの単位は、1人日の標準労働時間(H時間)と1か月の標準稼働日数(D日)を決めれば相互に換算できます。HもDも法令や規格が定めた値ではなく、見積書と契約書で当事者が決めるものです。本記事では計算例を示すために、H=8時間・D=20日と置いた契約を前提として説明します。Hを8時間と置くのは、労働基準法第32条が「休憩時間を除き一日について八時間を超えて、労働させてはならない」と定めていることに合わせた置き方であって、工数の単位としてこの値が決まっているわけではありません。Dの20日は本記事の計算例のための前提で、基準でも慣行でもありません。

ここで示したH=8時間・D=20日はあくまで本記事の計算例の前提であり、受け取った見積書が同じ前提で書かれている保証はどこにもありません。1人月を何時間とするか、そして稼働が前提を下回ったとき・上回ったときにどう精算するかは、契約で定めるものです。1人月が何時間なのかについては「1人月 何時間」の記事で詳しく扱っていますので、契約前に確認したい方はあわせてご覧ください。本記事では、前提時間は必ず見積書か契約書で確認するものという一点だけを押さえてください。

業界で違う単位——建設の一人工と、設備・イベントの数え方

工数の考え方は業界をまたいで使われますが、呼び名と数え方には方言があります。

• 建設業の一人工(いちにんく): 作業員1人の1日分の労働量を指し、実質的に1人日と同じです。公共工事では、国土交通省が職種別に定める公共工事設計労務単価が「所定労働時間内8時間当たり」の単価として示されており、1日分の労働を単位に金額を置く考え方は制度としても使われています
• 設備の稼働時間: 人の作業時間とは別に、設備が何時間動いたかを数え、人の工数とは分けて管理することがあります。原価計算や設備投資の判断では、人と設備を同じ単位で混ぜないことが要点です
• 延べ人日での積み上げ: 3日間のイベントに10人が毎日入るなら、3日 × 10人 = 30人日です。人件費だけでなく、弁当や宿泊の手配もこの単位で見積もれます

システム開発では人時・人日・人月の3つで足りますが、相手の業界によって言葉が変わることは知っておくと会話が早くなります。

前提が違えば比較できない——2社の見積もりを同じ土俵に並べる手順

私が現場で最も多く受ける相談が、「A社は96人月、B社は140人日と書いてあって比べられない」というものです。単位を人日に揃えると(この案件は1人月=20人日で合意していました)、96人月は1,920人日、B社は140人日。約14倍の開きです。ここまで違うと、単価が高い安いの話ではなく、そもそも作る範囲が違うと判断できます。実際、B社の見積もりは要件定義と結合テストが入っていませんでした。

2社の見積もりを並べるときは、次の順で揃えてください。(1)単位を人日に統一する、(2)1人日の前提時間を各社に聞く、(3)含まれている工程の範囲を突き合わせる、(4)そのうえで人日あたりの金額を比べる。この順序を飛ばして金額だけを比べていないでしょうか。

工数の数え方と計算方法——基本式・逆算・積み上げを数値例で

ここからは実際に手を動かす部分です。工数の計算そのものは掛け算と割り算だけで、難しいことはありません。難しいのは「何を数えるか」を漏らさず決めることのほうです。計算式、数値例、WBSによる積み上げ、数え漏れの起きやすい場所の順に見ていきます。

基本式と3つの逆算(工数・人数・期間のどれかが分かれば残りが出る)

工数の基本式は1つだけです。

工数 = 作業時間 × 作業人数

この式を変形すると、3つの逆算ができます。

見積もりの場面では「工数」を求め、体制を組む場面では「必要人数」を求め、納期を判断する場面では「必要期間」を求めます。同じ式を三方向から使っていると考えれば十分です。ただし、必要期間の計算はあくまで理論値で、そのまま現実にはなりません。理由は後述します。

計算例1〜3: 単純な作業、途中で人が増える作業、プロジェクト全体の積み上げ

例1: 単純な作業 1人のデザイナーが1ページの画像差し替えに2時間かかるとします。これは2人時です。5ページ分なら 2時間 × 5ページ = 10人時。1人日を8時間と定めた契約なら、人日への換算は 10 ÷ 8 = 1.25人日です。2人で並行すれば、計算上は約0.63日で終わります。

例2: 途中で人が増える作業 最初は3人で2時間作業し、そこへ3人が加わって6人で3時間作業した場合、工数は区間ごとに分けて足します。

(2時間 × 3人) + (3時間 × 6人) = 6 + 18 = 24人時

人の出入りがあるときは、必ず区間で切って足してください。平均人数で一括計算すると必ずずれます。

例3: プロジェクト全体の積み上げ 1年間のプロジェクトで、最初の3か月は5人、残り9か月は10人が稼働したとします。

(3か月 × 5人) + (9か月 × 10人) = 15 + 90 = 105人月

この105人月に人月単価を掛ければ概算費用が出ます。逆に、予算が先に決まっているなら、予算 ÷ 単価で使える工数の上限が出て、そこから作れる範囲を逆算できます。

WBSで数える——作業を分解してから足す手順

実務で工数を出すときは、プロジェクト全体をいきなり見積もりません。WBS(Work Breakdown Structure=作業分解構成図)で作業を階層的に分解し、末端の作業単位ごとに工数を置いて足し上げます。手順は次の4段です。

1. 成果物で分ける: 要件定義書、基本設計書、画面、API、テスト仕様書といった成果物の単位で大きく割る
2. 工程で分ける: 各成果物について、設計・実装・単体テスト・結合テスト・修正の工程に割る
3. 末端の作業単位まで割る: 1件ごとに、担当者が「何をするか」を具体的に言えるところまで割る。中身を説明できない大きな塊が残っていると、見積もりの精度は上がりません
4. 末端に工数を置いて足す: 担当者の想定スキルを決めたうえで人日を置き、階層を上に向かって合計する

末端の粒度を細かくするほど数え漏れは減りますが、分解自体にも工数がかかります。末端の1件について、担当者が着手から完了までの段取りを言えるところまで割れば、発注側が範囲を確認するには十分です。

数え漏れが起きる7カ所——会議・レビュー・手戻り・環境構築・調査・テストデータ・リリース作業

見積もりが実績より小さくなる原因は、難易度の読み違いよりも単純な数え漏れであることが多いのが実情です。私が見積書を見るとき、真っ先に確認するのは次の7カ所です。

これらを合計すると、実装工数の3〜5割に相当することも珍しくありません。見積書の総工数が実装の積み上げとほぼ一致しているときは、この7カ所が含まれているかを必ず聞いてください。含まれていない見積もりは安く見えますが、後から追加費用として跳ね返ってきます。数え漏れは、見積もりの精度ではなく合意の範囲の問題だ、と考えるのが安全です。

工数見積もりの4つの手法——類推・パラメトリック・ボトムアップ・三点見積もり

工数の出し方として、本記事では実務でよく使われる4つの手法を取り上げます。どれが優れているという話ではなく、その時点で使える情報の量と質で選ぶものです。引き合いの段階でWBSを作れと言われても要件がありませんし、要件定義が終わったあとに「勘」で出すのも乱暴です。まずは全体像を比較表で押さえてください。

4手法の比較表(必要な情報・精度・かかる手間・使う段階)

精度の目安は一般的な整理であり、案件の性質や過去データの質で変わります。重要なのは、段階が進むほど精度が上がる代わりに手間も増えるという関係です。企画段階で±10%の見積もりを求めることには無理があります。

類推見積もりとパラメトリック見積もり——過去の実績を使う2つのやり方

類推見積もりは、過去に行った似たプロジェクトの実績から「今回もこのくらい」と見積もる方法です。所要期間、予算、規模、複雑さといった項目を過去案件と突き合わせ、差分の分だけ調整します。誰もが日常的にやっていることですが、実績データを台帳として残しているかどうかで精度がまったく違います。

利点は、安く速いことです。特別な準備が要らず、数時間で数字が出ます。複雑でない案件なら、下手に他の手法を使うより実績に近い値が出ることもあります。欠点は、類似の過去案件がなければ使えないこと、そして大規模・複雑な案件になるほど当たらなくなることです。

パラメトリック見積もり(係数見積もり)は、類推を一歩進めて、規模の指標と単位あたり実績の掛け算にします。「1画面あたり平均3人日」「1APIあたり1.5人日」「ファンクションポイント1点あたり0.8人日」といった係数を、自社の過去実績から作っておき、今回の画面数・機能数を掛けます。

係数さえ持っていれば、要件が固まる前でも根拠のある数字が出せます。ただし係数は自社の生産性そのものなので、他社の数字を借りてきても意味がありません。なお2026年時点では、AIによるコード生成が実装工程の生産性を押し上げており、実装の係数は数年前の実績をそのまま使えなくなりつつあります。係数を持っている会社ほど、定期的な見直しが必要になっていると感じます。

ボトムアップ見積もり——WBSの末端を積み上げる

前章で説明したWBSの手順そのものが、ボトムアップ見積もりです。作業を末端まで分解し、1つずつ工数を置いて足し上げます。4手法のなかで最も精度が高く、作業の抜け漏れも見つけやすい方法です。

欠点は手間です。要件が固まっていないと分解できないため、要件定義が終わるまで実施できません。引き合いの段階でこれを求められると、開発会社は「要件定義だけ先に準委任で受けさせてほしい」と答えることになります。これは逃げではなく、順序として正しい対応です。要件定義をどう進めるかは「要件定義 進め方」の記事で扱っています。

三点見積もり——楽観値・最可能値・悲観値から期待値と幅を出す(計算例つき)

三点見積もりは、1つの数字を出すのではなく、3つの数字から期待値と振れ幅を計算する方法です。もとは米海軍のポラリス計画(潜水艦発射弾道ミサイルの開発)の進捗評価手法PERTとして考案されたもので、1959年の原著論文(Malcolm, Roseboom, Clark & Fazar, Operations Research 7巻5号)で発表されました。

• 楽観値: すべてが順調に進んだときの最短値
• 最可能値: 経験上もっともありそうな値
• 悲観値: 悪条件が重なったときの最長値

計算式は次のとおりです。

期待値 =(悲観値 + 4 × 最可能値 + 楽観値)÷ 6 標準偏差 =(悲観値 − 楽観値)÷ 6

たとえば、いつもは10日で終わる作業で、順調なら6日、最悪なら20日かかるとします。

• 期待値 =(20 + 4 × 10 + 6)÷ 6 = 66 ÷ 6 = 11日
• 標準偏差 =(20 − 6)÷ 6 ≒ 2.3日

最可能値の10日より1日多い11日が期待値です。さらに標準偏差から、8.7〜13.3日(期待値±1標準偏差)に収まる確率が約68%、6.4〜15.6日(±2標準偏差)なら約95%と、確率つきで幅を示せます。社内やクライアントに報告するとき、「11日です」と言い切るのではなく「11日が中心で、95%の確度なら15.6日を見てください」と伝えられるのが、この手法の価値です。天気予報の降水確率と同じで、断定しないほうがかえって信頼されます。

なお、この手法は関係者が多く不確実性の高いプロジェクトで効きます。少人数の小さな案件では、最可能値だけを使ったほうが手間に見合うこともあります。

バッファの置き方——10〜20%を目安に、誰のバッファかを明示する

どの手法で出しても、見積もりは外れます。そこでバッファ(余裕)を置きますが、置き方には作法があります。一般には総工数の10%前後を目安とする整理が多く、不確実性の高い案件では20%程度まで見ます。

大切なのはバッファを各作業に隠さず、プロジェクト全体で1カ所にまとめて持つことです。各担当者が自分の見積もりに2割ずつ上乗せすると、全体では2割どころではない余裕が積み上がり、しかもその余裕は必ず使い切られます。まとめて持ち、誰の判断で取り崩すかを決めておくほうが、結果的に総量は小さくなります。

当社が支援している介護記録SaaS「CareViewer」では、日本語のできるブリッジSE1名とフルスタックエンジニア2名の体制で、週次に優先順位を見直しながら開発を続けています。要件が動き続けるプロダクトでは、初めに全体の工数を確定させるより、期待値と幅で合意して週ごとに調整するほうが現実的です。手法は、案件の性質に合わせて選んでください。

工数と工期は別物——人を増やしても縮まない理由と、工数管理・検算のしかた

工数の話でいちばん誤解が多いのが、工期との関係です。「30人月の残作業を2か月で終わらせたいので、15人入れてほしい」という依頼は、式の上では正しく、現実にはほぼ成立しません。最後に、工数と工期の関係、工数管理の考え方、そして受け取った工数を検算する方法を整理します。

同じ10人月でも工期は変わる——工期の逆算表と、比例しない3つの理由

工期は「工数 ÷ 投入人数」で計算できます。10人月の作業なら、次のようになります。

右の列が理論値からずれるのは、次の3つの理由によります。

1. 教育とキャッチアップの工数が乗る: 新しく入った人が戦力になるまで、本人の時間と、教える側の時間の両方が消えます。既存メンバーの生産性が一時的に落ちる点も見落とされます
2. コミュニケーションの経路が増える: 人数が増えると、確認・調整の組み合わせが急速に増えます。5人なら10通り、10人なら45通りの経路ができ、その調整自体が工数になります
3. 分割できない作業がある: 1人が5日かけて書く設計書を、5人で1日にすることはできません。順序の制約がある作業は、人数を増やしても短縮できません

このため、遅れているプロジェクトへの後半の増員は、ほとんど効きません。むしろ遅れが拡大することさえあります。工期を縮めたいなら、人を足すより先に「作る範囲を削って工数そのものを減らす」ほうが確実です。この考え方は「人月の神話」として古くから知られており、人月という単位の限界については「1人月 何時間」の記事でも触れています。

工数管理は「計画と実績の差分」を見る——出来高で進捗を測る

工数管理というと、メンバーに作業時間を細かく入力させることだと思われがちですが、目的は記録ではありません。計画した工数と、実際に使った工数の差分を早く見つけることです。

進捗を見るときは、「消化した工数」ではなく「終わった作業の計画工数(出来高)」を数えてください。100人日の計画に対して50人日を使っていても、終わった作業の計画工数が30人日分しかないなら、進捗は30%であって50%ではありません。この差を毎週見ていれば、3か月後に「実は遅れていた」と気づく事故は防げます。

一方で、工数管理そのものにも工数がかかります。全タスクを15分単位で入力させると、入力だけで週に数時間が消えます。管理の単位は、まとまった作業ごと、週次程度で十分です。管理のための管理にならないよう、要注意です。

提示された工数を検算する3つの角度——単位の前提、工程別の比率、数え漏れ

発注側が開発会社の見積もりを検算するとき、金額から入ると必ず主観的な議論になります。次の3つの角度から工数を確かめるほうが、はるかに建設的です。

この3つに明確に答えられない見積もりは、金額の高い安い以前の問題です。逆に、質問に対して根拠を出せる会社は、見積もりの作り方そのものが整っていると判断できます。なお、見積書の項目ごとの読み方と金額差の正体については「システム開発 見積もり 内訳」の記事で詳しく扱っています。

当社の場合——単価を公開し、最小構成と1名単位で前提を先に合わせる

当社(TALENTBASE VIETNAM)がベトナム・ホーチミンでオフショア開発の体制をご提供するときは、この「前提合わせ」を最初に行います。単価は公開しており、実務3年目安で1,500USD(1USD=150円換算目安で約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです。協力会社を挟まず、グループで保有する2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするため、仲介マージンが工数と単価の間に入りません。

体制は、日本人PM/ブリッジSEをフロントに置くパターンAを推奨しており、最小構成は日本人PMフロント+2〜3人月で月額約80万円〜です。1名から始められ、最短2週間で稼働、増員は約1週間、縮小や交代は1か月単位で対応します。工数が読み切れない段階で大きな体制を組む必要はありません。打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始という流れで、契約と支払いは日本国内法人・日本法準拠です。継続的に開発を続ける体制の考え方は「ラボ型開発」の記事にまとめています。

見積もりを受け取ったら、金額の前にまず工数の前提を聞いてみてください。同じ質問を2社にすれば、比べるべきものが何かが自然に見えてくるはずです。

工数に関するよくある質問

最後に、工数について実際によくいただく質問を5つ取り上げます。いずれも見積書を受け取ったあと、あるいは社内で工数を出す場面で必ず出てくるものです。

Q1. 1人月は何時間ですか

法令にも規格にも決まりはなく、契約ごとに定めるものです。1日の標準労働時間と1か月の標準稼働日数を掛けて求めますが、そのどちらも当事者が合意して決める値です。契約では精算の幅(下限と上限)を定め、下回った場合の控除と上回った場合の超過単価を決めておくのが実務です。前提時間が違えば同じ「10人月」でも中身が変わりますので、見積書には必ず明記してもらってください。根拠と幅の詳しい解説は「1人月 何時間」の記事をご覧ください。

Q2. 工数と工期は何が違うのですか

工数は「延べの作業量」、工期は「開始から終了までの経過期間」です。10人月の作業を5人で行えば工期は2か月、2人なら5か月と、同じ工数でも投入人数で工期は変わります。逆に、工期を短くしたいからといって人数を増やしても、教育と調整の工数が乗るため比例して縮むことはありません。工期を確実に縮めたいときは、人を足すのではなく作る範囲を削ってください。

Q3. 作業工数に会議やレビューは含めるのですか

含めてください。定例会議は総工数の5〜10%、設計・コードのレビューも同程度を占めるのが実情で、これを数えない見積もりは必ず不足します。手戻り・バグ修正(10〜20%)、開発環境の構築、調査、テストデータ作成、リリース作業も同様です。「含まれていない」こと自体が悪いのではなく、含まれていないと双方が認識しないまま契約することが、後の追加費用の揉めごとにつながります。

Q4. 見積もりのバッファはどれくらい見ればよいですか

総工数の10%前後が一般的な目安で、新しい技術を使う、要件が固まっていない、外部システムと連携するといった不確実性があれば20%程度まで見ます。置き方のコツは、各作業に少しずつ隠さず、プロジェクト全体で1カ所にまとめて持つことです。各担当者が個別に上乗せしたバッファは、ほぼ確実に使い切られます。誰の判断で取り崩すかを決めておいてください。

Q5. 工数が当初見積もりから膨らんだときはどうすればよいですか

まず、膨らんだ原因が「範囲の追加」なのか「見積もりの誤差」なのかを分けてください。範囲の追加であれば変更管理の手続きに乗せて追加費用を確定させ、誤差であれば残りの作業の優先順位を見直して範囲を削ります。人を足して取り戻す判断は、プロジェクトの後半ほど効きません。当社では1名単位の増員(約1週間)と1か月単位の縮小・交代に対応していますが、それでも最初にお勧めするのは増員ではなく、週次での優先順位の見直し。

まとめ: 工数は作業量の単位——前提を揃え、数え漏れを潰し、幅で示す

工数とは、作業を終えるために必要な作業量を「人数×時間」で数値化したものです。単位は人時・人日・人月の3つで、1人日や1人月を何時間とするかは法令にも規格にも定めがなく、見積書と契約書で決める前提値です。そして工数が分かれば、費用は「工数×単価」、工期は「工数÷人数」で概算できます。工数は金額でも期間でもなく、その両方を導く土台の数字です。

工数を扱ううえで押さえるべきことは3つです。1つ目は単位の前提を揃えること。1人月が何時間かは法令でも規格でも決まっておらず会社ごとに違うため、前提を確認しないまま2社の見積もりを並べても比較になりません。2つ目は数え漏れを潰すこと。会議、レビュー、手戻り、環境構築、調査、テストデータ作成、リリース作業の7カ所が抜けると、総量は実装工数の3〜5割ぶん不足します。3つ目は手法を選び、幅で示すこと。引き合い段階なら類推やパラメトリック、要件定義後ならWBSからのボトムアップ、不確実性の高い作業には三点見積もりを重ね、期待値と確率つきの幅で合意してください。そして、工期は工数を人数で割った理論値どおりにはなりません。遅れを取り戻す手段は増員ではなく、作る範囲を削ることです。

見積もりを受け取ったら、金額の前に「1人月は何時間の前提か」「工程別の工数配分はどうか」「会議とレビューと手戻りは含まれているか」の3つを聞いてみてください。この3問に根拠を持って答えられる会社かどうかで、見積もりの信頼度は判断できます。単価そのものの相場と決まり方は人月単価の相場、見積書の項目ごとの読み方はシステム開発の見積もりの内訳もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、必要な工数の目安と体制、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。