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 でタスク生成とログを自動化し
新人モデルで再現性と標準化を完成させる

これによって、

ナレッジの散在、属人化、心理的抵抗、混乱した組織構造が
「仕組み」で一挙に変わっていく。

僕はこの経験を通じて確信しました。

💡ナレッジを残すのではなく、運用を設計することこそが 最も本質的な組織改善です。