入社手続き書類から従業員データベースへ：
新入社員データを一括で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のフォーム仕様に基づいています：

つまり、新入社員一人あたり約30のデータフィールドが、5つの異なるフォームに、それぞれ独自のレイアウトとラベル規則で分散しています。ある従業員は電話番号の横に「携帯」と書き、別の従業員は「モバイル」と書きます。ある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種類の異なる文書が含まれており、それらはすべて同一人物に属しているということです。各フォームタイプを個別に抽出し、その後従業員名で手動で統合するという方法は、フォームからスプレッドシートへの入力を、スプレッドシート間のマージに置き換えるだけです。データ入力の負担が移動しただけで、なくなりはしません。

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

列名抽出：1バッチ、全フォーム、1従業員レコード

列名抽出は、オンボーディングフォームスタックに対して異なるアプローチを取ります。出力スプレッドシートの列として必要なすべてのフィールドを指定します（フォームの種類を問わず）。AIはバッチ内のすべてのドキュメントをまとめて読み取り、各フィールドを正しい従業員にマッチングします。すべてのフォームに記載されている従業員のフルネームが、ドキュメントタイプ間のリンクキーとして機能します。SSNはW-4または従業員情報フォームから取得されます。銀行のルーティング番号は直接入金承認フォームから取得されます。緊急連絡先の電話番号は緊急連絡先フォームから取得されます。これらすべてが、従業員ごとに1行に集約されます。

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

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

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

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

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

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

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