こんにちは、インフラエンジニアのryuです。
いきなりですが、育成担当や情報システムの責任者の方に質問です。もし自社のサーバーやネットワークの面倒を見ている「あの人」が、明日から一ヶ月休むことになったら、業務は回るでしょうか。
「たぶん大丈夫」と即答できる会社は、実はそう多くありません。「あの人がいないと、何がどうなっているのか誰も分からない」——そんな状態に、心当たりはないでしょうか。
これがいわゆる 属人化 です。今日は、インフラ運用が特定の一人にぶら下がってしまう問題を、どう解きほぐしていくか。育成とナレッジ継承の観点から、明日から動ける形でお話しします。
そもそも「属人化」って、何が問題なの？¶
言葉はよく聞くけれど、何が困るのかを言葉にすると意外と難しいものです。まず、そこをそろえておきましょう。
属人化とは、ある業務のやり方や知識が特定の人の頭の中だけにあって、他の人には見えない・引き継げない状態を指します。手順書もなく、その人に聞かないと何も分からない。これが、インフラの現場では驚くほど起きやすいのです。
一人の名人が全部やってくれるのは、一見すると効率がいいように見えます。ですが、これは会社にとってかなり危うい状態です。
宅配便にたとえてみましょう。ある地域の配達を、地図を持たないベテラン一人が「体で覚えた勘」だけで回しているとします。毎日きちんと届くうちはいい。でも、その人が体調を崩した瞬間、代わりの人はどの家がどこにあるのかすら分かりません。荷物は止まり、誰も動けなくなる。属人化とは、まさにこの状態のことです。
属人化が生む、3つのリスク¶
もう少し具体的に、何が困るのかを整理します。
一つ目は、事業が止まるリスクです。担当者が休む・辞める・倒れる、そのどれか一つで運用が立ち行かなくなります。障害が起きても、原因を追える人が一人しかいなければ、その人が捕まるまで復旧できません。
二つ目は、品質とセキュリティのリスクです。一人しか中身を分かっていないと、その設定が本当に安全なのか、誰もチェックできません。ミスがあっても気づかれないまま放置される。ブラックボックス化した仕組みは、事故の温床になります。
三つ目は、人が育たないリスクです。「あの人がやるから」で仕事が固定されると、周りはいつまでも経験を積めません。結果、属人化はさらに進み、抜け出せなくなっていきます。
これは、あなたの会社だけの話ではない¶
属人化は、個々の会社のだらしなさの問題ではありません。国全体の課題として、正面から指摘されています。
経済産業省が2018年に公表した「DXレポート」は、古い基幹システムがブラックボックス化し、担当者の高齢化・退職によって中身が分からなくなっていく問題を「2025年の崖」として警告しました。このまま放置すれば、2025年以降に最大で年間12兆円もの経済損失が生じかねない、という試算まで示されています。
システムの複雑化・ブラックボックス化と、それを支える人材の不足。この二つが重なったとき、企業は身動きが取れなくなる。DXレポートが鳴らしたのは、そういう警鐘でした。
つまり属人化は、日々の運用の困りごとであると同時に、放っておくと経営を揺るがす構造的なリスクなのです。だからこそ、意識して解きほぐしていく価値があります。
なぜインフラは、こんなに属人化しやすいのか¶
対策の前に、原因を押さえておきましょう。敵の正体が分かれば、打ち手も見えてきます。インフラが属人化しやすいのには、はっきりした理由があります。
一つは、障害対応が緊急だからです。サーバーが落ちれば、悠長に手順書を書いている暇はありません。分かっている人が全速力で直す。そのくり返しの中で、知識はその人の中だけに溜まっていきます。
もう一つは、暗黙知が多いことです。「この機器はたまに不安定になるから、再起動はこの順番で」といったコツは、マニュアルには書きにくい。経験として体に染み込んでいるぶん、言葉にして残されないまま埋もれてしまいます。
そして、ドキュメント化が後回しにされがちなこと。記録を残す作業は、動いているシステムを前にすると「あとでやろう」になりやすい。その「あとで」は、たいてい永遠に来ません。
加えて、担当者本人が「自分にしかできない」状態に、無意識のうちに安心してしまう面もあります。頼られること自体は悪いことではありません。ですが、それが行き過ぎると、知識を抱え込むことが本人の存在価値になってしまい、共有が進まなくなる。これは本人の人柄の問題ではなく、そう仕向けてしまう構造の問題です。
こうして、悪気なく、むしろ真面目に頑張るほど属人化が進んでいく。ここがこの問題のやっかいなところです。裏を返せば、仕組みで対処しない限り、個人の善意では防げないということでもあります。だからこそ、次に挙げる打ち手は、どれも「個人の頑張り」ではなく「チームの仕組み」として設計していきます。
属人化を解消する、育成とナレッジ継承の設計図¶
では、どう解きほぐすか。順番が大事なので、3つのステップに分けて整理します。いきなり全部をやろうとせず、順に進めるのがコツです。
ステップ1：「あの人の頭の中」を書き出す¶
まず取りかかるのは、頭の中にある知識を、外に出して形にすることです。
とはいえ、いきなり完璧なマニュアルを作ろうとすると、必ず挫折します。おすすめは、障害対応の手順を一つずつ、短い「手順書（ランブック）」として残していくやり方です。例えば、こんな一枚から始めます。
# ランブック：Webサーバーが応答しないとき
## 1. まず確認する
- 監視画面でどのサーバーが赤いか確認
- ping で疎通確認： ping <サーバーIP>
## 2. サービスの状態を見る
- systemctl status nginx で稼働状況を確認
- ログを見る： tail -n 50 /var/log/nginx/error.log
## 3. 再起動する（順番を守る）
- systemctl restart nginx
- 直らなければ、上長 or 二次対応者へ連絡
## 4. 連絡先
- 監視ベンダー： 03-xxxx-xxxx
完璧である必要はありません。「その人がいなくても、これを見れば次の一手が分かる」。まずはこの水準を目指します。障害が起きるたびに一枚ずつ増やしていけば、半年後にはかなりの厚みになります。
残すべき知識は、大きく次のように分けて考えると漏れが減ります。
| 種類 | 具体例 | 残し方 |
|---|---|---|
| 構成情報 | サーバー一覧・IP・ネットワーク図 | 一覧表・構成図 |
| 手順 | 構築・変更・障害対応の段取り | ランブック |
| 判断の理由 | なぜこの設定にしたのか | 設計メモ・コメント |
| 連絡先 | ベンダー・契約・アカウント | 台帳 |
特に見落とされがちなのが、三つ目の「判断の理由」です。設定そのものは見れば分かっても、なぜそうしたのかは本人しか知らない。ここを一言残しておくだけで、引き継いだ人の理解がまるで変わります。
もう一つ大事なのが、どこに残すかです。せっかく書いても、個人のPCやメールの中に散らばっていては、いざというときに見つかりません。チームの誰もがたどり着ける共有の置き場所を一つ決めて、そこに集約する。凝ったツールでなくても、社内のWikiや共有フォルダで十分です。「困ったらまずここを見る」という場所が決まっているだけで、探す時間が大きく減ります。
ステップ2：複数人が「同じことをできる」状態にする¶
書き出したものは、使われて初めて意味を持ちます。次のステップは、その知識を実際に他の人へ移すことです。
ここで効くのが、クロストレーニング、つまり一つの役割を複数人ができるようにしておく考え方です。担当を一人に固定せず、二人目・三人目が同じ作業を回せる状態を意図的に作ります。
やり方はシンプルで、日々の運用に「ペアで対応する」「持ち回りで担当する」を少しずつ混ぜていくこと。ベテランが対応するとき、若手を横につけて手順を実況してもらうだけでも、暗黙知はかなり移っていきます。
コツは、いきなり本番の重い作業を任せないことです。まずは見学、次に手順書を見ながら一緒に、その次に本人が主でベテランが後見に回る。この三段階を踏むと、教わる側も安心して手を動かせますし、教える側も「任せて大丈夫か」を確かめながら渡していけます。一足飛びに突き放すと事故につながりますが、段階を踏めば着実に移っていきます。
もう一つ意識したいのが、教えることを評価する文化です。自分の仕事を人に渡すのは、短期的には自分の手間が増えるだけに見えます。ここで「よく引き継いでくれた」ときちんと認める姿勢がないと、誰も知識を手放そうとしません。引き継ぎやドキュメント化を、雑務ではなく評価される仕事として扱うこと。これが遠回りに見えて、いちばん効きます。
大事なのは、これを本人任せにしないことです。「時間があれば教えて」では、忙しい現場では永遠に後回しになります。引き継ぎを個人の善意ではなく、業務そのものとしてスケジュールに組み込む。ここが、成否を分けます。
この考え方は、新人の受け入れ設計とも地続きです。誰かに寄りかからないチームづくりの土台については、インフラ新人研修の設計や早期離職を防ぐオンボーディングの記事も、そのまま参考になります。
ステップ3：共通の「土台スキル」をそろえる¶
引き継ぎがうまくいかない原因の一つに、そもそも受け取る側の基礎が足りない、という問題があります。
ランブックを渡しても、systemctl が何なのか、ネットワーク図の矢印が何を意味するのかが分からなければ、知識は移りません。だからこそ、チーム全員がある程度共通の土台を持っていることが、ナレッジ継承の前提になります。
ここで役立つのが、経済産業省とIPAが策定した「デジタルスキル標準（DSS）」です。DXに関わる人材の役割と必要スキルが体系的に整理されていて、2026年4月には最新のver.2.0が公開されました。自社が「どのレベルまで全員に身につけてほしいか」を決める、公的な物差しとして使えます。
土台をそろえる学習の入り口としては、分野別のロードマップがある教材が向いています。InfraAcademyでも、まず押さえたいLinuxのロードマップやインフラエンジニアの全体ロードマップ、ネットワークの始め方といった形で、学ぶ順番に沿って進められるようにしています。基礎のコマンド操作ならLinuxコマンドの初心者向け解説あたりが取っかかりになります。
全員の土台がそろうと、ランブックの言葉が通じるようになり、引き継ぎのスピードが一気に上がります。遠回りに見えて、実はここが近道です。
属人化しにくいチームをつくる、日々の習慣¶
設計図を描いても、日々の習慣に落ちなければ元に戻ります。最後に、属人化を「起きにくく」する小さな工夫を挙げておきます。
一つは、変更を一人で完結させないことです。設定を変えるときは、必ずもう一人がレビューする。二人の目が入るだけで、知識は自然と共有され、ミスも減ります。
もう一つは、休みを「取れる」前提で回すこと。担当者が有給を取っても業務が止まらないなら、それは属人化が解けている何よりの証拠です。逆に「あの人は休めない」が続くなら、危険信号だと考えましょう。試しに、キーパーソンにあえて一日休んでもらい、残りのメンバーだけで回してみる。そこで浮かび上がった「詰まった箇所」こそ、次に手を打つべきポイントです。訓練だと割り切って、意図的に穴を見つけにいく発想も有効です。
そして、記録を残す時間を業務として認めること。ドキュメント作成を「手が空いたらやる雑務」ではなく、正式な仕事として時間を確保する。この後ろ盾があるかどうかで、ナレッジが残るかどうかが決まります。
小さな習慣として、障害対応が一段落したあとに数分だけ「今回どこでつまずいたか」を書き残す、というルールも効果的です。記憶が新しいうちに一言残しておくだけで、次に同じことが起きたときの立ち上がりがまるで変わります。完璧な報告書は要りません。あとで読んだ人が助かる、その一行があれば十分です。こうした小さな積み重ねが、気づいたときには立派なナレッジベースになっています。
こうした仕組みづくりを、自社だけで走らせるのが難しいときは、外の力を借りるのも一つの手です。InfraAcademyでは、チーム全体の土台スキルを底上げし、進捗の見える化まで含めた法人向けプランをご用意しています。属人化の解消は、一人の負担を減らすだけでなく、組織全体を強くする投資でもあります。
まとめ¶
インフラの属人化、つまり「あの人しかわからない」問題を、今日は解きほぐしてきました。
要点を振り返ります。属人化は、事業停止・品質低下・人が育たないという三つのリスクを抱え込み、DXレポートが「2025年の崖」として警告したほどの構造的な課題でもあります。インフラは障害対応の緊急性や暗黙知の多さから、放っておくと必ず属人化に傾きます。
だからこそ、頭の中を書き出し、複数人ができる状態を作り、共通の土台をそろえる。この三段構えで、意識的に解きほぐしていく必要があります。そして日々のレビューや持ち回りといった習慣で、元に戻らないようにする。
一人の名人に頼るチームは、強そうに見えて、実はもろい。知識が人から人へ流れるチームこそが、長い目で見ればいちばん頼りになります。まずは「あの人が一ヶ月休んでも回るか」を、チームで一度問い直すところから始めてみてはいかがでしょうか。
