「従業員がかわいそう」だから給与を先払いする。その運用、本当に続けるべきですか？
給与の支払い方法の中に、
「末締め・当月払い」
という運用があります。
例えば月末締めで25日払いの場合、25日時点では勤怠が確定していないため、
- 基本給は先に支払う
- 残業代や欠勤控除は翌月精算する
という方法を取ります。
理由を聞くと、
従業員がかわいそうだから
入社した月から給与を出してあげたいから
という話をよく耳にします。
たしかに入社直後の従業員にとってはメリットがあります。
働いた月に給与が支給されるため、生活面での安心感はあるでしょう。
しかし、そのメリットを受けるのは実質的に入社直後の一度だけです。
採用上のメリットはあるのか？
では、
「当月払いだから入社したい」
と思う人がどれだけいるでしょうか。
反対に、
「翌月払いだから応募をやめよう」
と思う人がどれだけいるでしょうか。
少なくとも採用現場で見る限り、そこが決定打になるケースはほとんどありません。
求職者が見ているのは、
- 給与額
- 仕事内容
- 人間関係
- 働き方
- 休日
- キャリア
です。
支払サイクルは、企業選びの優先順位で上位に来ることはまずありません。
採用競争力として考えた場合、その効果は限定的です。
一方で事務負担は大きく増える
問題は運用面です。
末締め当月払いでは、
今月支払う給与と前月勤怠を同時に管理しなければなりません。
通常の給与計算なら、
1か月分の勤怠を締めて給与計算する。
それだけです。
ところが当月払いでは、
- 基本給は今月
- 時間外手当は前月
- 欠勤控除は前月
というように計算対象期間が混在します。
これだけでも管理が複雑になります。
昇給や固定残業代変更時はさらに大変
特に厄介なのが、
- 昇給
- 降給
- 固定残業代変更
- 手当変更
です。
例えば昇給した月。
前月勤怠に対する残業代を計算するには、昇給前の給与額を基準に計算しなければなりません。
しかし給与ソフト上では既に昇給後の給与額になっています。
すると、
- 前月の給与額を確認
- 前月の固定残業代を確認
- 前月の残業時間を確認
- 今月の給与データを修正
という作業が発生します。
結果として手入力による調整が増えていきます。
ソフトで対応できない部分は人が対応することになる
現在の給与計算ソフトは非常によくできています。
しかし、それは標準的な給与計算を前提に設計されているからです。
特殊な運用になればなるほど、
システムが処理できない部分を人が補うことになります。
修正が増えれば増えるほど、
ヒューマンエラーの発生確率は高くなります。
給与計算担当者が優秀だからではありません。
人が介在する以上、ミスの可能性は必ず存在します。
だからこそ、
ミスを防ぐために仕組みを単純化する
という考え方が大切なのです。
退職時には別の問題も起きる
この運用の問題は退職時にも現れます。
特に休職後の退職などでは、
支払う給与がほとんどないにもかかわらず、社会保険料だけが発生するケースがあります。
結果として、
給与から控除しきれず本人へ請求しなければならない。
場合によっては複数月分の保険料回収が必要になる。
という状況も珍しくありません。
入社直後に退職するケースでも同様です。
また、最近の給与ソフトは退職日を入力すると自動で保険料や雇用保険料の計算を制御するため、運用によっては想定外の確認作業が発生することもあります。
結局のところ、
制度が複雑であればあるほど、管理コストは高くなります。
「従業員のため」という言葉で考えるのを止めてはいけない
私は、
従業員がかわいそうだから
という言葉だけで制度を決めることには違和感があります。
本当に従業員のためを考えるのであれば、
- 給与計算ミスが起きないこと
- 正しく支払われること
- 担当者が無理なく運用できること
- 制度が長く維持できること
の方が重要です。
制度設計は感情論で決めるものではありません。
「かわいそうだから」
「大変だろうから」
という発想だけで運用を複雑化し、その結果としてミスのリスクを増やしてしまうのであれば、本末転倒です。
シンプルが一番強い
給与計算の現場にいると常々感じます。
シンプルな制度ほど強い。
シンプルな制度ほどミスが少ない。
シンプルな制度ほど担当者が変わっても回る。
そして採用において本当に重要なのは、
「給与を早く払う会社」ではなく、 「ここで働きたいと思える会社」であること。
支払サイクルで人は集まりません。
人が集まるのは、会社に魅力があるからです。
制度の目的を見失わず、運用のしやすさと正確性を大切にしたいものです。