工数管理システムの発注は、業務の洗い出し、方式と要件の決定、提案と契約、導入と定着の順に進めると、業務成果につながりやすくなります。
発注形態の選び方、RFPと契約の整え方、費用相場、委託先の選び方、品質と定着を取り上げます。全体像は工数管理システム開発の完全ガイドにもまとめています。
▼全体ガイドの記事
・工数管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
工数管理システムの発注前に押さえる全体像
工数管理システムは、案件やタスクに使った時間を記録し、予定と実績の工数、人件費、原価、採算を見えるようにします。
タイムカードだけでなく、プロジェクト管理や勤怠とつなぎます。さらに、請求や会計ともつなぎ、経営、管理、現場が同じ事実を見られるようにします。また、発注の前に、何の判断に使うデータを誰がいつ確定するかを決めておきます。
SaaS・パッケージ・スクラッチの違い
入力、承認、レポートが標準化されている企業なら、SaaSは期間と初期費用を抑えやすい方式です。
- SaaS：標準機能を月額で使うため、導入期間と初期費用を抑えやすい方式です。
- パッケージ・クラウド拡張：標準機能に設定や追加開発を組み合わせて使います。
- フルスクラッチ：画面やデータモデルを業務に合わせて作るため、自由度は高くなります。
SaaSでは、独自の原価計算や複雑な権限を標準仕様に合わせる必要があります。一方で、スクラッチは要件定義、テスト、保守の責任が大きくなります。
部門ごとの発注目的と評価軸
RFPの優先順位を分けるには、部門ごとに何を目的とし、導入で何が変わるかを把握しておきます。
- 経営層：案件別粗利や稼働率を重視します。
- プロジェクトマネージャー：予実差とリソースの偏りを見ます。
- 現場・経理・情シス：入力、原価と締め処理、権限・API・セキュリティを重視します。
要望を同じ優先順位で並べると費用が膨らみやすいため、必須、希望、将来検討に分けます。
部門別のKPIも設定します。
発注の成否を左右するデータ品質と運用設計
開発の前に、データの扱いと日々の運用ルールを決めておきます。
- 表記と入力：案件名や作業名、入力単位、締め日をそろえます。
- 権限と突合：修正の権限や、勤怠と工数が合わない場合の扱いを決めます。
- 業務の洗い出し：紙、口頭、チャット、Excelの二重管理を確認します。
未整理のまま画面だけを導入すると、不正確なデータを速く集計するだけになります。
AXの視点で、不要な業務やカスタマイズも見直します。
発注形態の選び方
標準的な業務を早く始めたいならSaaS、既存業務や会計と一部だけ合わせるならパッケージやクラウド拡張が候補です。
独自の原価計算や複雑な連携が競争力に直結するなら、受託開発を検討します。
会社の規模だけでなく、利用者数や案件の種類も評価します。加えて、勤怠・会計との連携、3〜5年の総保有コスト、社内の運用担当者も見ます。
SaaS導入に向く企業
SaaSは、導入と全社展開を段階的に進めるのが基本です。その際、契約の前にデータの出し方や料金の条件も確認しておきます。
- 導入準備：アカウント、マスタ、権限、移行、教育を整えます。
- パイロット：1部署または1〜3案件で1〜2か月試します。
- 契約確認：CSV出力、API、解約時のデータ返却、最低人数、初期設定費用を確認します。
試行中は、未入力率、承認の滞留、集計時間を見てから全社に展開します。また、将来の乗り換え条件も契約前に確かめておきます。
パッケージ・クラウド拡張と既存業務の折り合い
標準に合わせる業務と、変えられない業務を分けて、拡張の範囲を決めます。
- 標準機能：基本機能を使い、設定で業務に合わせます。
- 追加開発：項目、ワークフロー、帳票、API連携を追加します。
フルスクラッチより早く業務に合わせられる場合があります。ただし、標準アップデートの影響調査と保守担当は、受託先に確認しておきます。
スクラッチ開発の独自性と長期責任
独自業務への適合度だけでなく、開発後の保守や引き継ぎまで含めて採否を判断します。
- 適する例：標準製品では業務を変えすぎる場合で、複雑な権限や独自単価などが該当します。
- 代替を検討する例：画面の色や帳票の変更なら、設定や拡張で足りる可能性があります。
開発費に加えて、障害・脆弱性対応、OS・ミドルウェアの更新、担当者の交代も予算に入れておきます。そのうえで、ソースコードと設計書の引き渡し方法も決めます。
工数管理システム開発の発注・外注の進め方
工数管理システムの発注は、機能一覧を開発会社へ送る前に、現状把握、目的とKPIの定義、RFP作成から始めます。その後は、提案依頼、要件定義、設計・開発と進み、テスト、移行、定着の順になります。
業務を説明できる責任者を置き、経営、現場、経理・情シスの判断をまとめておくと、後からの追加費用を抑えやすくなります。
現場観察とKPI定義
現在の入力経路を洗い出し、導入の目的を測定できるKPIに置き換えます。
- 現状確認：Excel、表計算、紙申請、チャット、勤怠、会計を並べて見ます。
- 目的の例：案件別粗利の月次確認、締め日前の未入力の把握、週次の予実差の検知です。
- KPI：入力率、入力時間、承認日数、集計時間、予実差の把握件数を測ります。
同じ情報を何度も入力していないかも確認します。
KPIを決めておけば、機能の多さだけで選ぶことを避けられます。
RFPに書く業務・データ・連携・運用
提案の条件をそろえるため、業務とデータ、連携、運用について具体的に書きます。
- 業務・データ：人数、組織、案件数、案件・WBS・タスクの階層、入力単位、締め日、承認者、権限、予定と実績の比較、単価と原価です。
- 連携・移行：勤怠、給与、会計、ERP、販売管理、Slack、Teams、カレンダー、移行範囲です。
- 非機能：スマートフォン、SSO、多要素認証、監査ログ、バックアップ、目標復旧時間です。
「使いやすく」と書くより、「スマートフォンで1日分を数分以内に入力できる」のように検証できる条件にします。
パイロットと段階導入によるリスク低減
1部署または1〜3案件で試し、入力から会計連携までの流れを確かめます。
- 運用確認：案件マスタ、未入力の催促、差し戻し、月末締めを試します。
- 連携確認：勤怠との不一致や、会計への連携を確かめます。
- 原因分析：入力項目、案件コード、承認者などの問題を分けて調べます。
問題が出た場合は、製品や現場だけの問題と決めつけず、原因に応じて改善してから展開します。
移行・教育・運用改善の開発範囲
移行の対象を絞り、研修や運用改善まで契約と計画に含めます。
- 移行設計：期間、項目、案件コードの対応、重複・欠損、移行後の検算を決めます。
- 保存範囲：会計・監査・分析に必要なデータを移し、古いデータは別保存も検討します。
- 定着支援：マスタ研修、入力練習、締めのリハーサル、問い合わせ窓口、改善会議を計画します。
マニュアルを配るだけでは定着しにくいため、管理者と現場の双方に、実地で練習する機会を設けます。
契約形態と委託先との責任分界の決め方
契約は、完成の責任を重視するか、専門家の支援と変更への柔軟性を重視するかで選びます。
要件が固まっていない企画と、確定後の開発は分けて考えます。
契約書や仕様書、見積書をそろえ、受入基準と変更管理表も用意します。そのうえで、決定者、納品物、検収の時点を明確にします。
要件整理や伴走支援に向く準委任契約
変更が多い工程では、支援の範囲と成果の確認方法を契約で明らかにします。
- 向く業務：現状分析、要件定義、プロジェクト管理、アジャイル開発、SaaS設定支援です。
- 契約で決めること：会議体、成果物、報告、品質基準、月の上限、追加作業の承認です。
準委任は、専門家の業務支援に報酬を支払う契約です。稼働時間や担当範囲だけを見ていると、完成した画面や連携の状態が分からなくなるおそれがあります。
請負契約の前提となる仕様と受入基準
成果物の仕様と受入基準を確定し、変更の手続を決めてから、請負を選びます。
- 向く業務：画面、DB、API、帳票の開発や、範囲を定めた移行作業です。
- 受入条件：テスト項目、性能・セキュリティの基準、修正の範囲、検収期限です。
- 変更手続：仕様変更の単価と承認方法を先に定めます。
請負は、合意した仕事の完成と、成果物の引き渡しに対する契約です。要件があいまいなままでは、品質や費用が自動的に安定するわけではありません。
納品物・知的財産・再委託の責任範囲
納品物や知的財産、データ管理は、契約で定めます。再委託や契約終了後の移行も、契約で定めておきます。
- 納品物：要件、画面・データ設計、テスト、API定義、設定、コード、復旧手順、運用マニュアルです。
- 権利と終了時：著作権・利用権、OSS、環境のアカウント、データの返却・削除、移行支援です。
- 委託管理：安全管理、再委託先、監査、事故時の報告を定めます。
個人データを扱う場合は、個人情報保護委員会のガイドラインに沿った安全管理を契約に含めます。
工数管理システムの費用相場と見積の内訳
価格は、利用者数や標準機能の範囲、移行や連携の量によって変わります。独自計算やセキュリティ、保守の範囲も、価格に影響します。
ここに示す金額は初期検討の目安で、専用開発の価格を保証するものではありません。
初期費用と月額を分け、3〜5年の総額で比べます。
方式別の費用レンジ
方式ごとの初期費用と継続費用を合わせて、自社の候補を比べます。
- SaaS：初期0〜50万円程度、1ユーザー月額無料〜数千円程度の例があります。
- パッケージ等：ライセンス、設定、移行、連携、教育込みで100万〜1,000万円程度です。
- 部分カスタマイズ：500万〜5,000万円程度が検討レンジです。
- フルスクラッチ：1,000万円から数億円以上まで幅があります。
法人向けSaaSは、導入支援込みで月額10万〜20万円台の例もあります。
業務システム全般の目安は、小規模が10万〜500万円、中規模が500万〜5,000万円、大規模が5,000万円〜数億円以上です。規模の区分は要件と連携数で変わるため、金額だけで方式を決めるのは避けます。
Lychee Redmineの2026年7月改定後の公式プランは、スタンダード900円、プレミアム1,400円、ビジネス2,100円です。いずれもユーザー月額で税別です（出典：株式会社アジャイルウェア「Lychee Redmine料金プラン」、2026年）。
対象プランやユーザー数に加え、クラウド利用料、追加拡張の条件も確認します。
TeamSpirit工数は公式料金ページで18,000円/月からで、初期費用は別途です。利用ユーザー数により変動すると表示されています（出典：株式会社チームスピリット「価格・料金」、2026年）。
見積書の開発費以外の内訳
見積の範囲と追加料金の条件を確認し、金額の根拠を明らかにします。
- 作業内訳：要件定義、UI・データ設計、開発、テスト、基盤、連携、移行、教育、管理、保守です。
- 数量根拠：「一式」は、画面数、API本数、移行件数、テスト件数、作業時間、納品物で確認します。
- 追加条件：人数、容量、API、サポート、休日、診断、再移行、変更費です。
追加費用が生じる条件を別欄で示してもらうと、見積の前提を照合できます。
3〜5年の総保有コスト
初期費用だけでなく、運用中と終了時の費用も含めて投資判断をします。
- 継続費：月額、支援、追加開発、連携、保守、教育、保管、利用者の増加です。
- 保守の目安：受託開発費の年10〜20％程度という試算例があります。
- 比較対象：データ出力や解約後の移行費も含めて、範囲をそろえます。
保守費は、障害対応や改修、基盤費を含む範囲によって変わります。また、SaaSでは、月額に更新と基盤運用が含まれる場合があります。
安価な製品でも、最低人数や初期設定、勤怠連携が別料金なら総額は上がります。データ出力や専用支援も、別料金かどうかで差が出ます。逆に高額でも、集計や二重入力、請求漏れなどを減らし、予算超過の発見遅れも抑えるなら、投資対効果が成り立つ場合があります。
各社の見積は、価格の順位ではなく、同じ業務成果を得るための費用で評価します。
RFP・要件整理と委託先選定のポイント
委託先は、近い業務の実績や体制で評価します。要件定義や連携・移行、保守、解約時の対応も比べます。SaaSと受託開発では、提案の条件や責任範囲が異なります。
同じRFPを送っても、回答の内容が一致しないことがあります。そのため、比較の条件をそろえ、質問への回答も選定の材料にします。
RFPの発注条件と比較基準
業務の成果に沿って要件を書き、各社の提案を比べられる条件にします。
- 背景・範囲：課題、部門、人数、業務、現行システム、時期、予算の考え方です。
- 機能要件：案件・タスク、入力、コピー、タイマー、承認、締め、履歴、集計、CSV/APIです。
- 非機能要件：可用性、性能、バックアップ、権限、ログ、認証、脆弱性、保存地域、障害通知です。
移行や連携、希望日程のほか、提案の成果物も明記します。対象の業務や要件が具体的なら、提案の条件がそろいやすくなります。
委託先の類似実績と担当者の参加
実績の内容と、発注後に実務を担うメンバーの経験を確認します。
- 業務実績：案件原価、勤怠との突合、会計・ERP、現場入力、データ移行です。
- 担当体制：要件責任者、PM、開発・連携、保守の各担当です。
営業担当だけでなく、実際の担当者にも初期の打ち合わせへ参加してもらいます。課題や制約を質問できる体制は、発注後の認識のずれを減らすのに役立ちます。
見積比較の金額・範囲・前提
各社の作業範囲と費用の前提をそろえ、運用の負担まで比べます。
- 対応区分：機能ごとに、標準、設定、追加開発、対象外を示します。
- 確認範囲：移行、テストの責任、教育の回数、保守の時間、窓口、初動、変更単価です。
- 評価項目：適合度、実績、提案、体制、納期、費用、セキュリティ、可搬性です。
勤怠連携をAPIで行うか月次のCSVで行うか、不一致を誰が直すかによって、費用と負担が変わります。価格だけを比べると、後から必要になる連携の追加や、不要なスクラッチを見逃します。
標準で満たせない要件の代替案と、将来追加する際の影響を質問すると、提案の透明性を比べられます。
失敗を防ぐ品質・セキュリティ・定着のチェックポイント
工数管理システムは、勤務実績や案件、原価、請求の情報を扱います。画面が使いやすくても、勤怠や権限、履歴の決め方があいまいだと、監査や労務管理に使えません。
法令の判断は、社労士、税理士、法務などの専門家に確認します。そのうえで、システムに任せる範囲と、人が確認する範囲を分けます。
勤怠と工数を分けた法令対応
法令対応では、勤怠と工数の区分、突合の方法、システムの役割を決めます。
- 記録の区分：工数は案件や作業への配分で、法的な労働時間の記録と同じとは限りません。勤怠打刻や客観ログとは分けます。
- 不一致時の対応：勤怠と工数の合計が合わない場合の、確認、修正、承認を決めます。
- システムの役割：超過アラートや申請を補助できますが、勤怠の法的要件を単独で満たすとは限りません。
厚生労働省は、36協定の時間外労働の限度を、原則月45時間、年360時間と示しています（出典：厚生労働省「時間外労働の上限について」、2026年確認）。
個人情報・会計データ・委託先の安全管理
アクセス権を設計し、安全管理の方法をRFPに書き込みます。認証と暗号化、障害対応、ログなどが対象です。
- 権限：部署、役職、案件、担当、承認者ごとに、閲覧、入力、承認、出力、管理を分けます。
- 対策：SSO、多要素認証、IP制限、暗号化、脆弱性対応、バックアップ、障害・インシデント通知、ログです。
- 委託先管理：安全管理措置と取扱状況を、契約で確認します。
個人情報保護委員会「個人情報保護法ガイドライン（通則編）」（2026年確認）は、委託先の安全管理措置を事前に確認し、契約で取扱状況を把握するよう示しています。
請求書や取引情報を保存する場合は、電子帳簿保存法の範囲を経理と確認します。電子取引には、ネットやメールで取引情報を授受する場合が含まれます（出典：国税庁「電子帳簿保存法の概要」、2026年確認）。
保存要件、検索性、訂正・削除の履歴を検討します。
工数データに一律に適用すると決めつけず、請求・会計データとの境界を要件定義で分けます。
入力定着とAI活用の基礎となるデータ品質
入力の負担を下げる機能を選び、導入後は利用状況に応じて運用を改善します。
- 入力支援：スマートフォン、カレンダー、前回値のコピー、選択式マスタ、タイマーです。
- 通知：SlackやTeamsの通知も検討します。
- 定着の確認：入力率、入力時間、未入力の理由、修正、承認の滞留、表記の揺れ、集計時間を見ます。
入力率が低いときは、催促を強めるだけでなく、項目、マスタ、入力時期を見直します。定期的な利用状況の確認が、改善につながります。
2026年、クラウドログはYoomとのAPI連携を発表しています。SlackやSalesforceなどを起点に、工数の反映や通知を自動化する取り組みです（出典：株式会社クラウドワークス「クラウドログとYoomのAPI連携」、2026年）。
AIとの対話で集計を自動化する方向も選択肢ですが、曖昧な元データでは誤った集計まで自動化されてしまいます。
入力候補、異常検知、レポートの草案から始め、最終承認は人が行います。
よくある質問
発注の際は、方式、費用、RFP、契約、運用のそれぞれで疑問が生じます。判断に迷いやすい点を取り上げます。
自社の業務や法令への当てはめは、社内の責任者や専門家にも確認してください。
工数管理システムはSaaSとスクラッチのどちらがよいですか？
標準の入力やレポートを早く使いたいならSaaS、独自の原価計算や複雑な連携が重要ならスクラッチを検討します。
決めきれない場合は、無料トライアルや1部署での試行で適合度を確かめます。
不足する部分だけを追加開発する方法もあります。
工数管理システムの発注予算はどのくらい必要ですか？
予算は方式によって大きく違います。SaaSは初期0〜50万円程度からの例がある一方、フルスクラッチは1,000万円から数億円以上まで幅があります。
- SaaS：初期0〜50万円程度からの例があり、月額、支援、移行、連携も総額に含めます。
- 部分改修：500万〜5,000万円程度です。
- フルスクラッチ：1,000万円から数億円以上まで幅があります。
利用人数、連携、移行、保守の前提をそろえ、複数社から見積を取ります。
RFPに最低限書くべき項目は何ですか？
まず、利用者と部門、案件・タスクの構造を記します。次に、入力・承認・締めと、勤怠・会計・ERP連携、移行範囲も書きます。
スマートフォン対応や権限、ログ、バックアップも記載します。時期や保守、納品物も含めます。現状の課題とKPIを添えると、業務成果に沿った提案を受けやすくなります。
契約は準委任と請負のどちらを選ぶべきですか？
変更が多い要件整理や伴走支援は準委任、仕様と受入基準が固まった開発は請負が基本です。要件定義を準委任、開発を請負に分ける方法もあります。
契約名だけで決めず、契約書で納品物と品質を確認します。変更や知的財産、再委託、データ返却、障害対応についても、契約書で確かめます。
まとめ
方式を選び、現場の業務とデータを洗い出したうえで、目的とKPI、RFP、要件を整理します。連携や移行も、同じ流れで整えます。契約上の責任や受入基準は、納品物や保守、データの可搬性とあわせて合意しておきます。
この順序で準備すると、開発中の認識差を抑えやすくなります。
比較の基準の「安さ」から「業務成果」への切り替え
初期の開発費以外も含めて、同じ期間と作業範囲で各社の見積を比べます。
- 総額：月額、移行、連携、教育、保守、利用の増加、解約時の移行を含む3〜5年分です。
- 見積の前提：標準、設定、追加開発、対象外、条件を分けます。
- 選定体制：実績、担当者、セキュリティ、障害対応、運用改善も比べます。
見積書の「一式」は、そのまま受け入れず、各費目と作業範囲を明らかにします。
最初の一歩となる小さなパイロットと具体的な相談
1部署または1〜3案件で、入力と承認、集計を試し、勤怠との突合や移行も確かめます。入力率や集計時間を測り、予実差と承認の滞留も見ながら、標準機能と開発範囲を分けます。
業務の背景と将来の運用まで説明できる委託先に相談し、無理のない範囲で始めると、長く使える仕組みにつながります。
▼全体ガイドの記事
・工数管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。