工数管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

工数管理システム開発は、業務の整理から定着まで、6つのフェーズを順に進めます。この進め方なら、入力率とデータ活用を改善しやすくなります。

開発の全体像、フェーズごとの内容、費用相場、見積もりの確認点を、順に見ていきます。

▼全体ガイドの記事
・工数管理システム開発の完全ガイド

工数管理システム開発の全体像

工数管理システムを中心に、案件やタスク、予定と実績、原価や粗利、リソース負荷がつながる図。
入力した工数が、採算や負荷を確かめる材料へつながります。

工数管理システムは、作業時間を記録し、予定と実績を同じデータで比べられるようにする基盤です。案件、プロジェクト、WBS、タスクごとに工数を管理します。

そのデータからは、人件費と原価、粗利を確かめられます。さらに、リソース負荷や納期遅延の兆候も判断できます。

工数管理システムの定義

工数管理システムは、従業員がどの案件や作業に、いつ何時間使ったかを記録して、予定と実績を分析する業務システムです。

タイムカードは出退勤の事実を扱うのに対し、工数管理は勤務時間を案件やタスクへ配分します。勤怠やプロジェクト管理と連携すると、記録を経営判断に生かせます。請求・会計や原価管理との連携も、同じ目的で役立ちます。

勤務時間を案件に配分して経営判断に生かすには、入力から締め、集計・連携までを一通りそろえる必要があります。機能ごとの中身は、下の項目で確認できます。

  • 記録:案件・プロジェクト・タスクのマスタと日次・週次入力
  • 管理:予定実績比較、上長承認、締め処理、修正履歴
  • 集計・連携:部署・案件・担当者別集計、CSV・API
  • 受託開発会社やSIer:勤怠時間との突合、案件別の労務費・粗利の確認、予算超過通知や資産計上用データの出力を、要件に含めることがあります

開発の成功の判断基準

成功は、正確なデータが集まり、意思決定にかかる時間が短くなったかどうかで判断します。また、導入前の現状値を2〜4週間測っておくと、稼働後の改善を評価しやすくなります。

目標は、役割ごとに使う指標と会議を決めて設定します。数字で測れる基準にしておくと、稼働後に達成したかを確かめられます。

  • 入力率:目標は95%以上
  • 未入力通知:翌営業日に通知する
  • 月次締め:5営業日から2営業日への短縮
  • 予実差:予定工数を20%以上超えた案件を翌週までに確認する
  • 採算確認:月次会議での案件別粗利の参照

経営層は採算と稼働率、プロジェクトマネージャーは予実差・負荷・納期を重視します。また、現場は入力時間とスマートフォン対応を、経理は原価計算と締めを確認します。

情シスは、権限、API、監査ログを確認します。全社共通の画面を先に作るより、誰がどの会議で数値を使うかから逆算するほうが、使われない画面を減らせます。

ポイント

工数が予定と実績を同じデータで比べられる形で残るかを、まず確かめます。成功の基準を役割ごとに決めておくと、後の要件や方式の検討で迷いにくくなります。

工数管理システム開発の進め方|6フェーズ

画面から先に開発を進めると、入力単位や案件の分け方、勤怠との関係、締め後の修正が曖昧なまま残り、データの意味がそろわなくなることがあります。

そこで、業務ルールとシステム機能を一緒に固めながら、次の6フェーズで進めます。

フェーズ1:要件整理|現場観察とデータ定義

要件を書く前に、現状の業務を観察します。Excel、紙、チャット、口頭、勤怠、会計ソフトの情報が、どこで発生するかを追います。そのうえで、誰が転記や承認をし、何を見て判断するかを業務フローにまとめます。

現場には、入力したくない項目や後から修正する場面、案件とタスクの区別を聞きます。こうした質問を重ねると、仕様書に出にくい例外が見つかります。

未決事項は一覧にして、仮定のまま開発に進まないようにします。要件整理では、利用者の範囲から導入後の評価まで、5つの観点で確かめます。

  • 利用・登録:対象者数、部署、案件・タスク登録の責任者
  • 入力・勤怠:日次・週次の単位と時間の突合方法
  • 承認・修正:承認者、締め日、締め後の権限と履歴
  • 連携・帳票:会計・ERP・請求との接続と必要な出力
  • 管理・評価:個人情報、権限、導入後に見るKPI

データモデルでは、社員・所属・雇用区分・単価を定義します。顧客・案件・契約、プロジェクト・WBS・タスクも、同じ段階で決めます。時間の記録では、予定工数と実績工数、休暇、非稼働を扱います。さらに、承認状態・締め日・修正理由も対象です。

作業名を自由入力にするか、選択式のマスタにするかも決めておきます。自由度が高すぎると表記揺れが増え、厳格すぎると入力が止まってしまいます。そこで、必須項目と任意項目を分けておきます。

フェーズ2:方式・開発会社の選定|標準化と独自性の切り分け

方式と開発会社は、同じ基準で比べます。観点は5つあり、方式の選び方から提案の具体性までを見ます。

  • 方式:標準機能中心ならSaaS、既存基盤の拡張ならパッケージやクラウド
  • 独自要件:独自の原価計算、複雑な権限、特殊な現場入力、外販には部分カスタマイズまたはスクラッチを検討
  • 費用:3〜5年分の利用・開発・運用・将来改修を含めて比較
  • 提案:同じRFPで前提、対象外、追加費用、体制、成果物を照合
  • 提案の具体性:「柔軟な対応」は画面、権限、連携、納品物で確認

SaaSを比べるときは、料金として月額、最低利用人数、追加ストレージを見ます。運用面では、APIやサポート、導入支援、解約時の出力も含めます。

スクラッチは、要件定義から移行、教育、保守まで工程全体を含めます。また、基盤や脆弱性対応、改修も対象に入れます。50名から3年後に300名へ増えるなら、課金や性能上限も見積もります。

要件定義に責任者とエンジニアが加わるか、移行担当は誰か、稼働後の窓口はどこかも確かめます。

フェーズ3:設計・開発|入力時間の目安と連携の境界

設計・開発では、入力のしやすさと、勤怠との境界を決めます。会計との連携や納品物も、この段階で固めます。

勤怠は勤務時間、工数は案件への配分を記録します。役割が違うため、両者のデータは同じではありません。

入力画面から会計・ERPとの連携まで、決める内容は5つあります。

  • 入力画面:スマートフォン・PWA、前日コピー、カレンダー・タイマー候補に対応
  • 確認操作:現場代表者が画面モックを操作し、自動推測、1件1分以内の入力、案件検索、修正理由を試す
  • 基本構成:WebアプリとRDBを基本にし、REST APIまたはCSVで連携します。SSO、RBAC、監査ログ、バックアップ、監視も組み合わせます。
  • 勤怠連携:取込時点、休憩・休暇、超過警告、確定後の修正履歴を明文化
  • 会計・ERP:締め済み工数を原価計算へ送り、締め後は差分と理由を再連携

API項目、文字コード、タイムゾーンは、設計書に残しておきます。あわせて、再送と重複防止、停止時の手動運用も書き残します。

納品物として、ソースコードか設定一覧のほか、API仕様とデータ定義を受け取ります。バックアップと復旧の手順も、納品物に含めます。

フェーズ4:テスト|業務シナリオとデータ品質の検証

実際の1か月を想定した業務シナリオを使い、表示とデータ品質を検証します。

  • 業務の流れ:案件・メンバー・予定の登録から、入力、差戻し、休暇、勤怠突合、締めまで
  • 例外・権限:締め後修正と会計連携、退職者停止が対象です。未入力・超過・重複、API停止等も試します。
  • 受入条件:勤怠差異、承認待ち一覧、修正履歴、CSV合計、他部署単価の閲覧防止

通信が切れた場合や、権限外の閲覧も試します。仕様書には、前提データと操作、期待結果を書きます。実績や担当者、再テスト結果も残します。

口頭の「問題なし」だけで、テストを完了扱いにしないようにします。

フェーズ5:稼働|小規模な開始と移行影響の抑制

本番は全社一斉に始めるより、1部署か1〜3案件で1〜2か月試す方が安全です。準備と確認では、5つの項目を押さえます。

  • パイロット:入力時間と未入力率、承認滞留を追います。マスタ不足、勤怠差異、集計時間も対象です。
  • 旧データ:Excelは比較用に限定し、システムとの差の理由を確認
  • 移行対象:分析・会計・監査に必要な期間と参照データを分ける
  • 移行検算:コードやタスク名、単価、期間、単位を整えます。その後、件数・時間・欠損・重複を照合します。
  • 初日準備:窓口、障害連絡、締め時刻、暫定Excel、権限申請を周知

移行元と移行先の対応表を作ります。そのうえで、責任者、修正期限、再移行の条件を、発注者と開発会社で合意します。

役割別の短いマニュアルを用意します。管理者にはマスタ登録と承認、現場には入力と修正、経理には締めと出力を、それぞれ説明します。

フェーズ6:定着|入力率とデータ活用の改善

入力しない人を責めるより、入力しにくい原因を取り除くほうが定着につながります。日次・週末入力、休暇・社内会議、未登録案件の依頼先は、ルールとして決めておきます。

  • 通知:未入力を本人・上長のどちらへ送るか決め、多すぎて無視されない頻度に調整
  • 月次確認:入力率、締め日数、差戻し率、勤怠差異を見ます。集計時間、予実差、閲覧数も含めます。
  • AI活用:入力候補、長時間工数の検知、会議用レポートの下書きを補助にする

40〜50名規模で、各部署長がマスタを設計し、1〜2か月で全社の工数を見える化した事例があります。ただし、数字をそのまま基準にはせず、自社の導入前後で比べます。

AI機能は、データ品質を整えたあとに導入する順番が適しています。また、AIの最終承認は人が行います。紙や口頭、FAX、Excelの二重管理が残ると不正確なデータを処理することになるため、先に業務を洗い出し、項目をそろえます。

ポイント

迷ったときは、画面より先に業務ルールとデータの意味を決めます。例外の扱いや締め後の修正を稼働前に決めておくと、後の手戻りを減らせます。

工数管理システムの費用相場とコストの内訳

SaaS、パッケージ・クラウド拡張、部分カスタマイズ、フルスクラッチの初期費用レンジを並べた図。
方式の選択に応じて、初期費用のレンジが広がります。

費用は、ユーザー数や入力・承認の複雑さで変わります。さらに、既存システムとの連携、データ移行、セキュリティ、運用支援の範囲でも変わります。

ここに示す金額は、業務・プロジェクト管理システム全般の目安と公開価格例をもとにした、初期検討の幅です。工数管理専用の一律料金ではないため、要件定義のあとに補正してください。

方式別の費用相場

方式別の初期費用、月額、開発期間の目安は、後ほど一覧にまとめます。

NotebookLMの調査では、業務システム全般の小規模は10万〜500万円で3〜6か月、中規模は500万〜5,000万円で6か月〜1年とされています。

大規模は、5,000万円〜数億円以上で、期間は1年以上です。この目安は周辺業務や大規模連携を含むものなので、工数入力だけの案件にはそのまま当てはめないでください。

  • SaaS:初期0〜50万円、月額無料〜数千円・ユーザー。法人向けは月10万〜20万円台の例もあり、導入1〜3か月
  • パッケージ・クラウド拡張:ライセンス、設定、移行、連携、教育込みで100万〜1,000万円、3〜6か月
  • 部分カスタマイズ:500万〜5,000万円、6か月〜1年
  • フルスクラッチ:1,000万円〜数億円以上、6か月〜数年

Lychee Redmineは、2026年7月の改定後、スタンダードが900円、工数・予算管理を含むプレミアムが1,400円、ビジネスが2,100円です。いずれも1ユーザー・月あたりで、別途クラウド利用料がかかります(出典:Lychee Redmine公式料金ページ、2026年7月改定の公式情報)。

TeamSpirit工数は、基本サポート込みで月18,000円からです。料金は利用ユーザー数で変わります(出典:TeamSpirit公式価格ページ、2026年8月確認の公式情報)。

クラウドログのジョブカン勤怠管理連携には、月125,000円からという公開例があります。ただし、これは2023年の公式発表例で、人数により変わるため、現在の条件は見積もり時に確認してください。

初期費用以外にかかる費用

初期費用のほかにも、主な費用がかかります。方式ごとの確認点とあわせて見ておきます。

  • 導入・連携:移行、外部サービスのAPI利用料、SSO・多要素認証、スマートフォン対応、研修、問い合わせ
  • 運用:クラウド、監視、脆弱性対応、機能追加、バックアップ、解約時の返却
  • 保守:スクラッチは初期開発費の年10〜20%程度の例があり、範囲や時間外対応で変動

SaaSの月額に更新や基盤運用が含まれる場合は、同じ費用を二重に計上しないよう注意します。

50名が1人月額1,400円なら、ライセンス費は月7万円です。導入支援、クラウド、初期マスタ、移行、連携、教育は、ライセンス費とは分けて確認します。

300名へ増えた場合の月額、休職者や閲覧専用ユーザーの扱い、最低契約数も確かめます。初年度、3年、5年の総額を並べると、方式を比べやすくなります。

ポイント

費用は初期費用だけでなく、3〜5年の総額で方式を比べます。見積もりは要件定義のあとに補正して使うと、判断のずれを小さくできます。

見積もりを取る際のポイントとチェックリスト

見積もり条件として、利用人数や案件数、承認経路、連携先、過去データ、セキュリティ、希望時期、予算、保守範囲を示すチェックカード。
前提条件をそろえると、各社の提案範囲を照合しやすくなります。

見積もりの差は、開発会社の単価だけでなく、前提条件からも生じます。機能一覧だけでは、「どこまで作るか」の解釈が各社で変わります。

RFPには、利用人数、部署、案件数、入力頻度、承認経路を記載します。連携先、過去データ、セキュリティ、希望時期、予算、保守範囲も記載し、同じ条件で提案を求めます。

RFPと要件表に記載する内容

RFP、要件表、見積書には、比較や検収に必要な情報を分けて書きます。

  • RFP:背景、業務、困りごと、利用者・権限、データ、画面を書きます。連携、非機能、移行、教育、保守、日程も含めます。
  • 要件表:「必須」「できれば」「将来検討」を分け、必須機能に受入条件を設定
  • 見積書:要件定義、UX・画面、開発、API、移行を分けて示します。テスト、教育、管理、クラウド、保守も含めます。

たとえば、勤怠連携では、取込時刻や超過通知の宛先、承認前の修正の可否まで定めておくと、各社を比べやすくなります。

「作業一式」とだけ書かれた見積もりは、追加費用が生じやすいので注意が必要です。そのため、各社に、ユーザー、画面、連携、データ件数を具体的に示してもらいます。環境や納品物、検収条件、変更管理の単価と手順も確かめます。

開発会社の比較基準

開発会社は、価格に加えて、実績や体制で比べます。移行・連携、保守、セキュリティ、契約条件も、比べる材料になります。

  • 開発力:近い業務の実績、要件定義の進め方、担当者の経験、連携実装
  • 運用力:移行支援、保守、障害時の目標復旧時間、データ返却形式
  • 契約:成果物、権利、第三者ライセンス、再委託を定めます。脆弱性、バックアップ、SLA、解約出力、追加単価も含めます。

候補の会社には、現場ヒアリングの参加者、提案後の担当変更、開発中の実機確認についても質問します。

SaaSの場合も、CSV出力項目、API料金、削除までの猶予を確かめます。また、乗り換えを想定しておくことは、事業継続のための通常の要件です。

法令・セキュリティ要件は、労務記録から電子帳簿、クラウド管理まで、分野ごとに確認します。

厚生労働省は、時間外労働の上限を原則として月45時間・年360時間と定めています。特別条項にも、年720時間や単月100時間未満、複数月平均80時間以内といった基準があります(出典:厚生労働省「時間外労働の上限規制」、2026年確認の公式情報)。

勤怠打刻、客観的ログ、36協定、申請・承認、工数配分の管理データは、社労務担当と切り分けます。

  • 個人情報:責任者と範囲、権限を定めます。ログ、委託先、事故連絡、保存・削除も決めておきます。
  • クラウド:SSO・多要素認証、IP制限、暗号化、保存地域、脆弱性・事故対応の扱い
  • データ管理:監査ログとデータ返却条件の確認

個人情報保護委員会の通則ガイドラインは、事業規模や個人データの性質・量に応じた措置を示しています。出典は、同委員会の「個人情報保護法ガイドライン(通則編)」です(2026年確認の公式情報)。

電子帳簿保存法の対象範囲は、税務担当と確かめます。訂正・削除履歴や検索、閲覧が必要になる場合があります。ダウンロードやバックアップ、保存期間も、確認の対象です。

CSVで保存するだけでは、不十分な可能性があります。出典は、国税庁の「電子帳簿保存法の概要」と「優良な電子帳簿の要件」です(2026年確認の公式情報)。

ポイント

見積もりを比べる前に、利用人数や承認経路、連携先などの前提をそろえます。前提がそろってはじめて、各社の提案範囲を照合できます。

工数管理システム開発でよくある質問(FAQ)

判断するときは、規模だけでなく、業務の標準化度、連携数、入力者数、原価計算の複雑さも踏まえます。

工数管理システムはSaaSとスクラッチのどちらが良いですか?

標準的な入力や承認を早く始めたいならSaaS、独自の原価計算や複雑な連携が競争力に直結するならスクラッチが向いています。

標準部分はSaaSやパッケージで試し、差別化の部分だけをカスタマイズする方法もあります。3〜5年の総額、変更の自由度、移行のしやすさを含めて考えます。

工数管理システムの開発期間はどのくらいですか?

SaaSの初期設定は1〜3か月、パッケージやクラウド拡張は3〜6か月が目安です。部分カスタマイズは6か月〜1年、フルスクラッチは6か月〜数年です。

期間は、要件の不確定さや連携、移行、テスト対象、社内の意思決定の速さで変わります。対象部署と必須機能を絞り、パイロット後に広げると、期間を短縮しやすくなります。

勤怠管理と工数管理は同じシステムにすべきですか?

勤怠と工数は、同じ製品でなくても構いませんが、差異を確認できる連携は設けておきます。勤怠は勤務時間、工数は案件への配分を記録します。

別システムでも、責任者や取込時刻、休憩・休暇、承認、締め後の修正をそろえれば運用できます。既存の勤怠を変えない場合は、APIまたはCSVで接続し、正とするデータを決めます。

過去のExcel工数データはすべて移行すべきですか?

過去データは、すべてを移すとは限りません。会計・監査で必要な期間を決め、参照用のデータと、継続して使うマスタを分けます。

移行する場合は、案件と社員のコードの対応表、工数の合計、欠損、重複、単位を検算します。移行しないデータについては、保管場所と閲覧権限も決めます。

ポイント

規模だけで決めず、業務の標準化度や連携数、入力者数、原価計算の複雑さを合わせて判断します。期間は対象部署を絞って始め、パイロット後に広げる形で短くできます。

まとめ

開発前に押さえる要点

工数管理システム開発では、画面より先に、現場業務と経営判断をつなぐデータを定義します。Excelや紙、チャット、勤怠、会計の流れを整理したうえで、方式を3〜5年の総額で比べます。

導入後まで見据えた次の一歩

導入後まで見据え、次の流れで段階的に進めます。

  1. 要件の整理と、方式・開発会社の選定
  2. 設計・開発後のテスト(業務シナリオとデータ品質)
  3. 1部署または1〜3案件で1〜2か月試し、入力時間と品質を見る
  4. 勤怠差異、移行責任、修正履歴、権限・監査ログ、データ返却条件の見積もりと契約への明記
  5. 標準機能と独自開発の範囲の切り分け、締め短縮、予実差、集計時間、案件採算の活用の確認

▼全体ガイドの記事
・工数管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。