なぜ大企業の人事システムは「例外」に強くなければならないのか
──1000人の会社で年1件のレアケースが、10万人の会社では毎月8件になる

「配偶者は1人」「長男は1人」──人事システムを設計するとき、誰もが当たり前の前提として置くルールだ。しかし法令に沿って業務を突き詰めていくと、この当たり前は驚くほど簡単に崩れる。そして、その「めったに起きない例外」が、従業員規模が大きくなるほど「毎日のように起きる日常業務」に変わっていく。本レポートでは、人事領域の例外処理がなぜシステム設計を難しくするのか、そしてなぜ中小企業向けと大企業向けのHRパッケージが明確に分かれているのかを、具体例をもとに整理する。

1. 「配偶者は1人」は本当か

結婚して配偶者ができ、その配偶者を配偶者控除の対象にする。これは人事システムにとって最も基本的な処理であり、どの製品でも簡単に設定できる。日本の法律上、ある時点で配偶者は1人しか存在しない。だから「従業員1人につき配偶者は1人」というデータ構造で何の問題もない──ように見える。

では、次のケースはどうだろうか。

ある従業員の配偶者が年の途中で亡くなり、同じ年のうちに再婚した。所得税の取扱いでは、年の途中で死亡した配偶者は死亡時点の状況で控除対象かどうかを判定する。一方で再婚した新しい配偶者は、12月31日時点の状況で判定する。両方が要件を満たす場合でも、配偶者控除の対象にできるのはどちらか1人だけだ。

これをシステムに落とすと、少なくとも次の要件が生まれる。

• 1人の従業員が、同じ年の中で複数の配偶者を持ちうる
• 配偶者の情報は上書きではなく、履歴として保持しなければならない
• 履歴を持ったうえで、どちらを控除対象とするかを選択できる必要がある

「配偶者は1人」という前提で作られたデータ構造では、この3つ目の「選択」が表現できない。履歴を持つことと、履歴の中から適用対象を選ぶことは、別の設計課題なのだ。

2. 「長男は1人」も崩れる──続柄は重複しうる

家族情報の「続柄」も同様だ。長男は1人しかいない。当たり前に思える。

しかし、戸籍上の性別変更は現実に起きる。長女・長男・次男の3人きょうだいで、最年長の長女が戸籍上の性別を男性に変更すると、本人の父母との続柄は「長男」に更正される。一方で、他のきょうだいの続柄は訂正されない。結果として「長男」が2人存在する状態が生まれる。しかもこれは過去と現在で入れ替わるのではなく、同じ期間に重複して存在する。

ここで「続柄＋従業員番号」を家族データの一意キーにしているシステムは、データを登録することすらできない。人事システムが前提にすべきなのは「現実にあり得る家族のかたち」であり、設計者が想像する「典型的な家族像」ではない。

3. 例外には「層」がある

このように法令に合わせて仕組みを考えていくと、業務パターンは大きく3つの層に分かれていく。

• 一般パターン：結婚・出産・扶養追加など、ほぼすべての従業員に起こりうるもの。どの製品でも標準機能で対応できる
• イレギュラーパターン：年の途中の扶養異動、出向・兼務、休職と復職の繰り返しなど。一定規模の企業なら毎年確実に発生する
• 超イレギュラーパターン：年内の死別と再婚、続柄の重複、複数の制度改正が同時期に重なるケースなど。発生はまれだが、起きたときの対応難易度が極めて高い

厄介なのは、層が上がるほど「データの持ち方」そのものを変えないと対応できなくなる点だ。一般パターンは入力画面を作れば済むが、超イレギュラーパターンは履歴管理、複数レコードからの選択、一意性の緩和といった、データモデルの根本に手を入れる必要がある。後から機能追加で対応しようとしても、土台の構造が許さないことが多い。だからこそ「どの層までをシステムで持つか」は、導入の初期段階で決めておくべき論点になる。

4. 例外の重さは「割合」ではなく「人数」で効く

では、こうした例外にどこまで備えるべきか。判断の鍵は発生頻度だが、ここで見誤りやすいのが「割合」で考えてしまうことだ。

仮に、あるイレギュラーケースが、従業員1000人の会社で年に1人起きる頻度だとする。

1000人規模の企業なら、年に1回、担当者が調べながら手作業で処理すればどうにかなる。しかし10万人規模の企業では、同じ事象が毎月8件前後発生する。そしてこうしたイレギュラーケースは1種類ではない。同程度の頻度のものが10種類あれば、月に80件、営業日で割ればほぼ毎日4件の例外対応が人事部門に降ってくる計算だ。

これをすべて手作業で吸収しようとすれば、人事担当者は例外対応だけで日々忙殺される。しかも例外処理は手順が定型化されにくく、担当者の知識に依存しやすい。担当者が異動すれば対応品質は一気に落ち、年末調整や社会保険の手続きで誤りが表面化する。

5. それでも「超イレギュラー」はシステムで持たない

では、あらゆる例外をシステムで持てばよいのか。答えは否だ。例外に対応しようとすると、その代わりに「便利なチェック」を手放さなければならない場面があるからだ。

わかりやすい例が、従業員の年齢チェックだ。入社時点で中学校を卒業する年齢に達していなければエラーにする。このチェック（バリデーション）は、生年月日の入力ミスを入口で確実に止めてくれる。「2001年」を「2021年」と打ち間違えれば、その場で登録が弾かれる。人事データの品質を守るうえで、地味だが非常に効くガードレールだ。

ところが、労働基準法には例外がある。映画の製作や演劇の事業であれば、労働基準監督署の許可を受けることで、13歳未満の子役も働くことができる。法令に「完全に」対応しようとすれば、子役を従業員として登録できる仕様にしなければならない。そのためにこのチェックを外せば、子役を雇うことのない大多数の企業で、生年月日の打ち間違いが毎日のようにすり抜けるようになる。

ある業界にとっての日常が、別の業界にとっては一生起きない超イレギュラーになる。複数の業界で使われるパッケージ製品ほど、この板挟みは深刻だ。

家族データにも同じ構図がある。「子は従業員より15歳以上年下でなければエラー」というチェックは、子の生年月日に親の生年を入れてしまうミスを防ぐ。しかし民法が養子縁組で求めているのは「養親より年下であること」だけで、1日でも年下なら縁組できる。年齢の近い成人を養子に迎えたというまれなケースのために、このチェックが付けられなくなってしまう。

どちらのケースも、正しく対応できなければ困る従業員が実在する。一方で、そのために外したチェックが防いでいた誤登録の後始末は、毎日、全社で発生する。そのコストは、まれなケースを手作業で処理するコストをはるかに上回る。

だから超イレギュラーパターンには、システムで完全に持つのではなく、手作業で受け止められる余白を残しておくのが現実的な解になる。たとえば次のような設計だ。

• 通常の登録画面ではバリデーションを維持し、管理者権限でのみチェックを越えて登録できる「例外登録」の経路を用意する
• 業界や企業によって例外の頻度が大きく違うチェックは、エラーにするか警告にとどめるかを企業ごとに設定できるようにする
• 例外登録には理由の記録と承認を必須とし、後から誰が何のために登録したかを追えるようにする
• システムで扱いきれない部分は、個別対応の手順として残し、年に一度は棚卸しする

すべてを自動で正しく処理しようとする完璧主義は、かえってシステムを使いにくく、壊れやすくする。どこまでをシステムで持ち、どこからを人の判断に委ねるか。その線引きこそが、設計者の腕の見せどころだ。

6. 中小向けと大企業向けは、何が違うのか

人事領域のパッケージ製品が、中小企業向けと大企業向けで明確に分かれている理由はここにある。

中小企業向けの製品は、一般パターンを素早く、わかりやすく処理できることに価値がある。例外はまれにしか起きないため、システムで持たずに運用でカバーするほうが、導入・運用のコストを含めて合理的だ。シンプルさそのものが競争力になる。

一方、大企業向けの製品に求められるのは、イレギュラー、さらには超イレギュラーパターンをデータとして正しく保持し、処理できることだ。画面の見た目や機能の数では差が見えにくいが、データモデルの奥行きがまったく異なる。履歴の持ち方、同一期間の重複の許容、複数候補からの適用選択といった設計が、製品の根幹に組み込まれている。

この違いを理解しないまま選定すると、2つの失敗が起きる。従業員規模が大きいのに「操作が簡単だから」と中小向け製品を選び、例外対応が手作業として現場に溢れ出す失敗。逆に、規模に見合わない大企業向け製品を選び、使わない例外対応のために重い運用と高いコストを抱え込む失敗だ。

7. 例外とどう付き合うか

すべての例外をシステムで持つことが正解なわけではない。例外への対応方針は、大きく3つに分けて考えるとよい。

• システムで持つ：発生件数が多く、誤ると法令違反や従業員の不利益に直結するもの。データモデルの段階から対応できる製品を選ぶ、あるいは周辺システムで補う
• 運用で吸収する：件数が少なく、手順を文書化すれば誰でも対応できるもの。ただし手順書と担当者の引き継ぎまでを設計に含める
• 余白を残す：発生頻度が極めて低く、システムで持つと大多数の利便性や正確性を損なうもの。例外登録の経路だけを用意し、発生時は個別判断とする。対応しないことも意思決定として明文化しておく

注意したいのは、「運用で吸収する」が気づかないうちに「特定の担当者の善意と記憶で吸収する」にすり替わることだ。これは例外処理に限らず、日本企業の現場が長年抱えてきた構造的な課題でもある。例外対応を誰がどう担っているのかが見えない状態は、担当者の異動や退職とともに突然の業務停止リスクに変わる。

人事システムの真価は、誰もが想定する一般的なケースではなく、誰も想定していなかったケースが起きたときに表れる。そしてその「想定外」は、企業規模が大きくなるほど確実に、そして頻繁にやってくる。自社にとっての例外が何で、それをどこで受け止めるのか──その設計こそが、人事システム導入の本当の要件定義だ。

※ 本レポートの税務・戸籍に関する記載は、制度の構造を説明するための例示です。実務への適用にあたっては、最新の法令・通達をご確認のうえ、必要に応じて税理士・社会保険労務士等の専門家にご相談ください。