人事管理システムの導入前に何を決める？従業員情報・異動・権限の整理方法

最初に、誰のどの人事情報を管理するか決める

導入の出発点は、担当者が困る仕事を一件で説明することです。例えば「異動の予定と現在の所属が同じ一覧に混ざり、上長へ確認しないと当日の所属を回答できない」という困りなら、所属の履歴と基準日を扱う条件が必要です。「従業員情報を一元管理したい」だけでは、誰の何が正しくなればよいかが定まりません。

従業員マスタと正本は、項目の管理元から説明する

従業員マスタは、社員を識別し、会社・所属・雇用などの基本情報を管理する記録です。正本は、食い違ったときに根拠として戻る管理元の記録を指します。どの情報でも一つのシステムだけが正しい、という意味ではありません。所属は人事、勤怠の実績は勤怠管理など、項目ごとに管理元と変更担当を決めます。

所属履歴は、誰がどの期間にどの部門へ属していたかを追える記録です。基準日は「いつの状態を見たいか」という日付です。今日入力した将来の異動と、今日時点の所属を区別できなければ、人事の資料と現場の一覧で違う値が見えても原因を説明できません。

人事、採用、勤怠、給与、ITの仕事を分ける

どの会社・拠点・雇用区分・社員を含め、社員情報のうち何を扱うかを決めます。候補者の管理、入社手続き、評価・育成、勤怠、給与計算、利用アカウントなどを、すべて同時に置き換える前提にはしません。今回対象外の仕組みを残すなら、どの情報をいつ渡し、どの結果を誰が確認するかを範囲へ入れます。

人事・給与・採用が別の製品でも、管理元と連携条件をそろえて運用できる場合があります。一つの製品へまとめても、入力の担当や反映時点が曖昧なら不一致が残ります。自社の変更一件で、どの二重入力を減らし、どの確認を人が残すかを示して比較してください。

勤怠の時間・対象期間・締め・修正版と給与側の取り込みをそろえる話は、勤怠管理と給与計算の連携で扱っています。本稿は、その元になる社員情報自体の管理元、所属の履歴、権限と基準日を主に扱います。

項目の管理元と、同じ人を見分ける方法をそろえる

同じ氏名がある、氏名が変わる、別会社でも同じ番号を使う、といった場面を考え、同じ人を取り違えずに追う方法を決めます。会社、社員の識別、雇用の記録、所属や役割を区別し、どの組合せで一意に見分けるかを提供会社へ確かめます。名前が一致することだけを、同一人物の条件にしないでください。

項目ごとに、入力と更新の責任を分ける

人事台帳、部門の一覧、勤怠・給与・IT側の記録について、どの項目をどこで管理し、誰が変更を受け付け、確認して更新するかを洗い出します。同じ項目を双方で自由に直せる場合は、食い違いをどう発見し、どちらの根拠へ戻るかが必要です。

社員情報の管理元を決めるときの確認例

必要な項目では、名称、意味、入力元、必須か、変更する条件、使う範囲、履歴と確認担当をそろえます。「所属」が主所属なのか、兼務を含むのか、出向元と出向先をどちらも持つのかで、同じ一覧の数字や見える対象が変わります。対象会社で必要な関係だけを具体化してください。

Microsoftの雇用情報のエンティティの公式説明も、雇用の開始・終了、有効期間、会社の識別、人物番号を別の項目として持っています。これは特定の製品・版の構造の例です。自社の雇用関係や社員番号の付け方を、そのまま同じにする根拠にはしません。

変更履歴は、いつ・誰が・何を変えたかに戻れるようにする

現在の値に加え、変更の根拠、入力した担当と時点、変更前後、適用する期間、訂正の理由を必要な範囲で追える条件を決めます。履歴の保管範囲と、誰が確認できるかも要求です。現在の所属だけを上書きして過去の基準日が再現できない場合、過去の資料との違いを説明しにくくなります。

草案登録・承認・有効日・実際の反映を分ける

登録日と有効日は、別の問いに答える日付です。登録日は「いつ情報を入れたか」、予定有効日は「いつから変更したいか」です。承認された時点、実際の反映時点、一覧が表示する基準日も分けて考えます。

架空例の所属変更の草案には、同じ人を照合する目印として仮E-01を置いています。実社員番号ではありません。元の所属は保守部、変更案は品質部です。以下では、番号だけを見出しにせず「所属変更の草案」と呼びます。

この草案では、承認する担当、承認されたか、実際に有効になった日は未確認です。社員の正本が更新されたか、旧所属の履歴が残っているか、周辺の記録へ反映されたかも未確認です。

図で見る問い：所属変更の草案を登録したら、11月1日の所属と見える情報も変わったと言えるでしょうか。10月24日に書いた草案、11月1日からの予定、まだ確かめていない承認・反映・権限を、同じ人の話として分けて見てください。

この解説図を原寸で見る

図の読み方：保守部から品質部へ変えたい草案があることは、承認された、11月1日時点で正本が変わった、必要な人だけが見られるようになったという証拠ではありません。同じ社員について、基準日を指定した表示と変更の記録を、誰が確認すれば分かるかを提供会社へ尋ねます。

基準日を変えたとき、何が見えるべきかを決める

将来の予定を登録した直後に、当日現在の所属まで変更されるのか、予定として別に見えるのかを確認します。過去日を指定した一覧、未来日の一覧、組織図、承認先の選択など、それぞれがどの基準日を使うかをそろえます。「社員情報は新しいのに一覧だけ違う」という場面では、参照する日付や更新時点も調べます。

未提出や差戻しの案がある場合に、正式な所属として使われないこと、予定を取り消した場合に何が残るかも確認します。すべての製品に同じ承認段階があるとは限りません。Microsoftの公式説明にも、草案、確認中、承認後の処理待ち、処理済みなどの区別がありますが、これは同製品の説明です。自社の運用と対象製品の状態名を対応させてください。

誰が誰の何を見て、変更できるかを決める

権限は、部署名だけでなく「対象の社員・項目・操作」の組合せで決めます。人事担当、所属長、本人、IT担当などが、それぞれ何の仕事にどの情報と操作を必要とするかを整理します。製品が用意する役割の名前と、自社で必要な範囲が一致するかを確かめてください。

閲覧、変更、承認、出力を別にする

画面を見ること、値を変更すること、申請を承認すること、一覧を出力することは別の操作です。所属長が部門の社員一覧を見られる場合でも、他部門や過去所属の社員まで見えるか、どの項目が表示されるか、出力に同じ制限が効くかを確認します。人事全体を管理する役割を、そのまま全利用者へ付ける前提にはしません。

この草案で人事に予定する閲覧範囲は、当該変更に必要な項目だけです。ただし、実際に人事が見られた範囲は未確認です。IT担当へ予定する編集権限も実際の編集範囲も未確認です。予定の言葉を、実際の権限設定や十分な管理ができた証拠にはしません。

ITの設定作業と、人事情報の閲覧を必要範囲で結ぶ

IT担当に必要なのが、連携の設定、利用者の管理、障害調査なのかを分けます。その作業のために、どの社員のどの項目を読む・変える必要があるかを、人事と情報管理担当が確認します。「ITだから一切見られない」「設定するからすべて見てよい」と一律に決めるのではなく、製品で分離できる範囲と自社の責任分担を確かめます。

この説明では、給与や家族情報の値は扱いません。制限した情報が実際に見えていないかも未確認です。実在の機微情報を試験用の資料へ出さず、許可された試験データで、見えるべき項目と見えないべき項目の双方を確認します。

異動・代理・退職で、権限が変わる条件を確かめる

所属の異動で参照できる社員が変わる場合、どの日付と根拠で変更し、旧所属の閲覧が残るかを確認します。代理承認や一時的な担当には、対象と期間、終えた後の扱いが必要です。人事の所属変更とアカウント側の権限変更が別処理なら、片方だけ変わった状態の確認先を示します。

履歴や出力された資料にも必要な制限があるかを確認します。保管・閲覧・削除等の条件は、対象会社が適用する規程や要件に基づき決めるもので、この草案から一律の保存期間や法的な適合を認定するものではありません。

入社・異動・退職・訂正の例外を具体化する

通常の所属変更だけでなく、自社で必要な入社・兼務・訂正・退職などを選び、同じ人の識別、期間、状態と後続の仕事を対応させます。すべての例外を全製品共通の必須機能にするのではなく、自社のどの仕事が成立しなければ困るかを示します。

入社予定：予定の存在と、就業開始や利用準備を分ける

もう一つの例は別の入社予定の草案です。目印の仮E-02は別の人物で、所属変更の草案を直した後の姿ではありません。入社予定日は2026年11月10日（架空）で、予定の草案は存在します。

一方、採用の了承、社員の正本の作成、雇用開始の確認はいずれも未確認です。所属への配置と役割の割当ても未確認です。予定日に名前があるだけで、実際に就業を開始したことや、所属長が決まったことにはしません。

必要な準備では、どの段階で社員の記録を作り、誰の確認を受け、予定変更や辞退があればどこまで戻すかを決めます。給与側への連携、アカウントの準備、必要なアクセスの確認も、この例では未確認です。給与計算や利用開始の成功を、入社予定の草案から推測していません。

兼務・出向：一人に一つの所属だけを置いてよいか確認

同じ期間に複数の部門で仕事をする場合は、主所属と兼務、会社と部門、役割と承認先をどう分けるかを確認します。一覧や組織図の人数、所属長の閲覧対象、連携先へ渡す所属が何を意味するかも必要です。一人を複数行で表示する場合、人数を数える条件までそろえます。

日付の変更や遡った訂正：元の履歴と、配った結果を追う

将来の異動日を変更したら、旧予定をどのように区別し、既に周辺へ渡した予定を誰が更新するかを決めます。過去の所属を訂正する場合も、元の記録、訂正理由、適用する期間と、影響する一覧・承認先・連携先を対応させます。現在値だけを変え、過去の基準日で見える内容が意図せず変わらないかを確認します。

承認済みの案を取り消す、入力中に別の担当が同じ項目を変える、といった場合は、どちらの根拠を確認して、どこで保留するかが必要です。最新の値を無条件に上書きするのではなく、競合する対象と版、変更担当へ戻れる条件を求めます。

退職・休職等：人事上の状態と、閲覧・利用の扱いを分ける

人事上の期間、現在の所属、アカウントの利用停止、記録の参照・保管は別の条件です。どの状態になったら、誰が何を変更し、どの記録を確認するかを担当間で決めます。退職予定を入れたことだけで全アカウントが止まった、社員の記録を直ちに削除してよい、という扱いにはしません。

周辺への反映、移行、停止中の扱いを決める

人事側が更新されたことと、他の仕組みが同じ状態になったことを分けて確認します。勤怠、給与、IT側、部門の一覧など、残す連携先ごとに、渡す社員の識別、項目、基準日、送る条件、受け側の結果を決めます。

元の変更から受け側の記録まで、同じ人と日付でたどる

社員や会社の番号が違う製品間では、どの対応情報で同じ人を識別するかを確認します。送るのが承認後の情報か、未来の予定も含むか、受け側でいつ反映するかを示してください。現在値だけを送るのか、適用期間と履歴も必要かで、項目と訂正方法が変わります。

送信できた、受け側が受け付けた、社員の記録へ反映された、必要な人が見られた、という結果を分けます。エラーがなくても、対象者が送信対象から漏れていないかを元側と照合します。結果不明や一部だけの反映では、同じ変更を重ねず、元と先の記録を調べてから再実行の範囲を決める必要があります。

移行：同じ人・同じ基準日・同じ項目で旧と新を比べる

移す社員と期間、現在の所属、将来の予定、履歴、添付資料などの範囲を決めます。番号やコードの変換、重複や欠損を誰が調べるか、旧台帳をどこまで参照するかも必要です。旧側の「現在」と新側の「未来」を比較して違いを誤判定しないよう、基準日と反映状態をそろえます。

件数だけでなく、社員の対応、所属の期間、予定と正式な記録、変更の履歴を必要な範囲で照合します。移行後の権限も別に確認し、旧台帳で全員へ配っていた一覧を、そのまま新しい閲覧権限の正解にはしません。

切替と停止：一方だけ更新された状態を戻せるようにする

切替の基準時点、旧側で受け付ける変更の締切、未処理と未来の予定を引き継ぐ場所、差が出たときの確認担当を決めます。並行して比べる場合は、二つから同じ変更を本番の連携先へ重ねて送らない条件が必要です。

停止中に変更を別の記録へ残すなら、元の社員と変更内容、予定日、承認の状態を対応させます。再開後は既に反映した分と照合し、人事の記録と周辺の更新・閲覧結果を同じ対象で確かめます。緊急の権限変更など別の対応が必要な場合の相談先も、対象会社で決めてください。

同じ人・同じ基準日で、候補の回答と実結果を比べる

製品ごとの機能名を比べるだけでなく、自社の変更一件と必要な例外を同じ条件で示します。人事、所属長、ITの役割ごとに「何を見て、どの操作ができ、何ができないべきか」を決め、提供会社に結果と制限を説明してもらいます。

• 標準機能で合う場合：使う版や利用条件、対象の項目と期間、設定する役割、基準日と反映の動作を確認します。紹介画面だけでなく、同じ社員の表示と変更履歴を見ます。
• 設定・追加対応が必要な場合：不足する条件、誰が何を変更するか、追加費用と保守、将来の項目・組織変更への対応を分けます。その変更を試す条件も確認します。
• 人の運用を残す場合：確認する担当、対象、時点、資料、引き継ぐ結果を具体化します。人事が多忙な時や代理担当でも、更新漏れと過剰な閲覧を見付けられるかを判断します。
• 必須条件に合わない・回答が不明な場合：どの人の、どの状態や操作を確認できないかを明らかにし、追加質問、範囲や候補の見直しへ戻します。未確認を「たぶん設定できる」で合格にしません。

通常の変更と、必要な例外を実際の結果へ結び付ける

1. 試験の前提をそろえる。試せる場所と権限、製品の版・設定、架空の社員と役割、基準日、元の所属と変更案を決めます。実社員の個人情報や本番の承認を説明のために使う必要はありません。
2. 先に期待する状態を決める。草案の間、提出後、必要な承認後、有効日前後に、誰のどの項目がどう見えるかを決めます。自社で承認を使わない場合も、変更を確定する条件を明示します。
3. 同じ人と日付で表示・操作を試す。予定の登録、必要な提出や承認、基準日の切替、正式な所属と履歴の確認を、対象の範囲で通します。予定日や完了表示だけでなく、記録と実際の表示を照合します。
4. 役割を変えて権限を確かめる。人事、所属長、ITなどで、見えるべき社員・項目と、見えてはいけない範囲を確かめます。閲覧だけでなく、変更・承認・検索・出力など必要な操作も対象にします。
5. 例外と周辺の結果を確認する。未提出・差戻し、予定日の変更、兼務、過去の訂正、連携が遅れた状態、停止・再開など、必要な場面を選びます。残る記録、保留する位置、次の確認担当を見ます。
6. 差の原因へ戻り、同じ条件で再確認する。人の違いなら識別、所属の違いなら基準日と履歴、反映の違いなら処理状態、見える範囲の違いなら役割・対象・項目の設定へ戻します。変えた条件と影響する表示・連携を照合します。

まとめ：一人の変更を、記録と権限の確認までつなぐ

人事管理システムの導入前には、対象の社員と情報、項目ごとの管理元、同じ人を見分ける方法、所属や雇用の期間をそろえます。登録日、承認、予定有効日、実際に使う記録の反映を区別し、基準日を指定して過去・当日・将来を説明できる条件が必要です。

権限は、誰がどの社員のどの項目を閲覧・変更・承認・出力するかへ具体化します。異動、入社、訂正や退職、移行と停止時にも、元の記録と履歴、周辺へ渡った結果を追ってください。候補の回答を設定・追加対応・人の仕事へ分け、同じ人と基準日で実際の表示・操作を確かめます。