「あの作業、〇〇さんしかわからないんですよね」
運用保守の現場にいれば、一度は聞いたことがある言葉だと思います。
正直に告白します。私自身、かつては「〇〇さん」の側でした。
自分しか触れないサーバー、自分しか手順を知らない作業。当時はそれを、少し誇らしく思っていた部分すらあります。「自分がいないと回らない」——それが自分の価値だと勘違いしていました。
でも、あるとき気づきました。
それは価値じゃなくて、リスクだったんです。
今は20名のチームを預かる立場になり、属人化を崩す側にいます。今回は、実際にやってみて効果があった3つのことを、失敗も含めて正直に書きます。
なぜ、属人化は生まれてしまうのか
対策の前に、原因を整理しておきます。ここを飛ばすと、対策が的外れになります。
属人化は、誰かがサボった結果ではありません。むしろ逆で、真面目に仕事をした結果として生まれます。
- 忙しいから、自分でやったほうが速い
- 手順書を書く時間がない
- 教えるより、やってしまったほうが早い
一つひとつは、正しい判断に見えます。目の前の仕事を回すことだけを考えれば、実際に正しい。
でも、それが積み重なると、その人しか触れない領域ができあがる。そして時間が経つほど、崩すのが難しくなります。
つまり属人化は、「悪意なく、忙しさの中で自然に育つ」ものです。だから、意識して手を打たないと絶対になくなりません。
実践①：まず「誰が何を知っているか」を可視化した
最初にやったのは、手順書づくりではありませんでした。
現状の見える化です。
いきなり「手順書を書こう」と号令をかけても、量が多すぎてどこから手をつければいいかわかりません。実際、以前それをやって失敗しました。全員が「とりあえず書けるものから」書き始めた結果、重要度の低いものばかり整備されて、肝心なところが手つかずのまま残ったんです。
そこで、順番を変えました。
やったこと
顧客ごと・システムごとに、担当できる人を洗い出して一覧表にしました。エクセルで十分です。
| 顧客/システム | 主担当 | 対応できる人 | リスク |
|---|---|---|---|
| A社 AD環境 | 田中 | 田中のみ | 高 |
| B社 監視基盤 | 佐藤 | 佐藤、鈴木 | 中 |これを埋めていくと、「対応できる人が1人しかいない領域」が一目で浮かび上がります。
効果
驚いたのは、可視化しただけで空気が変わったことです。
一覧表を見たメンバーが、「これ、自分しかできないのはまずいですね」と自分から言い出しました。誰かに指摘されるより、自分で気づいたほうが、人は動きます。
そして何より、どこから手をつけるべきかが明確になりました。リスク「高」の領域から潰していけばいい。それだけのことですが、これがないと優先順位がつけられません。
実践②：手順書を「書く」より「使わせる」ようにした
手順書は、書けば終わりではありません。
正直に言うと、私は長いこと勘違いしていました。手順書さえ整備すれば属人化は解消されると思っていたんです。
でも、書いただけの手順書は、たいてい使われません。
理由はシンプルで、書いた本人しか、その手順書の存在を知らないからです。または、あっても内容が古くて信用されない。結局「〇〇さんに聞いたほうが早い」に戻ります。
やったこと
手順書を「書く」のではなく、「使う」ルールに変えました。
- 作業は、必ず手順書を開きながらやる（覚えていても、です）
- 詰まったところ、間違っていたところは、その場で直す
- 主担当以外の人に、手順書だけを見て作業してもらう
3つ目が特に効きました。
書いた本人は、書いていない前提知識を持っています。だから自分では「わかりやすい手順書」に見える。でも他の人が読むと、平気で詰まります。
「ここ、前提がわからなくて止まりました」と言われて初めて、抜けに気づく。これを繰り返すことで、手順書が本当に使えるものに育っていきました。
失敗したこと
最初は「完璧な手順書を作ろう」として、いつまでも公開できませんでした。
今は、60点で出して、使いながら直す方針にしています。使われない100点より、使われる60点のほうが圧倒的に価値があります。
実践③：意図的に「担当を入れ替える」機会を作った
これが一番効きました。そして、一番勇気が要りました。
手順書があっても、実際にやったことがなければ人は動けません。読むのとやるのでは、まったく違うからです。
だから、やる機会を意図的に作る必要があります。
やったこと
定期メンテナンスや定型作業を、主担当以外の人に任せる回を設けました。
もちろん、いきなり本番で放り出すわけではありません。
- 主担当は横で見ているが、口を出さない
- 詰まったら手順書を見る。それでも無理なら聞く
- 終わったあとに、詰まった箇所を手順書へ反映する
この形なら、リスクを抑えつつ経験を積めます。
正直、最初はしんどかった
自分でやれば30分で終わる作業が、任せると2時間かかる。横で見ているこちらも落ち着かない。
「今回は自分でやろう」と何度も思いました。
でも、そこで自分がやってしまうと、永遠に変わりません。属人化を崩すには、短期的な非効率を受け入れる覚悟が要ります。ここが一番の踏ん張りどころでした。
効果
半年ほど続けたころ、明らかに変化が出ました。
夜間の障害対応で、これまでなら特定の人しか対応できなかった案件を、別のメンバーが一次対応できるようになった。主担当が休んでも、作業が止まらなくなった。
そして予想外の効果として、任された側のモチベーションが上がりました。「自分にも任せてもらえる」という実感は、思っていた以上に大きかったようです。
属人化を崩すときに、気をつけていること
ここまで実践を書いてきましたが、進め方を間違えると逆効果になります。私が意識していることを3つ挙げておきます。
1. 「属人化している人」を責めない
これが一番大事です。
属人化は、その人が真面目に働いた結果として生まれています。責める話ではありません。「あなたのおかげで回っていたが、これからは仕組みで支える」という伝え方をしないと、協力は得られません。
2. 一気にやろうとしない
すべての領域を同時に崩そうとすると、現場が回らなくなります。リスクの高いところから、少しずつ。半年、1年かけるつもりで進めるのが現実的です。
3. 「完全になくす」を目指さない
正直に言うと、属人化はゼロにはなりません。専門性の高い領域は、どうしても詳しい人ができてしまう。
目指すべきは撲滅ではなく、**「その人が休んでも止まらない状態」**です。ここを目標にすると、現実的な落としどころが見えてきます。
まとめ
属人化を解消するために、実際にやった3つのことをまとめます。
実践したこと
- 誰が何を知っているかを可視化する — 手順書より先に現状把握。優先順位が見える
- 手順書を「使わせる」 — 書くだけでは終わらない。他の人に使わせて抜けを潰す
- 意図的に担当を入れ替える — 読むだけでは動けない。やる機会を作る
気をつけること
- 属人化している人を責めない
- 一気にやろうとしない
- 「完全になくす」ではなく「休んでも止まらない」を目指す
かつての私は、「自分しかできない仕事」を持つことが価値だと思っていました。
でも今は、自分がいなくても回る状態を作ることのほうが、はるかに難しくて価値があると思っています。
もし今、あなたのチームに「あの人しかわからない領域」があるなら——まずは一覧表を作るところから始めてみてください。書き出すだけで、驚くほど景色が変わります。
コメント