人事・勤怠管理のAccess活用と移行｜個人情報とアクセス権限の勘所

結論：人事・勤怠のAccessは「個人情報の扱い」が最大の弱点

社員名簿・勤怠集計・評価記録・入退社手続き。人事部門でAccessが担っている業務はこのあたりが中心で、当社への相談案件でも同じ構成が繰り返し登場します。

問題は、これらの業務が扱うデータの性格にあります。氏名・住所・給与・健康状態・評価といった個人情報と機微情報が、ファイル共有型のaccdbに入っている。共有フォルダに置かれた1ファイルをパスワード1つで守っているだけ、というケースが珍しくありません。

この記事では、人事・勤怠部門でよく見るAccessの使われ方と、そこで起きやすい課題、移行を検討するときの勘所を整理します。製造業・販売・経理・建設の事例記事と同様、特定企業の話ではなく当社が支援を通じて経験した典型パターンとしてまとめています。

人事・勤怠でよくあるAccessの使われ方

当社が相談を受ける人事部門のAccessは、大きく4つの用途に分類できます。

これらが1つのaccdbに混在しているケースも多く、「人事担当しか触らないはずなのに、実態は誰でもファイルを開けるフォルダに置いてある」という状況を当社でよく見かけます。

人事・勤怠Accessの4つの課題

1. アクセス権限をファイル単位でしか制御できない

Accessのaccdb形式は、データベースパスワードを設定してファイルを開く/開けないの二択で管理する仕組みです。「社員名簿は人事のみ」「勤怠集計は部門長まで参照可」「評価は閲覧と入力で権限を分ける」といった行レベル・列レベルのアクセス制御は、標準機能では実現できません。

mdb形式には旧来のユーザーレベルセキュリティ機能がありましたが、accdbではこれが廃止されています。人事情報を扱う業務でこの制約はかなり厳しく、「本当はこの項目だけ経営層に見せたい」「退職理由は人事担当しか見てはいけない」という要件を満たす手段がAccess単体にはありません。パスワード保護の具体的な限界についてはAccessのパスワード保護はどこまで守れる？で詳しく解説しています。

2. 持ち出し・漏えいリスクへの対処が難しい

人事情報が入ったaccdbは、そのままコピーして持ち出せます。ファイルの閲覧・コピー・送信の操作ログがAccess単体には残りません。共有フォルダに置いている場合、フォルダのアクセスログはOSやファイルサーバーの設定次第です。「誰がどのレコードを見たか」などの閲覧ログについて、当社で確認した標準構成では、レコード閲覧者を記録する標準機能は確認できていません。変更履歴についてはデータマクロやVBAで独自実装できますが、閲覧を含む網羅的で改ざん耐性のある監査証跡をAccess単体で確保するのは難しいです。

個人情報保護法では、要配慮個人情報の漏えいや財産的被害のおそれがある場合など一定の要件に該当すると報告義務が発生します（具体的な条件の解釈は専門家に確認が必要です）。また、安全管理措置として組織的・技術的な対応が求められます。当社の経験では、内部監査や情報セキュリティの点検を機に「Access管理の限界」に気づくケースが増えています。個人情報をAccessで管理するリスクの全体像は個人情報をAccessで管理するリスクにまとめています。

3. 担当者の退職と属人化

人事部門のAccessは、長年その部門にいた担当者が少しずつ育てていくケースが多く、「この計算式の意味を知っているのは前任者だけ」という状態になりやすいです。勤怠集計の端数処理や、手当の計算ロジック、年度をまたいだ有給残日数の扱いなど、業務ルールがVBAに暗黙に埋め込まれています。

退職時に引き継ぎが間に合わず、「動かし方は分かるが、何をどう計算しているかは分からない」という状態で使い続けているケースを当社ではよく目にします。属人化のリスクと対処についてはAccess属人化の危険度と脱・属人化の進め方を参考にしてください。

4. 法改正・制度変更への追従

人事・労務の業務は法改正の影響を受けやすい領域です。育児介護休業法の改正、割増賃金率の変更、電子申請の要件など、制度が変わるたびにVBAの計算ロジックや帳票の様式を修正する必要があります。修正できる担当者がいれば対応できますが、属人化が進んでいると法改正のたびに修正コストが跳ね上がります。

当社の経験では、「制度変更に対応しようとして、どこを直せばいいか分からなくなった」という相談が人事部門から来ることがあります。Accessの構造が可視化されていないまま修正を積み重ねると、何かを直すと別の計算が崩れる状態になります。

移行を検討するときの判断基準

人事・勤怠Accessの移行を考える際、当社では以下の軸で状況を整理します。

人事情報を扱うAccess特有の判断として、「アクセス権の制御が現状で足りているか」は早めに確認する価値があります。現状のAccessが個人情報保護の観点でどこまでのリスクを抱えているかを把握したい場合は、無料の解析可否チェックから現状整理を始めることもできます。

MicrosoftのライフサイクルページではAccess 2021のサポート終了日が2026年10月13日と掲載されています。人事情報を扱うシステムは移行準備に時間がかかることが多く、データの洗い出し・移行先の選定・権限設計を含めると余裕を持ったスケジュールが必要です。

人事・勤怠Accessの移行先の選択肢

人事・勤怠のAccess移行では、「アクセス権の細かい制御ができるか」と「法改正に追従できるか」が移行先選定の主軸になります。当社の経験から見た傾向を整理します。

勤怠管理については、既製の勤怠SaaSへの切り替えが現実解になるケースが多いです。法改正対応機能やセキュリティ機能を提供している製品もありますが、対応範囲・契約条件・設定内容は製品ごとに異なるため、個別に確認が必要です。また、独自の手当計算ロジックや特殊な勤務形態がある場合は既製品で再現できないことがあります。

社員名簿・評価・スキル管理は、kintoneやPower Appsへの移行が選択肢になります。kintoneでは項目単位の参照権限設定が可能で、Power AppsはDataverseを採用した構成で列レベルセキュリティや監査ログを設定できます（ただしライセンス・設定が必要）。複雑な計算ロジックや独自帳票は再現に手間がかかる点には注意が必要です。移行先の詳しい比較はAccessの移行先を比較でまとめています。

より細かい権限制御と操作ログが必要な場合、SQL Serverへのバックエンド移行が選択肢になります。Accessのフォームを残したままデータだけSQL Serverへ移す構成では、SQL Server側で利用者ごとの認証・権限・監査ポリシーを設計・設定することでデータ保護を強化できます（設計は別途必要です）。この構成の概要はAccessの画面はそのまま、データだけSQL Serverへ移す構成で解説しています。

移行前に確認しておくべきこと

人事・勤怠Accessの移行で、後から問題になりやすい点を当社の経験から挙げます。

• 勤怠・給与計算のロジック：残業時間の端数処理・深夜割増の適用条件・有給残日数の計算など、業務ルールがVBAに埋め込まれています。移行前にロジックを文書化しておかないと、移行先で同じ計算結果を再現できません。
• 退職者・休職者データの扱い：退職した社員のデータをどこまで移行先に持ち込むか、または参照専用で残すかを事前に決めておく必要があります。個人情報の保持期間ポリシーがあれば移行のタイミングで整備できます。
• 給与ソフト・勤怠システムとのデータ連携：勤怠データをExcel経由で給与ソフトに渡す運用がVBAで自動化されている場合、移行後の連携方法を並行して設計しないと手作業が増えます。
• 帳票の様式：在籍証明書・源泉徴収票の補助資料・研修修了証など、帳票の様式が細かく決まっていることがあります。移行先での再現可否と印刷レイアウトは早い段階で確認が必要です。

これらの洗い出しは移行前の業務フロー調査で行います。調査の進め方はAccess移行前の業務フロー調査に整理しています。

よくある質問

Q. 人事情報が入ったAccessにパスワードをかけていれば、セキュリティは十分ですか。

ファイルを開く/開けないの制御はできますが、ファイルを開けた後の閲覧操作はAccessには記録されません。変更については、データマクロやVBAで変更履歴を別テーブルに記録する実装は可能ですが、標準状態では自動的な監査履歴として記録されません。またパスワードを知っている人はファイルをコピーして持ち出すことも可能です。個人情報を扱う業務では、このレベルの保護では不十分なケースが多く、SQL Serverに適切な権限・監査ポリシーを設定する構成や、アクセス制御機能を持つクラウドサービスへの移行を当社では勧めることが多いです。

Q. 勤怠計算のロジックがVBAに入っています。移行先で同じ計算ができますか。

移行先によってできる・できないが変わります。kintoneやPower Appsの標準ノーコード機能だけでは、既存VBAの複雑な計算をそのまま再現できない場合があります。JavaScript・Power Fx・外部サービスとの連携で拡張できるケースもありますが、移行コストとのバランスを検討する必要があります。SQL Serverへのバックエンド移行（アップサイジング）ではAccessのフォームやVBAを継続利用できる場合がありますが、クエリの互換性確認やコード修正が必要になることもあります。どちらの場合も、ロジックの複雑さと移行先の相性を事前に確認することが重要です。

Q. 作った担当者がもういない人事AccessはVBAのロジックを読み解けますか。

ファイルを開いてコードが確認できる状態であれば、VBAの内容を読み解くことは可能です。ただしパスワード保護されたVBAプロジェクトやACCDE形式の場合、コードが参照できず解析の範囲が限られます。まずファイルの状態確認から始めることになります。仕様書も担当者もいない状態のAccessへの対処についてはAccess属人化の危険度と脱・属人化の進め方も参考にしてください。

Q. 人事部門のAccess移行はどのくらいの期間がかかりますか。

対象業務の範囲と複雑さによります。当社の経験では、社員名簿と勤怠集計のみで給与ソフト連携も単純なケースは3〜5か月が目安です。評価管理・スキル管理・入退社手続き管理が一体化したAccess、かつVBAに複雑な計算ロジックがある場合は業務フロー調査だけで1〜2か月かかることがあります。Access 2021のサポート終了（2026年10月13日）から逆算すると、2026年初頭には着手できる状態を整えておくのが安全です。