新人とベテランの違い｜本番作業で止まる場所・確かめる順番

差は知識量より「どこで止まるか」。同じ本番作業を新人とベテランがどう進めるか、表で並べて比べます。

新人とベテランの違いと聞くと、知っているコマンドの数やタイピングの速さを思い浮かべるかもしれません。しかし本番作業の現場で差が出るのは、多くの場合そこではありません。同じ手順書を渡されても、ベテランは「どこで手を止めるか」「何を先に確かめるか」を決めてから作業に入ります。この記事では、その違いを具体的な作業の進め方として分解し、新人が今日から真似できる習慣にしていきます。

前提として、ベテランも間違えます。違いは、間違えない能力ではなく、間違えても早く気づける・戻せる進め方を身につけていることです。精神論ではなく、手順と道具の使い方の話として読んでください。

違いは知識量より「どこで止まるか」

新人の作業は、手順書の 1 行目から最後まで止まらずに流れがちです。止まる理由が分からないので、止まる場所がありません。ベテランは作業の前に「この出力が想定と違ったら止める」「この件数を超えたら止める」という条件を決めています。止まる場所があらかじめ決まっているので、想定外のことが起きたときに迷わずに手を止められます。

止める条件は、手順書の各ステップに「期待する結果」を書き添えるだけで作れます。たとえば「対象件数は 120 件前後」「設定チェックで syntax is ok が出る」「再起動後に 200 が返る」です。期待する結果が書かれていない手順は、実行した結果が正しいかどうかを判断できません。

同じ作業を新人とベテランはどう進めるか

違いは具体的な作業で比べると分かりやすくなります。ここでは「本番 DB の不要データの削除」と「本番サーバーの設定ファイル変更」の 2 つを例に、進め方を並べます。どちらもコマンド自体は数行で、新人でも打てる内容です。差が出るのは、そのコマンドの前後です。

例 1：本番 DB から不要なデータを削除する

SELECT current_database();SELECT COUNT(*) FROM sessions WHERE expires_at < '2026-01-01';CREATE TABLE sessions_backup_20261017 AS  SELECT * FROM sessions WHERE expires_at < '2026-01-01';BEGIN;DELETE FROM sessions WHERE expires_at < '2026-01-01';-- DELETE 1203 のように影響行数が出る。COUNT(*) と一致したら COMMIT、違えば ROLLBACKCOMMIT;

ポイントは、DELETE の前に「何件消えるはずか」という数字を自分で持っていることです。数字を持っていなければ、DELETE 1203 と表示されても多いのか少ないのか判断できません。MySQL でも、START TRANSACTION で始めれば同じように影響行数を見てから COMMIT か ROLLBACK を選べます（InnoDB の場合）。ただし MySQL では CREATE TABLE などの DDL が暗黙にコミットするため、退避用のテーブルは上の例のようにトランザクションを始める前に作ります。

例 2：本番サーバーの設定ファイルを変更する

hostnameBAK=/etc/nginx/nginx.conf.bak.$(date +%Y%m%d%H%M)sudo cp -p /etc/nginx/nginx.conf "$BAK"sudo vi /etc/nginx/nginx.confdiff -u "$BAK" /etc/nginx/nginx.confsudo nginx -tsudo systemctl reload nginxcurl -sS -o /dev/null -w '%{http_code}\n' https://example.com/healthz

nginx -t は設定ファイルの構文と参照先を検査し、問題があれば反映前に教えてくれます。restart ではなく reload を使うと、構文エラーがあっても多くの場合は古い設定のまま動き続けます。退避したファイルがあれば、問題が出たときに cp で戻して reload するだけで元に戻せます。どの手順も特別な知識ではなく、順番の問題です。

想定外の出力を無視しない

新人が見落としやすいのは、エラーで止まらなかった出力の中の違和感です。最後に「完了しました」と表示されても、途中に WARN が出ている、件数が想定より 1 桁多い、普段より極端に速く終わった、といった兆候は、何かが意図と違うことを示しています。人は自分の予想に合う情報を重く見て、合わない情報を軽く見やすく、この傾向は経験の長さでは消えません。

ベテランはこの傾向を意志の力で抑えているのではなく、比べる対象を先に用意することで防いでいます。実行前に「期待する件数」「期待する出力」を書いておけば、実際の出力は予想と比べる数字として読めます。予想を持たずに出力を見ると、どんな結果でも「こんなものか」と受け入れてしまいます。

分からないと言える・聞き方を知っている

ベテランは「分からない」と早く言います。分からないまま推測で進めた場合の損失を知っているからです。新人は、聞くと迷惑ではないか、できないと思われないか、と考えて一人で抱え込みがちです。しかし本番作業で推測のまま進めることは、相手に迷惑をかけるよりずっと大きな影響を生む可能性があります。

聞き方にも違いがあります。「動きません」だけでは、相手は状況を一から聞き直す必要があります。次の 4 点をそろえると、短いやり取りで答えにたどり着けます。

1. やりたいこと（目的）と、作業している環境。
2. 起きていること（実際のエラーや出力をそのまま貼る）。
3. 調べたこと・試したことと、その結果。
4. 自分の理解で自信がない点（「ここが分からない」をはっきり書く）。

調べる時間に上限を決めておくのも有効です。たとえば「30 分調べて進まなければ聞く」と決めておけば、遠慮で時間を失うことが減ります。本番作業中なら、迷った時点で手を止めて聞くのが基本です。

影響範囲を見積もり、作業を記録する

新人は目の前の 1 台のサーバー、1 つのテーブルだけを見て作業しがちです。ベテランは「そのテーブルを他にどの処理が読んでいるか」「その設定を同じロードバランサー配下の何台が共有しているか」「作業中に利用者から何が見えるか」を先に考えます。影響範囲が分かれば、作業する時間帯、事前に連絡すべき相手、失敗したときに最初に確かめる場所が決まります。

もう 1 つの違いは記録です。ベテランは作業中に、実行したコマンド、時刻、出力の要点を残します。script コマンドでターミナルの入出力をファイルに保存する、作業チャットに貼りながら進める、といった方法があります。記録があれば、問題が起きたときに「何をいつしたか」を正確に報告でき、記憶違いによる二次的な混乱を防げます。

script -a ~/worklog/$(date +%Y%m%d)-nginx-change.log# ここで作業する。exit で記録を終えるexit

ベテランも間違える前提で、仕組みで防いでいる

ここまでの習慣は、どれも「人は間違える」ことを前提にしています。ベテランが慎重に見えるのは、自分の注意力を信用していないからだとも言えます。疲れているとき、急いでいるとき、慣れた作業のときほど確認が甘くなることを知っているので、注意力に頼らない手順を選んでいます。

• 接続先をプロンプトや画面の色で区別し、作業前に hostname で確かめる。
• 危険なコマンドは、まず確認用のコマンド（ls、SELECT COUNT(*)、--dry-run）で対象を見る。
• 取り消しにくい操作の前に、退避（バックアップ、mv、複製）を手順に入れる。
• 一人で判断しない場面（本番の削除や設定変更）はダブルチェックを受ける。
• 手順書に期待する結果を書き、違えば止めることを事前に合意する。

ミスが起きたときに個人を責めず、仕組みを直す方向で振り返る文化も、この考え方の延長にあります。新人が「自分はまだ未熟だから慎重にする」と考える必要はありません。経験を積んでも同じ手順を続けることが、ベテランの進め方そのものだからです。

新人が今日から真似できる習慣

最後に、知識の量に関係なく、明日の作業からすぐに取り入れられる習慣をまとめます。最初からすべてを完璧にする必要はなく、1 つずつ手順に組み込んでいけば十分です。

• 作業の最初に hostname や SELECT current_database() で接続先を画面に出す。
• コマンドを実行する前に、期待する結果（件数・出力・所要時間）をメモに書く。
• 変更する前に、元に戻す方法を 1 行で書けるか確かめる。書けなければ着手しない。
• 出力は最後の行だけでなく、途中の WARN・error・件数まで読む。
• 想定と違ったら止めて、事実（何をして何が出たか）をそのまま共有する。
• 迷ったら、調べたこと・試したこと・分からない点をそろえて聞く。
• 実行したコマンドと出力を作業中に記録する。

下の問題では、出力の読み方や相談の仕方、ダブルチェックの考え方を実際の場面で試せます。正解かどうかより、自分ならどこで手を止めるかを意識して解いてみてください。

参考

• nginx: Command-line parameters
• script(1) - Linux manual page
• PostgreSQL Documentation: Transactions
• MySQL Reference Manual: Statements That Cause an Implicit Commit
• Google SRE Book: Postmortem Culture