入社フォームから従業員データベースへ：
新入社員データを一括でExcelに抽出

新入社員10名、書類50枚、人事担当は1人

新入社員の書類手続きを象徴する瞬間は、入社初日ではなく、その前の金曜日に訪れる。月曜日に10名の社員が入社する。人事コーディネーターの机の上には、10枚の従業員情報届、10枚の給与所得者の扶養控除等申告書、10枚の雇用適格性確認書類、10枚の給与振込依頼書、そして10枚の緊急連絡先シートが積まれている。メールに添付された記入済みPDFもある。入社前訪問時に社員が持参した印刷コピーもある。プリンターがないため手書きで記入されたものもある。扶養控除等申告書の1枚は、社員が国税庁の現行様式ではなく、適当なサイトから見つけた2019年の旧様式を使用している。

これら50枚の書類は、それぞれ1行のデータ、いや、複数のシステムにまたがるデータポイントになる。氏名とマイナンバーは給与システムへ。住所と電話番号は人事システムへ。緊急連絡先は別のタブへ。銀行口座情報は振込設定へ。扶養控除等申告の区分と控除数は源泉徴収の計算に反映される。人事コーディネーターの月曜の朝は、新入社員を歓迎することではなく、個人データを紙からデータベースへ、1フィールドずつ正確に転記することに費やされる。マイナンバーや口座番号の入力ミス1つが、解決に数週間を要する修正作業の連鎖を引き起こすことを承知の上で。

r/humanresourcesでは、従業員35名の企業の人事担当者がまさにそのジレンマを綴っている。有給休暇管理とオンボーディングにスプレッドシートを使っているが、従業員が50名になるまで人事システムの導入は待つように言われているという。別のスレッドでは、従業員32名の企業から「新入社員のオンボーディングプロセスはなぜこんなに複雑なのか？」という質問が寄せられ、問題が社内システムにあるのか、プロセス自体にあるのか確信が持てない様子だ。一方、r/ITManagersでは、多くの小規模人事チームの本音を代弁する投稿がある。「Excelスプレッドシートをあまりにも長く使いすぎている。」

標準的な新入社員フォーム一式：50枚のシートの中身

データ抽出の方法を考える前に、その全体像を理解することが重要です。米国の標準的な新入社員パケットには通常5〜6種類のフォームが含まれており、それぞれが異なるカテゴリの従業員データを収集します。以下のフィールドはAIHRのオンボーディング文書ガイドおよびIRS/USCISのフォーム仕様に基づいています：

つまり、新入社員1人につき約30のデータフィールドが、それぞれ独自のレイアウトとラベル規則を持つ5種類のフォームに分散しています。ある従業員は電話番号の横に「Cell」と書き、別の従業員は「Mobile」と書きます。あるI-9には社会保障番号が記入されていますが、別のI-9ではSSNフィールドが任意のため空白のままです。データは存在します—書き留められています。しかし、それは文書全体に断片化されており、新入社員ごとに誰かが正しいフォーム上の各フィールドを見つけ、正しい列に入力しなければなりません。

W-4抽出ツールが仕事の大半を残したままにする理由

Parseurは、税額控除フォームから氏名、住所、申告ステータス、SSN、署名日を取得するW-4抽出ツールを提供しています—そして、多数のW-4を処理する組織にとって、これは本当に有用です。このツールはI-9や直接入金フォームも処理します。しかし、各フォームタイプを独立した抽出ジョブとして扱うこと自体に問題があります：新入社員のデータが3つまたは4つの別々のスプレッドシートに分散してしまうのです—W-4フィールド用、I-9フィールド用、直接入金情報用—そして誰かがそれらを単一の従業員レコードに統合しなければなりません。

実際の問題は、W-4抽出が機能しないということではありません。問題は、新入社員パケットには5〜6種類の異なる文書があり、それらすべてが同じ人物に属しているということです。各フォームタイプを個別に抽出し、その後従業員名で手動で統合するという方法は、フォームからスプレッドシートへの入力を、スプレッドシート間の統合に置き換えるだけです。データ入力の負担は場所が変わるだけで、なくなりません。

必要なのは、新入社員パケット全体を1つの単位として処理する単一の抽出です—従業員情報フォーム、緊急連絡先、W-4、I-9、直接入金—そして、すべてのフィールドを統合した従業員ごとの1行を生成します。フォーム別のエクスポートファイルは不要。手動の統合ステップも不要。1回のバッチ処理で完全な従業員レコードが生成されます。

列リストは採用パケットに限定されません。数ヶ月後に書面による警告が従業員ファイルに追加された場合、懲戒フォームからExcelへの変換により、アクションレベル、インシデントの説明、過去の発生回数が同じレコードの追加列として追加されます—従業員ファイルは紙のフォルダとスプレッドシートに分かれることなく、1つのテーブルとして維持されます。

列名抽出：1バッチで全フォームを処理し、従業員1人につき1レコードに

列名抽出は、オンボーディングのフォーム一式を別の方法で処理します。出力するスプレッドシートの列として、全フォームタイプにわたって必要なすべてのフィールドを指定すると、AIがバッチ内のすべての文書をまとめて読み取り、各フィールドを正しい従業員に照合します。すべてのフォームに記載されている従業員の氏名が、文書タイプ間の紐付けキーとして機能します。SSNはW-4または従業員情報フォームから取得されます。銀行のルーティング番号は、直接入金の承認フォームから取得されます。緊急連絡先の電話番号は、緊急連絡先フォームから取得されます。これらすべてが、従業員ごとに1つの行に集約されます。

完全なオンボーディングバッチに対する列名の完全なリストは、次のようになります：

AIは各文書を個別に読み取ります。W-4フォームで「Maria Gonzalez」に属する社会保障番号を検出すると、そのSSNをMaria Gonzalezのレコードに関連付けます。このレコードには、従業員情報フォームからの住所と、直接入金フォームからの銀行詳細がすでに含まれています。列名抽出では、すべてのデータが同じフォームにある必要はありません。フォームを個別に処理するのではなく、データが存在するフォームに関係なく、人を処理するためです。

10枚の書類から1つの従業員データベースへ：ステップバイステップ

月曜朝のデータ入力作業をAI抽出に置き換えるワークフロー：

新入社員書類バッチの出力は、各従業員を完全で自己完結した1行として構成します。緊急連絡先、税務、銀行データはすべて同じレコードに — マージ不要、VLOOKUP不要、別々のスプレッドシート間での従業員IDの相互参照も不要：

人事向け計算列：試用期間、不足項目、ポリシーフラグ

各フォームに書かれた内容を抽出するのは第一歩です。しかし、人事のオンボーディングには、抽出後に行う追加の処理工程（通常は手作業のExcel作業）があります。各従業員の試用期間の終了日を計算し、すべてのフォームが提出されたことを確認し、不完全なレコードを給与計算に回す前にフラグを立てることです。計算列は、抽出中にこれらを処理します。