人事・給与システムは、従業員ファイル、契約、休暇残日数、勤怠を保管し、手当と控除を含めて毎月の給与を計算し、銀行や公式プラットフォームが受け付ける形式で給与台帳と賃金保護ファイルを作成します。これらすべてをスプレッドシートで運用している企業は二重のコストを払っています。毎月末に失われる時間と、修正が難しくなってから遅れて表面化する不一致や違反です。良い選択は、市場で最大のシステムを買うことではなく、自社が本当に必要とするものを定義することから始まります。

スプレッドシートが解決策でなくなるのはいつか？

一枚のシートで十人の従業員なら何とかなります。問題が始まるのは、複数の拠点、異なる職位等級、月の途中で入社・退社する従業員があり、さらに誰も詳細を覚えていない休暇、前払い、控除が加わったときです。その時点でファイルは一人の経理担当者の個人的な記憶となり、その人が不在になったり退職したりすると、プロセス全体が止まってしまいます。

兆候は簡単に読み取れます。給与台帳の作成に毎月丸一日以上かかる、給与の誤りが振込前ではなく振込後に見つかる、同じデータを複数の場所に再入力している、そして特定の従業員の休暇があと何日残っているか、ある拠点で前四半期に残業代がいくらかかったかといった簡単な質問にすぐ答えられない、といったものです。

システムが実際にカバーすべきもの

ベンダーの機能一覧から始めないでください。採用から雇用終了まで、自社における従業員のライフサイクルから始め、システムが次の各段階をカバーしているかを確認してください。

  • 一元化された従業員ファイル。契約、職名、基本給、手当、身分証とイカーマ（滞在許可証）の有効期限、資格証明書を、散らばったフォルダではなく一か所にまとめます。
  • 給与に直結した勤怠と休暇。遅刻、欠勤、残業が手作業ではなく自動的に給与台帳に反映されます。
  • 給与計算エンジン。固定・変動の手当、前払い、控除を処理し、月の途中で入社または退社した従業員の日割り計算を正しく行います。
  • 振込にそのまま使える出力。給与台帳、賃金保護ファイル、銀行振込ファイル、そして保管して後から参照できる承認済みの給与台帳です。
  • 法定義務。社会保険料、雇用終了時の退職給付、累積休暇などを、必要なときだけでなく継続的に計算します。
  • 権限と監査証跡。誰がいつ給与を変更したかをシステムが把握します。それだけで、ある種類の問題全体を防げます。

政府プラットフォームとの連携が勝負の半分

国のプラットフォームとやり取りできないシステムは、解決策の半分にすぎません。Mudad は賃金保護と給与管理のための公式ポータルで、企業はここに賃金ファイルをアップロードし、銀行連携を通じて給与を振り込みます。社会保険庁（GOSI）は保険料算定の基礎となる賃金と、雇用主と従業員が毎月負担する保険料を定めています。Qiwa は契約、労働力データ、そして労働市場における事業所の位置づけを管理します。

ここでの実務上のリスクは不一致です。社内システムに記録された給与が公式プラットフォームに登録された給与と異なると、違反が発生し、事業所の位置づけに影響します。ほとんどの場合、原因は不正ではなく、誰も同期していないデータが三つの場所に存在していることです。良いシステムは単一の信頼できる情報源をつくり、ファイルのアップロード後ではなく前に警告してくれます。

雇用終了と休暇：誤りが静かに積み重なる場所

経営者を驚かせるのは、毎月の給与であることはまれです。驚かせるのは累積債務です。退職給付と未消化の休暇残高は毎月静かに増えていき、システムがそれを継続的に計算していなければ、従業員が退職するその日になって初めて義務の実際の大きさに気づくことになります。本来は把握できていたはずの数字が、資金繰り上の不意打ちになり、ときには労働紛争にもなります。

適切なシステムは、これらの数字を一つのレポートで常に見えるようにします。今日時点の累積債務はいくらか、拠点や部門ごとにどう配分されているか、ここ数か月でどう推移したか。これは人事情報である前に、経営と財務の情報です。

パッケージかカスタムか？実践的なルール

業務が標準的であれば、パッケージ製品が理にかなっています。固定の月給、シンプルな組織構造、限られた数の拠点、他システムとの深い連携が不要な場合です。導入が早く、サブスクリプション費用も明確です。

給与の計算方法そのものがビジネスモデルの一部である場合には、カスタム開発が正当化されます。拠点の業績に連動した販売手数料、訪問件数や完了した作業指示の数に連動した報酬、変動する現場シフト、あるいは給与を販売時点管理（POS）や作業指示管理など既存の業務システムに直接つなぐ必要がある場合などです。こうしたケースでは、パッケージ製品に合わせて自社の業務を作り変えざるを得なくなり、結局はすでに費用を払ったシステムの横に補助的なスプレッドシートが並ぶことになります。

三つ目の、通常は最も現実的な選択肢は、基本機能にはパッケージのコアを使い、その上に API を通じて構築したカスタム層で自社に固有の部分だけを処理する方法です。すでにあるものを作り直すためではなく、自社を差別化する部分にお金を払うことになります。

給料日を壊さない導入計画

最悪の移行方法は、同じ月に旧システムを止めて新システムを稼働させることです。安全な道はデータの整理から始まります。最新の従業員リスト、公式登録内容と一致する契約、合意済みの休暇残日数です。次に一回か二回のサイクルを並行稼働させ、両方のシステムで給与を計算し、差異がゼロになるまで照合します。そのうえで初めて旧プロセスを廃止します。

初日からデータの責任者を決めてください。直属の上司が勤怠を承認し、人事が休暇を承認し、財務が最終的な給与台帳を承認します。システムは混乱した権限を正すのではなく、その混乱を速くするだけです。

公式情報源

  • Mudad Business — 賃金保護と給与管理：mudad.com.sa
  • 社会保険庁（GOSI）：gosi.gov.sa
  • Qiwa — 労働市場サービスプラットフォーム：qiwa.sa
  • 人的資源・社会開発省 — 賃金保護ファイルのアップロードサービス：hrsd.gov.sa