こういう話、Linuxの現場では驚くほどよくあります。
設定ファイルは複雑にカスタマイズされているのに、なぜそうしたのかの記録がどこにもない。cronには謎のスクリプトが並んでいるのに、何をしているのか誰も説明できない。
この記事では、SE時代にドキュメントゼロのサーバーを何台も引き継いだ経験と、その後20年近くLinuxサーバーを運用してきた知見から、引き継ぎ地獄を防ぐための3つの習慣を解説します。
この記事でわかること
・Linuxサーバーが属人化しやすい3つの構造的な理由
・SE時代に経験した「引き継ぎ地獄」の具体的な実態
・今日から始められる属人化防止の3つの習慣
・設定コメント・cron説明・構成メモの具体的な書き方
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜLinuxサーバーは「属人化」しやすいのか
Windowsサーバーと違い、LinuxサーバーにはGUIの管理画面がほとんどありません。設定は全てテキストファイルで行い、操作は全てコマンドで実行します。これはLinuxの大きな強みですが、同時に「属人化」の温床でもあります。
1. 設定意図が見えない
GUIであれば、設定画面を開けば何が設定されているか一目で分かります。しかしLinuxの設定ファイルは、中身を読んでも「なぜその値にしたのか」が分かりません。たとえば、httpd.confにMaxRequestWorkers 150と書いてあっても、デフォルトの256からなぜ150に変えたのか。メモリが足りなかったのか、同時接続数を制限する業務要件があったのか。設定値だけでは意図が読み取れないのです。
2. 自由度が高すぎる
Linuxは同じ目的を達成する方法が何通りもあります。ファイアウォールならiptablesでもfirewalldでもnftablesでも実現できる。タスクスケジューリングもcrontab、systemd timer、atコマンドと選択肢が豊富です。この自由度の高さが、「その人の流儀」でサーバーが構築される原因になります。前任者がiptablesで書いたルールを、firewalldしか知らない後任者が解読できない。こういった場面は現場で珍しくありません。
3. 「動いているから触るな」の呪い
20年近くサーバーを運用してきた経験から言うと、最も属人化が進むのは「安定して動いているサーバー」です。障害が起きなければ誰も中身を確認しない。確認しないからドキュメントも更新されない。年月が経つにつれて、そのサーバーを理解している人間が減っていく。そして前任者が異動や退職でいなくなった瞬間、誰も手が出せない「ブラックボックス」が完成します。
SE時代に経験した引き継ぎ地獄の実話
私がSE時代（2001年から2006年）に経験した引き継ぎの中で、特に印象に残っている場面を3つ紹介します。1. 設定ファイルにコメントが一行もなかった
ある案件で引き継いだRed Hat LinuxのWebサーバーは、Apacheの設定が大幅にカスタマイズされていました。バーチャルホストが10個以上定義され、リダイレクトルールも複雑に組まれている。しかし、設定ファイルにコメントが一行もありませんでした。# 引き継いだhttpd.confの一部（実際の設定をマスク） # コメントが一切なく、なぜこの設定にしたか全く分からない状態 <VirtualHost *:80> ServerName app01.example.co.jp DocumentRoot /var/www/app01 RewriteEngine On RewriteRule ^/old-api/(.*)$ /new-api/$1 [R=301,L] RewriteRule ^/campaign/?$ /lp/campaign2003.html [L] RequestHeader set X-Forwarded-Proto "http" ProxyPass /api/ http://192.168.1.xx:8080/api/ ProxyPassReverse /api/ http://192.168.1.xx:8080/api/ </VirtualHost>
結局、1週間以上かけてアクセスログとにらめっこしながら、一つひとつの設定の意味を解読するしかありませんでした。
2. cronに謎のスクリプトが20本並んでいた
別の案件では、引き継いだサーバーでcrontab -lを実行したところ、20本以上のジョブが登録されていました。$ crontab -l 0 3 * * * /opt/scripts/backup.sh */5 * * * * /opt/scripts/check_disk.sh 0 9 * * 1 /opt/scripts/report.sh 30 2 * * * /opt/scripts/cleanup.sh 0 * * * * /opt/scripts/sync_data.sh 15 4 * * 0 /opt/scripts/rotate_logs.sh # ...全部で20本以上（コメントは一切なし）
しかも途中で、sync_data.shが外部のFTPサーバーにデータを送信していることが判明し、そのFTPサーバーの接続先情報が社内のどこにも残っていないという事態まで発生しました。
3. 構成情報が「前任者の頭の中」にしかない
最も困ったのは、サーバーの構成情報がどこにも記録されていなかったケースです。・このサーバーのIPアドレスは何か → ifconfigで確認するしかない
・外部との通信で使っているポートは何か → iptablesのルールを解読するしかない
・バックアップはどこに取っているのか → cronとスクリプトを追うしかない
・障害時の連絡先は誰か → 誰にも分からない
全ての情報がサーバーの中に散らばっていて、全体像を把握するだけで数日かかりました。これが「引き継ぎ地獄」の正体です。
属人化を防ぐために実践している3つの習慣
SE時代の苦い経験を経て、私は「自分が明日いなくなっても、誰かがこのサーバーを運用できるか」を常に意識するようになりました。セミナーで3,100名以上を指導してきた中で、この考え方を伝えると「そこまでやるんですか」と驚かれることがあります。しかし、やらなかったときの代償を知っているからこそ、この3つの習慣は絶対に外せません。
1. 設定変更時は「なぜ変えたか」をコメントで残す
設定ファイルを編集するときは、「何を変えたか」だけでなく「なぜ変えたか」をコメントに書きます。# 良いコメントの例（httpd.conf） # 2026-04-11 miyazaki: 同時接続が200超でメモリ不足が発生したため、 # MaxRequestWorkersを256から150に制限（メモリ8GB、1プロセス約50MB） MaxRequestWorkers 150 # 2026-03-15 miyazaki: app01サーバー移設に伴い、ProxyPassの転送先を変更 # 旧: 192.168.1.10 新: 192.168.1.20（移設チケット #1234） ProxyPass /api/ http://192.168.1.xx:8080/api/
・日付と名前を入れる：いつ、誰が変更したかが追えるようになる
・「なぜ」を書く：数値の根拠が分かれば、後任者が環境に合わせて調整できる
・変更前の値を残す：問題が起きたときに元に戻す判断ができる
たった数行のコメントですが、これがあるだけで引き継ぎの難易度は劇的に下がります。
2. cronジョブには必ず説明コメントを書く
crontabにジョブを登録するときは、その直前に「何のためのジョブか」を必ずコメントとして書きます。# --- バックアップ --- # /var/www/以下の全サイトデータを/backupに日次バックアップ（7世代保持） 0 3 * * * /opt/scripts/backup.sh # --- 監視 --- # ディスク使用率が90%超でroot宛にメール通知 */5 * * * * /opt/scripts/check_disk.sh # --- レポート --- # 週次のアクセスログ集計をCSVで/opt/reports/に出力（毎週月曜9時） 0 9 * * 1 /opt/scripts/report.sh # --- メンテナンス --- # /tmp配下の7日以上前のファイルを自動削除 30 2 * * * /opt/scripts/cleanup.sh
作業ログの残し方については、Linuxの作業記録を残す習慣が現場の評価を変える理由でも詳しく解説しています。
3. サーバー構成を1枚のテキストにまとめる
サーバーを構築・運用するときは、そのサーバーの構成情報をテキストファイル1枚にまとめておきます。私はこれを「サーバーカルテ」と呼んでいます。# === サーバーカルテ === # 最終更新: 2026-04-11 miyazaki # # ホスト名: sv01.example.co.jp # OS: Rocky Linux 9.4 # 用途: Webサーバー（Apache 2.4）+ リバースプロキシ # IPアドレス: 192.168.1.xx（eth0） # # --- 公開ポート --- # 80/tcp : HTTP（443にリダイレクト） # 443/tcp : HTTPS（Apache + mod_ssl） # # --- 定期ジョブ --- # 毎日 3:00 : バックアップ（/opt/scripts/backup.sh） # 5分毎 : ディスク監視（/opt/scripts/check_disk.sh） # # --- バックアップ --- # 対象: /var/www/ , /etc/httpd/ # 保存先: /backup/（7世代） # リストア手順: /opt/scripts/README_restore.txt 参照 # # --- 障害時連絡先 --- # 1次: 田中（内線 1234） # 2次: 宮崎（携帯 090-xxxx-xxxx）
重要なのは、「完璧なドキュメント」を目指さないことです。テキストファイル1枚で十分です。ExcelやWordで立派な資料を作ろうとすると、面倒になって結局やらなくなります。テキスト1枚なら、viで開いてすぐに更新できる。この手軽さが継続の鍵です。
「自分がいなくなっても回る」が本物のスキル
Linuxの技術力というと、難しいコマンドを使いこなせることや、複雑な設定ができることをイメージするかもしれません。しかし現場で本当に信頼されるエンジニアは、「自分がいなくなっても、サーバーが回り続ける状態」を作れる人です。
「Linuxの仕組みを理解する人」と「コマンドをコピペする人」の決定的な差でも触れましたが、技術を本当に理解している人は「なぜそうするのか」を説明できます。その説明をコメントやドキュメントとして残す。それだけで、あなたの後を引き継ぐ人は何倍も楽になります。
「こんな面倒なことを毎回やるのか」と思うかもしれません。しかし、コメント1行を書く時間は10秒です。引き継ぎ地獄でサーバーを解読する時間は数日です。どちらが効率的かは明らかでしょう。
まとめ
| 習慣 | 具体的なアクション | 効果 |
|---|---|---|
| 設定コメント | 変更時に日付・名前・理由・旧値を記録 | 設定意図が後任者に伝わる |
| cron説明 | 各ジョブの直前に目的をコメントで記載 | crontab -lで全体像が一目で分かる |
| サーバーカルテ | 構成情報をテキスト1枚にまとめて/rootに配置 | 緊急時でも即座に全体像を把握できる |
今日から始めてください。設定ファイルを編集するときにコメントを1行追加する。cronにジョブを登録するときに説明を書く。サーバーの情報をテキスト1枚にまとめる。
この3つの習慣が身についたとき、あなたは「技術ができる人」ではなく「一緒に仕事をしたい人」として現場で信頼されるようになるはずです。
サーバー管理の「型」を体系的に学びたい方へ
「サーバーを構築できるようになりたいけれど、何から手をつければいいか分からない」「引き継いだサーバーの全体像を理解したい」——そのような悩みは、正しい手順で体系的に学べば必ず解決できます。
ネットの断片的な情報に頼るのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxの「動いている」を信じすぎると痛い目に遭う理由｜現役講師が語る監視と確認の習慣
- 前のページへ：Linuxを独学で学んだ人が現場で最初につまずく5つの場面｜現役講師が教える実務との埋め方
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます