Accessで社員名簿・社員管理を作る｜項目設計と運用の注意

結論：Accessで社員名簿は作れるが、個人情報の保護に構造的な限界がある

氏名・所属部署・入退社日・緊急連絡先といった基本項目を管理する社員名簿であれば、Accessで十分に構築できます。テーブルに社員情報を格納し、入力フォームと検索画面を乗せるのはAccessが得意とする用途のひとつです。

ただし社員名簿は個人情報を扱います。Accessのファイル共有型という構造上、アクセス権限を細かく制御しにくい点に注意が必要です。この記事では、テーブル設計の考え方から帳票・運用の注意点まで、実務的な作り方を整理します。

社員マスタのテーブル設計：項目と分割の考え方

社員名簿を作る最初の判断は「1つのテーブルに全部入れるか、分けるか」です。Excelの感覚で全項目を1シートに並べたくなりますが、Accessでは正規化を意識してテーブルを分けるのが基本です。

社員マスタには、1人の社員に対して値が1つしかつかない項目を集めます。部署や役職は変わることがあり、異動履歴を残したい場合は別テーブルに分けます。

正規化の詳しい考え方はAccessのテーブル設計と正規化の基礎で解説しています。社員番号は自動採番（オートナンバー型）でも手動採番でも構いませんが、会社の規則に合わせた形式を使うなら短いテキスト型で管理するほうが実務に合うことが多いです。

入力フォームと検索の設計

テーブルを直接開いて入力することも技術的にはできますが、実務では専用フォームを作るのが普通です。コンボボックスで部署や役職をリストから選ばせれば入力ミスが減り、必須項目にはNull値を受け付けないよう入力チェックをかけられます。

検索画面は「氏名・読み・社員番号・所属部署・在籍フラグ」で絞り込める構成が使いやすいです。クエリの抽出条件にフォームのコントロールを参照させる形が基本で、例えば退職者を除きたいときは「退職日がNullのレコードのみ表示」という条件をクエリに組み込みます。

フォームとレポートの役割の違いについてはAccessのフォームとレポートの入門も参考になります。

よく使う帳票：名簿・証明書の下書き

社員名簿でよく作られる帳票を整理します。

Accessのレポートはページをまたいだ繰り返し出力が得意で、部署ごとの改ページや連番の自動付与も設定できます。ただし証明書類など様式が厳密に定まった書類については、当社の経験ではレポートの余白・フォントサイズの微調整に時間がかかることがあります。

個人情報の取り扱いと運用上の注意

社員名簿には氏名・住所・生年月日・家族情報など個人情報が含まれます。Accessはファイル共有型のため、情報の取り扱いには以下の点に注意が必要です。

まずアクセス制御の範囲です。accdb形式はデータベースパスワードを設定することでファイルを開く・開けないの制御はできますが、ファイルを開いた後に「社員番号と氏名は全員閲覧可・住所と家族情報は人事担当のみ」といった列単位・行単位のアクセス制御は標準機能では実現できません。Access 2007以降のaccdbではユーザーレベルセキュリティ機能が廃止されているためです。パスワード保護の具体的な限界についてはAccessのパスワード保護の実力と限界で解説しています。

次に持ち出しリスクです。個人情報が入ったaccdbファイルは、パスワードを知っている人であればそのままコピーして持ち出すことができます。誰がどのレコードを参照したかのログをAccess単体で記録する標準機能は確認できていません。変更履歴についてはデータマクロやVBAで別テーブルに記録することは可能ですが、参照ログを含む網羅的な監査証跡をAccess単体で確保するのは難しい状況です。

個人情報を扱う業務システムでは、個人情報の取り扱いについて適切な管理体制を整えることが求められます。具体的な法令上の要件は専門家への確認が必要ですが、「共有フォルダに置いてパスワードだけかけている」構成では、担当者以外もファイルを閲覧できる状態になっていないか確認する価値があります。

退職者データの扱いも決めておく必要があります。退職日を入れてフラグ管理するだけでは、データ自体は残り続けます。個人情報の保管期限ルールを事前に決め、Accessの設計に反映しておくことをお勧めします。

複数人で使うときの注意と限界

人事担当が1人でローカル管理している場合は問題が起きにくいですが、複数人が同時にAccess社員名簿を参照・入力する構成では別の問題が出ます。

共有フォルダに置いたaccdbを複数人が同時に開く構成は、Accessのファイル共有型という仕組み上、接続が増えると動作が重くなりやすく、ネットワーク障害が重なるとファイル破損のリスクも高まります。同時利用の問題についてはAccessの複数人同時利用と速度低下で詳しく解説しています。

人事担当以外も一覧を参照したい場合など、複数人が同時にアクセスするケースでは、バックエンドにSQL Serverを使ってフロントエンドのAccessからリンクテーブルで接続する構成が実務的な選択肢になります。この構成ではAccess側の画面はほぼそのままに、SQL Server側でユーザー別の権限制御や操作ログを設定できます。

現在の社員管理Accessが移行できる状態かどうかを確かめたい場合は、無料の解析可否チェックで現状整理を始めることもできます。

よくある質問

Q. Excelで管理している社員名簿をAccessに移せますか？

Excelシートをインポートする機能はありますが、セル結合・複数種類の情報が混在するシートでは取り込み後に修正が必要です。当社の経験では、1シートに社員情報と連絡先が混在しているようなExcelは、インポート後の修正より最初からテーブルを設計し直した方が早く終わることがあります。

Q. 社員番号はオートナンバー型にすべきですか？

主キーとしてオートナンバー型を使うこと自体は問題ありません。ただし「会社の社員番号体系（例：入社年度＋連番）」を管理したい場合は、オートナンバーとは別に社員番号フィールドを設け、そちらに入力する形にする方が実務に合います。オートナンバー型の値は削除したレコードの番号が再利用されないため、欠番が出るという点にも注意が必要です。

Q. 退職した社員のデータはどう管理しますか？

退職日フィールドを設けて退職日を入力し、検索・帳票の抽出条件で在籍中のみを絞り込むのが一般的な対処です。ただしデータを残し続けると保管期限の問題が出ます。社員名簿に含まれる情報の種類によっては、労働関連法令など他の法令による保存義務が課される場合もあります。社内ルールで保管期限を定める前に、対象データに適用される法令上の要件を専門家に確認することをお勧めします。期限を決めたら、退職者データの削除または別保管の手順を運用設計に含めておいてください。

Q. 社員情報のAccessを複数の管理職に参照させたいのですが、全員に同じパスワードを教えるしかないですか？

accdbの標準機能では、開く・開けないの制御がデータベースパスワード1つになります。閲覧できる人を増やしたいが参照できる情報を制限したいという要件が出てきた場合、Access単体では対応が難しくなります。SQL Serverへのバックエンド移行か、アクセス権管理機能を持つクラウドサービスへの移行が現実的な解になります。管理台帳一般の設計についてはAccessで管理台帳を作る設計の考え方もあわせて参考にしてください。