中国で給与計算を外注しても、なぜ管理業務が残るのか

給与計算の外注では、会社が確定させた勤怠、入退社、給与改定、手当、控除などを渡し、委託先が計算、明細、支払データ、申告用データを作成します。専門性のある計算工程を任せられる一方、入力が遅い、承認がない、制度上の扱いが未決定、例外の理由が記録されていないという問題は、会社側の運用として残ります。

中国では、月次給与が社会保険、個人所得税、住宅積立金（住房公積金 / Housing Provident Fund）、入退社や人員情報の変更と結び付きます。社会保険法には事業主による社会保険料の申告・納付と従業員への納付明細の通知に関する規定があり、給与・賃金を支払う側には、支払対象者、所得、控除、源泉徴収額等を含む源泉徴収申告と基礎情報の変更反映に関する規定があります。[1][2] 賃金支払記録と個人別給与明細、住宅積立金の拠出登録・従業員口座・変動時の手続も、雇用主側の情報と判断を前提に進みます。[3][4] 実際の適用は都市、従業員の事実関係、運用・委託の形態で変わるため、当該ケースの現行要件を確認します。

したがって、外注後に社内へ残るのは「計算しなかった仕事」ではなく、計算できる状態をつくり、結果を会社として引き受ける仕事です。委託先との役割分担は、サービス名ではなく、月次の受け渡しで定義するほうが実務に合います。

平常月は、必要なデータを同じ締め日までに渡せば処理できます。負荷が表面化するのは、採用、退職、異動、昇給、賞与、休暇、時間外勤務、遡及修正、本社からの集計変更が重なる月です。こうした案件では、計算そのものよりも「何を、いつから、どの根拠で反映するか」が問われます。

変更を一件ごとの運用単位として扱うと、給与業務は急に見通しやすくなります。最低限、発生事実、適用日、根拠書類、入力者、承認者、委託先への連絡日、計算結果の確認者を結び付けます。遡及修正なら、元の処理、修正理由、影響月も同じ履歴に残します。これにより、担当者が替わっても、翌月に同じ確認を最初からやり直さずに済みます。

この考え方は特定の給与製品を導入する話ではありません。匿名化されたフィールドサービスの実装済みケース「サービスの知識が、人々の頭の中だけにあったとき。」は、Error → Troubleshooting → Parts → Resolution をつなぐ運用・知識の仕組みを扱っています。人事・給与の導入結果ではありませんが、変更、対応、結果、履歴を一続きにし、文脈を担当者の頭の中に閉じ込めないという点で、給与の引継ぎを考えるための類比になります。[5]

ベンダー管理を「質問があればメールする仕事」と捉えると、締切直前の確認と個人依存が増えます。月次の流れを、会社側の確定、委託先の計算、会社側の照合・承認、本社への説明という四つの受け渡しに分け、各段階のオーナーと締切を見えるようにします。

実務では、次の役割を曖昧にしないことが重要です。

• 入力オーナー：人員・勤怠・支給控除の情報を集め、締め日までに確定する。
• 変更・例外の承認者：給与改定、臨時支給、遡及修正、退職月の扱いなど、標準処理に乗らない判断を行う。
• ベンダー窓口：質問、修正依頼、締切、回答の履歴を一か所に残す。
• 照合・支払い承認者：人数、支給項目、前月との差異、支払ファイルを確認する。
• 本社報告のオーナー：現地の計算出力を、本社が理解できる部門・通貨・予実の見方へつなぐ。

一人が複数の役割を担うことはあっても、役割まで一人の記憶に置かないことが大切です。共有された締切表、変更台帳、承認記録、委託先との決定事項があれば、担当交代やベンダー変更の際にも月次を引き継げます。

委託先を変える局面で困るのは、計算式だけではありません。未処理の変更、過去の例外、承認権限、支払前の照合方法、本社が求める説明が、前任者やメールの受信箱に散っていることです。

そのため、ベンダー交代や担当者の離任に備えて、少なくとも次を月次運用の一部にします。

1. 入力元、締切、承認者、提出形式を一覧にする。
2. 進行中の変更と未解決の例外を、次の処理月まで追える形で残す。
3. ベンダーへの問い合わせ、回答、修正依頼、確定版を同じ履歴に紐付ける。
4. 計算結果の照合手順と、本社向け報告の作成元を引継ぎ対象に含める。

この四点があれば、交代のたびに制度と過去判断を再構築する必要が減ります。外注先の選定より先に、会社が渡せる入力と、会社が回収すべき説明を整えることが、継続性の土台になります。

給与明細や支払ファイルが完成しても、本社が知りたいのは、人数・部門・変更理由・前月との差異が説明できる状態かもしれません。現地の計算出力と本社の管理ビューが別々に作られると、同じ数字を何度も確認し、差異の説明が個人依存になります。

月次報告では、人数、主要な変更、例外、総額の差異、未解決事項を、給与計算の確認履歴と結び付けます。これにより、報告は後追いの資料作成ではなく、承認と照合の最終段階になります。複数都市の給与、社会保険、住宅積立金、時間外勤務・手当・休暇控除、雇用主コストと都市別サマリーを一望するための Multi-City China Payroll & Social Insurance Calculator は、SAMPLE TOOL · FICTIONAL DATA のワーキングサンプルです。[6]

外注費を含む運営モデル全体の費用や、本社向けの予実管理を検討する論点は、中国で20〜50名のチームを立ち上げると、実際に何にコストがかかるのかで扱っています。そこでは 3-Year People-Cost Budget & Budget-vs-Actual を SAMPLE MODEL · FICTIONAL DATA のワーキングサンプルとして示しています。[7]

給与に必要な機能と、初日から専任人事を置くかどうかは別の判断です。給与運用では、入力の正確性、変更と例外の判断、最終承認、従業員への説明、本社への報告を担う人が必要です。誰を社内に置き、どこまで外部の専門性を使い、いつ内製の役割を増やすかという組織設計は、中国進出初期、20〜50名規模で専任の人事部門は本当に必要かで詳しく整理しています。

ここで優先すべきなのは、給与の月次が止まらない責任の置き方です。匿名化された「共有リソースが共有されなくなったとき。」は、共有能力層とガバナンスの設計を扱う Proposed — Not Implemented（提案済み・未実装） の記録で、NO IMPLEMENTATION RESULTS CLAIMED（実装成果は主張していない） と明記されています。給与・人事の成果の証拠ではなく、判断権とリソースの境界を設計する際の参照に限られます。[8]

1. 月次入力の締め日と、情報を確定する責任者は明確か。
2. 給与改定、賞与、休暇、入退社、遡及修正を、どの承認経路で確定するか。
3. 標準処理に乗らない例外を、誰が判断し、その理由をどこに残すか。
4. 委託先の出力を、誰が人数・支給項目・前月差異・支払額の観点から確認するか。
5. 本社が必要とする集計と、現地で保管する履歴を、同じ説明可能な流れでつなげられるか。

この五つへの答えがなければ、ベンダーとのメールが運用設計の代わりになります。答えが簡潔に定義されていれば、委託先は計算と定型処理に集中でき、社内は判断、承認、説明、引継ぎを管理できます。