この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
自分では分かっているつもりなのに、ドキュメントを渡したら「意味が分からない」と言われた。
こういう経験は、Linuxエンジニアなら誰しも一度は通る道です。
この記事では、20年以上Linuxサーバーを運用・指導してきた経験から、引き継ぎで本当に起きること、そして「引き継がれる側が困らないドキュメント」の作り方を正直にお伝えします。
引き継ぎが上手い人は、現場で突出して信頼されます。その理由も含めて解説します。
この記事のポイント
・引き継ぎドキュメントが「使えない」根本原因は作る側の思い込みにある
・「なぜそうなっているか」を書かないと読んだ側が動けない
・引き継ぎ品質が高い人が現場で長く必要とされる理由がある
・今すぐ実践できる引き継ぎドキュメントの3つの型を紹介
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
引き継ぎで本当によく起きること
私がSEとして現場に出ていた2001年から2006年、引き継ぎは常に課題でした。プロジェクトが変わるたびに、前担当者のドキュメントを読み解くことになる。
ところが、そのドキュメントが「役に立つ」と感じたことは、正直ほとんどありませんでした。
コマンドの手順だけが書いてある。でも「なぜそのコマンドを使うのか」が書いていない。
サーバー構成図はある。でも「このポート番号はどのサービスが使っているか」が分からない。
定期メンテナンスの手順はある。でも「失敗したときの戻し方」が一切ない。
結果として、私は引き継いだ初日から先輩に聞いてまわることになりました。
「この設定を変えたのは誰ですか？」
「このcronはいつから動いてるんですか？」
「このバックアップ、どこに戻せばいいですか？」
先輩は答えてくれましたが、その人も「たぶんこうだと思う」という返答が半分以上でした。
これが引き継ぎの現実です。
セミナーで3,100名以上を指導してきた中でも、引き継ぎに関する悩みを打ち明けてくれる受講生は後を絶ちません。
「自分が書いたドキュメントを同僚に渡したら、後から何度も聞かれた」という声は特に多い。
問題はドキュメントの量ではなく、「何を書くか」にあります。
引き継ぎドキュメントが機能しない3つの理由
1. 「やり方」しか書いていない
Linuxの引き継ぎドキュメントで最も多い失敗パターンは、手順だけが書いてあるケースです。# よく見かける引き継ぎドキュメントの例 # Apacheを再起動する sudo systemctl restart httpd
「いつ再起動するのか」が分からない。「再起動の前後に確認すべきことは何か」も分からない。
「失敗したらどうなるのか」「失敗を検知する方法は何か」も分からない。
コマンドは正確に書いてある。でも「なぜこの操作が必要なのか」という文脈がないため、読んだ側は動けません。
20年以上サーバーを運用してきた経験から言うと、引き継ぎドキュメントに「なぜ」を書く習慣があるかどうかで、現場のチームの生産性は大きく変わります。
2. 書いた人だけが「分かる」書き方をしている
引き継ぎドキュメントを書く人は、すでにそのシステムを熟知しています。だから「この設定は分かるよね」という前提で書いてしまう。
私が現場でよく見かけるのが、こういう記述です。
「設定ファイルを編集して、従来通りの手順で適用する」
「従来通り」とは何か。引き継いだ人には分かりません。
設定ファイルがどこにあるか、どう編集するか、適用の方法は何か——すべてが「知っている人」前提で書かれています。
これは書いた人の悪意ではなく、単純な「思い込み」です。
「これくらいは分かるだろう」という前提が、引き継ぎを破綻させます。
私がセミナーで繰り返しお伝えしているのは、「ドキュメントはそのシステムを知らない人が読む」という視点で書くことです。
これだけで、引き継ぎドキュメントの質は劇的に上がります。
3. 「正常系」しか書いていない
引き継ぎドキュメントで最もよく抜け落ちるのが「異常系」の記述です。正常に動いている手順は書いてある。でも、トラブルが起きたときの対処法がない。
実際の現場では、正常な手順通りに動くことの方が少ない。
特にLinuxサーバーの運用では、想定外の事態が日常的に発生します。
# バックアップスクリプトの実行例 ./backup.sh # 正常終了時のメッセージ Backup completed: /backup/20260511_030001.tar.gz # よく起きるエラーとその意味 # [ERROR] No space left on device # → /backup のディスクが満杯。古いバックアップを削除してから再実行 # [ERROR] Cannot open: Permission denied # → スクリプトの実行権限が必要。chmod +x backup.sh で付与する
私が現場でよく見かけるのは、エラーが出るたびに引き継いだ人が前担当者に連絡してくるケースです。
それは引き継ぎが完了していない証拠です。
今すぐ実践できる引き継ぎドキュメントの3つの型
1. 「なぜ」を必ず添える型
手順の前に「なぜこの操作が必要か」を一文で書く習慣をつけます。# 定期メンテナンス：ログローテーションの手動実行 # なぜ必要か: /var/log/messages が1GB超えると # syslogdがディスクフルで止まる事故が過去に発生 # 毎週月曜09:00にcronで自動実行しているが、 # 手動で実行が必要な場合はこのコマンドを使う sudo logrotate -f /etc/logrotate.conf
「このlogrotateはcronが動いていれば自分で叩かなくていいんだ」という判断ができるようになります。
これは手順だけを読んでいたら絶対に分からないことです。
2. 「知らないと困ること」を最初にまとめる型
ドキュメントの冒頭に「このシステムで知っておかないと困ること」をリストアップします。・このサーバーは深夜02:00にバックアップが走る。その時間帯はディスクI/Oが重くなる
・/etc/hostsに直書きのエントリがある。DNSを変えただけでは一部の通信が切れることがある
・rootのcronは別管理になっている。crontab -e ではなく /etc/cron.d/ を確認すること
・サービス再起動後は最低5分待ってからログを確認すること（起動直後に別プロセスが起動する）
こうした「地雷の場所」をあらかじめ伝えておくのが、引き継ぎ上手な人がやっていることです。
私が現場でよく見かけるのが、ベテランが「あ、それ知らなかったの？」と当たり前のように言う場面です。
それは悪意ではなく、あまりにも自分には当然のことすぎて文書化されていないのです。
引き継ぎとは、この「暗黙知」を言語化する作業です。
3. 「前の人に聞けない時の行動フロー」を書く型
引き継ぎ後に最も困るのは、「前担当者がいない状況で初めて見る障害」です。| よくある状況 | 最初に確認すること | 確認コマンド |
|---|---|---|
| Webサービスに繋がらない | httpdのプロセスが動いているか | systemctl status httpd |
| メールが送れない | PostfixとSMTPポートの状態 | systemctl status postfix |
| ディスクが重い | 使用率と残容量の確認 | df -h |
| 何か分からないがサーバーが重い | 負荷の高いプロセスを特定 | top -b -n 1 | head -20 |
| ログに見知らぬエラーが出ている | 直近のエラーを時系列で確認 | tail -100 /var/log/messages |
「前担当者に何度も電話してしまう」という状況を防ぐのも、良い引き継ぎドキュメントの役割です。
引き継ぎが上手い人が現場で信頼される理由
引き継ぎドキュメントをきちんと作れる人は、現場で突出して信頼されます。その理由は、ドキュメントの質だけではありません。
引き継ぎを丁寧にできる人は、自分の作業を「他者の視点で見る力」があります。
これは、システム設計でも、コードレビューでも、障害報告でも、すべてに共通する能力です。
「自分には分かっている」を疑い、「相手には何が分からないか」を考えられる。
私が20年以上現場を見てきた中で、長く活躍するエンジニアには必ずこの視点があります。
技術力が高くても、自分の作業を他者に伝える力がない人は、チームの中での価値を十分に発揮できません。
反対に、技術力が並程度でも、引き継ぎや文書化が上手い人は、プロジェクトをまたいで頼りにされ続けます。
セミナーで受講生によく話すのですが、「次の人が困らないドキュメントを書く」という習慣は、実は自分の理解を深める練習でもあります。
なぜなら、「なぜそうなっているか」を書くためには、自分が本当に理解していないと書けないからです。
まとめ
引き継ぎで失敗する原因は、技術力の不足ではありません。「書いた人にしか分からない前提」「手順だけで理由がない」「異常系が書かれていない」——この3点に集約されます。
・「なぜこの操作が必要か」を手順の前に一文書く
・「知らないと困ること」を冒頭にリストアップする
・「困ったときの初動フロー表」を添える
この3つを実践するだけで、引き継ぎドキュメントの質は大きく変わります。
引き継ぎを丁寧にできる人は、技術の伝達者として現場で長く必要とされます。
コマンドを覚えることと同じくらい、この「伝える力」を磨いてほしいと思います。
引き継ぎが上手くなる前に、まず「現場で通用するLinuxの基礎」を固めたいあなたへ
伝える力は、本当に理解していないと身につきません。まずは正しいLinuxの土台を作ることが先です。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、'Linuxサーバー構築入門マニュアル（図解60P）'を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxの教科書には書いていない現場のリアル｜20年以上の運用経験で気づいた「知識」と「使える力」の差
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます