変形労働時間制を導入した後、勤怠管理システムを入れたのに「結局Excelでも確認している」という状況に陥っている担当者は少なくない。勤怠管理SaaSは確かに便利なツールだが、自社の勤務ルールと噛み合わないと、導入前より工数が増える。建設・医療・製造・サービス業など、繁閑差がある業種では特にこの問題が起きやすい。どんな業務実態でミスマッチが生まれ、どこで判断を変えるべきかを整理する。
変形労働時間制で勤怠SaaSの設定が複雑になる理由
変形労働時間制は、1ヶ月または1年単位で所定労働時間を配分し、繁忙期に長く・閑散期に短く働けるよう設計する制度だ。建設・製造・医療・介護・小売といった繁閑差が大きい業種で採用されることが多い。
通常の定時勤務なら残業の判定は単純だ。「1日8時間・週40時間を超えたら時間外」という基準に対してシステムが自動計算する。しかし変形労働時間制では、「その日の所定労働時間」「その週の所定労働時間」「対象期間全体の総所定労働時間」の3つの基準で時間外労働を判定する必要がある。月単位変形では月内のカレンダー管理、1年単位変形では年間カレンダーの事前作成が求められる。
汎用の勤怠SaaSも「変形労働時間制に対応」と表示しているものは多い。ただし、対応の粒度には大きな差がある。標準的なパターンなら問題なく設定できても、就業規則に独自の例外規定が多い場合や複数のシフトパターンが複雑に入り組んでいる場合は、「設定はできたが計算が合わない」という状態になりやすい。
よく起きる3つのミスマッチパターン
パターン①——シフトカレンダーが複雑で初期設定が終わらない
月単位変形労働時間制では、対象期間の所定労働日と所定時間をあらかじめ確定させる必要がある。SaaSは「シフトパターンを登録してカレンダーに割り当てる」仕組みを取ることが多いが、パターンが10種類以上あったり、祝日や行事で月ごとに変動したりする場合、設定作業だけで数日かかる。
「入力項目が多すぎて、年間カレンダーはExcelで別管理しています」という状況に陥ると、SaaSが二重入力のコストになってしまう。
パターン②——パート・アルバイト・正社員が混在して計算ロジックが分岐する
正社員は変形労働時間制、パートは時給で通常勤務、派遣は別契約——という混在は中小企業でも珍しくない。汎用SaaSは雇用形態ごとに設定を切り替えられるが、種類が増えるほど整合性の確認が複雑になる。
特に問題になるのが「同一人物が雇用形態を変更したとき」や「アルバイトが繁忙期に長時間シフトに入る場合の時間外判定」など、想定外のパターンが出てきたときだ。SaaSのマスタ設定変更が想定されていないケースでは、手動対応するしかない局面が生まれる。
パターン③——特別休暇や手当の社内ルールをシステムに反映できない
会社ごとに「〇〇の日は特別休暇扱い」「特定現場への出勤は手当加算」「土曜は半日を所定の基準にする」といった独自ルールが存在することがある。汎用SaaSにはプリセットされていないルールであり、カスタマイズできないか、できても追加費用が発生するケースが多い。
「SaaSに合わせて社内ルールを変えましょう」という提案がベンダーから出ることもあるが、就業規則の変更には労使合意が必要で、簡単には動かせない。
「動いているが合っていない」状態の見分け方
SaaSを導入した後でも以下の状態が続いているなら、ツールが実態に合っていないサインと見た方がいい。
- 月次締め処理でExcelを使って集計値を別途確認している
- 担当者が「システムの数字は参考程度」として手計算で給与を確認している
- 月に1〜2件、システムの集計ミスを手修正している
いずれも「ないよりマシ」という状態で運用し続けているケースだ。給与計算に直結するエラーが毎月起きているなら、未払い残業リスクと担当者の工数の両面で無視できない。
Excelでの勤怠管理が持つリスクについては「Excel・紙管理を放置するリスクと業務アプリ化のタイミング」で整理しているが、「SaaSが合わないためにExcelが手放せない」という問題も、根は同じだ。
汎用勤怠SaaSで「対応できる範囲」の目安
ミスマッチが起きにくいのは、以下の条件が揃う場合だ。
- 変形労働時間制のパターンが月単位かつシンプル（シフト3〜4パターン以内）
- 雇用形態が1〜2種類で、それぞれのルールが明確に分離できる
- 特別休暇・手当の種類が少なく、既存のプリセットで対応できる
- 就業規則が比較的標準的で「例外の例外」が少ない
逆に、これらの条件から外れるほど「対応している」というSaaSでも設定が困難になる。サポート対応・追加カスタマイズ費用が積み上がると、最初に期待していたコストメリットが薄れていく。
業務アプリという選択肢が出てくるケース
汎用SaaSがミスマッチを起こすケースで、「自社のルールに合わせた勤怠管理アプリを開発する」という選択が出てくることがある。
就業規則・シフトルールをプログラムのロジックとして実装するため、SaaSの設定上限に縛られない。また、勤怠データを現場管理・案件管理など他の業務と一元的に扱えるメリットもある。
ただし、勤怠管理アプリの開発は「労働基準法の規定に準拠した計算ロジックを組み込む」性格上、設計段階で就業規則の全パターンを洗い出すことが前提になる。要件定義の精度がそのまま成否に直結する。「業務アプリ開発で失敗しないための要件定義の進め方」も参照されたい。
スモールスタートとしては、打刻記録・集計・CSV出力（給与ソフト連携）という最小構成から着手し、段階的に機能を追加するアプローチが現実的だ。
よくある質問
変形労働時間制に対応した勤怠管理システムとは？
変形労働時間制では、対象期間内の所定労働時間を日ごとに設定し、期間・週・日それぞれの単位で時間外労働を判定する必要がある。対応システムは、このような複数軸での残業計算と期間カレンダーの管理を自動で行う機能を持つ。ただし「対応している」と表記があっても、就業規則の複雑度によっては追加設定やカスタマイズが必要になる場合がある。
SaaSと業務アプリはどちらを選ぶべきか？
就業規則がシンプルで雇用形態が少ない場合はSaaSが合理的だ。一方、複雑な独自ルールがあり毎月の手修正が発生しているなら、カスタム開発の検討が現実的な選択肢になる。詳細な判断基準は「汎用SaaSと専用業務アプリ、自社に合うのはどちら？」にまとめている。
まとめ——SaaSを使い続けるか、別の手を打つか
汎用SaaSのまま使い続けることが合理的なのは、設定の複雑さが許容範囲で、今後就業規則を整理・標準化する方向性がある場合だ。逆に、毎月の手修正・二重管理が担当者の大きな負担になっている、法令遵守の観点で不安が残るという状況なら、見直しを検討するタイミングと言える。
勤怠管理は給与計算に直結するため、「なんとなく動いている」状態を放置し続けるリスクが特に高い領域だ。毎月手修正が発生しているなら、それはシステムが実態に合っていないサインと受け取った方がいい。
