複数拠点・部署のアカウント管理、入退社対応の「量」が追いつかなくなったら

入退社に伴うアカウントの発行・削除は、ひとり情シスの時代であれば、月に数件程度の対応で済んでいたかもしれません。1件ずつ丁寧に、手作業で確認しながら処理しても、業務に支障が出ることはなかったはずです。しかし、会社が成長し、拠点や部署が増えてくると、この「1件ずつ丁寧に」という進め方そのものが、処理能力の限界を迎えます。月に数十件規模のアカウント関連対応が発生するようになると、これまでと同じやり方を続ける限り、対応漏れや遅延が構造的に発生するようになります。このガイドでは、アカウント管理・入退社対応の「量」が処理能力を超えたときに、何を見直すべきかを整理します。

なぜ「量」が問題になるのか

アカウント管理における問題の多くは、「やり方が間違っている」のではなく、「そのやり方が想定していた量を超えた」ことによって発生します。月に数件の対応であれば、次のような進め方でも十分機能します。

• 人事からの連絡を受けて、都度手作業でアカウントを発行・削除する
• 各システムに個別にログインし、1つずつ設定を行う
• 対応した内容を、担当者の記憶やメモ程度で管理する

この進め方は、件数が少ないうちは合理的です。わざわざ仕組み化するコストをかけるより、手作業で対応したほうが早いためです。しかし、拠点や部署が増え、月あたりの対応件数が数十件規模に膨らむと、同じやり方を続けることが、次のような問題を引き起こします。

• 対応漏れが発生しやすくなる: 件数が増えるほど、うっかり対応を忘れる、あるいは重複して対応してしまうミスの発生確率が上がる
• 退職者アカウントの削除が遅れる: 特に退職者のアカウント削除は、セキュリティ上の重大なリスクに直結する。件数が増えると、削除が後回しになったまま放置されるケースが増える
• 拠点ごとの対応品質にばらつきが出る: 本社では丁寧に対応できていても、目の届きにくい拠点では対応が疎かになりやすい
• 担当者の負荷が限界に達する: 1件あたりの対応時間が変わらなくても、件数が増えれば総所要時間は比例して増加し、他の業務を圧迫する

「拠点が2つ、3つと増えていくうちに、気づけば月の入退社対応が以前の5倍近くになっていました。それでも同じやり方を続けていたので、対応漏れが増え、退職者のアカウントが数ヶ月放置されていたことが後から発覚したこともあります。量が変わったのに、やり方を変えていなかったのが原因でした」

処理件数を可視化するところから始める

体制を見直す前に、まず「実際にどれだけの件数を処理しているか」を可視化することが出発点です。感覚的に「忙しくなった」と感じていても、具体的な数字がなければ、どの程度の対応が必要か、経営層への説明も難しくなります。

可視化する際は、次の観点で記録を残すことをお勧めします。

数ヶ月分のデータが蓄積されると、単なる「忙しい」という感覚が、「月間〇件、合計〇時間の対応が発生している」という具体的な数値に変わります。この数値化は、後述する体制強化や自動化の投資判断において、重要な根拠資料になります。

手作業の限界点を見極める

処理件数がどこまで増えたら、手作業の限界を迎えるのかは、会社の状況によって異なりますが、次のようなサインが複数当てはまる場合、体制の見直しを検討すべきタイミングです。

• 入退社対応にかかる時間が、担当者の勤務時間の無視できない割合を占めるようになった
• 対応漏れ、あるいは対応の遅延が、月に1件以上発生するようになった
• 拠点や部署からの依頼が、担当者の把握しきれないタイミングで飛び込んでくることが常態化している
• 退職者アカウントの削除が、退職日から1週間以上経ってから行われることがある

特に最後の項目は、セキュリティの観点から特に注意が必要です。退職者のアカウントが削除されずに残っている期間が長いほど、不正アクセスや情報漏えいのリスクが高まります。警察庁・総務省・経済産業省が公表している調査でも、不正アクセスの手口として、退職者や関係者の古い認証情報が悪用されるケースが継続的に報告されており、退職者アカウントの速やかな削除は、規模を問わず優先度の高い対応事項です。

体制強化の3つの方向性

処理件数の増大に対応するための方向性は、大きく3つに整理できます。

1. プロセスの標準化: 誰が対応しても同じ手順・同じ品質になるよう、対応フローを明文化する
2. 役割分担による処理能力の拡大: 複数人で分担することで、1人あたりの処理件数を減らす
3. 仕組み・ツールによる自動化: 手作業で行っていた処理の一部を、システムやツールで自動化する

これら3つは、いずれか1つを選ぶものではなく、多くの場合は組み合わせて進めることになります。まずプロセスを標準化し、その上で役割分担を行い、余力があれば自動化に投資する、という順序で進めるのが現実的です。

方向性①: プロセスの標準化

処理件数が増えてきた際、最初に着手すべきなのがプロセスの標準化です。入社・退職・異動それぞれについて、対応すべき手順をチェックリスト化しておくことで、担当者による対応品質のばらつきを防ぎ、対応漏れのリスクを減らせます。

標準化する際は、次の要素を明確にしておくことをお勧めします。

• トリガーとなる情報の発生源: 誰が、いつ、どのように「入社/退職/異動」の情報を情シスに連携するのか。人事システムからの自動連携か、人事担当者からの手動連絡か
• 対応すべきシステムの一覧: 入社時にアカウントを発行すべきシステム、退職時に削除・無効化すべきシステムを、漏れなくリスト化する
• 対応の期限: 入社日までにアカウントを用意する、退職日当日(あるいは可能な限り早いタイミング)にアカウントを無効化する、といった期限を明確にする
• 対応完了の確認方法: 対応が完了したことを、誰がどう確認するか(チェックリストへの記録、上長への報告など)

このチェックリストは、担当者が1人であっても複数人であっても有効です。特に、退職者アカウントの削除については、対応すべきシステムが漏れなくリスト化されているかどうかが、削除漏れを防ぐ最大の鍵になります。システムが複数に分散している会社ほど、この一覧化の重要性は増します。

方向性②: 役割分担による処理能力の拡大

プロセスを標準化しても、件数そのものが多すぎれば、1人の担当者だけでは処理しきれない状態が続きます。この場合、複数人で分担する体制への移行を検討する必要があります。

分担の切り口としては、次のようなパターンが考えられます。

• 拠点別の分担: 拠点ごとに担当者を割り振り、それぞれの拠点からの依頼を専任で処理する
• 業務プロセス別の分担: 入社対応を担当するメンバーと、退職・異動対応を担当するメンバーを分ける
• システム別の分担: 特定のシステム(例えば人事システムと連携するIDプロバイダー)の操作を専任で担当するメンバーを置く

どの分担方式が適しているかは、会社の拠点構成や業務量の偏りによって異なります。役割分担の考え方の基本については兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方で詳しく扱っているので、アカウント管理業務の分担を検討する際の参考にしてください。

分担を進める際に注意すべきなのは、単に人数を増やすだけでは、標準化されたプロセスがなければ効果が限定的だという点です。プロセスが標準化されていない状態で複数人が対応すると、担当者ごとにやり方が異なり、かえって管理が複雑になることがあります。標準化と役割分担は、順序立てて進めることが重要です。

方向性③: 仕組み・ツールによる自動化

プロセスの標準化と役割分担を進めた上でも、処理件数がさらに増え続ける場合、仕組みやツールによる自動化を検討する段階に入ります。自動化の選択肢としては、次のようなものがあります。

• IDaaS(IDフェデレーション・シングルサインオン基盤)の導入: 複数システムのアカウントを一元管理し、入社時のアカウント発行、退職時の一括無効化を効率化する
• 人事システムとの連携: 人事システムに入社・退職・異動の情報が登録されると、自動的にアカウント発行・削除のワークフローが起動する仕組みを構築する
• ワークフローツールによる申請・承認の自動化: 権限付与の申請から承認、実際の権限設定までの流れを、ワークフローツール上で完結させる

自動化への投資は、初期導入のコストと、運用開始までの設定作業を伴います。処理件数がまだそれほど多くない段階で、いきなり大掛かりな自動化に投資するのは、コストに見合わない場合もあります。前述した処理件数の可視化データをもとに、「自動化に投資するコストと、手作業を続けるコストのどちらが大きいか」を比較検討し、投資判断の材料にすることをお勧めします。

繁忙期の集中対応をどう乗り切るか

アカウント関連業務には、季節による波があります。特に新卒一括採用や、期初・期末の異動が多い会社では、特定の月に入退社・異動の依頼が集中し、平常月の何倍もの件数を処理しなければならない事態が発生します。この繁忙期の集中対応を乗り切るための準備は、通常月の処理体制とは別に検討しておく必要があります。

繁忙期対策として、次のような取り組みが有効です。

• 繁忙期の到来を事前に予測する: 過去の実績から、毎年どの月に処理件数が集中するかを把握し、前もって備える。新卒入社であれば入社日が固定されているため、特に予測がしやすい
• 繁忙期前に前倒しできる作業を進めておく: アカウント発行に必要な情報(氏名、所属部署、必要な権限など)を、入社日よりも前の段階でできるだけ確定させ、入社日直前の作業量を減らす
• 繁忙期だけ臨時の応援体制を組む: 通常は他の業務を担当しているメンバーに、繁忙期だけアカウント関連業務を手伝ってもらう。事前に手順書が整備されていれば、専任でなくても対応しやすくなる
• 繁忙期後の振り返りを行う: 繁忙期にどんな問題が発生したか、次年度に向けてどう改善すべきかを、繁忙期が明けたタイミングで振り返る

繁忙期の集中対応は、毎年同じような課題が繰り返し発生しやすい領域です。一度乗り切って終わりにするのではなく、翌年により少ない負荷で乗り切れるよう、経験を蓄積していく視点を持つことが重要です。

権限管理の複雑化にも目を向ける

拠点・部署が増えると、単純なアカウントの発行・削除件数が増えるだけでなく、権限管理そのものの複雑さも増していきます。部署ごとに異なるシステムへのアクセス権限、拠点ごとに異なる承認フロー、役職に応じた権限レベルの違いなど、組織が複雑化するほど、権限設計そのものが煩雑になっていきます。

権限管理の複雑化に対応するためには、次のような整理が有効です。

• ロールベースでの権限設計: 個人ごとに権限を設定するのではなく、「営業部一般社員」「経理部マネージャー」といった役割(ロール)単位で権限セットをあらかじめ定義し、個人にはロールを割り当てる形にする。これにより、異動時の権限変更が「新しいロールへの切り替え」というシンプルな操作に単純化できる
• 例外的な権限付与を最小限にする: 「この人だけ特別にこの権限も必要」という個別対応が積み重なると、後から見直す際に収拾がつかなくなる。例外はできるだけ記録に残し、定期的に見直す運用にする
• 定期的な権限の棚卸し: 異動を重ねた社員が、過去の部署の権限を持ったまま残っているケースは珍しくない。半期に1回程度、実際の所属と権限が一致しているかを確認する棚卸しを行う

権限管理が複雑化したまま放置されると、単純なアカウントの件数以上に、対応の負荷と、不要な権限が残り続けるセキュリティリスクの両方が増大していきます。処理件数の増大への対応と、権限設計そのものの整理は、切り離さずに同時に検討することをお勧めします。

拠点間のばらつきをどう解消するか

複数拠点を持つ会社では、アカウント管理のプロセスが拠点ごとに独自に発展してしまっているケースがよく見られます。本社は情シス担当者が丁寧に対応している一方、支社では総務担当者が見よう見まねで対応している、といった状態です。

拠点間のばらつきを解消するためには、次のステップが有効です。

1. 各拠点の現状の対応プロセスを洗い出す: 拠点ごとに、誰が、どうやってアカウント関連の対応を行っているかを確認する
2. 共通化できる部分と、拠点固有の事情が残る部分を切り分ける: 全拠点で完全に同じプロセスにできるとは限らないため、共通化すべき最低限のルールと、拠点の裁量に任せる部分を分ける
3. 拠点の一次窓口を明確にする: 情シス担当者が常駐していない拠点であっても、アカウント関連の依頼を誰が最初に受け付け、本社の情シスにどう連携するかを明確にする

拠点間のばらつきは、単なる非効率にとどまらず、セキュリティ上のリスクにも直結します。目の届きにくい拠点で退職者アカウントの削除が漏れる、権限付与のルールが緩くなる、といった事態は、拠点の管理体制が本社と分離していることが原因で起きやすくなります。この点は、セキュリティ体制全体の見直しとも密接に関わるため、従業員100人超えで必要になるセキュリティ体制、ひとり対応の限界ラインで扱っている内容とあわせて検討することをお勧めします。

拠点間の共通ルールを定める際、本社の情シス担当者だけで一方的に決めるのではなく、各拠点の実情に詳しい担当者を巻き込んで検討することも重要です。本社の視点だけで作られたルールは、拠点の実務にそぐわない部分が出やすく、結局形骸化してしまうことがあります。拠点側の意見を取り入れながらルールを設計することで、実際に守られる、実効性のある共通ルールに近づけることができます。

問い合わせ窓口との連動

アカウント関連の対応は、多くの場合、社員からの問い合わせを起点に発生します。「新しいメンバーのアカウントを作ってほしい」「異動になったので権限を変更してほしい」といった依頼が、情シスの窓口に集まってくることになります。

このとき、アカウント関連の依頼が、他の一般的な問い合わせと同じ窓口に混在していると、優先順位の管理が難しくなります。入社日までに間に合わせる必要があるアカウント発行の依頼が、他の緊急度の低い問い合わせに埋もれてしまうと、対応漏れの原因になります。ヘルプデスクの窓口設計において、アカウント関連の依頼を独立したカテゴリとして扱い、優先順位や対応期限を明確にしておくことが重要です。窓口一本化の設計全体についてはチーム化した情シスのヘルプデスク対応、属人対応から窓口一本化へで詳しく扱っています。

監査・証跡の観点から見た「量」の問題

処理件数が増えると見落とされがちなのが、対応の証跡(いつ、誰が、何を対応したかの記録)をどう残すかという観点です。件数が少ないうちは、担当者の記憶やメールの履歴を辿れば、後から「いつアカウントを発行したか」「いつ削除したか」を確認できました。しかし件数が数十件規模になると、記憶や個別のメール履歴に頼った確認は現実的でなくなります。

証跡管理が不十分だと、次のような場面で困る事態が生じます。

• 取引先やお客様から、情報セキュリティに関する監査・確認を求められた際、いつどの社員がどのシステムにアクセスできる状態だったかを説明できない
• 退職者アカウントの削除漏れが後から発覚した際、いつから削除されずに残っていたのかを正確に把握できない
• 特定の権限がいつ、誰の承認で付与されたのかを、後から追跡できない

これらの問題を防ぐためには、アカウントの発行・削除・権限変更のたびに、最低限「いつ・誰が・何を・誰の承認で」という情報を記録に残す運用を、処理件数が増える前の段階から習慣化しておくことが望ましいです。件数が少ないうちは記録の手間を惜しんでしまいがちですが、後から量が増えたときに証跡管理の仕組みを一から作り直すよりも、最初から記録を残す習慣をつけておくほうが、長期的な負担は小さくなります。

証跡の記録方法は、必ずしも高度なツールを使う必要はありません。スプレッドシートへの記録や、申請・承認のやり取りをチャットツールやメールで残すだけでも、最低限の証跡としては機能します。重要なのは、記録を残すという行為そのものを、日常業務の一部として定着させることです。

証跡管理を軽視してしまう背景には、「今は自分ひとりで把握しているから大丈夫」という感覚があります。しかし、この感覚こそが、複数人体制への移行を難しくする落とし穴です。証跡が個人の記憶に依存している限り、その担当者が異動・退職した瞬間に、過去の経緯を辿る手段が失われます。処理件数がまだ少ないうちから記録を残す習慣を持っておくことが、将来的な体制拡大への備えにもなります。

複数拠点特有の「情報が本社に届かない」問題

拠点が増えると、本社の情シス担当者が把握できていない入退社・異動が発生しているケースも珍しくありません。人事異動の情報が、本社の情シスに正式に連携される前に、拠点内で「とりあえず」対応が済んでしまっていることがあるためです。

この問題を防ぐためには、情報連携の経路を明確に設計しておく必要があります。

1. 情報の発生源を特定する: 入社・退職・異動の情報は、最初にどこ(人事部門、拠点の総務担当など)で把握されるか
2. 情シスへの連携ルートを1本化する: 拠点ごとにバラバラな連携方法(電話、口頭、個別のメールなど)ではなく、統一されたフォーマット・経路で情シスに情報が届く仕組みを作る
3. 連携の期限を明確にする: 「入社の何日前までに情シスへ連携する」といった期限を設け、直前になって慌てて依頼が来る事態を防ぐ

拠点の担当者からすれば、「本社の情シスに連携する」という手順自体が、日々の業務フローに組み込まれていなければ、忘れられがちです。連携漏れを防ぐためには、人事システムやワークフローツールと連動させ、情シスへの連携を自動化する、あるいは連携を忘れにくいチェックリストに組み込むといった工夫が有効です。

この問題の根本には、「情シス」という機能そのものが、拠点の担当者にとって日常的に意識される存在ではないという事情があります。本社に情シス担当者がいることを知っていても、日々の忙しさの中で「まず情シスに連絡する」という発想が後回しになりがちです。拠点の担当者にとって、情シスへの連携が「面倒な追加作業」ではなく「当たり前の手順」として定着するまでには、繰り返しの周知と、連携しやすい仕組みづくりの両方が必要になります。

増員のタイミングをどう判断するか

処理件数の増大に対して、プロセスの標準化と自動化だけでは対応しきれない場合、最終的には増員による処理能力の拡大が必要になります。増員を判断する目安としては、次のような観点が参考になります。

• 標準化されたプロセスに沿って対応しても、処理件数が担当者の対応可能な時間を恒常的に超えている
• 自動化ツールの導入を検討しても、投資対効果が見合わない、あるいは導入までに時間がかかりすぎる
• アカウント関連業務以外の業務(ヘルプデスク対応、セキュリティ対応など)にも、慢性的なしわ寄せが出ている

増員の必要性を経営層に説明する際は、可視化した処理件数の推移データが、最も説得力のある材料になります。「感覚的に忙しい」ではなく、「月間〇件の対応が発生しており、標準的な対応時間で計算すると〇時間かかっている」という具体的な数字を示すことで、増員の必要性を客観的に伝えられます。採用基準の設計や求人票の書き方については100-300人規模で必要になる情シス専任の採用基準と求人の書き方で詳しく扱っているので、実際に増員を進める段階になったら、あわせて参照してください。

増員以外の選択肢として、アカウント管理業務の一部を外部のアウトソーシング先に委託するという方法も検討の余地があります。特に、定型的な入退社対応(手順が確立しているシステムへのアカウント発行・削除など)は、外部委託になじみやすい業務です。一方で、権限設計の判断や、複雑な例外対応は、自社の業務内容を理解したメンバーが担う必要があるため、すべてを外部に委託するのではなく、定型業務と非定型業務を切り分けたうえで、外部委託の可否を検討することをお勧めします。

まとめ: 「量」の変化に気づき、やり方を変える判断を

アカウント管理・入退社対応が回らなくなる原因の多くは、担当者の能力不足ではなく、拠点・部署の増加によって処理すべき「量」が変化したにもかかわらず、対応の「やり方」を変えずに続けてしまったことにあります。処理件数を可視化し、プロセスの標準化、役割分担、自動化という3つの方向性を、自社の状況に応じて組み合わせながら、量の変化に見合った体制へと更新していくことが重要です。

特に退職者アカウントの削除漏れは、セキュリティ上の重大なリスクに直結します。処理件数が増えてきたと感じたら、対応が後手に回ってからではなく、早めに体制の見直しに着手することをお勧めします。件数がまだ致命的な水準に達していない今のうちに手を打つことが、後になって大きなトラブルへ発展するリスクを未然に防ぐ、最も効率のよい投資になります。

自社のアカウント管理体制がどの程度限界に近づいているか、客観的に把握したい場合はひとり情シス危険度診断もあわせてご活用ください。

処理件数の増大は、多くの場合、会社の成長そのものを反映した結果です。拠点や部署が増えるということは、事業が拡大しているという裏返しでもあります。この変化を前向きに捉え、増大する業務量に合わせて体制を計画的にアップデートしていくことが、成長を支える情シス機能として求められる役割です。可視化・標準化・分担・自動化という一連のプロセスを、一度にすべて完璧に整える必要はありません。今、最も逼迫している部分から着手し、少しずつ体制を厚くしていく現実的なアプローチを選んでください。

「量」の壁にぶつかることは、決して失敗のサインではありません。むしろ、それだけ会社が成長し、対応すべき範囲が広がった証です。この壁を一つ乗り越えるたびに、情シスの体制はより強固なものへと進化していきます。目の前の処理件数に追われる日々の中でも、自社が今どの段階にあるのかを俯瞰し、次に何を整えるべきかを見極める視点を持ち続けてください。

処理件数の増大への対応は、アカウント管理という一つの業務領域にとどまらず、情シスチーム全体の体制設計とも密接につながっています。役割分担の見直し、採用によるリソース強化、ヘルプデスク窓口との連携、セキュリティ体制の底上げ。これらはすべて、規模の拡大という同じ根から生まれる課題であり、一つずつ着実に手を打っていくことが、100〜300人規模という移行期を乗り越える最も確実な道筋になります。目の前の1件1件の対応に追われながらも、こうした全体像を時折振り返る視点を忘れないようにしてください。今の対応件数がどれだけの負荷になっているかを正しく認識することこそが、次の一手を的確に選び取るための出発点です。まずは今月の入退社対応が何件あったか、数えるところから始めてみてください。