200人規模企業で、属人化を解消して「止まらない運用」を作った話

社員約200名の当社では、情シス（情報システム）の実務を1名の担当者が担っていました。社内インフラ、SaaS管理、アカウント運用、問い合わせ対応、軽微な開発まで——いわゆる「何でも屋」として現場を支えてくれていた一方で、ある問題がじわじわと深刻化していました。

それは、システムの“肝”がその担当者の頭の中にしかないこと。

• 「この設定、なぜこうなっているのか分からない」

• 「障害が起きたら、まずその人に電話」

• 「棚卸しや権限整理のタイミングは、毎回その人の記憶頼り」

このまま担当者が退職・長期離脱した場合、業務が止まるのではないか。経営側も現場側も、同じ不安を抱えていました。

課題：属人化は“能力の高さ”が作ってしまう

今回の属人化は、単にドキュメントが不足していた…というだけではありませんでした。担当者の技術力が高く、最適解を素早く出せるからこそ、

• イレギュラー対応がその場で片付く

• 手順が「その人のやり方」で積み上がる

• 改善も個人のスクリプト・工夫に閉じる

結果として、会社にとって重要な運用が「再現できない仕事」になっていました。

取り組みの全体像：やったのは3つだけ

属人化解消は「気合いのドキュメント作り」では続きません。今回は、次の3点に絞って進めました。

1. 引き継ぎの徹底（見える化・分解・標準化）

2. 技術力による解析（ブラックボックスの棚卸し）

3. BPO / システムで省力化（属人作業を仕組みに置換）

1) 引き継ぎの徹底：まず“仕事を部品化”した

最初にやったのは、「情シスの仕事」を丸ごと引き継ぐのではなく、部品に分解することでした。

• 定常業務（アカウント発行、権限付与、端末手配、棚卸し）

• 月次・年次（監査対応、ライセンス更新、台帳更新）

• 問い合わせ（PC不調、VPN、権限、SaaSログイン等）

• 障害・緊急対応（一次切り分け〜復旧）

それぞれを「誰が見ても同じ判断ができる形」に落とし込むために、手順を次のテンプレで統一しました。

• 目的（何のためにやるか）

• 入力（何がトリガーか）

• 判断基準（分岐条件）

• 操作手順（最短で終わる順番）

• 完了条件（何ができたら終了か）

• 例外時のエスカレーション（誰に、何を、どこまで）

結果、引き継ぎが「この画面見て、こうやって…」ではなく、誰でも再現できる運用に変わり始めました。

2) 技術力による解析：ブラックボックスを“地図化”する

次に、属人化の根本である「システムの肝」を解析しました。ポイントは、感覚ではなく、構造として理解できる状態にすること。

• どのSaaSが何の業務に使われているか

• どのアカウント/権限が重要か

• どの設定変更が事故につながるか

• どこが“触ると壊れる領域”か

これを、構成図・権限体系・運用フローとして整理し、重要度（止まる・遅れる・困る）で優先順位を付けました。

ここで大きかったのは、属人化の正体が「全部が難しい」ではなく、“数個の急所”が難しいだけだと分かったことです。急所を特定できると、対策は急に現実的になります。

3) BPO / システムで省力化：属人作業を“仕組み”へ移した

最後に、担当者だけが回せていた作業を、自動化・半自動化しました。特に効果が大きかったのは以下です。

Google Apps Script：定型運用を自動化

さらに、Google Workspace周りの定型処理をGAS（Google Apps Script）で省力化しました。

例：

• 入社・異動・退職に伴うアカウント処理の一部自動化

• 権限付与の申請情報をスプレッドシート起点で整理し、作業漏れを防止

• 棚卸し用の一覧生成、差分チェックの自動化

• 手作業で作っていた報告用データの生成

「その人が速いから回っていた作業」を、人が速くなくても回る仕組みに変える。ここが属人化解消の決定打になりました。

結果：不安が“構造的に消えた”

施策後、目に見えて変わったのは次の3点です。

• 退職・離脱リスクが現実的に下がった

• 急所が可視化され、手順と判断基準が共有されたため

• 対応が早くなり、品質が安定した

• AIで初動が標準化され、GASで定型が減ったため

• 情シス担当者の負荷が下がり、改善に時間が使えるようになった

• 「回すだけ」から「仕組みを育てる」側に寄せられた

属人化は、誰かのせいではなく、成長過程で自然に発生します。だからこそ、気合いではなく、再現性のある運用として設計し直すのが最短でした。