人事データベース設計の正解は「項目一覧」ではない｜正本・履歴・権限の決め方

項目一覧をコピーしても、人事データベースにならない

「所属部署」という列があっても、その値が給与システム、組織図、チャットのどれを正しい情報としているか決まっていなければ、異なる値が並びます。「役職」という列があっても、現在値だけを上書きすると、昨年の評価を現在の役職で集計してしまいます。

必要なのは、列の名前より次の答えです。

• この項目は、どの業務・判断に使うのか
• 複数の値があるとき、どの場所を正しい情報として扱うのか
• 現在の値だけでよいか、過去の変化を残すか
• 誰が、どの出来事をきっかけに更新するのか
• 誰が、誰の、どの項目を、どこまで操作できるか

これらを決めずに項目だけ増やすと、入力欄は豊富でも判断には使えないデータベースになります。

人事データは「現在値・履歴・証拠」の3層に分ける

現在値だけでは過去を説明できず、履歴だけでは今日の組織図をすぐ作れません。証拠となる文書をすべて列へ転記すると、情報が重複します。3層を役割で分け、現在値から必要な履歴・証拠へたどれるようにします。

項目定義書で決める13列

人事データの項目定義書には、次の列を用意します。これがシステム選定、移行、権限設定、連携の共通資料になります。

1. 項目ID
2. 項目名
3. 利用目的
4. データ型
5. 正しい情報の参照元
6. 現在値または履歴
7. 更新者
8. 更新タイミング
9. 閲覧範囲
10. 編集範囲
11. 保存期間
12. 連携先
13. 備考・例外

最初に持つ項目は、業務を動かす最小構成にする

法定の労働者名簿に必要な情報と、日々の人事・情シス業務を動かす項目を分けて考えます。最初から評価コメントや詳細なスキルまで集めず、更新できる範囲から始めます。

識別と在籍

社員ID、氏名、表示名、在籍状況、入社日、退職日。社員IDは再利用せず、氏名が変わっても同じ人として追えるようにします。

組織と役割

主所属、兼務部署、上長、役職、職種、等級、勤務地。部署名や上長名を自由記述にせず、組織・従業員を参照します。

雇用と連絡

雇用区分、契約期間、勤務区分、社用メール。個人メール・住所・緊急連絡先は利用目的と閲覧者を限定します。

育成と配置

資格、スキル、研修履歴、評価期間、確定した評価結果。自己申告、上長確認、証明済みを同じ値として混ぜないようにします。

情シスとの接続

貸与端末、利用中SaaS、アカウント状態。人事の在籍・所属・役割が変わったとき、必要なアクセスも変わる設計にします。

25項目の記入例つきCSVを、自社の目的に合わせて削るところから始めてください。

「あれば使える」だけの項目は収集しない

人事データは、集められることと、集める必要があることが同じではありません。項目を追加する前に、次の5問へ答えます。

1. この情報がないと、どの業務・判断ができないのか
2. 本人は、収集目的と利用者を合理的に予測できるか
3. 正しい状態を維持できる更新者と確認時期があるか
4. より機微性の低い情報で同じ目的を達成できないか
5. 不要になった時点を判定し、削除または利用停止できるか

「将来分析に使うかもしれない」「入力欄が用意されている」という理由だけでは、収集目的になりません。健康、家庭、私生活、自由記述の面談メモなどは、特に利用目的・閲覧者・保存期間を限定します。

所属・役職・評価を上書きすると、過去の分析が変わる

所属や役職を一つのセルで上書きすると、過去の出来事まで現在の組織に見えてしまいます。たとえば、昨年は営業部だった人が今年プロダクト部へ異動した場合、昨年の評価や勤怠をどちらの部署で集計するかが曖昧になります。

変化する項目は、次の形で履歴を残します。

組織図には現在値を使い、過去の分析には対象日時点の履歴を使います。「現在」と「当時」を同じ列で済ませないことがポイントです。

権限は「誰が × 誰の × どの項目 × 何をする」で決める

「人事」「管理職」「本人」という役割だけでは粗すぎます。次の4軸を組み合わせます。

1. 利用者：本人、上長、人事、労務、情シス、経営、監査担当。
2. 対象者：自分、直属部下、自部署、担当会社、全社。
3. 項目：公開プロフィール、雇用、評価、給与、連絡先、健康、IT資産。
4. 操作：閲覧、申請、編集、承認、出力、権限変更。

個人情報保護委員会も、アクセス権限の最小化と、必要な人・機能だけに絞る考え方を示しています。人事部全員へ給与・健康・個人連絡先を一律公開するのではなく、担当業務に必要な範囲へ分けます。

更新頻度ではなく「更新を起こす出来事」を決める

「毎月見直す」だけでは、月初の異動が月末まで反映されません。変化の原因となる出来事と更新期限を決めます。

各項目に「最終更新日」だけでなく「最終確認日」を持つと、値が変わらなかった項目も確認済みか判断できます。

人事データベースは、3人の架空ケースで検証する

項目表を眺めるより、次の3ケースを通すと欠落が見つかります。

1. 新入社員

内定承諾から入社日までに、社員ID・所属・上長・端末・アカウント・オンボーディング担当が一度の登録からつながるか。

2. 異動・昇格する社員

新しい組織図と権限は適用日から変わり、過去の評価や費用は当時の所属で残るか。旧部署のSaaS権限が残らないか。

3. 退職する業務委託

雇用区分にかかわらず、最終稼働日、端末返却、アカウント停止、文書の所有権移管がつながるか。

この3ケースで人事・情シス・現場が別々の表へ再入力するなら、項目は揃っていても「一つの正しい情報源」にはなっていません。

人事AIの精度は、モデルより「データの正しさと権限」で決まる

AIに「来月入社する人の準備状況」「この部署の離職率」「資格が切れる人」を聞いても、元データが古ければ答えも古くなります。さらに、AIが全データを読める設定なら、画面では隠していた給与や健康情報を回答してしまう危険があります。

人事AIを使う前に、次の条件を満たします。

• 同じ項目の正しい参照元が一つに決まっている
• 現在値と履歴を日時で区別できる
• 質問した人の権限に応じて、AIが参照できる項目も変わる
• 回答に使った時点・対象範囲・根拠を確認できる
• AIが提案した変更は、人が確認してから反映する

AI機能を追加する前にデータ設計を整えるほうが、誤答・情報漏えい・判断のやり直しを減らせます。

ChordOneで人事データと実務をつなぐ

ChordOneは、従業員台帳を組織図、採用、評価、サーベイ、SaaS・端末管理、ChordOne Noteと同じ基盤で扱います。

• ノートの管理表から、従業員・部署を文字ではなく参照して選ぶ
• 利用者が見られる人事項目だけを、ノートの管理表へ表示する
• 入社・異動・退職の情報を組織図や情シス業務へつなぐ
• 個人用ノートは管理者にも本文を見せず、必要なページだけ共有する

項目数の多さではなく、会社の正しい従業員情報が、実際の入社準備・評価・権限管理・文書へつながることを重視しています。

よくある質問

Q. 人事データベースには何項目必要ですか？

会社規模で一律には決まりません。まず入社・異動・退職・組織図を動かす基礎項目から始め、利用目的、更新者、権限を説明できない項目は追加を保留します。

Q. Excelでも設計できますか？

項目定義や試験運用は可能です。ただし、履歴、複数人の更新、項目別権限、他システム連携が増えると運用負担が上がります。CSVテンプレートで要件を整理し、必要な機能を確認してください。

Q. 所属や役職は現在値だけでよいですか？

現在の組織図だけなら現在値が必要です。過去の評価・勤怠・費用を当時の所属で分析するなら、開始日・終了日を持つ履歴も残します。

Q. 権限は部署単位で十分ですか？

給与、健康、個人連絡先、評価コメントなどは部署単位だけでは広すぎる場合があります。利用者・対象者・項目・操作の4軸で必要最小限にします。

関連記事

• 人事マスタとは？従業員情報を一元管理しないと起きる問題
• 社員名簿・組織図・SaaS管理を一つにつなぐ設計
• 社内Wikiと人事データがつながると何が変わる？