工務店・ハウスメーカーのアクセス権管理 入社・異動・退職時の運用

実務では、システムごとに設定を始める前に、「誰が申請し、誰が承認し、誰が設定し、誰が完了を照合するか」を一本の運用にまとめることが重要です。本記事では、入社・異動・退職を同じ権限台帳で処理し、設定漏れや過剰権限を見つけるところまでを扱います。個別製品の操作方法ではなく、工務店が自社で再現できる判断順序と記入様式に絞ります。

01.アクセス権管理を「アカウント発行作業」にしない

アクセス権管理とは、メールアドレスやパスワードを発行するだけの仕事ではありません。顧客名簿を閲覧できる、見積金額を変更できる、発注を確定できる、図面を社外共有できる、原価を閲覧できるといった「業務上できること」を、必要な人に必要な期間だけ認める仕事です。

工務店では、一人が営業、積算、現場支援を兼務することがあります。少人数だから全員に同じ権限を与えると早く見えますが、誤操作が起きたときに影響範囲が広がり、誰が何を変更したかも追いにくくなります。反対に、権限を細かく絞りすぎると、現場で必要な資料が開けず、個人のメールや私物端末への転送が始まるおそれがあります。

目標は「最も厳しくすること」ではなく、業務を止めずに説明できる状態をつくることです。少なくとも次の四つに答えられれば、アクセス権管理を設定作業から経営管理へ移せます。

この表から読み取るべきなのは、アカウントの有無だけでは管理が足りないという点です。「できること」「理由」「期間」を一緒に残して初めて、異動や退職の際に何を外すべきか判断できます。

情報管理は、担当者だけに任せるテーマでもありません。IPAの「中小企業の情報セキュリティ対策ガイドライン」は、経営者編と実践編に分けて中小企業の段階的な対策と運用を扱っています。アクセス権管理も、経営者が方針と責任者を決め、現場が実行できる形へ落とす必要があります。

一方、本記事で示す権限台帳、申請票、当日確認表は、IPAが個々の工務店に義務づける公式様式ではありません。一次資料の考え方を踏まえ、少人数の工務店でも漏れを見つけやすくするための運用提案です。

02.最初に管理対象と責任者を一枚にする

いきなり全社員の権限を調べ始めると、メール、施工管理、クラウドストレージ、会計、複合機などが別々の一覧になり、照合できなくなります。最初に作るべきものは「システム管理台帳」です。何があるか、誰が管理しているか、利用者をどこで確認できるかを一枚にします。

対象は、いわゆる業務システムだけではありません。共有メール、ファイルサーバー、NAS、Wi-Fi、複合機のスキャン先、SNS、写真共有、電子契約、Webサイト管理画面、銀行やカードのオンラインサービスも候補です。取引先が用意した現場ポータルも、自社社員が使うなら把握しておきます。

管理対象を棚卸しする単位

製品名だけではなく、「どの情報に到達できるか」で整理します。同じクラウドストレージでも、施工写真フォルダと経営資料フォルダでは、認める範囲が異なるからです。

ここで読み取るのは、業務の責任者と設定担当者を分ける必要があることです。営業管理システムの技術的な設定ができる人でも、新入社員に全顧客の閲覧を認めるべきかは単独で決められません。必要性は業務責任者が判断し、設定担当者は承認内容どおりに作業します。

小規模な工務店では、一人が複数の役割を兼ねても構いません。ただし、台帳上の役割まで曖昧にしないことが大切です。社長が申請承認と設定を兼ねるなら、完了後の照合だけは管理部担当者が行うなど、誤設定を見つける機会を残します。

管理対象の追加や入れ替えが進んでいる会社は、権限設定より前に導入目的を整理したほうがよい場合があります。その場合は、工務店のDX計画｜導入する前に業務の目的を決めるで、業務とシステムの対応関係を先に整えてください。

03.職種名ではなく「業務・範囲・操作」で権限を決める

「営業だから営業システムを使える」「現場監督だから施工管理を使える」という決め方だけでは、権限が粗すぎます。同じ営業でも、新規客の登録だけを担う人と、契約条件を承認する責任者では必要な操作が違います。同じ現場監督でも、自分の担当案件だけを見る人と、全現場の応援配置を決める人では閲覧範囲が異なります。

権限は、次の三つに分けて判断します。

• 業務：何の仕事を担当するか
• 範囲：どの顧客、案件、部署、期間を対象にするか
• 操作：閲覧、登録、変更、承認、削除、出力、共有のどこまで認めるか

この分解をすると、「施工管理システムを使わせるか」という二択ではなく、「担当する二案件について、図面と写真の閲覧・登録は可能、原価変更と協力会社招待は不可」と具体化できます。

標準権限と個別追加を分ける

毎回ゼロから考えると、承認者によって判断が変わります。まず職務ごとの標準権限を作り、案件責任者、兼務、期間限定応援などを個別追加として扱います。

この表からは、役職が上ならすべての編集権限が必要とは限らないことが分かります。経営者は全社の数値を確認できても、日常的な顧客情報の削除や工程変更まで行う必要がない場合があります。閲覧権限と作業権限を分ければ、経営判断を妨げずに誤操作の範囲を狭められます。

給与や社会保険の手続で扱う従業員のマイナンバー（特定個人情報）は、他の情報とは別の扱いが必要です。番号法と個人情報保護委員会のガイドラインでは、事務を扱う担当者を明確にすること、担当者以外がアクセスできないように制御することなどの安全管理措置が求められています。経営者であっても、事務取扱担当者でなければ閲覧できない設定にするのが基本です。中小規模の事業者向けの特例を含め、自社に必要な措置は個人情報保護委員会「特定個人情報の適正な取扱いに関するガイドライン（事業者編）」で確認し、事務取扱担当者の異動や退職時には、この権限を最優先で外します。

標準権限は完成品ではありません。実際のシステムに該当する設定がなければ、「システム上は編集者だが、運用上は削除しない」といった補助ルールが必要です。ただし、守れないほど細かな禁止事項を紙に増やすのではなく、製品選定や設定変更で改善できないかも検討します。

これからシステムを選ぶ段階なら、必要な権限区分を選定条件に入れます。工務店の業務システム比較｜現場で使える選定表を作るの比較表に、「案件単位で閲覧範囲を分けられるか」「承認と編集を分けられるか」「利用者一覧を出せるか」を追加すると、導入後の管理可能性まで比較できます。

04.申請から照合までを一つの流れにする

権限付与の事故は、設定担当者の操作ミスだけで起きるわけではありません。上司から口頭で「今日から使えるようにして」と頼まれ、どの範囲が必要か分からないまま既存社員を複製した結果、原価や給与まで見えることがあります。

申請、承認、設定、照合を分け、それぞれの記録を残します。少人数で担当者を完全に分離できなくても、同じ人が思いつきで申請から完了まで進めない順序にすることはできます。

この模式図で重要なのは、設定が最後ではないことです。本人が必要な画面を開けるか、不要な範囲まで見えていないかを確認し、その結果を台帳に反映して初めて完了です。

申請票は、長い稟議書にする必要はありません。次の項目がそろえば、チャットや口頭依頼より判断しやすくなります。

この表は、そのまま紙や表計算の申請票として使えます。特に「不要操作」を書く欄が有効です。必要な権限だけを尋ねると、申請者はシステムの機能一覧を理解していないため、「現場監督と同じ」で済ませがちです。認めない操作まで言語化すると、承認者と設定者の認識差を見つけられます。

緊急時を除き、設定担当者は承認のない依頼を処理しないルールにします。「社長に言われた」という伝言だけではなく、社長本人の承認記録を残します。承認のために業務を止めないよう、通常申請の締切と緊急申請の連絡先を先に決めておくことも必要です。

05.入社時は初日に合わせて逆算する

入社時の目的は、初日の朝にすべてのシステムへ入れる状態をつくることではありません。初日に担当する業務を始められ、まだ説明を受けていない重要操作はできない状態をつくることです。

内定から入社までに担当業務が変わることもあります。採用時の職種名をそのまま設定依頼に使わず、入社日の数営業日前に直属責任者が実際の初期業務を確定します。未確定の案件は無理に付与せず、配属後の追加申請に回します。

ここからは、運用を具体化するために一つの架空例を使います。実在する会社、人物、成果ではありません。

架空の工務店「松風工務店」は、社員18人、1拠点で注文住宅とリフォームを扱っています。管理対象はメール、予定表、顧客・営業管理、見積・原価管理、施工管理、クラウドストレージ、会計です。情報管理担当は総務1人、各システムの権限承認者は営業部長、工事部長、管理部長に分かれています。

2026年10月1日に、現場監督の「山田太郎」が入社します。入社時点で担当するのは新築A邸と改修B邸の2案件です。見積作成、発注確定、支払承認は担当しません。この条件を途中で変えずに、入社、異動、退職の処理を追います。

入社前に確定する内容

山田さんには、メールと予定表、工事部共通フォルダ、施工管理のA邸・B邸を付与します。施工管理では、工程更新、写真登録、図面閲覧を認めます。全現場一覧、原価変更、利用者招待は認めません。

端末もアクセス権の一部として扱います。会社支給PCとスマートフォンの識別番号、貸与日、返却予定、画面ロックの設定確認、業務アカウントの登録状況を端末台帳に記録します。個人所有端末の利用を認めるかどうかは、自社の方針と利用サービスの条件を確認したうえで別途決めます。

この表から、入社日を「付与日」だけで終わらせないことが読み取れます。初日はログイン確認、3営業日以内は権限の過不足、30日以内は実際の担当との差を確認するという三段階にすると、採用時の想定を引きずりにくくなります。

初回ログインでは、本人が必要な画面へ到達できることに加え、不要な全社フォルダや他案件が見えないことも確認します。確認用に顧客の実データを画面撮影して残す必要はありません。「A邸工程閲覧可」「全現場一覧は表示なし」のように結果だけを記録します。

個人情報を含む顧客情報については、権限設定だけで対応が完結するわけではありません。個人情報保護委員会の「個人情報保護法ガイドライン（通則編）」は、個人情報の利用目的、安全管理、適正な取扱いなどを扱っています。どの情報を入力・保存し、誰と共有するかは具体的な利用条件に応じて確認し、アクセス権の運用と結びつけます。

本記事の「入社後3営業日以内」「30日以内」という日数は法令上の一律期限として示すものではありません。松風工務店が漏れを早期発見するために採用した架空の社内期限です。自社では給与締日、配属決定日、管理担当者の勤務日を踏まえて設定してください。

06.異動時は追加より先に不要権限を見つける

異動時には、新しい部署の権限を足すことへ意識が向きます。しかし、アクセス権管理で難しいのは旧業務の権限をいつ外すかです。引き継ぎがあるため即時削除できないケースが多く、「念のため残す」が積み重なります。

異動は、所属変更だけを指しません。営業から設計への職種変更、現場担当の交代、管理職就任、兼務開始、長期応援、休職、復職、担当エリア変更も対象です。人事上の異動通知が出ない案件交代まで拾えるよう、現場責任者が申請できる入口を用意します。

松風工務店では、山田さんが2027年4月1日付で現場監督から積算担当へ異動するものとします。A邸は3月末に後任へ引き継ぎ、B邸だけは4月15日まで問い合わせ対応を行います。新しい仕事では、見積対象案件の数量と単価を編集しますが、発注確定と支払情報の閲覧は行いません。

この模式図の要点は、新権限の追加より前に旧権限を分類することです。「新しい権限を追加してから、暇なときに古い権限を整理する」という順番では、一時継続の終了日が記録されません。

旧権限を三つに分ける

「終了」は異動日または引き継ぎ完了日に外します。「一時継続」は対象案件と終了日時を決めます。「共通」は全社員向けのメールや就業規則フォルダなど、異動後も必要な権限です。

この表を見ると、異動日だけでは処理できない権限があると分かります。B邸のような一時継続には、対象、理由、期限の三点が必要です。「引き継ぎが終わるまで」ではなく、終了日時を置き、延長する場合は再承認します。

異動日に新旧すべての権限を一括で入れ替えると、引き継ぎ中の資料が読めなくなることがあります。反対に、後任へデータを渡すため、個人のPCへ大量に保存させるのも適切ではありません。システム内の担当者変更、共有フォルダへの移動、正式な共有機能など、会社が管理できる場所で引き継ぎます。

管理職への昇格でも、部下と同じ編集権限を単純に足すのではなく、承認権限と閲覧範囲を確認します。部門全体の状況を見る必要があっても、全データの削除や出力が必要とは限りません。システムの仕様上分離できない場合は、その制約を台帳に記録し、操作履歴の確認や承認手続で補います。

休職時は、復職の可能性だけを理由に通常利用のまま残さないことが基本です。ただし、停止した場合にメール受信、担当引き継ぎ、自動通知、ライセンス、保存データがどうなるかはサービスごとに異なります。停止、転送、代理対応などの設定を一律に断定せず、社内方針と各サービスの仕様を確認して決めます。

07.退職時は「アカウント停止」と「業務の回収」を分ける

退職処理では、アカウントを消せば完了と思いがちです。しかし、先に削除すると、会社が保管すべき業務資料やメールの所在が分からなくなることがあります。反対に、引き継ぎを理由に停止を延ばすと、退職後も本人がアクセスできる状態が残ります。

そのため、退職日までに業務データと管理権限を会社側へ移し、最終利用時刻に本人のアクセスを止め、その後に保管・削除を判断します。「引き継ぎ」と「停止」と「削除」を別の作業として管理するのが要点です。

松風工務店では、山田さんが2028年3月31日に退職し、最終出勤日は3月27日とします。3月28日から31日までは出勤予定がなく、会社との合意に基づく通常の退職手続が進んでいるという架空条件です。具体的な労務判断や個別事情は別途確認が必要であり、ここでは情報アクセスの処理だけを扱います。

この模式図から読み取れるのは、アカウント停止前に「本人しか管理できないもの」をなくす必要があることです。一方、退職後の利用を防ぐため、データ移管と停止を同じ作業に混ぜず、それぞれに完了条件を持たせます。

退職前に回収するもの

対象は会社支給PCやスマートフォンだけではありません。入館用カード、鍵、USBメモリ、認証用機器、紙の顧客名簿、図面、現場写真、会社名義のSNS、共有メールの管理権限も確認します。

本人のアカウントを使って複数人がログインしていた場合、退職者のパスワードだけを変えても影響範囲が分かりません。共有利用を直ちに全面解消できなければ、利用者、用途、変更日時を記録し、個人別アカウントへ移す期限を決めます。

この表で注目すべきなのは、停止後の照合列です。設定担当者が「停止ボタンを押した」と報告しても、共有リンク、別名アカウント、スマートフォンの同期、取引先側のアカウントが残る可能性があります。各管理画面や台帳で、本人が到達できる経路をもう一度たどります。

停止日時を曖昧にしない

退職日は日付ですが、アクセス停止は時刻まで必要です。「最終出勤日の17時30分」「会社支給端末の返却と最終作業確認が終わった時点」など、自社で実行できる条件を申請票に書きます。

ただし、退職を知る範囲や告知時期には配慮が必要です。情報管理担当者には設定に必要な範囲だけ共有し、全社員へ早すぎる告知をしない運用も考えられます。通常退職、契約満了、突然の退職などで対応が変わる場合は、経営者、人事・労務担当、業務責任者が連携し、情報管理担当者だけに判断を背負わせません。

アカウント削除の時期は、停止と同日に固定しません。メール、ファイル、案件履歴、操作記録など、会社側で必要な情報の移管と保管方法を確認してから判断します。保存期間や取扱いは、情報の種類、契約、法令、社内規程など具体条件によって異なるため、根拠を確認せず一律の年数を設定しないようにします。

08.協力会社・短期利用・共有アカウントを例外のまま放置しない

工務店のアクセス権は、社員だけを管理しても完成しません。協力会社、設計事務所、撮影担当者、保守会社、派遣スタッフなど、期間限定で情報へ接する人がいます。社内の人事異動に連動しないため、終了日を決めないと権限が残りやすい領域です。

外部利用者には、会社単位の管理だけでなく、実際に利用する人、対象案件、必要操作、招待者、終了日を記録します。「○○設備さん」という名前だけでは、その会社で担当者が交代したときに利用実態を追えません。

この表からは、例外だから記録を減らすのではなく、期限と実利用者を通常より明確にする必要があると分かります。短期利用は開始が急な一方、終了の連絡が管理担当者へ届きにくいためです。

共有アカウントは利用者を見えなくする

複合機の送信、現場掲示用端末、SNSなどで、共有アカウントを使わざるを得ない場面はあります。ただし、誰が操作したかを個人単位で追いにくく、退職者だけを止めることも困難です。

すぐに個人別へ切り替えられない場合は、少なくとも用途、利用者、管理責任者、認証情報の変更日、保管方法を台帳に記録します。利用者が一人抜けたときは、認証情報を変更し、残る利用者へ安全な方法で再設定します。チャットの過去ログに新しい認証情報を恒久的に残す運用は避けます。

緊急権限には終わりを先に書く

現場トラブルで担当外の監督が図面を見る、休暇中の承認者に代わって別の責任者が処理するなど、緊急付与が必要なことはあります。緊急時に通常の申請を完全に省略するのではなく、付与者、理由、対象、終了時刻を最低限記録し、事後承認の期限を設けます。

たとえば「本日中に必要」ではなく、「C邸の検査是正資料を閲覧するため、2027年8月6日9時から18時まで」のように限定します。作業が終わったら自動的に解除される設定が使える場合は活用し、使えない場合は解除担当者の予定に登録します。

例外を増やすほど、通常ルールは形骸化します。同じ緊急付与が月に何度も発生するなら、それは例外ではなく標準権限や代理承認の設計不足です。記録を責任追及だけに使わず、標準権限を直す材料にします。

09.権限台帳は人別とシステム別の両方から照合する

台帳を作っても、更新されなければ「正しいはずの一覧」になるだけです。人別台帳には山田さんが使えるものが並び、システム管理画面には現在有効な利用者が並びます。この二方向を照合して初めて、記録漏れと設定漏れの両方を発見できます。

人別台帳だけを見ると、記録されていない別名アカウントや外部招待を見落とします。システム別一覧だけを見ると、その人がなぜ必要なのか、いつまで使うのかを判断できません。両者を同じ識別情報で結びます。

権限台帳の最小構成

この表を読めば、台帳がアカウント一覧ではなく、判断と実行を結ぶ記録だと分かります。パスワードそのものを同じ台帳へ書く必要はありません。台帳が閲覧されたときに認証情報まで漏れる構造にせず、認証情報の管理方法は分けます。

照合では四種類の差を探す

台帳と実設定の差は、次の四つに分類すると修正しやすくなります。

1. 台帳にあり、実設定にもある 原則として一致。ただし権限範囲と期限も確認します。

2. 台帳にあるが、実設定にない 設定漏れ、アカウント変更、利用終了後の台帳未更新が考えられます。

3. 台帳にないが、実設定にある 口頭依頼、外部招待、別名アカウント、退職者の残存などを疑います。

4. 両方にあるが、内容が違う 閲覧予定なのに編集可能、担当案件だけの予定なのに全案件閲覧可能といった差です。

差が見つかったら、直ちに全件削除するのではなく、業務上の必要性と設定経緯を確認します。ただし、退職者の有効アカウントや必要性を説明できない強い管理権限など、影響が大きいものは、責任者へ速やかに連絡して停止を含む対応を判断します。

照合頻度は、全システムを毎日確認する必要はありません。入社・異動・退職の発生時は対象者について照合し、それとは別に定期確認を行います。重要な情報を扱うもの、外部利用者が多いもの、管理者権限を持つものを優先します。

「半年ごと」などの周期だけでは忘れやすいため、給与改定、年度更新、協力会社契約の見直し、繁忙期終了など、自社の業務日程に結びつけます。頻度は一律の正解ではなく、利用者数、変更回数、情報の重要性、確認に要する負担を踏まえて決めます。

10.漏れや誤設定が見つかったときの判断を決めておく

アクセス権の運用を始めると、退職者のアカウント、用途不明の共有リンク、誰も管理者を把握していないSNSなどが見つかることがあります。発見自体を担当者の失敗と扱うと、報告が遅れます。重要なのは、影響を広げずに事実を確認し、再発条件を修正することです。

最初に「利用できる状態か」「実際に利用された形跡があるか」「どの情報や操作に届くか」「いつからか」を切り分けます。ログや履歴が取得できるかはサービスによって異なるため、見られない情報を推測で埋めないようにします。

この模式図では、原因究明より前に影響を抑える判断を置いています。ただし、証拠となる設定状況や記録を残さず変更すると、何が起きていたか確認できなくなる場合があります。緊急性に応じ、画面上の顧客情報をむやみに複製しない形で、利用者ID、権限、日時、確認者など必要な事実を記録します。

不備の重さをそろえて判断する

この表で見るべき点は、不備の種類によって初動が違うことです。必要な閲覧権限が一つ足りないケースと、退職者が顧客情報へ到達できるケースを同じ優先度で処理してはいけません。

個人情報に関わるおそれがある場合、単なる権限修正だけで終えてよいとは限りません。どの情報が対象か、実際のアクセスや外部提供があったかなど、具体的な事実を整理します。個人情報保護委員会への報告や本人への通知が必要な場合があるため、法令上の対応や本人・関係先への連絡が必要かは、個人情報保護委員会の漏えい等の対応に関するページで条件を確認し、社内責任者や必要に応じて専門家へ相談して判断します。

原因は「担当者が忘れた」で止めません。退職情報が設定担当者へ届かなかった、外部招待が台帳に載らない、終了日を入力する欄がない、承認者が不在のときの代行ルールがないなど、漏れを生んだ条件を探します。

修正後は、不備一件に対して手順を過剰に増やさないことも大切です。担当案件の交代が毎週あるなら、毎回長い稟議書を作るより、案件管理画面の担当変更と連動した短い申請にするほうが続きます。運用の実効性は、厳しさだけでなく、現場が正しい入口を使えるかで決まります。

11.30日で運用を立ち上げる

すべてのシステムと全社員を一度に完璧に整理しようとすると、台帳作成だけで止まりやすくなります。最初の30日では、管理対象を把握し、入社・異動・退職の入口を一本化し、重要な差分を直せる状態を目指します。

ここでいう30日は本記事独自の導入例であり、制度上の期限ではありません。システム数、拠点数、利用者数によって調整してください。期限を延ばす場合も、「いつか全件確認する」ではなく、対象の優先順位を決めます。

この表から、文書作成と現物照合を交互に行うことが読み取れます。机上で標準権限を作るだけでは、製品上できない設定に気づきません。実設定だけを触ると、判断基準が残りません。

優先順位は情報と権限の影響で決める

最初に確認する対象は、利用者数の多いものとは限りません。給与、支払、顧客名簿、契約書、全案件の原価など、影響が大きい情報へ到達できるアカウントを優先します。管理者権限、全件出力、削除、承認、外部共有ができる利用者も先に確認します。

次に、退職者、長期間使われていない利用者、終了日を過ぎた外部利用者、個人名と一致しないアカウントを調べます。名称だけで不要と決めず、システム連携や機器用のアカウントかもしれないため、用途と管理者を確認します。

導入時には、現場から「面倒になる」「毎回申請すると仕事が遅れる」という反応も想定されます。その場合は、申請の目的を説明するだけでなく、標準権限なら選択式で申請できる、案件追加なら短い様式にする、承認者不在時の代理を決めるなど、正規手続を使いやすくします。

新しい仕組みが入力されない原因は、担当者の意識だけではありません。操作の重複、承認の滞留、入力後に何も返ってこない設計も影響します。運用開始後に申請が定着しない場合は、工務店のシステム定着｜入力されない原因を解く方法を参考に、入力者、利用者、管理者のどこで流れが止まるかを分けて見直します。

12.入社・異動・退職の運用セットを完成させる

最終的な成果物は、分厚い情報セキュリティ規程だけではありません。経営者、直属責任者、設定担当者が、実際の発生日に迷わず使える一式をそろえます。

必要なものは、システム管理台帳、標準権限表、権限申請票、人別権限台帳、入社確認表、異動確認表、退職確認表、定期照合記録の八点です。既存の人事申請や端末台帳があるなら、同じ内容を二重入力せず、参照先を明確にしてつなぎます。

入社確認表

• 入社日、所属、直属責任者が確定している
• 初期業務と担当案件が記載されている
• 標準権限と個別追加が分かれている
• 不要な操作と閲覧範囲も確認した
• 会社支給端末と認証手段を台帳へ登録した
• 初回ログインで必要画面と不要範囲を確認した
• 入社後の見直し日を設定した

異動確認表

• 新業務の開始日と旧業務の終了日が分かる
• 旧権限を終了、一時継続、共通に分類した
• 一時継続には対象、理由、終了日時がある
• 担当案件、承認待ち、共有資料を後任へ移した
• 新しい承認権限と閲覧範囲を個別に判断した
• 期限日に旧権限が解除されたことを照合した
• 兼務終了や復職も同じ入口で処理できる

退職確認表

• 最終出勤日、最終利用日時、退職日を区別した
• 案件、メール、ファイル、承認待ちを移管した
• 管理者権限と会社名義サービスを引き継いだ
• PC、スマートフォン、鍵、カード、認証機器を回収した
• 本人アカウントを予定時刻に停止した
• 外部招待、共有リンク、同期端末、別名アカウントを確認した
• 停止後の保管と削除を別々に判断した
• 権限台帳とシステム側の利用者一覧を照合した

三つの確認表を別々の手続に見せながら、記録先は同じ権限台帳へ集約します。入社時に付与した理由が残っていれば、異動時に継続の要否を判断でき、退職時には停止対象を洗い出せます。

運用開始後に経営者が見るべき数字は、アカウント総数だけではありません。期限切れの一時権限数、理由不明の管理者数、停止待ち件数、設定と台帳の不一致件数など、放置すると影響が広がる差分を見ます。

比率を使う場合は分母を明記します。たとえば、「照合対象80アカウントのうち、台帳と設定が一致したもの72件」であれば、一致率は `72件 ÷ 80件 × 100＝90％` です。この数字は架空の計算例であり、特定企業の成果値ではありません。一致率だけを目標にせず、不一致8件の中に退職者や管理者権限が含まれていないかを優先して確認します。

アクセス権管理の完成形は、誰にも権限を与えない状態ではありません。入社者が初日から必要な仕事をでき、異動者が旧業務を期限どおり手放し、退職者のアクセスと会社の業務データを確実に分離できる状態です。

まずは直近に発生した一人の入社、異動、退職のいずれかを選び、本記事の項目で処理を再現してください。申請理由、承認者、設定内容、確認結果のどこかが残っていなければ、そこが自社の最初の改善点です。一件を最後まで通してから対象システムを広げると、書類だけではない運用へ育てられます。