こんにちは、インフラエンジニアのryuです。
現場に配属されて最初に渡されるものは、分厚い参考書ではなく、たいてい1枚の手順書です。
「書いてあるとおりにやればいいから」と言われて受け取ったあの紙、あるいは共有フォルダのExcelファイル。あれを前にして、少し不安になった経験はないでしょうか。
書いてあることは読めます。コマンドも打てそうです。それでも、なぜか指が止まる。その感覚は、決して実力不足のサインではありません。むしろ、手順書というものの正体をうすうす感じ取れている証拠です。
今日は、未経験からインフラエンジニアになった方が最初にぶつかる「手順書に沿った作業」について書いてみます。読み方を変えるだけで、同じ手順書がまったく違って見えてきます。
手順書は「正解の台本」ではありません¶
手順書を、そのとおりに演じれば必ず成功する台本だと思っていると、少しズレが出た瞬間に対応できなくなります。
手順書の正体は、台本よりも地図に近いものです。ある日ある人が歩いた道を、あとから書き起こしたもの。地図に描かれた橋が、今日も架かっているかどうかまでは保証していません。
手順書が書かれた日と、作業する日は違う¶
ここがいちばん大きな落とし穴です。
手順書が作られたのが半年前だったとします。その間にOSのマイナーバージョンが上がり、パッケージ名が変わり、設定ファイルの置き場所が移動しているかもしれません。前回の作業のあとに、誰かが暫定対応でファイルを1つ足しているかもしれません。
つまり手順書は、書かれた瞬間の環境を前提にした記録であって、今日の環境の説明書ではないのです。
引っ越しのときにもらう、手書きの道案内を思い浮かべてみてください。「コンビニを右に曲がって、次の信号を左」と書かれていても、そのコンビニが閉店していたら、そこで迷子になります。書いた人が嘘をついたわけではなく、街のほうが変わっただけです。手順書も同じで、古くなること自体は避けられません。
「手順書どおりにやったのに動かない」という言葉は、現場でよく聞きます。でも正確には、手順書どおりにやったから動かなかったのではありません。手順書が想定していた前提と、目の前の環境がズレていただけです。
書いた人の頭の中は、手順書に全部は入っていない¶
もうひとつ。手順書には、書いた人が「当然わかるだろう」と思ったことが書かれません。
たとえば「Apacheを再起動する」と1行だけ書いてあるとき、書いた人の頭の中には、再起動したら数秒間アクセスが落ちること、設定ファイルにミスがあると起動に失敗して戻せなくなること、事前に設定確認のコマンドを流す習慣があること、そういった前提がぜんぶ入っています。
書かれていないのは、隠しているからではありません。その人にとっては、息をするのと同じくらい当たり前だからです。
手順書に書かれていないことのほうが、手順書に書かれていることより多い。
これを最初に知っておくだけで、作業前の準備の質が変わります。
作業の前日までに確かめておきたいこと¶
では、具体的に何を確かめればいいのでしょうか。私がおすすめしているのは、次の3つです。どれも、作業当日ではなく前日までにやっておくのがコツです。
まず、手順を1行ずつ声に出して読む¶
黙読すると、目が滑ります。読めているつもりで、実は読み飛ばしています。
小さな声でかまわないので、1行ずつ口に出して読んでみてください。そうすると「この行、主語がないな」「このファイルパス、さっきと違う気がする」といった引っかかりが、自然に浮かび上がってきます。
読み上げは、黙読の3倍ほど時間がかかります。それでも前日にやっておく価値があるのは、当日に気づくのと前日に気づくのとでは、打てる手の数がまるで違うからです。前日なら調べる時間も、聞く時間もあります。
引っかかったところには、その場で印をつけます。あとで先輩に聞くための材料になりますし、印が1つもつかない手順書はまず存在しません。
コマンドの意味を、手を動かす前に分解する¶
手順書に書かれたコマンドを、コピーして貼り付けるだけで終わらせないことです。
たとえばこんな行があったとします。
sudo systemctl restart httpd
sudo tail -n 50 /var/log/httpd/error_log
この2行を「Apacheを再起動して、ログを見る」とだけ理解して終わるのか、「restart は停止と起動を続けて行うから一瞬落ちる」「error_log は書き込みが止まっていれば異常に気づける」というところまで分解して理解するのか。作業中に想定外が起きたとき、差が出るのはここです。
コマンドの意味が曖昧なら、man で調べておきます。オプションの意味がわからないまま本番環境で実行するのは、行き先を確認せずに電車に飛び乗るようなものです。基本的なコマンドに不安が残っているなら、Linuxコマンドの基本を未経験者向けに解説した記事で先に足場を作っておくと安心できます。
どうなったら成功かを、自分の言葉にする¶
意外と抜けやすいのが、ゴールの確認です。
手順書には作業のやり方が書いてあっても、「何がどうなれば終わりなのか」が曖昧なことがあります。プロセスが起動していればいいのか、画面が表示されればいいのか、特定のログが出ていればいいのか。
作業前に、自分の言葉で1文にしておきます。「systemctl status が active (running) で、ブラウザでトップページが表示されれば成功」というように。
この1文が書けないときは、手順書を理解できていないというサインです。恥ずかしがらずに聞いてしまいましょう。
作業前チェックを表にまとめると、こんな形になります。
| 確認すること | 具体的にやること | 抜けたときに起きること |
|---|---|---|
| 環境の前提 | OSやミドルウェアのバージョンを手順書の記載と突き合わせる | 存在しないパスやコマンドで手が止まる |
| コマンドの意味 | 未知のオプションを man や公式ドキュメントで引く |
意図せず設定を上書きする |
| 成功の定義 | 「〜が〜になれば成功」を1文で書く | 終わったのか判断できず、作業が長引く |
| 影響範囲 | どのサービスが何秒止まるかを確認する | 利用者からの問い合わせに答えられない |
| 連絡先 | 困ったときに誰へ、どの手段で連絡するか | 判断を1人で抱え込んでしまう |
調べ方そのものに自信がないときは、公式ドキュメントの読み方をまとめた記事も合わせて読んでみてください。手順書の裏取りは、結局のところ一次情報にあたる作業です。
手順書に書かれていない3つの問い¶
作業前に自分へ投げかけてほしい問いが、3つあります。経験を積んだインフラエンジニアが、手順書を受け取った瞬間に無意識で確認していることです。
| 問い | なぜ大事か | 答えられないときの行動 |
|---|---|---|
| 失敗したら、どう戻すか | 戻し方のない作業は、失敗した瞬間に詰む | 切り戻し手順を先輩と作ってから着手する |
| この作業は、誰に影響するか | 止まる範囲を知らないと、影響の大きさを判断できない | 対象サーバーが担う役割を構成図で確認する |
| どこで手を止めるか | 粘るほど傷が広がる作業がある | 「ここまで来たら中断して相談」の線を決める |
とくに1つめの切り戻しは、未経験のうちに習慣づけておきたいところです。
設定ファイルを触る作業なら、変更前に必ずコピーを取ります。地味ですが、これがあるかないかで、トラブル時の空気がまるきり変わります。
# 変更前に日付つきでバックアップを取っておく
sudo cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.20260921
# 構文チェックを通してから再起動する
sudo apachectl configtest
configtest のような事前確認のコマンドが手順書に書かれていないことは、けっこうあります。書き足してよいか先輩に確認したうえで、自分用のメモとして持っておくといいでしょう。
当日は、速さより確かさを優先します¶
準備が終わったら、いよいよ当日です。ここで意識してほしいのは、速く終わらせようとしないことです。
未経験のうちは、もたついている自分が申し訳なく感じられて、つい急ぎたくなります。ですが現場で歓迎されるのは、速い作業ではなく、やり直しの発生しない作業のほうです。5分早く終わることに価値はありませんが、5分の確認で事故が1件減るなら、それは十分に価値があります。
打つ前に読み上げる、という習慣¶
鉄道や医療の現場で、指差し確認という習慣があるのをご存じでしょうか。指をさして声に出すことで、思い込みによる取り違えを減らす方法です。
インフラエンジニアの作業にも、同じことが応用できます。コマンドを実行する直前に、打ち込んだ内容を小さく読み上げてみてください。
とくに効くのが、接続先のホスト名です。同じような名前のサーバーが並んでいる環境では、検証機のつもりで本番機に入っていた、という取り違えが起こります。プロンプトに表示されているホスト名を読み上げるだけで、この種の事故はかなり防げます。
削除や上書きを伴うコマンドも同じです。rm や > が含まれる行は、実行前に必ず一度止まる。これを自分のルールにしておくと、指が勝手に動いてしまう事態を避けられます。
予定と違ったら、一度手を止めてよい¶
手順書の想定と違う画面が出たとき、なんとかその場で解決しようとしてしまう気持ちは、よくわかります。
ですが、未経験のうちにいちばん避けたいのは、想定外の状態にさらに手を加えて、元の状態がわからなくなってしまうことです。状況が単純なうちに相談したほうが、結果的に早く終わります。
手を止めるのは、サボりでも力不足でもありません。判断を保留して、材料をそろえる行為です。「ここで止めて聞く」と最初に決めておけば、当日の自分を守れます。
作業中に記録を残すと、あとで自分を助けます¶
作業が始まったら、手を動かすことに集中したくなります。それでも、記録だけは残してください。
いちばん簡単なのは、ターミナルの操作をまるごと記録してしまう方法です。
# 作業ログをファイルに残しながら操作する
script -a ~/worklog_20260921.log
# 作業が終わったら
exit
script コマンドは、端末に表示された内容をそのままファイルに書き出してくれます。あとで「あのとき何を打ったか」を思い出す必要がなくなりますし、うまくいかなかったときに先輩へ見せる材料にもなります。
記録が残っていれば、ログを読む練習にもそのまま使えます。何が起きていたかを時系列で追う力は、ログの読み方を扱った記事のような基礎と組み合わせると、ぐっと伸びていきます。
うまくいかなかったときは、手順書を疑う前に事実を集める¶
想定外が起きたとき、いきなり原因を推理したくなります。でも先に集めるべきは、事実です。
どのコマンドで、どんなメッセージが出たのか。ログに何が記録されたのか。直前に自分は何をしたのか。この3点をそろえてから相談すると、先輩の回答の精度が一気に上がります。
切り分けの考え方そのものは、Linuxのトラブルシューティング手順を解説した記事が参考になります。作業中の焦りは、手順を持っていないことから生まれることが多いものです。
手順書を読む力は、そのまま書く力になります¶
手順書に沿った作業は、下積みのように見えるかもしれません。ですが、ここで身につくものは想像以上に大きいです。
読み手として「ここが足りない」と感じた経験は、自分が手順書を書く側に回ったときの財産になります。前提条件を書く、成功の状態を書く、切り戻しを書く。自分が困ったところを埋めていけば、それだけで質の高い手順書になります。
もう一段深いところで言えば、手順書を読むという行為は、その現場が過去にどんな失敗をしてきたかを読むことでもあります。妙に細かい確認手順が挟まっている箇所は、たいてい昔そこで事故が起きています。なぜこの1行があるのかを想像できるようになると、現場の歴史が見えてきて、仕事がぐっとおもしろくなります。
運用監視のような、最初に任されやすい役割との相性もよいところです。運用監視での過ごし方を書いた記事と合わせて読むと、日々の当番が学びの時間に変わっていく感覚がつかめると思います。
そして、手順書の一行一行を理解するには、結局のところLinuxやネットワークの基礎が必要になります。断片的な知識のままだと、書かれていない前提に気づけないからです。InfraAcademy では、コマンドの意味と仕組みを順番につなげていくLinuxの学習ロードマップを用意しています。現場で手順書と向き合いながら、足りないところを埋めていく使い方をしてもらえたらうれしいです。
まとめ¶
最後に、今日の内容を振り返ります。
手順書は正解の台本ではなく、ある日の道のりを書き起こした地図です。書かれた日と今日では、環境が変わっていることがあります。
だからこそ、作業前に声に出して読み、コマンドの意味を分解し、成功の定義を自分の言葉にする。そして、失敗したらどう戻すか、誰に影響するか、どこで手を止めるかを決めてから着手する。
作業中は script などで記録を残し、想定外が起きたら推理より先に事実を集める。これだけで、同じ手順書を前にしたときの落ち着き方が変わります。
手順書どおりにできたかどうかより、手順書の外側にある前提をどれだけ自分で拾えたか。現場で見られているのは、たぶんそちらです。
手順書に沿った作業を何度か経験すると、書かれていない前提のほうが自然と目に入るようになります。そうなればもう、渡された1枚は不安の種ではなく、その現場の設計思想を読み解くための資料に変わっています。
最初の1枚は、誰でも緊張します。それでも一度きちんと向き合えば、2枚目からは景色が変わります。焦らず、1行ずつ読んでいきましょう。
