工数計算のやり方｜人日・人月の計算式と単位換算・見積もりの手順

工数計算とは、ある作業を終えるのに必要な「人数×時間」を数値で見積もることです。基本式は工数＝作業時間×作業人数で、実務では人時・人日・人月という単位に換算して扱います。ここでは計算式と単位の換算（1人月＝20人日＝160人時）を計算例つきで示し、代表的な見積もり手法、見積もり精度を上げる進め方、工数表やツールでの管理・削減までを順に整理します。

まとめ：工数計算の要点

• 計算式：工数＝作業時間×作業人数。3人が5日作業するなら 3×5＝15人日。
• 単位：人時（MH）＝1人が1時間、人日（MD）＝1人が1日、人月（MM）＝1人が1ヶ月ぶんの作業量。建設・製造では人日を「一人工（いちにんく）」とも呼ぶ。
• 換算：1人日＝8人時、1人月＝20人日＝160人時（1日8時間・1ヶ月20営業日で計算した場合）。
• 実務補正：人は会議や休憩で常に100%は動けない。見積工数は稼働率で割り戻す（稼働80%なら1.25倍）。
• 費用換算：見積金額＝工数（人月）×人月単価。工数は原価とスケジュールの土台になる。

以下で、単位の意味・換算表・計算例・見積もり手法・削減の順に掘り下げます。

工数の定義と単位（人時・人日・人月）

工数は、作業の量を「何人が、どれだけの時間をかけるか」で表した指標です。金額でも作業件数でもなく、投入する労力の総量を測る点が特徴で、見積もり・スケジュール・原価計算の共通言語になります。基本の考え方は次の一式に集約されます。

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

たとえば1人で40時間かかる作業は40人時、これを2人で分担すれば「20時間×2人＝40人時」で、総工数は人数を変えても変わりません（分担で短縮できるのは所要日数であって工数ではない、という点が実務で誤解されがちです）。

人時・人日・人月・一人工の違い

同じ工数でも、作業の規模に合わせて単位を使い分けます。短時間のタスクは人時、数日〜数週間の作業は人日、数ヶ月規模のプロジェクトは人月が読みやすくなります。英語表記の頭文字からMH（人時）・MD（人日）・MM／M/M（人月）と略され、検索でも「工数 md」のように単位名で調べられます。

単位の定義そのものは会社の就業時間で決まります。1日の稼働を8時間、1ヶ月の営業日を20日と置くのが標準的ですが、自社の実態（1日7.5時間、月18〜21日など）に合わせて固定しておくと、換算のブレを防げます。

工数の計算方法と単位換算（人日・人月の出し方）

工数計算は「基準となる稼働時間を決める→単位を統一する→合算する」という順番で進めます。人日・人月への換算がここでの中心です。

単位の換算表

1日8時間・1ヶ月20営業日を前提にすると、換算は次のようになります。人月から人時まで一直線に変換できるので、見積もりの粒度を後から変えても数値がつながります。

逆算も同じ係数です。150人時の作業なら 150÷8＝18.75人日、これをさらに20で割れば約0.94人月と表せます。1ヶ月の営業日を自社基準（例：21日）に変えるときは、20を21に置き換えて計算し直します。

工数を出す4つの手順

個別タスクの積み上げで総工数を求める流れは次のとおりです。粒度を細かくするほど、抜け漏れと見積もり誤差が小さくなります。

1. 作業を独立したタスクに分解する（1タスクは長くても数日で終わる粒度にする）。
2. 各タスクに「必要な作業時間×担当人数」を割り当てる。
3. 単位を人時か人日にそろえて全タスクを合算する。
4. 規模が大きければ人月に換算し、稼働率で割り戻して実効工数にする。

手順3で単位を混在させると合算を誤ります。まず人時で積み上げ、最後にまとめて人日・人月へ換算するのが安全です。

Webサイト制作を例にした計算

設計40人時・デザイン32人時・実装80人時・テスト24人時の案件を考えます。合計は176人時で、8で割ると22人日、この22人日を20で割ると1.1人月です。2人で並行すれば所要日数は11日前後になりますが、総工数の22人日は変わりません。

この176人時をそのままスケジュールに置くと、たいてい遅れます。実際には会議・レビュー・問い合わせ対応で作業以外の時間が発生するためで、次の稼働率補正が必要になります。

稼働率・生産性の織り込み方

1日8時間の勤務でも、純粋に手を動かせるのは6〜6.4時間ほどで、稼働率はおおむね75〜80%に落ちます。見積工数はこの稼働率で割り戻します。稼働率80%なら、必要な実効工数は見積工数÷0.8＝1.25倍です。先ほどの22人日は 22÷0.8＝27.5人日を確保しておく計算になります。新人が多いチームでは生産性係数をさらに掛け、経験者の1.3〜1.5倍の工数を見込むと現実に近づきます。工数の妥当性やチームによる見積もりのばらつきについては、開発現場で工数管理が破綻する背景と見積もり精度を左右する構造的要因もあわせて確認してください。

工数見積もりの4つの手法

タスクごとの数値をどう見積もるかで精度が決まります。案件の性質と手元にあるデータ量に応じて手法を選びます。

3点見積もり法は「（楽観＋最可能×4＋悲観）÷6」で期待値を出す方法（PERT）が代表的で、読めない要素を数値に織り込めます。仕様が固まった案件はボトムアップ法で精度を取り、引き合い段階の概算では類推法や係数法で素早く当たりをつける、という使い分けが実務的です。

工数見積もりの精度を上げる5つの勘所

手法を選んだうえで、見積もりの外し方を減らす工夫を重ねます。ここは工数計算そのものより、運用でものを言う部分です。

• タスクを細分化する：1タスクを数日以内の粒度に割ると、見落としと過大・過小見積もりが減る。
• バッファを分けて持つ：各タスクに上乗せせず、プロジェクト全体で1本のバッファ（総工数の10〜20%目安）に集約すると、盛りすぎと不足の両方を防げる。
• クリティカルパスを押さえる：完了までの最長経路上のタスクにリソースを優先配分し、遅延の連鎖を止める。
• 見積もりをレビューする：担当以外の目で前提条件をすり合わせ、根拠のない数値を落とす。
• 予実を突き合わせる：見積工数と実績工数の差を案件ごとに記録し、次の類推法の精度に還元する。

とくにバッファをタスクごとに上乗せするのは避けます。各所に隠れた余裕が積み上がって総工数が膨らみ、かえって進捗が緩む「学生症候群」を招くためです。プロジェクト規模ごとに管理工数の適正量は変わるので、プロジェクト規模別に異なる管理工数の定義と適正範囲の考え方も参考になります。

工数を可視化・削減する方法（工数表・ツール）

算出した工数は、記録して初めて次の見積もりに生きます。可視化の手段と、工数そのものを減らす打ち手を分けて考えます。

工数表・エクセルでの管理

小規模なら、タスク・担当・見積工数・実績工数・差異を列に並べた工数表で足ります。エクセルは導入コストゼロで始められる一方、担当者が増えると入力ゆれや集計ミス、リアルタイム共有の弱さが表面化します。手作業の限界が見えてきたら、エクセルでのプロジェクト管理が向いているケースと運用限界の見極めで切り替えの判断基準を確認できます。

工数管理ツールの導入

工数入力・ガントチャート・実績集計を一元化するツールを使うと、予実の差がリアルタイムで見え、次の見積もりに反映しやすくなります。選定の観点や導入で得られる効果は、Excel管理の限界を感じるPMが知るべき工数管理ツールの基本機能と導入価値で詳しく整理しています。

工数を削減する具体策

工数削減は「作業を速くする」ことより「作業をなくす・減らす」ことが効果的です。ねらう先は、稼働率補正で見たように総時間の2〜3割を占める作業以外の時間です。定型作業をテンプレート化して着手のたびの再設計をなくす、問い合わせ対応が多いタスクはFAQやマニュアル整備で発生件数そのものを抑える、定例会議を週1本に集約して残りを非同期の情報共有に寄せる、といった打ち手が中心になります。削減の効果は、削減前後の実績工数を工数表で比較して数値で裏づける。工数が動かなければ、その施策は削減できていないと判断する。

よくある質問

工数の計算式を教えてください。

工数＝作業時間×作業人数です。3人が4日作業すれば 3×4＝12人日になります。人月で表すなら20で割って0.6人月です。

1人月は何人日・何時間ですか。

1日8時間・1ヶ月20営業日で計算する場合、1人月＝20人日＝160人時です。営業日を21日とする会社では21人日＝168人時になります。

「工数 md」の md とは何ですか。

md は man-day（人日）の略で、1人が1日でこなす作業量を指します。man-hour（人時）は mh、man-month（人月）は mm と略されます。

見積もった工数どおりに終わらないのはなぜですか。

会議や休憩、割り込み対応で稼働率が下がるためです。見積工数を稼働率（例80%）で割り戻し、実効工数として日程に反映すると現実に近づきます。

工数から見積金額はどう出しますか。

見積金額＝工数（人月）×人月単価で概算します。人月単価は技術者の水準や役割で変わるため、原価となる工数を正確に出すことが金額精度の前提になります。

関連記事

• 開発現場で工数管理が破綻する背景と見積もり精度を左右する構造的要因
• Excel管理の限界を感じるPMが知るべき工数管理ツールの基本機能と導入価値
• プロジェクト規模別に異なる管理工数の定義と適正範囲の考え方
• エクセルでのプロジェクト管理が向いているケースと運用限界の見極め