採用・内定を承認で、人員枠と採用コストを管理する
承認を経ない内定で人員枠と採用コストが計画を超える問題を、基幹システムの採用承認ワークフローが採用責任者、人事、財務の承認を通して解決します。
秋も深まる金曜日です。ある部門長はエンジニア2名が足りず、重要な受注の納期が迫っています。採用担当は有望な候補者を見つけ、給与等級を気付かれぬよう12%引き上げて内定をまとめ、昨日の昼食の席で口頭で出しました。採用責任者はチャットで承認を出し、人事は事後報告を受け、財務がその新しい給与を知るのは翌月、給与見込が役職1人分まるごとずれたときです。誰がどの権限で内定を承認したか、人員枠が2名から3名にどう動いたか、誰も示せません。半年後、採用は事実として残ります。決定の記録だけが残りません。
これが今日の日本の中堅企業の採用の実態です。人材市場が厳しい状況下では、スピードだけが優先事項に見えます。令和7年版情報通信白書によると、デジタル化の障害として人材不足を挙げる企業は48.7%に上り、最も多い回答です。人材が不足しているとき、早く動いて書類は後で整えるという判断になりがちです。そしてその書類が整えられることはほとんどありません。採用・内定の承認ワークフローを持つ基幹システムは、スピードと統制を同時に保ち、人員枠と採用コストが計画から逸れるのを止めます。
統制のない内定が計画を静かに壊す理由
内定は人事の出来事に見えます。予算の観点では、設備投資を除けば企業が行う最大級の裁量支出の一つです。内定に統制された経路がないとき、3つのことが同時に滑り落ちます。
1つ目は人員枠です。年間計画では工場に技術者を6名追加することになっています。採用責任者は急な欠員を埋めようと7人目、さらに8人目を加えます。1件ずつ見ればどれも合理的です。合計すると人員計画は崩れ、年初来の給与が予算を超過して初めて誰かが気づきます。各内定が別々のチャットのスレッドで承認されているため、計画に対していくつの内定が出たかを一覧できる場所はありません。
2つ目は採用コストです。紹介手数料、リファラル報奨、入社一時金、引き上げられた給与が、内定ごとに複利で積み上がります。10月には必要に思えた5%の給与引き上げは、雇用が続く限り毎月の固定費になり、同じ等級の次の採用の下限を据えます。内定が出る前に財務の承認を経ていなければ、コストは確定した後に承認されることになり、それは承認ではありません。
3つ目は監査証跡です。内部統制のレビューアーや外部監査人が、等級を超える内定を誰がどの根拠で認可したかを問うたとき、転送されたチャットが答えになってはなりません。上場企業がJ-SOXの下で応える内部統制の枠組みは、何が決定され、誰がいつ承認したかを示す固定された記録を求めます。昼食の席での合意はこの問いに耐えられません。
3つすべてに共通する欠陥は単純です。内定に統制された申請・承認の経路がないことです。採用の申請が内定が出る前に採用責任者、人事、財務の承認を経る単一の場所も、決定がなされた時点でそれを固定する仕組みも存在しません。
-> 関連:中堅製造業が走らせる60の承認ワークフローと、一つの基幹システムに集約するROI
統制された内定ワークフローが実際にどう見えるか
解決策は、後から追加する単体の採用ツールではありません。経費や購買発注、休暇申請を既に動かしている基幹システムと同じ場所にある承認ワークフローです。今日本当に実装されていることと、正直言ってまだロードマップ上にあることを以下に述べます。
1件の内定申請を、採用・人事・財務へ回す
内定の申請は1件の構造化されたフォームから始まります。採用責任者は役職、等級または給与バンド、提案する給与とその内訳、報告先、業務上の理由を入力します。役職の種類ごとに異なる項目を表示するよう設定できるため、エンジニア採用には担当するプロジェクトを、管理部門の採用にはコストセンターを尋ねる、といった切り替えが可能です。これは経費や休暇のワークフローが既に使っている動的フォームと同じ機能を、採用に適用したものです。
申請が提出された瞬間、設定可能な承認ルートを流れます。このルーティングは今日実装され稼働しています。ワークフローエンジンは管理者を固定の名前ではなく申請者から解決するため、申請は自動的に採用責任者の直属の上司に届きます。そこから人事へ回り、等級ポリシーや人員計画、雇用形態のルールと照合されます。続いて財務へ回り、給与が給与予算と紹介手数料の確定と照合されます。ルーティングは条件で分岐できます。等級内の内定はスピードのため人事と財務に並行して回り、等級を超える内定や計画を超える新規人員は、完了前に追加の役員承認を要求します。
この条件付きで役割を意識したルーティングこそ、メールで最も失敗しやすい部分です。規程には等級外の内定には2名の承認が必要と書きながら、実際には最初にいた方が承認を出し、内定が出てしまう運用になりがちです。ワークフローエンジンは、設定された承認者が実際に決定するまで申請が完了しないため、規程を毎回必ず適用します。
すべての内定がどこで詰まっているか一目で分かる
すべての内定がワークフローの中にあるため、進行中の採用申請の状態をすべて確認できます。どれが直属上司待ちか、どれが等級確認のために人事のキューにあるか、どれが予算承認のために財務にあるか。廊下を歩いて人を探す必要も、候補者が別社の内定を受ける前に返答できるか推測する必要もありません。承認者ではなく申請を追いたい関係者、例えば自部門の採用パイプラインを追う部門長は、承認の連鎖を乱すことなく申請の動きを追えます。
承認内容を固定スナップショットで証跡化
内定が承認されると、システムは決定内容を固定スナップショットとして記録します。役職、等級、給与とその内訳、報告先、承認者、タイムスタンプです。これが、監査人の問いに記憶から決定を再構築せずに答える監査証跡です。今日システムが経費承認や発注承認を守っているのと同じスナップショットの規律を、部門が負う最大級の裁量支出まで広げたものです。
採用責任者の不在でも止まらない安全な代理承認
採用責任者が出張中でも承認は止まりません。エンジンは安全な代理承認に対応しており、出張中の採用責任者は自身のキューを代理者に委ねられます。ただし等級外の内定など高リスクの項目には必須の再承認経路が設定されます。採用が、顧客先に出向いている1人の都合で1週間止まることはありません。それはまさに、人々に内定を早く出して後で謝りたくなる種類の遅延です。
自動書き戻しについて正直に
すべての購入者が尋ねるべき境界を、率直に述べます。
内定承認の統制は今日実装され稼働しています。採用責任者が役職を申請し、ワークフローが役割と条件によって人事と財務の承認へ申請を回し、決定とその完全な文脈が固定された監査スナップショットとして記録され、申請の移動中の状態がすべて見える、という統制の階層は実在し、動いています。
ロードマップにあり、まだ実装されていないのは、従業員マスタへの自動書き戻しです。内定が承諾された瞬間に自動で従業員レコードを作成し、給与や社会保険の設定を開き、入社対応のタスクを起動することは、これから進める作業であり、完成した作業ではありません。正確な表現はこうです。内定承認の統制は現在稼働しており、承諾時の従業員レコード自動作成は次のステップです。承認ボタンを押すだけで今日、人事レコード全体を自動で展開すると語る方は、過剰に売り込んでいます。
書き戻しがなくても、価値は具体的です。今日のギャップは通常、人事が新入社員を設定できないことではありません。誰が給与を認可したか証明できないこと、人員枠が計画に対してどう動いたか分からないこと、確定の記録の持ち主がいないことです。ワークフローは証明と持ち主、そして人員枠の集計を閉じます。従業員マスタへの最終自動ステップは統制が整った後のまとまった作業であり、それこそがロードマップが担う部分です。
書き戻しの境界について完全に正直に記します。今日自動書き戻しが実装されているのは経費精算と休暇申請の2つだけです。従業員レコードの作成を含め、それ以外の書き戻しはすべてロードマップ上にあります。もっとも、内定決定に対する統制の階層は、書き戻しの有無にかかわらず今日稼働しています。
事例:静岡の精密部品メーカー
自動車や産業機械の完成車メーカー各社に部品を供給する、静岡の精密部品メーカーを想像してください。社員数は約280名。本社と工場、営業拠点を持っています。工場はシフト制で動き、設計チームは少数精鋭のため採用は恒常的に発生し、現場では人材不足の影響を直接感じています。
従来の流れでは、欠員に迫られたシフトの責任者が採用担当に電話し、電話口で給与を引き上げることで合意し、口頭の内定が出た後に人事へ報告していました。財務が新しい給与を知るのは、月次の給与見込がずれたときでした。ある四半期、計画3名に対して実態は4名を採用し、4件のうち2件は公開された給与等級を超えて着地しました。内部統制のレビューアーが承認記録を求めたとき、チームが提出できた最善のものは、合意された権限も固定スナップショットもないチャットのメッセージのやり取りだけでした。
統制された流れでは、すべての内定がワークフローの中の申請として始まります。採用責任者が役職、等級、提案する給与を提出します。申請は自動的に適切な承認者へ回ります。等級と人員計画の確認のために人事へ、予算承認のために財務へ、そして内定が等級を超える場合や計画を超える新規人員の場合は条件により追加の役員承認者へ。採用責任者と情シスは保留中の内定をすべて確認でき、入社日を計画できます。内定が承認されると、決定は完全な文脈とともに固定されます。役職、給与、報告先、承認者、タイムスタンプです。
翌四半期、人員計画は守られます。等級を超えてしまうはずだった内定は役員承認へ回り、いくつかは等級に収まるよう調整されて戻ってきます。給与見込は財務が確定の前に承認しているため、役職1人分まるごとのずれで外れることがなくなります。そして内部統制のレビューでは、すべての採用に固定スナップショットがあり、計画に対する内定の件数が綺麗に数えられ、等級を超える給与を誰が認可したかの明確な記録が見つかります。
ERPの横ではなく、ERPの中にあるべき理由
単体の採用ツールを買い込み、採用を純粋な人事の課題として扱う誘惑があります。それが人員枠のズレとして戻ってくる経緯です。内定は人事の出来事であると同時に予算の確定であり、経費や購買、休暇の監査規律を既に保持しているのと同じ基幹システムの中にあるべきです。
内定のワークフローが基幹システムの中にあるとき、3つのことが揃います。承認ルートは経費承認と同じ管理者解決を使えるため、部門改編でルーティングが壊れません。監査スナップショットは内部統制の他の部分と同じ固定記録の規律を使うため、監査人は採用、支出、アクセスにまたがって2つではなく1つの一貫した証跡を見ます。そして人員枠の集計は給与予算のすぐ隣に置かれるため、計画と確定が決して突き合わさらない2つのシステムではなく、同じ画面の中に並びます。
人員計画の側面でも恩恵があります。一度内定が統制された申請になれば、同じパターンを昇格、異動、報酬改定へと拡張できます。これらは今日チャットで行われている決定であり、いずれも次の監査を待つ指摘事項です。採用から始めることで、その先の筋肉が鍛えられます。
-> 関連:権限付与と自動失効を申請で統制し、退職者の放置アカウントを防ぐ
よくある質問
内定が承諾されたとき、従業員レコードは自動で作成されますか?
内定承認のワークフローは申請を人事と財務の承認へ回し、決定を監査スナップショットとして固定します。内定が承諾された瞬間に従業員マスタのレコードを自動で作成する書き戻しはロードマップにあり、まだ実装されていません。決定の統制と記録は今日稼働しており、従業員マスタへの最終自動ステップはこれからです。
等級を超える内定に役員承認を要求できますか?
はい。ここで条件付きルーティングが真価を発揮します。等級内の内定はスピードのため人事と財務に並行して回り、等級を超える内定や計画を超える新規人員は条件により追加の役員承認者へ回せます。設定された承認者が実際に決定するまで申請が完了しないため、規則は毎回必ず適用されます。これは実装済みで稼働しています。
採用責任者が不在のときはどうなりますか?
ワークフローは安全な代理承認に対応しています。出張中の採用責任者はキューを代理者に委ねられます。ただし等級外の内定など高リスクの項目には必須の再承認経路があります。採用が、顧客先に出向いている1人の都合で1週間止まることはありません。
既存の人事システムを置き換えることになりますか?
いいえ、置き換える必要もありません。ワークフローは内定の申請と決定を統制し、スナップショットを記録します。承認された内定から既存の従業員マスタや給与設定への接続は、ロードマップが担う書き戻しのステップです。重要なのは、内定の前に統制された監査可能な管理を置くことであり、すでに動いているものを引き剥がすことではありません。
重要なポイント
統制された経路を経ずに出る内定こそが、人員枠と採用コストが計画を超える理由です。設定可能なワークフローを持つ基幹システムは根本原因を解決します。すべての内定が申請として始まり、役割と条件によって採用責任者、人事、財務の承認を経て、固定された監査スナップショットとして記録されます。承諾時の従業員レコード自動作成はロードマップ上の次のステップです。統制と記録は今日稼働しており、それこそが、等級を超える給与が誰の承認もないまま固定費になるのを止めるものです。
Kikan System で始める
人員枠のズレや統制されていない内定が点検で繰り返し指摘されているなら、Kikan System をご覧ください。内定承認のワークフローは、採用の申請を役割と条件によって人事と財務の承認へ回し、すべての決定を監査スナップショットとして固定し、すべての内定を見える形で保持します。2ユーザーまで無料、カード不要のフリープランですぐに始められます。/#get-startedからご開始ください。
関連記事
退職者のアカウントを放置しない、権限付与と自動失効の申請
手作業のアカウント発行は退職者の放置アカウントを生み、不正アクセスの温床になります。基幹システムの申請・承認フローで権限付与を統制する方法を解説します。
続きを読む→現場の勝手なSaaS導入を防ぐ、シャドーIT対策
現場が勝手にSaaSを導入し企業データが散逸する問題を、基幹システムの申請・承認ワークフローで統制するシャドーIT対策の仕組みを実務に沿って解説します。
続きを読む→基幹システムの多段階請求書承認ワークフローで GST コンプライアンスを守る
ERP 基幹システムで多段階請求書承認ワークフローを導入し、発行前の GST 誤りを防ぎ、職務分掌を徹底するインド企業向けの実践ガイドです。
続きを読む→