「今日もMiTERASで退勤を打って、そのあとCrowdLogにも同じ時間を書き写す」
勤怠システムと工数管理システムを両方導入している会社で、社員から一番出る不満はこれです。ツールはちゃんと入っている。でも社員の手元では毎日2回、同じ時間を入力している。この状態、放置していませんか？
この記事は、勤怠SaaSも工数SaaSも導入済みなのに、その間を人が手で埋めている中堅企業向けです。「ツールを入れる段階」ではなく「入れたツール同士をつなぐ段階」の話をします。
こんなお悩みありませんか？
- 勤怠は勤怠で入れる、工数は工数で入れる。同じ出退勤を1日2回入力していて、社員から「どっちが正なんですか」と聞かれる（言われてみれば確かに困る）
- 月末の照合作業で、勤怠の実働時間と工数の合計がズレる。毎月誰かが半日以上かけて突き合わせている
- 入力忘れ・打ち間違いの修正依頼が月末に集中し、経理の締め処理が2〜3営業日遅れる
ツール自体は両方ちゃんと動いています。問題は「ツールとツールの間」に人手の作業が残っていることなんですけど、ここは意外と見過ごされがちな領域です。
Before / After
| Before | After | |
|---|---|---|
| 社員1人あたりの月間入力時間 | 約10時間 | 約0.5時間（95%削減） |
| 転記ミス・打ち間違い件数 | 月3〜5件 | 月0件（100%解消） |
| 月末の締め・突合作業 | 毎月約8時間 | 毎月約1時間（87%削減） |
| 工数データがプロジェクト側に反映されるまで | 1〜3営業日 | 翌営業日の朝には反映（当日自動） |
数字は一例ですが、勤怠と工数を別々に運用している中堅企業では、規模感として近い値が出やすい領域です。
なぜ「ツールを入れたのに二重入力が残る」のか
先にここをほどいておきます。そうしないと解決策がズレます。
勤怠管理の目的は 労基法上の労働時間を正しく記録すること、工数管理の目的は どのプロジェクトに何時間使ったかを把握すること。見ているデータはほぼ同じなのに、法務と経営管理という別々の目的のために、別々のSaaSが発達してきました（そりゃそうなるよね、という歴史的経緯です）。
結果として、多くの中堅企業では次の状態になっています。
- 勤怠システム（MiTERAS）: 法的な記録と給与計算の前段
- 工数管理（CrowdLog）: プロジェクト採算と請求根拠
- その間: 社員1人ひとりの手入力
ここを人が埋めている限り、二重入力と月末の突合は構造的に消えません。
どうやって解決したか
Step 1: 「どちらが正か」を決める
最初にやるのは技術の話ではなく、運用ルールを決めることです。
ある中堅製造業のケースで実際に決めたのは、「勤怠システム側を正とする」というルールでした。出退勤時刻は勤怠側で打刻され、それが法的な記録になります。工数側のプロジェクト別内訳は、勤怠の合計と一致していなければいけないわけです。
「勤怠と工数でズレた数字が出たときに、どっちを信じるかで毎回議論していました。先にルールを決めたら、あとはシンプルでした」
バックオフィス担当者の方はこう振り返っています。この一言を先に決めるかどうかで、後のシステム設計の迷いが大きく減ります（逆に言うと、ここが決まらないままツールを選ぶと何度もやり直すことになる、というあるあるです）。
Step 2: アプローチの選定
ツール間の二重入力を解消するには、大きく3つの選択肢があります。
| 選択肢 | メリット | デメリット | 判定 |
|---|---|---|---|
| 工数管理をやめて勤怠側で代替 | SaaSが1つで済む | プロジェクト別集計ができなくなる。請求根拠が崩れる | — |
| 勤怠と工数を1つのSaaSに統合して乗り換え | 理論上は二重入力がなくなる | 現場の運用を全部作り直し。1年がかりの大プロジェクトになる | — |
| 既存の2つのSaaSを使ったまま間だけ自動連携 | 今の運用をほぼ変えずに済む。現場の負担が小さい | 連携部分の作り込みが必要 | 採用（◯） |
3つ目を選ぶ企業が多いのは、「今の運用を壊さず、差分だけ手当てする」という判断が、中堅企業の経営判断としてリスクが小さいからです。既存のシステムを活かしたまま、データの橋渡しの部分だけを自動化するアプローチなら、大きなリスクなく始められます。
Step 3: 導入の流れ
実装は要件が整っていれば4〜6週間で立ち上がります。
- 業務フローの棚卸し（1週間） — 誰が、いつ、どちらのツールに、何のために入力しているかを図にする
- 連携ルールの確定（1週間） — どちらが正か／勤務区分のマッピング／休憩時間の扱いを決める
- 連携の構築と検証（2〜3週間） — 勤怠データを工数側に自動反映する仕組みを作り、過去1ヶ月のデータで精度確認
- 本番稼働と並走（1〜2週間） — 最初の1ヶ月は手入力と並走し、数値が一致することを確認してから切り替え
大事なのはStep1-2です。ここを飛ばして「とりあえず連携を作ってみる」と、月末の突合作業がむしろ増えることがあります（ツールを増やしたのに作業が減らない、という残念な結末）。
技術者向け: 実装の概要
勤怠システムのAPIから日次データを取得し、工数管理システムのAPIへ出退勤・休憩時間を自動連携するブリッジを構築します。
| 項目 | 構成 |
|---|---|
| 連携方式 | 日次バッチ（深夜帯に自動実行） |
| データソース | 勤怠システムのDailyAttendance相当データ |
| 反映先 | 工数管理システムのタイムシート |
| 重複防止 | 処理済みフラグで再実行時の二重登録を防止 |
| 運用 | エラー時はログと通知で原因特定 |
既存のAPIの範囲で完結するため、勤怠・工数どちらのSaaSも設定変更は最小限で済みます。技術的な詳細は 勤怠の二重入力を95%削減する方法 にまとめています。
導入効果まとめ
| 指標 | 成果 |
|---|---|
| 月間入力時間 | 10時間/人 → 0.5時間/人（95%削減） |
| 転記ミス | 月3〜5件 → 0件（100%解消） |
| 月末の締め作業 | 8時間/回 → 1時間/回（87%削減） |
| 工数反映の速度 | 1〜3営業日 → 翌営業日（当日自動化） |
| 年間コスト削減目安 | 社員30名規模で年間約280時間分の人件費に相当 |
「『同じ時間を2回書き写す』という作業がなくなっただけで、月末の空気がまるで変わりました。経理の締めが1営業日以上早まったのが一番ありがたいです」
経営管理ご担当者の方のコメントです。数字以上に、月末にピリピリしていた空気が和らいだ、という定性的な効果が大きいと言われることが多い領域です。
あなたの会社でも始められます
ここまで読んで「うちの会社に当てはまりそう」と感じた方へ、判断の目安を3つだけ置いておきます。
- 勤怠SaaSと工数SaaSを両方導入済みで、どちらかをやめる予定がない
- 社員数30名以上で、月末の突合作業に半日以上使っている
- 現場を止めずに改善したい（全社一斉リプレースはリスクが大きすぎる）
このどれかに当てはまるなら、今の2つのSaaSを活かしたまま、間だけをつなぐアプローチが費用対効果で一番合いやすいです。逆に、勤怠がまだExcelの段階であれば、先にそちらを片付けたほうが順番として効きます。勤怠管理のExcel集計を脱却した方法 と 工数集計をExcelから卒業した事例 の2記事が、そのまま地続きの話になります。
「どこから手をつけるか判断がつかない」という段階でも大丈夫です。まずは今の勤怠と工数の入力フローを書き出してみて、どこにムダがあるか一緒に整理するところから始めませんか？
