---
title: "工数管理システムとは？工数の単位・機能・勤怠管理との違いと選び方を解説"
url: "https://www.issoh.co.jp/column/details/15378/"
published: 2026-07-19
updated: 2026-10-19
categories: ["DX"]
publisher: "株式会社一創"
---

# 工数管理システムとは？工数の単位・機能・勤怠管理との違いと選び方を解説

工数管理システムとは、「誰が・どの案件に・何時間使ったか」を作業単位で記録し、プロジェクトごとの原価と採算を数字で見えるようにする仕組みです。労働時間の合計を扱う勤怠管理システムとは目的が異なり、時間の使い道を案件別に把握できる点が特徴です。本記事では工数という単位の数え方（人時・人日・人月の換算）を起点に、主要機能、エクセル・単機能SaaS・勤怠一体型・ERP型という提供形態の比較、選定の観点までを順に整理します。あわせて受託開発会社の視点から、パッケージ導入で足りるケースと、基幹システム連携・個別開発に踏み込むべきケースの切り分けも示します。

## まとめ：工数管理システムは案件別原価を映す鏡であり導入判断の起点になる

工数管理システムの本質は、時間の記録そのものではなく「プロジェクト原価の見える化」にあります。時間単価と工数を掛け合わせれば案件別の労務費が自動で算出され、赤字案件を決算前に発見できるのが最大の利点です。この工数実績を予算と突き合わせて案件単位で予実を回す実務は、[プロジェクト予算管理の進め方を解説した記事](https://www.issoh.co.jp/column/details/15642/)で扱っています。勤怠管理システムが労働時間の合計を法令対応と給与計算のために扱うのに対し、工数管理システムは同じ時間を案件別の内訳として扱う、という役割の違いを押さえることが出発点になります。

もう一つの出発点が、工数という単位そのものの扱いです。人時・人日・人月をどの換算で運用するか、どこまでの作業を工数に含めるかが決まっていないと、集計した数字が原価計算に耐えません。単位と集計範囲を先に決め、そのうえで製品を選ぶ順序を推奨します。

選定の結論は組織の規模と原価粒度で分かれます。案件単位の採算が見えれば足りる組織には単機能SaaSで十分であり、スクラッチ開発は過剰です。一方、独自の原価配賦ルールや基幹システムとの統合要件がある組織では、パッケージのカスタマイズより基幹側に工数・原価管理を組み込む個別開発が合理的な選択になります。本文でこの判断基準を条件付きで具体化します。

## 工数管理システムの定義と勤怠管理・プロジェクト管理ツールとの違い

「工数管理システム」を正しく選ぶには、まず工数という単位の意味と、隣接するシステムとの守備範囲の違いを整理する必要があります。名前が似た仕組みが多い領域だからです。

### 工数管理システムの定義と人日・人月という単位で測る工数の基本

工数とは、作業量を「人数×時間」で表した単位です。1人が1日（実働8時間）働く作業量が1人日、1人が1か月（おおむね160時間前後）働く作業量が1人月と数えられ、システム開発の見積もりでは「この機能は15人日」のように使われます。3人のチームが5営業日かければ15人日という計算です。

工数管理システムは、この工数をメンバー各自が日々入力し、案件別・工程別に自動集計するソフトウェアを指します。手書きの作業日報やエクセルの工数表と役割は同じですが、集計の自動化、時間単価を掛けた労務費への換算、予定と実績の対比までを一つの画面で完結できる点が両者の違いです。日報の電子化そのものから検討する場合は[日報アプリとは？機能・種類・比較の選び方と既製か自社開発かの判断軸を解説](https://www.issoh.co.jp/column/details/15385/)で入力・共有側の仕組みを整理しています。

### 労働時間を扱う勤怠管理システムと案件別時間を扱う工数管理の違い

勤怠管理システムが記録するのは出退勤時刻と労働時間の合計で、目的は労働基準法への対応と給与計算です。厚生労働省の[労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン](https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou%5Froudou/roudoukijun/roudouzikan/070614-2.html)（平成29年1月20日策定）は、始業・終業時刻をタイムカードやICカード、パソコンの使用時間といった客観的な記録で確認することを原則としています。つまり勤怠側が答えるのは「いつからいつまで働いたか」であり、「その時間をどの案件に使ったか」までは射程に入りません。残業が月10時間発生したとき、どの案件が原因かを特定できないのが勤怠データの限界です。

工数管理システムは同じ時間を案件別の内訳として記録し、原価計算と採算分析に使います。両者は代替関係ではなく補完関係にあり、勤怠の総労働時間と工数の合計を突き合わせて入力漏れを検出するのが実務で定着した運用です。勤怠側の仕組みを詳しく知りたい場合は[勤怠管理システムの機能・種類・費用と失敗しない選び方の解説](https://www.issoh.co.jp/column/details/15081/)で確認できます。

### プロジェクト管理ツール・案件管理システムと工数管理の役割分担

プロジェクト管理ツールはWBSやガントチャートでタスクと進捗を管理し、「何がいつ終わるか」に答えます。案件管理システムは商談から受注・請求までの案件情報を一元管理し、「どの案件がどんな状態か」に答える仕組みです。工数管理システムが答えるのは「その案件にいくらかかっているか」であり、三者は扱う軸が異なります。

実務では、進捗はプロジェクト管理ツール、原価は工数管理システムと使い分けるか、両方を備えた一体型製品を選ぶかの二択が基本です。それぞれの選び方は[プロジェクト管理ツールの機能・種類と既製か自作かの判断軸](https://www.issoh.co.jp/column/details/15248/)、[案件管理システムの機能とSFA・プロジェクト管理との違い](https://www.issoh.co.jp/column/details/15374/)で個別に解説しています。会計事務所・税理士事務所のように顧問先ごとの工数と採算を扱う場合の設計は[会計事務所の案件管理システムの選び方](https://www.issoh.co.jp/column/details/16701/)が具体例になります。

## 工数の数え方と単位｜人時・人日・人月の換算と見積りへの落とし込み

製品選定より前に決めるべきなのが、工数をどの単位で数え、どこまでの作業を含めるかという定義です。ここが曖昧なまま入力を始めると、部署ごとに数え方が食い違い、集計値を原価計算にも見積り補正にも使えなくなります。

### 工数の単位を人時・人日・人月で換算する式と1人月160時間の根拠

工数の単位は、細かい順に人時（man-hour）・人日（man-day）・人月（man-month）の3段です。換算は「1人日＝8人時」「1人月＝20人日＝160人時」を基準に置くのが国内の慣習で、この8時間と20日という数字には根拠があります。1日8時間・1週40時間という法定労働時間は[労働基準法第32条（e-Gov法令検索）](https://laws.e-gov.go.jp/law/322AC0000000049)に定められており、週40時間を4週分積み上げると160時間になるためです。

| 単位 | 意味         | 換算の基準      | 主に使う場面   |
| -- | ---------- | ---------- | -------- |
| 人時 | 1人が1時間の作業量 | 最小単位       | 日次の工数入力  |
| 人日 | 1人が1日の作業量  | 8人時        | 週次の進捗と予実 |
| 人月 | 1人が1か月の作業量 | 20人日・160人時 | 見積書と契約金額 |

注意したいのは、160時間が全社共通の固定値ではない点です。所定労働時間が7時間45分の会社なら1人月は155時間前後になり、月の営業日数でも上下します。自社の就業規則から換算値を確定し、工数管理システムの設定にも同じ値を入れておくと、システム側の集計と見積書の人月換算がずれません。換算の詳細と早見表は[工数の単位とは？人時・人日・人月の換算早見表と1人月160時間の根拠](https://www.issoh.co.jp/column/details/11021/)、計算手順は[工数計算のやり方｜人日・人月の計算式と単位換算・見積もりの手順](https://www.issoh.co.jp/column/details/2382/)で個別に扱っています。

### 直接工数と間接工数を区分して工数に含める作業範囲を決める手順

次に決めるのが集計範囲です。案件に直課できる設計・実装・テストは直接工数、社内会議・採用面談・全体研修などは間接工数として扱い、案件原価には直課しないのが基本形になります。悩ましいのは、特定顧客との定例会や提案前の調査といったグレーゾーンで、ここを部署ごとの判断に委ねると案件別原価の比較ができなくなります。

実務的な決め方は、「請求の根拠になるか」を第一の基準に置き、受注前の提案活動は営業原価、受注後の顧客対応は案件の直接工数と線を引く方法です。判断に迷う作業を10件ほど列挙し、それぞれの扱いを表にして社内で合意しておけば、入力時の迷いがなくなります。区分の考え方と比率の目安は[直接工数と間接工数の違いとは？区分の判断基準・グレーゾーン・比率の目安を解説](https://www.issoh.co.jp/column/details/11002/)で詳しく整理しています。

### 見積り工数を予定工数へ落とし込みバッファを持たせる配分の考え方

工数管理システムに入れる予定工数は、見積書の工数をそのまま流し込むだけでは機能しません。見積りは受注のための金額であり、予定工数は進行を管理するための計画値だからです。両者を分け、見積り工数から間接的な立ち上げ作業やレビュー時間を差し引いた値を各工程の予定工数として配分します。

配分の目安として参照できるのが、業界横断の実測データです。IPAが公開した[ソフトウェア開発分析データ集2022](https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html)は、2004年から蓄積した5,546件のプロジェクトデータをもとに工数・工期・規模・生産性・信頼性を分析しており、直近6年分の1,479件からベンチマーク値を算出しています（2022年9月公開時点）。自社の予実データが貯まるまでは、この種の公開データを工程別配分の当たりとして使い、実績が3案件ほど溜まった段階で自社値へ切り替える進め方が現実的です。バッファは工程ごとに10〜20%を上乗せするより、プロジェクト全体で一括して確保し、消費状況を予実で追うほうが管理しやすくなります。見積り手法そのものの選び分けは[プロジェクト規模と開発体制に応じた工数見積もり手法の全体像](https://www.issoh.co.jp/column/details/11019/)、発注側から見た人月単価の妥当性判断は[人月とは？計算方法・人月単価の相場と発注者が見積もりの妥当性を見抜く方法](https://www.issoh.co.jp/column/details/13207/)を参照してください。

## 工数入力から原価計算・予実対比まで担う工数管理システムの主要機能

工数管理システムの機能は「入力」「集計・原価換算」「予実対比」「外部連携」の4系統に分かれます。製品比較の際は、この4系統ごとに自社の要件を満たすかを確認すると抜けがありません。

### 予定工数と実績工数の予実対比で見積もり精度を高める中核の機能

予実対比は、見積もり時に設定した予定工数と、日々入力される実績工数を案件別・工程別に突き合わせる機能です。予定20人日の案件に実績28人日かかっていれば40%の超過であり、進行中にアラートで把握できれば追加請求の交渉や体制変更の判断が間に合います。

蓄積された乖離データは次回見積もりの補正根拠になります。「設計工程は毎回2割超過する」と分かれば、次の見積もりで設計に2割の係数を掛ける、という改善が数字を根拠に回せます。工数管理を単なる記録で終わらせないための中核がこの機能です。

### 時間単価を掛けてプロジェクト原価と採算を自動算出する原価計算機能

原価計算機能は、メンバーごとの時間単価と実績工数を掛け合わせ、案件別の労務費を自動算出します。時間単価5,000円のエンジニアが160時間従事すれば労務費80万円、受注額150万円なら粗利率は約47%と、案件の採算が月次で確認できます。

製品によっては外注費や経費を合算した総原価まで扱えます。どの粒度まで原価を見たいか（案件単位か、工程単位か、タスク単位か）は製品選定の分岐点になるため、要件として先に固めておく必要があります。研究開発税制で兼務エンジニアの人件費を試験研究費に按分する場合は、研究テーマと工程区分の粒度まで必要になります。その記録項目は[研究開発税制とソフトウェア開発費が対象になる条件](https://www.issoh.co.jp/column/details/18218/)で解説しています。

### 勤怠・給与・会計システムとのデータ連携でつくる二重入力のない運用

工数管理システムは単体で完結せず、勤怠管理システムから総労働時間を取り込んで工数合計と突き合わせ、算出した労務費を会計システムへ引き渡す形で真価を発揮します。CSV出力とAPI連携のどちらに対応するか、既存の勤怠・会計製品と直接つながるかは、導入前に必ず確認したい項目です。

連携が取れないと、同じ時間情報を勤怠と工数の両方へ二重入力する運用になり、現場の入力率が下がります。入力率が下がったデータは原価計算の信頼性を失い、システム全体が形骸化するため、連携要件は機能一覧の中でも優先度を上げて評価すべき主要な項目です。既存の勤怠側を刷新したうえで工数データと同じ基盤に載せたい場合は、[勤怠管理システム開発](https://www.issoh.co.jp/service/business%5Fsystem/attendance-management/)で打刻・集計と工数入力を一体で設計する相談も受け付けています。

## 導入で解決できる採算課題と「工数管理は意味ない」に陥る失敗パターン

工数管理システムの導入効果は採算の可視化に集約されます。ただし入力が定着しなければ効果はゼロになり、「工数管理は意味がない」という評価に変わるのが現実です。効果と失敗要因はセットで理解しておく必要があります。

### プロジェクト別の採算が見えないまま赤字案件を繰り返す課題の解消

受託型のビジネスでは、売上は案件ごとに立つのに原価（特に労務費）は部門単位でしか集計されない、という状態が起きがちです。この状態では決算で利益が出ていても、実は特定の案件が赤字で他の案件が補填している構造に気づけません。

工数管理システムを入れると、案件別の労務費が月次で見えるため、赤字案件を進行中に特定できます。「あの顧客の保守案件は毎月20人時超過している」と分かれば、契約範囲の見直しや値上げ交渉という具体的な打ち手につながります。採算の見える化は、値決めと受注判断の精度を上げる経営情報の基盤です。

### 入力が形骸化して「意味ない」と言われる状態に陥る3つの失敗要因

導入後に形骸化する典型要因は3つあります。第一に入力粒度が細かすぎること。15分刻み・タスク単位の入力を求めると、入力自体が負担になり実態と乖離した「つじつま合わせ」の数字が入ります。第二に、入力した本人に結果が返らないこと。集計が管理部門にしか見えないと、現場は入力する理由を失います。第三に、工数データが個人の評価や叱責に使われること。過少申告や案件付け替えを誘発し、データの信頼性が壊れます。

裏返せば、粒度は1日3〜5件程度の案件単位にとどめ、案件別の採算をチームに公開し、評価には直結させない、という運用設計が定着の条件です。ツール選びより先に、この運用ルールを決めることを推奨します。破綻の構造をより深く知りたい場合は[開発現場で工数管理が破綻する背景と見積もり精度を左右する構造的要因](https://www.issoh.co.jp/column/details/11022/)が参考になります。

### 導入効果を測る指標の置き方と定着までに必要な運用ルールの設計

定着度は感覚ではなく指標で追います。実務で使いやすいのは、入力率（対象者のうち期限内に入力した割合）、入力リードタイム（作業日から入力日までの日数）、予実乖離率（予定工数に対する実績の超過率）の3つです。入力率95%以上・リードタイム2営業日以内を最初の目標ラインに置くと、データが原価計算に耐える品質になります。

運用ルールとしては、締め日（週次または月次）と承認者、未入力時のリマインド方法をあらかじめ決めておきます。導入初月から完璧を求めず、最初の四半期は入力率の改善だけを追う、と割り切ったほうが結果的に早く定着します。他社が導入効果をどの指標で示しているかは、[工数管理ツールの導入事例：6社の公開事例で比べる集計時間の削減幅と原価連携の分かれ目](https://www.issoh.co.jp/column/details/18574/)で実名の事例を並べて比較しています。

## エクセル・単機能ツール・一体型システムの提供形態の比較と選定基準

工数管理の実現手段は、エクセル運用から基幹一体型システムまで幅があります。自社の規模と目的に合わない形態を選ぶと、機能過多によるコスト超過か、機能不足による二重管理のどちらかが起きます。

### エクセル・単機能SaaS・勤怠一体型・ERP型という4タイプの比較表

主要な4タイプの守備範囲と向き不向きを整理すると次のようになります。

| タイプ       | 主な守備範囲       | 原価管理       | 向く組織        |
| --------- | ------------ | ---------- | ----------- |
| エクセル      | 工数の記録と簡易集計   | 手作業で算出     | 数名規模の試行段階   |
| 単機能SaaS   | 工数入力と予実対比    | 案件別に自動集計   | まず定着を急ぐ組織   |
| 勤怠一体型     | 勤怠と工数の同時記録   | 労務費と突合可能   | 労務管理も刷新する組織 |
| ERP・案件一体型 | 受注から請求まで一元管理 | 採算・原価管理の中核 | 案件型の中堅規模以上  |

エクセルは初期費用ゼロで始められる一方、同時編集の衝突、集計作業の属人化、単価情報の管理リスクという構造的な限界があります。[エクセルで工数管理を始める前に押さえたい全体設計の考え方](https://www.issoh.co.jp/column/details/11037/)で述べている通り、試行段階の手段と割り切り、人数が10名を超えたらシステム移行を検討する使い方が現実的です。

### 入力負荷・原価粒度・既存システム適合で絞り込む選定チェック観点

製品比較で最初に見るべきは入力負荷です。1日分の入力が1分以内で終わるか、スマートフォンから入力できるか、カレンダーやプロジェクト管理ツールから作業実績を取り込めるかで、定着率が大きく変わります。機能の多さより先に、この1点を実機のトライアルで確かめる価値があります。

次に原価粒度（案件・工程・タスクのどこまで割れるか）と単価管理（個人別単価・等級別単価・外注単価の扱い）が自社の管理会計に合うかを確認します。最後に確認するのは、既存の勤怠・会計・案件管理システムとの連携可否です。この順で絞り込めば、候補は通常2〜3製品まで減らせます。料金の実額を並べて比べたい場合は[工数管理ツール比較｜料金の実額試算と中小企業向けの選び方](https://www.issoh.co.jp/column/details/11023/)が試算の下敷きになります。

## パッケージ導入と基幹システム連携・受託開発を切り分ける判断基準

工数管理は既製のSaaSが多数ある領域であり、何でも個別開発すべきではありません。ここでは受託開発会社の立場から、あえて「開発しないほうがよい条件」を先に示し、そのうえで開発に踏み込むべき条件を整理します。

### パッケージ導入で足りる条件とスクラッチ開発がむしろ過剰になる場面

次の条件がそろう組織では、単機能SaaSか勤怠一体型の導入で足り、スクラッチ開発は採用しません。従業員がおおむね50名未満、同時進行の案件が月10件程度まで、原価は案件単位で見えれば十分、そして既存システムとの連携がCSVの月次取り込みで許容できる場合です。この規模で個別開発を選ぶと、開発費が数年分のSaaS利用料を上回り、保守の負担も自社に残るため、投資対効果が成立しません。

「自社の業務は特殊だ」という理由での開発判断も、いったん保留すべきです。入力画面や集計軸の細かな違いは、多くの場合パッケージの設定やカスタムフィールドで吸収できます。まず既製品のトライアルで埋まらない差分を書き出し、それでも残る要件だけを開発対象として評価する順序が、費用の過剰を防ぎます。

### 基幹システムや案件管理と統合して原価管理まで踏み込む開発の判断

一方、工数を独立したツールで記録するだけでは要件を満たせない組織があります。典型は、受注・請求・購買・外注管理を担う基幹システムが既にあり、工数由来の労務費を外注費・経費と合算して案件別の総原価と粗利を一元管理したいケースです。共通経費の配賦ルールが自社独自である、承認フローが多段である、といった条件が重なると、パッケージ側の設定では吸収しきれず、二重管理が発生します。

この場合は、基幹システム側に工数入力と原価管理のモジュールを組み込む、または既存の案件管理と工数管理をAPIで統合する個別開発が候補になります。既存資産を生かした段階的な統合の進め方は[基幹システム開発サービス](https://www.issoh.co.jp/service/business%5Fsystem/core%5Fbusiness/)で相談を受け付けており、パッケージ適合性の診断から要件定義に入る進め方も選べます。判断の目安は「工数データを何と突き合わせたいか」であり、突き合わせ先が基幹側にあるなら統合開発、工数単体で完結するならパッケージ導入が原則です。すでにERPを運用している場合に、ERP標準の工数機能で足りるかを分ける粒度・賃率・案件コード・締めの4要件は[ERPの工数管理とは？標準機能で足りる範囲と別立てツール連携の選び方](https://www.issoh.co.jp/column/details/18576/)で整理しています。

## よくある質問

工数管理システムの検討時に寄せられることの多い質問へ、本文の要点を踏まえて簡潔に回答します。

### 工数の単位は人日と人月のどちらで管理すべきですか？

日々の入力は人時または人日、経営報告と見積りは人月と、用途で使い分けるのが実務の定石です。入力を人月単位で求めると精度が粗くなり、逆に見積りを人時で提示すると顧客が金額感を掴めません。システム側は人時で保持し、表示のときに1人日＝8人時、1人月＝160人時（自社の所定労働時間に合わせて調整）で換算する設計にしておけば、両方の要求を1つのデータで満たせます。

### 工数管理システムと勤怠管理システムはどちらを先に導入すべきですか？

勤怠管理システムが先です。労働時間の把握は労働基準法上の義務であり、給与計算にも直結するため優先度が上がります。工数管理は勤怠の総労働時間と突き合わせて初めて入力漏れを検証できるため、勤怠データが整った状態で始めるのが早道です。両方を刷新するなら勤怠一体型を候補に入れると移行が一度で済みます。

### 工数管理はエクセルだけで続けられますか？

数名規模で案件数が少ないうちは続けられます。ただし人数が10名を超えるあたりから、同時編集の衝突、集計の属人化、時間単価という機密情報の管理リスクが顕在化します。月次の集計作業に半日以上かかるようになったら、その工数自体がシステム利用料を上回っている合図なので、移行を検討する時期です。

### 工数の入力を従業員に定着させるにはどうすればよいですか？

入力粒度を1日3〜5件程度の案件単位に抑え、入力結果をチームに公開し、評価や叱責には使わないという3点をルール化します。加えて入力率と入力リードタイムを指標として週次で追い、未入力のリマインドを仕組み化すれば、多くの組織で入力率95%前後まで到達できます。粒度の細かさと定着率は両立しないため、欲張らないことが先決です。

### 工数管理システムの費用はどのくらいかかりますか？

単機能SaaSはユーザー数に応じた月額課金が主流で、少人数なら月数千円台から始められる製品もあります。勤怠一体型やERP型は機能範囲が広がる分、初期設定費と月額の両方が上がります。個別開発は要件次第で数百万円規模からとなるため、まず既製品で埋まらない要件を特定し、開発は差分に限定するのが費用を抑える定石です。

### 小規模チームでも工数管理システムは必要ですか？

受託型・案件型の仕事をしているなら、5名程度の規模でも導入する価値があります。案件別の採算は人数に関係なく発生する情報であり、小規模ほど1件の赤字案件が経営に与える影響が大きいためです。逆に、案件という単位が存在しない定常業務中心の組織であれば、勤怠管理と業務改善の枠組みで足り、工数管理システムは不要と判断できます。

## 関連記事

- [工数の単位とは？人時・人日・人月の換算早見表と1人月160時間の根拠](https://www.issoh.co.jp/column/details/11021/)：単位の換算と160時間という基準値の成り立ちを早見表で確認できます。
- [工数管理ツール比較｜料金の実額試算と中小企業向けの選び方](https://www.issoh.co.jp/column/details/11023/)：ツール単体の料金を実額で試算し、中小企業向けの選び方を掘り下げています。
- [開発現場で工数管理が破綻する背景と見積もり精度を左右する構造的要因](https://www.issoh.co.jp/column/details/11022/)：見積もり精度が崩れる構造要因を開発現場の実務から解説しています。
- [予算管理システムとは？機能・タイプ比較と選び方・個別開発の判断基準を解説](https://www.issoh.co.jp/column/details/15372/)：工数と並ぶ管理会計側の仕組みとして予算の予実管理を扱っています。

---

出典: [工数管理システムとは？工数の単位・機能・勤怠管理との違いと選び方を解説](<https://www.issoh.co.jp/column/details/15378/>)（株式会社一創）
