未経験でインフラに入った1年目、現場で生き残るためにやったこと｜教えてくれる人がいない現場で
「このサーバーに接続して」が、できなかった
未経験からインフラエンジニアとしてキャリアを始めたとき、僕は資格だけは持っていました。
RDP、SSH、Linuxの基本的なコマンド。
一通り勉強して、頭では分かっているつもりでした。
でも、現場に入って最初に言われたひとことで、その「つもり」は崩れます。
「このサーバーに接続しておいて」
……どうやって接続すればいいのか、分からなかったんです。
資格の勉強で「SSHとは何か」は知っている。
でも、目の前の環境で、どのツールを使って、どこに、どの情報を入れて接続するのか。
実務でやったことがなければ、その一歩が踏み出せない。
資格で知っていることと、現場で手を動かせることは、まったくの別物でした。
雰囲気は最悪、「分からない作業はやるな」
最初に配属されたのは、監視業務の現場でした。
そして、その現場の雰囲気は、正直に言って最悪でした。
ルールとして、**「わからない作業は実施してはいけない」**と決まっていました。これ自体は事故防止のために正しいルールです。下手に触って本番を壊すよりはずっといい。
でも、未経験の自分にとっては、ほとんどの作業が「わからない作業」です。つまり、何をするにも人に聞くしかない。
ところが、その「聞く」ができない環境でした。
プロパー（クライアント社員）は会議ばかりで、ほとんど席にいない
先輩エンジニアは自分の作業で手一杯
質問すると、あからさまに嫌な顔をされる
聞かないと作業ができない。
でも聞ける人がいない。
聞いても歓迎されない。
完全に、八方塞がりでした。
それで、僕はやらかした
そんな状態で仕事をしていれば、当然ミスをします。
僕がやらかしたことは、地味だけど、思い出すと今でも少し冷や汗が出ます。
消してはいけないファイルを消してしまった
エスカレーションを正しくできなかった（誰に、どのタイミングで、何を上げればいいのか分かっていなかった）
監視の現場で、エスカレーションが正しくできないのは致命的です。
異常を見つけても、それを適切なルートで上げられなければ、見つけていないのと同じになってしまう。
そして、消してはいけないファイルを消してしまったときは、始末書を書く羽目になりました。
入って間もない未経験のうちに、自分の名前で「なぜこのミスが起きたのか、再発防止のために何をするのか」を書面で出す。
あれは精神的にかなりこたえました。
情けなくて、申し訳なくて、自分はこの仕事に向いていないんじゃないかとさえ思いました。
「わからない作業はやるな」と言われている現場で、わからないままやって、ミスをして、始末書を書く。
聞きたくても聞けない。
この時期が、キャリアの中で一番きつかったかもしれません。
八方塞がりが、結果的に「武器」を作ってくれた
どうにもならない状況で、僕はあることに気づきます。
聞ける人がいないなら、聞かなくても進められるレベルまで、自分で持っていくしかない。
そこからやり方を変えました。
分からないことにぶつかったら、まず自分で調べる。ドキュメントを読む、過去の手順を探す、似たケースを探す。そして、「たぶんこうすればいいはず」という自分なりの答えを出してから、人に確認しにいく。
「これってどうやるんですか？」と丸投げで聞くと、嫌な顔をされる。
でも、「この作業、こうやろうと思っているんですけど、合っていますか？」と聞くと、相手の反応がまるで違いました。
答える側の負担が一気に下がるからです。
一から説明する必要がなく、イエスかノーか、どこを直せばいいかだけ言えばいい。
教えてくれる人がいない現場で身につけたのは、「自分で調べて、自分なりの答えを出してから聞く」習慣だった。それが、その後のどの現場でも一番の武器になった。
あの環境が良かったとは、今でもまったく思いません。
でも、聞けない環境だったからこそ、この習慣が嫌でも身につきました。
そしてこのスキルは、その後どの現場に行っても役に立ち続けています。
1年目の僕がやらかした3つ
これからインフラに入る人が同じ轍を踏まないように、当時の失敗を残しておきます。
① 「接続して」に固まった … 資格はあっても、実務の初歩でつまずいた。知っていることと、できることは違う
② 消してはいけないファイルを消した … 影響範囲を確認しないまま手を動かした結果
③ エスカレーションを正しくできなかった … 誰に・いつ・何を上げるかの基準を持っていなかった
どれも「技術力が足りなかった」というより、現場の動き方を知らなかったことが原因でした。
八方塞がりの現場で身につけた、生き残りの3つの習慣
逆に、この時期に身につけて、今でも使っている習慣がこれです。
① 分からないことは、調べて“仮説”を持ってから聞く … 「どうやるんですか」ではなく「こうしようと思うんですが合ってますか」。相手の負担が下がり、自分も伸びる
② 本番を触る前に、影響範囲を必ず確認する … 「これを消す/変える」と何が起きるか。消してはいけないものを消さないための一手間
③ エスカレーションの基準とルートを先に押さえる … 何が起きたら、誰に、どう上げるのか。異常を見つける前に決めておく
特に①は、未経験の最大の武器になります。聞き方を変えるだけで、聞ける環境がない現場でも前に進めるようになります。
環境は選べなくても、得るものは選べる
あの監視現場は、いい環境ではありませんでした。
聞ける人はいなかったし、雰囲気もよくなかった。
でも、振り返ると、あそこで身につけた「自分で答えを出してから聞く」という習慣は、その後のキャリアの土台になっています。
プライベートクラウドのSRE、AWSの設計、今やっている上流工程。
どの現場でも、この習慣が一番効いています。
技術力は、後からいくらでも付いてきます。最初の現場でつくべきだったのは、すごい技術力じゃなくて、「分からない状況の中で、自分で前に進む力」でした。
同じ状況で潰れそうな人へ
もし今、聞ける人がいない現場で、わからないまま仕事をして、ミスをして、しんどい思いをしている人がいたら。
それは、あなたの能力が低いからじゃありません。
環境がきついだけです。
そのうえで、ひとつだけ提案させてください。
「どうやるんですか」と聞く前に、自分なりの答えを一回作ってみてください。
調べて、仮説を立てて、「こうだと思うんですけど」と確認しにいく。
これだけで、聞ける環境がなくても前に進めるようになります。
そして、その力は環境が変わっても一生使えます。
きつい現場ほど、後から効いてくるスキルが身につく。
僕がそうだったように。
この記事が参考になったら、スキ・フォローをもらえると励みになります。同じように駆け出しで戦っている人に届きますように。
次は、その現場からどう抜け出したかを書いた「[SES会社でヘルプデスクから抜け出すために、私がやったこと]」もあわせてどうぞ。
