Linuxサーバーの作業で、自分が何をやったか後から思い出せなくなった経験はありませんか。サーバー管理者なら誰でも一度はぶつかる壁です。
この記事では、15年以上Linuxサーバーを運用してきた経験から、現場で信頼される作業記録の残し方と、それがエンジニアとしての評価にどうつながるのかを解説します。
この記事のポイント
・作業記録を残す人は障害対応の速度が段違いに速い
・記録は「何をしたか」だけでなく「なぜそうしたか」が重要
・historyコマンドとscriptコマンドが記録の基本になる
・記録の習慣がキャリアアップにも直結する
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ作業記録を残さないエンジニアが多いのか
「忙しいから記録なんて書いている暇がない」。私がセミナーで3,100名以上を指導してきた中で、作業記録について聞くと、こう答える方が本当に多いです。気持ちはわかります。目の前のサーバーが動かないとき、悠長にメモを取っている場合ではないと感じるのは自然なことです。
しかし、現場で信頼されているエンジニアほど、記録を残しています。
理由は単純です。記録がなければ、同じ問題が起きたときにまたゼロから調べ直すことになるからです。
私自身、SE時代の2000年代前半に痛い経験をしました。深夜のサーバー障害で必死に対応し、なんとか復旧させた。ところが翌月、まったく同じ障害が再発したとき、前回何をやったのか思い出せない。結局、また一から調査して2時間かかりました。
あのとき5分でも記録を残していれば、2回目は15分で終わっていたはずです。
現場で信頼される作業記録の3つの要素
「記録を残せ」と言われても、何をどう書けばいいのかわからない方も多いでしょう。15年以上サーバーを運用してきた経験から言うと、必要な要素は3つだけです。1. 「いつ・何をしたか」を時系列で残す
最も基本的な要素です。日時と実行したコマンド、変更した設定ファイルの内容を時系列で記録します。ポイントは、「うまくいかなかった操作」も消さずに残すこと。失敗の記録こそ、次回の時間短縮につながります。
たとえば、こんな書き方です。
# 2026-04-01 14:30 Apacheが起動しない件の調査 # systemctl status httpd でエラー内容を確認 # → AH00526: Syntax error on line 42 of /etc/httpd/conf/httpd.conf # httpd.conf の42行目を確認 → DocumentRootのパスにtypoあり # /var/www/htmll → /var/www/html に修正 # systemctl start httpd で起動成功を確認
2. 「なぜそうしたか」の判断理由を書く
私が現場でよく見かけるのが、「やったこと」だけ書いて「なぜそうしたか」が抜けている記録です。たとえば「firewalldでポート8080を開放した」とだけ書いてあっても、半年後の自分は「なぜ8080が必要だったのか」を思い出せません。
・NG例：firewalldで8080を開放した
・OK例：開発チームからTomcat用に8080番ポートの開放依頼あり。社内NWからのみアクセス可能な設定でfirewalldに追加
判断理由が残っていると、後から「この設定は本当に必要か」の棚卸しもできます。設定が増えていく一方のサーバーで、不要な設定を見つけられるのは大きなメリットです。
3. 「変更前の状態」をバックアップとセットで残す
設定ファイルを変更するとき、変更後の内容だけ記録する方がいますが、それでは不十分です。変更前の状態を残しておくことで、問題が起きたときにすぐ切り戻しができます。実務では、設定変更前にコピーを取る習慣をつけましょう。
# 変更前のバックアップ（日付をファイル名に含める） cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.20260401
変更前後の差分を残しておくなら、diffコマンドも活用できます。
作業記録に役立つLinuxコマンド
記録を残すのが面倒に感じる方のために、Linuxには作業を自動的に記録してくれる便利なコマンドがあります。historyコマンドで過去のコマンドを振り返る
最も手軽な方法がhistoryコマンド（bashシェルに標準搭載されているコマンド履歴機能）です。過去に実行したコマンドの一覧を確認できます。# 直近20件のコマンド履歴を表示 history 20
# .bashrcに追記してhistoryにタイムスタンプを記録する export HISTTIMEFORMAT="%F %T "
scriptコマンドでターミナル操作を丸ごと記録する
重要な作業のときは、scriptコマンド（ターミナルセッションの全入出力を記録するユーティリティ）を使うのがおすすめです。ターミナルの入出力をまるごとファイルに記録してくれます。# 作業記録の開始 script /tmp/work_20260401.log # ここから通常どおり作業する # ... # 作業記録の終了 exit
障害対応のとき、まず最初にscriptコマンドを実行する。これを習慣にしている人は、私の経験上、例外なく現場で頼りにされています。
【注意】scriptコマンドで記録したファイルには、パスワード入力時の画面出力も含まれます。記録ファイルの保管場所と権限には十分注意してください。作業後は記録ファイルを適切なディレクトリに移動し、chmod 600で自分だけが読めるように設定に変更しておくのが安全です。
記録がない場合に起きるトラブルと対処法
「記録を残していなかったけど、過去の作業内容を調べたい」。こういう場面は実務で必ず出てきます。・historyが消えている場合：ログアウトやサーバー再起動で履歴が飛ぶことがあります。~/.bash_historyファイルが残っていれば復元できる可能性があるので、まず確認してください
・誰が変更したかわからない場合：/var/log/secureや/var/log/auth.log（ログイン履歴）を確認すれば、いつ誰がログインしたかは追えます。lastコマンドも併用しましょう
・設定ファイルの変更履歴がない場合：バックアップからの差分比較で推測するしかありません。これが「記録を残さないコスト」です
こうした痛みを経験すると、次からは自然と記録を残すようになります。
作業記録がキャリアを変える理由
「記録を残すなんて地味な話だ」と思うかもしれません。でも、15年以上この業界にいて断言できることがあります。作業記録をきちんと残せるエンジニアは、現場での評価が確実に上がります。
理由はいくつかあります。
・引き継ぎがスムーズになる：自分の作業記録がそのまま引き継ぎ資料になる。チームから「助かる」と言われる場面が増える
・障害対応が速くなる：過去の記録を検索するだけで原因の当たりがつく。ゼロから調べる人との差は歴然
・判断の根拠を説明できる：「なぜこの設定にしたのか」を聞かれたとき、記録があればすぐ答えられる
特に3つ目は重要です。上司やクライアントから「この設定の根拠は？」と聞かれて、「覚えていません」と答えるのと、「このとき、こういう理由で変更しました」と即答するのでは、信頼度がまるで違います。
Linuxのログが読めるだけで現場の信頼が変わるという話を以前書きましたが、ログを読む力と同じくらい、自分の作業を記録する力も大切です。
まとめ
作業記録は、今日から始められる最もコストの低いスキルアップ方法です。| ポイント | 内容 |
|---|---|
| 時系列で残す | 日時・コマンド・結果を順番に記録する |
| 判断理由を書く | 「なぜそうしたか」が半年後の自分を助ける |
| 変更前を残す | cpで日付付きバックアップを取ってから変更する |
| historyの活用 | HISTTIMEFORMATで時刻付き履歴にする |
| scriptの活用 | 重要な作業はscriptコマンドで丸ごと記録する |
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxで伸び悩むエンジニアが捨てるべき3つの思い込み｜現役講師が語る学習の方向性
- 前のページへ：Linuxのエラーメッセージが読めれば障害対応は3倍速くなる｜現場で差がつく英語力の身につけ方
- この記事の属するカテゴリ：Linux学習ガイドへ戻る