この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「作業はできるのに、手順書になると途端に書けなくなる」
「後任者のために残した手順書が、結局役に立たないと言われた」
Linuxの現場で20年以上サーバー運用に携わってきましたが、この悩みは本当によく耳にします。コマンドを叩いて目の前の作業を終わらせる力と、他人が同じ作業を再現できる手順書を残す力は、まったく別のスキルです。
この記事では、20年以上Linuxサーバーを運用し、3,100名以上のエンジニアを指導してきた経験から、現場で信頼される「ドキュメントが書けるエンジニア」の共通点と、その技術の身につけ方を解説します。
コマンドが打てる段階から一歩先、「仕事を任される人」になるための視点としてお読みください。
この記事のポイント
・ドキュメントが書ける人は「再現性」で信頼を作っている
・良い手順書には前提条件・戻し手順・確認方法が必ず揃う
・書けない原因はスキル不足ではなく「読み手目線の欠如」
・書く力は小さな作業記録の積み重ねで鍛えられる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ「ドキュメントが書けるエンジニア」が現場で強いのか
Linuxの現場で評価されるエンジニアは、コマンドが速い人ではありません。自分が休んでも、退職しても、同じ品質で作業が回る状態を作れる人です。
ドキュメントが書ける人は、作業の全体像を言語化できています。だから新人への引き継ぎもスムーズで、障害対応の現場でも落ち着いて指示が出せます。
逆にコマンドは達者でも、作業が全部自分の頭の中にしか残っていない人は、ある瞬間から組織のボトルネックになります。休めない、任せられない、聞かないと誰も動けない。本人にとっても周囲にとっても、健全な状態とは言えません。
私のセミナーでも、ハンズオンの最後に「今やった手順をWordで書き起こしてください」という課題を出すことがあります。コマンドが動いた直後なのに、多くの受講生がここで手が止まります。書くという作業は、思っている以上に頭を使うのです。
現場で役に立つ手順書に共通する3つの条件
20年以上運用の現場を見てきて、「この手順書は使える」と感じるものには、はっきりした共通点があります。情報量が多いことでも、図が豪華なことでもありません。
1. 前提条件が最初に書いてある
OSのバージョン、実行ユーザー、接続先サーバー、事前に必要なパッケージ。
これらが冒頭に並んでいる手順書は、それだけで読み手の安心感がまるで違います。
実際に私が見てきた失敗の多くは、前提が曖昧なまま作業を始めてしまうケースでした。「RHEL 9の手順書をAlmaLinux 8に適用してエラーになった」「rootで実行する前提なのに一般ユーザーで流してしまった」。技術力の問題ではなく、情報が足りないだけで事故は起きます。
2. 戻し手順（ロールバック）が明記されている
これは本当に差が出ます。適用手順しか書いていない手順書は、正直あまり信用できません。
本番サーバーでの作業は「うまくいかなかった時にどう戻すか」がセットで決まって初めて実行可能になります。設定ファイルのバックアップコマンド、systemctl revertに相当する戻し方、DBなら事前ダンプの取得タイミング。ここまで揃っていると、レビュー側も「これなら任せられる」と判断できます。
受講生からよく聞かれるのが「戻し手順をどこまで書けばいいか」という質問です。私の答えは決まっていて、「その手順書を受け取った後任者が、真夜中に一人で障害対応する場面」を想像して書きなさい、と伝えています。
3. 作業後の確認方法がコマンド付きで書いてある
「設定が反映されたことを確認する」とだけ書いてある手順書と、「systemctl status httpd で active (running) であることを確認する」まで書いてある手順書では、再現性がまったく違います。
確認コマンドまで書けるということは、書いた本人が作業の完了条件を言語化できているということです。これができている時点で、その人は作業を理解しています。
なぜ書けないのか｜原因はスキルではなく視点
私が現場でよく見かけるのが、「文章力がないから書けない」と思い込んでいる人です。しかし20年以上見てきた感覚で言うと、原因はほぼ文章力ではありません。読み手目線が持てていないことです。
自分が作業した記憶のまま書くと、どうしても前提が抜けます。自分にとっては当たり前すぎて「わざわざ書く必要がない」と感じてしまうからです。
この壁を越えるために有効なのが、「この手順書を、明日入社する新人が一人で読んで実行する」と強制的に想定することです。すると途端に、省略していた接続情報、ユーザー権限、OSバージョンを書き足したくなります。読み手が変われば、書くべきことも変わるのです。
もう一つよくあるのが、完成形を目指しすぎて手が動かないケースです。最初から完璧な手順書を書こうとせず、まず雑でもいいから書いて、実際に誰かに試してもらう。そこで初めて「ここが伝わらないのか」が見えてきます。これは料理のレシピと同じで、他人が作って初めてレシピの精度が分かります。
書く力を鍛える日常の習慣
では、どうすればドキュメントが書けるエンジニアになれるのか。特別な訓練は必要ありません。日常の作業にちょっとした習慣を加えるだけです。
1. コマンド履歴を「物語」に書き直す
作業を終えた直後、historyに残ったコマンド群を、そのままではなく「目的・手順・確認」の3段構成に書き直してみてください。
たとえばApacheの設定変更なら、「目的：バーチャルホストを追加する」「手順：conf.dにファイルを作成してreload」「確認：curlで応答を確認」のように整理します。コマンドだけでは伝わらなかった意図が、ここで初めて言語化されます。
これを1日1件、数分で続けるだけで、3ヶ月後のドキュメント力はまるで変わります。
2. 社内Wikiを「書き換える」習慣を持つ
既存のWikiやConfluenceを読んで、分かりにくいと感じた箇所を1行でも書き換える。これが一番速い訓練です。
自分で一から書くより、他人の手順書を直す方がハードルは低く、かつ読み手目線が自然に鍛えられます。「なぜここで詰まったのか」を言語化する過程が、そのまま自分の書く力になります。
3. 作業ログにコメントを添える
scriptコマンドやティー出力で作業ログを残している人は多いと思いますが、そのログにあとから数行のコメントを添えるだけで、手順書の原型ができあがります。
「この時エラーが出たので、原因は権限設定」「この設定変更後、反映までに30秒かかった」。こうした注記は、書いた本人にしか残せない一次情報です。これがドキュメントの価値を決めます。
ドキュメント力が身につくと変わる3つのこと
書けるようになると、現場での立ち位置が明確に変わります。20年以上見てきた中で、よく目にする変化がこの3つです。
・任される仕事の範囲が広がる：「この人なら後任も育てられる」と判断され、設計や要件定義に呼ばれるようになります
・障害対応が落ち着いて進む：手順書を書き慣れた人は、障害時にも「前提・原因・対処・確認」の順で考える癖がつき、パニックに陥りにくくなります
・自分の時間が増える：ドキュメントを残せば、同じ質問を何度も受けずに済みます。結果的に、新しい技術を学ぶ時間が確保できます
コマンドが打てるだけの状態から、書けるエンジニアに移行できた人は、キャリアの選択肢がはっきり広がります。転職市場でも「チームを育てられる人材」として扱われ、単価の交渉余地が変わってきます。
まとめ
Linuxエンジニアにとって、ドキュメントを書ける力は「コマンドを覚える」と同じくらい重要なスキルです。特別な才能ではなく、日常の作業に読み手目線を足すだけで鍛えられます。
| 観点 | コマンドを打つだけの人 | ドキュメントが書ける人 |
|---|---|---|
| 作業の再現性 | 本人しか再現できない | 他人が同じ品質で再現できる |
| 引き継ぎ | 口頭で長時間かかる | 手順書で完結する |
| 評価されるポジション | 作業担当者 | 設計・レビュー・教育担当 |
| 障害対応 | パニックになりやすい | 前提と戻し手順で冷静に進む |
大切なのは、完璧な手順書を目指さず、まず小さく書き始めることです。historyを物語に書き直す、既存Wikiを1行直す、作業ログにコメントを添える。どれも5分あればできることばかりです。
コマンドが打てるだけのエンジニアから、現場で信頼される「書ける人」へ。この一歩を踏み出すかどうかで、3年後のキャリアは大きく変わります。
現場で信頼される「書けるエンジニア」になりませんか？
手順書が書ける力は、Linuxサーバーの仕組みを正しく理解していることが土台になります。現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：AI時代もLinuxの理解が問われる理由｜LPI-Japan調査「約6割が根本原因特定に苦慮」を現役講師が読み解く
- 前のページへ：Linuxの作業ミスを繰り返さない人がやっていること｜インシデントから学ぶ現役講師が教える習慣
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます