作業記録と報連相 — エンジニアの基本動作

Linuxエンジニア養成講座第2回｜全36回・フェーズ1「エンジニアのいろは」の第2回です。
前回までに学んだこと: エンジニアの仕事の全体像と学び方（第1回）。
今回学ぶこと: 作業記録の残し方と報連相。

この記事は座学回です。仮想マシン（VM）の操作はありません。

この回の学習目標

この記事を読み終えると、以下ができるようになります。

scriptコマンドとTeraTermログ機能の役割を説明できる
良い作業記録の3つのポイント（5W1H、変更前の状態、コマンドと結果のセット）を実践できる
障害発生時の第一報をテンプレートに沿って書ける
技術的な質問を構造化して相談できる

第1回では「作業ログを残す」ことの大切さに触れました。変更前の状態を記録していなかったために、本番環境で設定を元に戻せなくなる ―― そんなヒヤリハットも紹介しました。今回はその「作業記録」について、具体的な残し方と、インフラ現場で命綱となる「報連相」を学びます。

コンテンツ

この回の学習目標

なぜ「作業記録」が最初の技術スキルなのか
作業記録とは何か
- 作業記録の3つの役割
- 記録がなかったらどうなるか
作業記録の残し方 — 4つの方法
「良い作業記録」と「役に立たない作業記録」の違い
報連相 — エンジニアの命綱
ヒヤリハット — 作業記録がなかった夜
やってみよう — 作業記録を書いてみる
- 演習1: 作業報告書を書いてみる
- 演習2: 障害の第一報を書いてみる
理解度チェック
まとめ
シリーズ一覧

なぜ「作業記録」が最初の技術スキルなのか

Linuxのコマンドを学ぶ前に、なぜ「記録の残し方」から始めるのか。理由は明快です。

インフラエンジニアの成果物は「正常に動いているサーバー環境」です。開発エンジニアのソースコードのように、目に見える形で成果が残りにくい仕事です。だからこそ、作業記録が唯一の証跡になります。

どれだけ高度なコマンドを使いこなしても、記録が残っていなければ「何をやったのか」を誰にも証明できません。逆に、技術的にはまだ覚えたてでも、記録をきちんと残せるエンジニアは信頼されます。記録は技術力以前の「プロとしての基本動作」です。

作業記録とは何か

作業記録の3つの役割

作業記録は、主に次の3つの場面で力を発揮します。

1. 再現性の担保

あるサーバーで行った設定を、別のサーバーでも同じように再現する。そのためには、実行したコマンドと手順が正確に残っている必要があります。「あのとき何をやったか」が手元にあれば、2台目・3台目の構築は格段に速くなります。

2. トラブルシューティングの手がかり

障害が発生したとき、真っ先に確認するのは「最近何を変更したか」です。記録があれば変更箇所をすぐに特定でき、復旧の判断を素早く下せます。記録がなければ、原因調査はゼロからのスタートです。

3. 引き継ぎと監査への対応

担当者が異動や退職をしても、作業記録があれば後任がシステムの経緯を追えます。金融・医療・官公庁のシステムでは、「いつ、誰が、何をしたか」の記録提出が義務付けられることもあります。

作業記録の3つの役割。再現性（同じ手順を別のサーバーでも再現）、トラブルシューティング（変更箇所を特定し素早く復旧）、引き継ぎ・監査（後任や監査に経緯を説明）。記録がすべての土台。

記録がなかったらどうなるか

具体的なシナリオで考えてみましょう。

障害対応の場面 ―― 上司から「昨日何か設定を変更しましたか?」と聞かれて、「覚えていません」としか答えられない。原因の切り分けが大幅に遅れ、サービス停止時間が延びる。

引き継ぎの場面 ―― 「このサーバー、なぜこの設定にしたんですか?」と聞いても、前任者はもういない。設定の意図がわからないため変更もできず、誰も触れない「聖域サーバー」が生まれる。

監査の場面 ―― 「この変更は誰が承認しましたか?」という質問に、証跡を出せない。「やりました」という口頭の報告だけでは監査は通りません。

どの場面でも、記録があれば防げた問題です。

作業記録の残し方 — 4つの方法

ここからは、インフラエンジニアが実務で使う作業記録の方法を4つ紹介します。第4回以降でVMに接続して作業するとき、これらの方法を実際に使います。今は「こういう手段がある」ということを頭に入れておいてください。

方法1: テキストファイルに手書きメモ

最もシンプルな方法です。テキストエディタを開き、自分がこれから行う作業と、実行したコマンド・結果を書き留めていきます。

記録する項目の例:

日時: 2026/03/28 14:00
作業者: 山田
対象サーバー: alma-main（192.168.1.121）
目的: Apacheの設定変更（ServerName の修正）
実行コマンドと結果（コピー&ペースト）
変更前の設定値と変更後の設定値

メリットは道具を選ばないこと。メモ帳でもテキストエディタでも、Excelでも構いません。デメリットは、記録の抜け漏れが起きやすいことです。コマンドの打ち間違いや出力の記録忘れを防ぐには、次に紹介するツールを併用します。

方法2: scriptコマンド

script はLinuxに標準で搭載されているコマンドで、ターミナル上の入力と出力をすべてファイルに記録します。AlmaLinux 9.6のMinimal Installにも含まれています。

基本的な使い方は以下のとおりです。

実行コマンド:

$ script /tmp/work_20260328.log

実行結果:

Script started, output log file is '/tmp/work_20260328.log'.

このメッセージが表示されたら記録開始です。以降のコマンド入力と出力がすべてファイルに保存されます。記録を終了するには exit と入力します。

実行コマンド:

$ exit

実行結果:

Script done, output log file is '/tmp/work_20260328.log'.

実務では、日時を含むファイル名を付けて記録するのが一般的です。

実行コマンド:

$ script -a ~/logs/work_$(date +%Y%m%d_%H%M%S).log

-a オプションは追記モードです。同じファイルに追記したい場合に使います。

scriptコマンドの注意点:

出力ファイルにはANSIエスケープシーケンス（色や画面制御のコード）が含まれる。テキストエディタで開くと制御文字が混じって見づらいことがある
vi や less などの全画面コマンドをログ中に使うと、画面制御コードが大量に記録されてログが読みにくくなる
script は新しいシェルを起動する仕組みのため、exit で記録を終了すると元のシェルに戻る

方法3: TeraTermのログ機能

TeraTermはWindows環境で広く使われるSSHターミナルソフトです。ログ機能を設定すると、接続のたびに自動でログファイルが作成されます。

手動でログを取得する手順:

TeraTermでサーバーに接続する
メニューから [ファイル] → [ログ…] を選択する
保存先とファイル名を指定して [保存] をクリックする
以降の操作がすべてログファイルに記録される
ログ記録を停止するには、ログ取得中に表示されるログダイアログの [閉じる] ボタンをクリックする（または接続を切断する）

ただし、手動では取り忘れが発生します。実務では以下の自動ログ取得設定を使います。

自動ログ取得の設定手順:

TeraTermを起動する
[設定] → [その他の設定] を選択する
[ログ] タブをクリックする
「標準のログファイル名」に &h_%Y%m%d_%H%M%S.log と入力する
「標準のログ保存先フォルダ」に保存先（例: C:\Users\ユーザー名\Documents\teraterm-log\）を指定する
「自動的にログ採取を開始する」にチェックを入れる
[OK] をクリックする
[設定] → [設定の保存] を選択し、TERATERM.INI を上書き保存する

この設定により、接続するたびに alma-main_20260328_143045.log のようなファイル名でログが自動保存されます。&h は接続先ホスト名、%Y%m%d は年月日に展開されます。

方法4: 作業報告書テンプレート

ツールによる自動記録に加え、構造化された作業報告書を書くことも重要です。scriptコマンドやTeraTermのログは「何を実行したか」の生ログですが、作業報告書は「なぜ」「どういう判断で」「結果はどうだったか」を含む整理された記録です。

以下は最低限の構成です。

目的: この作業で何を達成するか
前提条件: 対象サーバー、必要な権限、事前準備
作業手順: 番号付きのステップ。コマンドと期待される出力をセットで記載
確認手順: 作業後の動作確認方法
切り戻し手順: 問題が発生した場合の復旧方法
作業者・レビュー者: 誰が関わったかの記録

特に「切り戻し手順」は見落とされがちですが、本番作業では必須です。変更を元に戻す方法がないまま作業を始めるのは、パラシュートなしでスカイダイビングをするようなものです。

「良い作業記録」と「役に立たない作業記録」の違い

記録を残すだけでは不十分です。「半年後の自分が読んでも再現できる記録」を目指す必要があります。ここでは、良い記録にするための3つのポイントを紹介します。

5W1Hを押さえる

作業記録にも5W1Hが当てはまります。

When（いつ）: 2026/03/28 14:00〜14:30
Who（誰が）: 山田
Where（どこで）: alma-main（192.168.1.121）
What（何を）: Apache の ServerName を変更
Why（なぜ）: ドメイン名の変更に伴うWebサーバー設定の更新
How（どうやって）: httpd.conf を直接編集し、Apache を再起動

特に見落としがちなのはWhy（なぜ）です。コマンドの記録だけでは「何をしたか」はわかっても「なぜそうしたか」がわかりません。半年後に見返したとき、「なぜこの変更をしたのか」が書いてあるかどうかで記録の価値は大きく変わります。

変更前の状態を必ず残す

これは第1回のヒヤリハットとも直結するポイントです。設定を変更するときは、必ず変更前の状態を記録してから作業を始めます。

悪い記録の例:

httpd.confを編集した
Apacheを再起動した
動作確認OK

この記録では、「何を」「どう変えたか」がわかりません。問題が起きても元に戻せません。

良い記録の例:

1. 作業前のバックアップを取得
   # cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.20260328

2. httpd.conf の ServerName を変更
   # vi /etc/httpd/conf/httpd.conf
   変更前: ServerName www.example.com:80
   変更後: ServerName app.example.com:80

3. 設定ファイルの文法チェック
   # apachectl configtest
   結果: Syntax OK

4. Apache を再起動
   # systemctl restart httpd

5. 動作確認
   # systemctl status httpd
   結果: Active: active (running)

6.【切り戻し手順】問題が発生した場合
   # cp -p /etc/httpd/conf/httpd.conf.20260328 /etc/httpd/conf/httpd.conf
   # systemctl restart httpd

変更前の値・変更後の値・バックアップの場所・切り戻し手順がすべて揃っています。この記録なら、別の人が見ても何が起きたかを追えます。

作業記録の良い例と悪い例の対比。悪い例は「httpd.confを編集した、Apacheを再起動した、動作確認OK」のみで何を・なぜ・変更前の値が不明。良い例はバックアップ取得、ServerName変更（変更前後を明記）、文法チェック、再起動・動作確認、切り戻し手順ありの5ステップ。

コマンドと結果はセットで記録する

コマンドだけ記録して結果を残さない記録は、半分の価値しかありません。

たとえば以下の記録を見てください。

# systemctl status httpd

このコマンドを実行したことはわかりますが、結果がどうだったかがわかりません。「active (running) だった」のか「inactive (dead) だった」のか。結果がなければ、後から見たときに状況を正確に再現できません。

コマンドを記録するときは、必ず出力結果もセットで残す習慣をつけてください。scriptコマンドやTeraTermのログ機能を使えば、出力は自動的に記録されます。

報連相 — エンジニアの命綱

なぜエンジニアに報連相が必要なのか

報連相（報告・連絡・相談）は一般的なビジネスマナーとして知られていますが、インフラエンジニアの現場ではもっと切迫した意味を持ちます。

インフラの障害は1つの機能ではなく、サービス全体に波及します。情報共有が1分遅れるだけで、被害の範囲が広がることがあります。障害対応はチーム戦です。誰が何を調べていて、何がわかっていて、何がまだわかっていないのか。その情報がチーム内で共有されていなければ、対応はバラバラになります。

新人のうちは「こんなことで報告していいのだろうか」と遠慮しがちです。しかし現場では、報告が遅れて問題になるケースは多い一方、報告が早すぎて怒られるケースはほぼありません。迷ったら報告する。これが鉄則です。

報告 — 結論から、事実と推測を分けて

エンジニアの報告で最も重要なのは、結論を先に伝えることと、事実と推測を明確に分けることです。

悪い報告の例:

えっと、先ほどアラートが出まして、いろいろ調べてみたんですけど、
ログを見たらエラーが出ていて、たぶんディスクが原因だと思うんですが、
もう少し調べないとはっきりとは言えなくて...

何が起きているのか、いつからなのか、影響はどの範囲なのか ―― 聞いた側は何も判断できません。

良い報告の例（第一報テンプレート）:

【障害発生】alma-main SSH接続不可
■ 事象: alma-mainサーバーにSSH接続ができない
■ 検知: 2026/03/28 14:30 監視アラートにより検知
■ 影響: バッチ処理が停止している可能性あり（確認中）
■ 状況: 原因調査中（対応者: 山田）
■ 次回報告: 15:00 または状況変化時

この報告のポイントは3つあります。

件名で概要がわかる: 「障害発生」「SSH接続不可」という情報だけで、何が起きているか把握できる
事実と推測が分かれている: 「SSH接続ができない」は事実、「バッチ処理が停止している可能性あり」は推測（「確認中」と明記）
次のアクションが明示されている: 「次回報告: 15:00」があることで、上司は安心して待てる

障害の原因が判明してから報告しようとすると、第一報が大幅に遅れます。完璧な情報を待つ必要はありません。「まだわかっていないこと」を含めて報告することで、チーム全体が状況を把握できます。

中間報告の例:

【続報】alma-main SSH接続不可
■ 進捗: ディスク使用率100%が原因と判明。/var/log配下のログ肥大化
■ 対応: 不要ログの削除とlogrotate設定の見直しを実施中
■ 復旧見込: 15:30頃
■ 次回報告: 15:30 または状況変化時

完了報告の例:

【復旧】alma-main SSH接続不可
■ 復旧時刻: 2026/03/28 15:20
■ 原因: /var/log/messagesが肥大化しディスク使用率100%に到達
■ 対応内容: 古いログファイルの削除、logrotate設定を週次から日次に変更
■ 再発防止: ディスク使用率80%でアラート設定を追加予定

障害報告の流れ。発生直後に第一報（発生事象と影響範囲を即座に共有）、調査中に中間報告（原因調査の進捗と復旧見込を報告）、復旧後に完了報告（原因・対応内容・再発防止策を報告）。報告が遅れると被害が拡大する。速報性が最優先。

連絡 — 判断が必要な情報は即座に

連絡は、計画作業の事前共有や、判断を要する状況変化の通知に使います。障害の報告とは異なり、予定どおりの作業であっても、関係者に事前・事後の連絡が必要です。

作業前連絡の例:

【作業予告】alma-main メンテナンス
■ 作業内容: OSセキュリティパッチの適用
■ 対象: alma-main（192.168.1.121）
■ 作業日時: 2026/03/29 22:00〜23:00
■ 影響: 作業中、サービスが一時停止（再起動あり）
■ 作業者: 山田 / レビュー者: 田中

作業後連絡の例:

【作業完了】alma-main メンテナンス
■ 作業結果: 正常完了
■ 完了時刻: 2026/03/29 22:35
■ 確認事項: サービス正常稼働を確認済み

ここで、ヒヤリハットを1つ紹介します。

ヒヤリハット: メンテナンスウィンドウ超過

あるエンジニアが、22:00〜23:00の予定でサーバーメンテナンスを行っていました。パッチ適用後の再起動でサービスが正常に上がってこず、原因調査を始めました。「もう少しで直るはず」と思い、23:00を過ぎても連絡を入れませんでした。

23:30、利用部門から「サービスが使えない」と問い合わせが入り、上司が初めて事態を把握。結局、復旧したのは翌0:30でした。

問題は復旧に時間がかかったことではありません。予定時刻を超えた時点で連絡しなかったことです。23:00の時点で「予定どおり完了していない。復旧作業中。次回報告は23:30」と一報を入れていれば、上司は体制の判断（追加の人員を呼ぶ、利用部門へ事前に連絡するなど）ができました。

「自分で何とかなりそう」と思ったときほど、連絡が遅れがちです。計画と現実にズレが生じた時点で、即座に連絡する。これがインフラ現場の基本です。

相談 — 自分で調べた上で聞く

第1回で「質問の仕方」の基本を学びました。ここではそれを実践的なテンプレートに落とし込みます。

悪い相談の例:

Apache が動きません。どうすればいいですか?

これでは回答する側が「何をしたのか」「何が起きているのか」「環境はどうなっているのか」をゼロから聞き直す必要があります。

良い相談の例:

【質問】Apache のポート追加について

■ やりたいこと:
  Apache の設定を変更して、ポート8080でもリクエストを受け付けたい

■ 試したこと:
  1. /etc/httpd/conf/httpd.conf に「Listen 8080」を追加
  2. systemctl restart httpd を実行

■ 結果:
  以下のエラーで httpd が起動しなかった
  ---
  (13)Permission denied: AH00072: make_sock: could not bind to address [::]:8080
  ---

■ 環境:
  - OS: AlmaLinux 9.6
  - Apache: 2.4.57
  - SELinux: Enforcing

■ 自分の仮説:
  SELinux がポート8080へのバインドをブロックしているのではないかと考えています

この形式のポイントは4つあります。

エラーメッセージ全文を貼る: 「動きません」ではなく、実際の出力を示す
試したことを書く: 回答者が同じ提案を重複して行うのを防げる
環境情報を添える: OS・ソフトウェアのバージョン・SELinuxの状態など、問題の再現に必要な情報を含める
自分の仮説を書く: 自分で考えた形跡を示すことで、回答者も的を絞りやすくなる

相談は「わからないから丸投げ」ではなく、「ここまで調べた上で、この部分がわからない」という形にすることで、回答の精度もスピードも上がります。

ヒヤリハット — 作業記録がなかった夜

もう1つ、作業記録に関するヒヤリハットを紹介します。

ある深夜、本番サーバーで障害が発生しました。原因を調査すると、数日前にネットワーク設定を変更した形跡がありました。しかし、変更を行ったエンジニアは作業記録を残していませんでした。

「どのファイルを変更したか」「変更前の設定値は何だったか」がわからないため、復旧方針を立てられません。結局、バックアップからの復元を選択しましたが、復元に3時間かかり、その間サービスは停止したままでした。

後日の振り返りで、変更を行ったエンジニアは「設定ファイルを2行変えただけだったので、記録するほどでもないと思った」と話しました。

作業記録があれば、変更箇所を特定して元に戻すだけで済んだはずです。所要時間は5分程度。「記録するほどでもない」と判断した2行の変更が、3時間のサービス停止につながったという事例です。

記録を残すかどうかの判断基準は「小さな変更だから不要」ではなく、「本番環境に対する変更はすべて記録する」です。

やってみよう — 作業記録を書いてみる

今回は座学回ですが、手を動かす演習を2つ用意しました。テキストエディタを開いて取り組んでください。

演習1: 作業報告書を書いてみる

以下の架空シナリオを読み、作業報告書テンプレートに沿って記録を書いてみてください。

シナリオ:

あなたはalma-mainサーバーでApacheの設定ファイル（/etc/httpd/conf/httpd.conf）の ServerName を「www.example.com」から「app.example.com」に変更する作業を任されました。

課題: 以下のテンプレートに沿って、目的・前提条件・作業手順・確認手順・切り戻し手順を書いてください。

【作業報告書】
■ 目的:（この作業で何を達成するかを書く）
■ 前提条件:（対象サーバー、必要な権限、事前準備を書く）
■ 作業手順:（番号付きで、コマンドと期待される結果をセットで書く）
■ 確認手順:（作業後の動作確認方法を書く）
■ 切り戻し手順:（問題が発生した場合の復旧方法を書く）
■ 作業者:（自分の名前を書く）

まず自分で書いてから、以下の記入例と見比べてください。

記入例:

【作業報告書】
■ 目的: ドメイン名変更に伴い、ApacheのServerNameをapp.example.comに変更する
■ 前提条件:
  - 対象: alma-main（192.168.1.121）
  - 権限: root権限（またはsudo）が必要
  - 事前準備: Apacheが稼働中であることを確認済み
■ 作業手順:
  1. 設定ファイルのバックアップを取得する
     # cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
  2. httpd.confのServerNameを変更する
     # vi /etc/httpd/conf/httpd.conf
     変更前: ServerName www.example.com:80
     変更後: ServerName app.example.com:80
  3. 設定ファイルの文法チェックを行う
     # apachectl configtest
     期待結果: Syntax OK
  4. Apacheを再起動する
     # systemctl restart httpd
■ 確認手順:
  - systemctl status httpd で Active: active (running) を確認
■ 切り戻し手順:
  1. バックアップから設定ファイルを復元する
     # cp -p /etc/httpd/conf/httpd.conf.bak /etc/httpd/conf/httpd.conf
  2. Apacheを再起動する
     # systemctl restart httpd
■ 作業者: （自分の名前）

書けたら、以下のチェックポイントで自己採点してください。

バックアップ（変更前の状態の保存）が手順に含まれているか
変更前と変更後の値が両方書かれているか
切り戻し手順があるか（バックアップからの復元方法が具体的に書かれているか）
確認手順があるか（作業後に何をもって「成功」と判断するかが明確か）

演習2: 障害の第一報を書いてみる

次に、障害発生時の第一報を書く演習です。以下の架空シナリオを読み、テンプレートに沿って記入してください。

シナリオ:

あなたは運用チームのメンバーです。2026年3月28日の16:45、監視システムから「alma-main: HTTP応答なし」というアラートを受信しました。ブラウザで確認すると、Webサイトにアクセスできません。サーバーへのping（ネットワークの疎通確認コマンド）は通ります。まだ原因はわかっていません。あなたはこれから調査を始めます。

課題: この状況で、チームのチャットに第一報を投稿してください。

以下のテンプレートを使って書いてみましょう。

【障害発生】（件名を書く）
■ 事象:（何が起きているかを書く）
■ 検知:（いつ、どうやって検知したかを書く）
■ 影響:（わかる範囲で影響を書く）
■ 状況:（現在の対応状況を書く）
■ 次回報告:（次にいつ報告するかを書く）

記入例（自分で書いてから確認してください）:

【障害発生】alma-main Webサイト応答なし
■ 事象: alma-mainで稼働中のWebサイトにHTTPアクセスができない。ping応答あり
■ 検知: 2026/03/28 16:45 監視アラート「HTTP応答なし」により検知
■ 影響: Webサイトの全ページが閲覧不可（利用者に影響あり）
■ 状況: 原因調査中（対応者: 自分の名前）
■ 次回報告: 17:15 または状況変化時

書けたら、以下のチェックポイントで自己採点してください。

件名だけで何が起きているかわかるか
事実と推測が混在していないか
次回報告のタイミングが明示されているか
「わかっていないこと」を正直に書いているか（「原因調査中」など）

理解度チェック

以下の文が正しければ○、誤っていれば×で答えてください。

Q1. scriptコマンドは、入力したコマンドだけでなく、その出力結果もファイルに記録する。

Q2. 障害の第一報は、原因が完全に判明してから出すべきである。

Q3. 作業記録には、変更後の設定値だけ残しておけば十分である。

Q4. 技術的な質問をするときは、エラーメッセージ全文を貼るより「動きません」と伝える方が回答者にとってわかりやすい。

Q5. 計画作業でも、予定時刻を超えた場合は状況を連絡する必要がある。

Q6. TeraTermの自動ログ取得を設定すれば、手動でログを開始しなくても接続のたびにログが保存される。

Q7. 作業報告書に切り戻し手順は含めなくてもよい。作業が成功すれば不要だからである。

解答:

Q1: ○ — scriptコマンドはターミナルの入力と出力の両方を記録します
Q2: × — 原因の判明を待たず、検知した時点で速やかに第一報を出します。完璧な情報を待っていると報告が遅れます
Q3: × — 変更前の設定値も必ず記録します。変更前がわからなければ、元に戻すことができません
Q4: × — 「動きません」では情報が足りません。エラーメッセージ全文を貼ることで、回答者が正確に状況を把握できます
Q5: ○ — 計画と現実にズレが生じた時点で、関係者に状況を連絡します
Q6: ○ — 「自動的にログ採取を開始する」設定を有効にすると、接続のたびにログファイルが自動作成されます
Q7: × — 切り戻し手順は作業開始前に必ず用意します。問題が発生したときに元に戻す方法がなければ、被害が拡大します

まとめ

今回学んだことを整理します。

作業記録はインフラエンジニアの必須スキル。再現性の担保・トラブルシューティング・引き継ぎと監査の3つの場面で力を発揮する
記録の方法は4つ。手書きメモ、scriptコマンド、TeraTermのログ機能、作業報告書テンプレート。目的に応じて組み合わせる
良い記録のポイント。5W1Hを押さえる、変更前の状態を必ず残す、コマンドと結果をセットで記録する
報連相はエンジニアの命綱。報告は結論から・事実と推測を分けて。連絡はズレが生じた時点で即座に。相談は自分で調べた上で具体的に

作業記録と報連相は、この先36回を通じて繰り返し実践するスキルです。第4回以降でVMを操作するようになったら、scriptコマンドやTeraTermのログ機能を実際に使っていきます。

なお、作業記録にはサーバーのIPアドレスや認証情報など、機密性の高い情報が含まれることがあります。記録の取り扱いや情報セキュリティの基本については、次回の第3回「セキュリティ意識の基本」で学びます。

シリーズ一覧

フェーズ1: エンジニアのいろは（第1〜3回）

第1回エンジニアの仕事と学び方
第2回作業記録と報連相（この記事）
第3回セキュリティ意識の基本

フェーズ2: Linux基礎（第4〜15回）

フェーズ3: ネットワークとインフラ基盤（第16〜27回）

フェーズ4: サーバー構築と運用（第28〜36回）