1. 導入 — 上場企業インフラ部で目にした“ナレッジ地獄”
とある上場企業のインフラ部で、
「ナレッジが整備されていないため、まずはマニュアル整備からお願いしたい」
という依頼を受けました。
正直なところ、僕は軽い気持ちでした。
「運用はできていて、あとは人の頭の中の手順を聞き出せばいいのかな？」
ところが、実際に配属されて見えた光景は、完全に想定外でした。
- Active Directory があるのに、ドメインユーザーでログインさせていない
- EDR は導入済みだが、インストールは“ユーザー任せ”、後追いも無し
- 共有フォルダには同じファイルの複製が散在
- システムフォルダと業務フォルダが混在
- IPアドレス台帳もネットワーク台帳も更新されていない
- Microsoft 365 アカウント一つ作るにも「〇〇さんじゃないとできない」
- 何より、情報を聞き出そうとすると露骨に嫌な顔をされる
- 個人フォルダにもマニュアルが存在。しかも見ようとすると「プライバシー」だと怒られる。
そして極めつけはこれです。
「どうして私の仕事を勝手にしたんですか？
この手順が漏れているんですけど！」
善意の作業が非難される文化。
このチームは「担当領域を守り合うことで、かろうじて崩壊を免れている」ような状態でした。
僕はこのとき、
“既存メンバーへの聞き取りでは、正しい手順はもう抽出できない”
と判断しました。
2. なぜマニュアル整備では再生できなかったのか
マニュアルらしきものはありました。しかし、
- どれが最新版か誰も知らない
- 古いメモが残り続けて混乱を生む
- 書いた本人が異動済み、または内容を覚えていない
- 「書けと言われたから書いただけ」の文書が散在
- マニュアルを読んでも“誰が・いつ・どう実行するか”は分からない
- 書くこと自体に強い心理的抵抗がある
この状況では、いくらマニュアルを整備しようとしても、
運用は安定せず属人化は深まる一方です。
さらに僕は、もう一つの事実に気づきました。
既存メンバーは、ナレッジの外部化に強い拒否反応を持っている。
これでは聞き取りは成立しません。
3. アプローチを転換：「変わらない人」ではなく「変われる人」から着手
既存メンバーの心理的抵抗はとても強く、
アプローチしてもナレッジ抽出は困難だと分かりました。
そこで僕は方向転換し、
“変えられる人ではなく、変われる人”
を探す戦略に切り替えました。
そのとき、ある新人の存在が目に止まりました。
- 技術は発展途上
- 知識は広く浅い
- ただし、現場の理解力と順応性は抜群
- こちらの意図をすぐ理解し行動できる
- 新しい仕組みに抵抗がない
- 責任感が強い
僕は確信しました。
「このチームを変えるなら、彼を中心に据えるしかない」
これは SRE の原則「小さく始める」「ボトルネック以外の部分から改善する」とも一致します。
4. SREの教え：運用は“ドキュメント”ではなく“システム”で設計する
Google SRE では、運用を静的なドキュメントに依存する危険性が指摘されています。
- ドキュメントはすぐに腐る
- 読んでも状況や前提が分からない
- 属人知識をコピペしただけでは意味がない
- 繰り返しの手作業（Toil）が増殖する
- 運用は“コード・データ構造・フロー”で表現すべき
つまり、
“ナレッジを書いて残す” だけでは運用改善は成立しない。
必要なのは、運用そのものの設計です。
5. SharePoint × Planner × Power Automate による“運用モデルの構築”
僕は、SharePoint／Planner／Power Automate を使い、
運用を以下のように“動くシステム”として再構築しました。
5-1. SharePoint：システムごとの“システムポータル”を作成
SharePoint は「業務手順DB」ではなく、
“システム単位のポータル” として運用しました。
各システムごとに、以下の情報を一箇所に集約します。
- 設定手順
- 定常運用手順
- 障害時の対応手順
- 構成情報
- 注意点
- 関連する Planner のタスクへのリンク
- 古い手順・メモの統合と廃棄
新人の彼が迷わないよう、
「そのシステムはここを見ればすべて分かる」
という設計に徹しました。
5-2. Planner：業務の“パッケージ化”
Planner の最も重要な役割は、
業務を “パッケージ（テンプレート化されたタスク群）” にしたこと
です。
従来は
- 作業依頼が Slack やメール
- Excel に記載
- 手順は人の頭の中
- ミスや漏れは日常茶飯事
という状態でした。
僕は、新人の彼と一緒に業務を分解し、
以下の流れで“業務パッケージ化”しました。
① 業務をステップに分解
② 業務ごとに Planner のタスクとして登録
- 目的
- 手順
- 入力・出力
- リンク（マニュアル / SharePoint）
- チェックリスト（ステップ）
- 権限・注意点
- 依存タスク
③ 業務は単位でまとめ、“ボードテンプレート化”
例えば：
- 障害対応パッケージ
- 月次メンテナンスパッケージ
- ユーザー管理パッケージ
- システム初期セットアップパッケージ
④ Power Automate による自動生成
- 定期実行
- 障害発生
- インシデント登録
- 申請フォーム送信
をトリガーに、
→ Planner にタスクパッケージが自動生成される
ようにしました。
新人の彼は、
Planner のタスクを上から順に実行するだけで業務が正しく回る
という状態になり、属人化は一気に解消していきました。
6. 新人モデルの採用：仕組みが人を動かす
この仕組みは、新人の彼に完璧にハマりました。
- 技術が浅くても迷わない
- “次に何をするか” が常に明確
- 困ったら SharePoint ポータルを参照すればよい
- ミスは Power Automate が検知・ガイド
- パッケージ化された業務が再現性を保証
その結果、
「新人のやり方が最も正確」
という状態が生まれました。
7. 導入による効果：文化ではなく“行動パターン”が変わっていく
新人の彼を中心に運用モデルを整えた結果、現場には次のような変化が起きました。
- 再現性が向上し、誰が実施しても同じ結果が出るようになった
- Toil（手作業）が大幅に削減された
- 手順ミス・抜け漏れが激減
- 古いドキュメントによる混乱がなくなった
- 「聞いたら怒られる」雰囲気が消え、「ポータルに載せるなら教えますよ」という前向きなスタンスに変わった
そして最も大きかったのは、
新人の彼が“部門で一番正しく業務できる人”になったことです。
運用パッケージとシステムポータルがあるため、
彼が最も迷わず、最も正確に、最も早く業務を実行できました。
7.5 しかし現場はさらに予想外の方向へ動いた
新人の彼がすべての業務を正しく回せるようになると、
現場は自然と “彼中心の業務運用” が進みました。
結果として──
- 実質的に彼だけが業務を回している状態 になり
- 負担が一点に集中してしまうため
- もう一人追加で人を雇う判断が下されました
いわゆる 「この仕組みが分かる人をもう一人追加する」 という動きです。
仕組み自体は堅牢であっても、実行できる人が彼しかいない＝ボトルネック という判断は妥当です。
そして、さらに驚くべき“後日談”がありました。
7.6 事業部長からの報告：組織が“静かに再編”された
しばらくして、事業部長からこんな報告がありました。
「既存メンバー3人は、今は“特にやることがない”状態です。」
このチームは、“担当領域を守ることで辛うじて成立していた”
という構造だったため、
- 運用パッケージ化
- システムポータル化
- 手順の標準化
- 自動化
- 新人モデルの確立
によってその“暗黙の役割”が消滅しました。
結果として、
「仕事を持たない人」から本当に仕事が消える
という、現場あるあるの結末になったわけです。
もちろん、これは狙ったことではありません。
しかし、属人化に寄りかかった組織が構造改善で崩れる というのは、SRE の世界ではしばしば起きる現象です。
- 個人が仕事を抱え込む
- 仕組みは整備されない
- 全員が担当領域を守ることで破綻を回避している
- しかし根本改善が入ると“守る領域”が無くなる
非常に示唆的な出来事でした。
8. 結果と気づき：文化改革ではなく“構造改革”が組織を動かす
この一連の経験で僕が強く感じたのは、
人は簡単には変わりませんが、仕組みが変わると行動は変わる。
仕組みが変わりきると、組織そのものが変わる。
という現場の真実です。
今回のインフラ部はまさにその典型例で、
- 属人化と心理的抵抗に支えられた“なんとか回る組織”
→ システム化により構造崩壊
→ 新人中心の効率運用へ再編
→ 部長・既存メンバーの役割が消滅
という 構造的変化の連鎖 が起こりました。
文化は変えなくても、構造が変われば、文化も人も動いてしまう。
それを肌で感じる体験でした。
✔ 結論：運用は「書く」のではなく、「設計して回す」もの
- SharePoint で“システムポータル”を作り
- Planner で“業務パッケージ化”し
- Power Automate でタスク生成とログを自動化し
- 新人モデルで再現性と標準化を完成させる
これによって、
ナレッジの散在、属人化、心理的抵抗、混乱した組織構造が
「仕組み」で一挙に変わっていく。
僕はこの経験を通じて確信しました。
💡ナレッジを残すのではなく、運用を設計することこそが 最も本質的な組織改善です。