新卒でインフラ現場に入って1年働いたリアルな話

正直、当時は

「エンジニアって何するの？」

というレベルで、かなりふわっとした状態でした。

今この記事を読んでいる方の中にも、

「なんとなく興味はあるけど、実際どんな仕事か分からない」

という人は多いと思います。

自分も、まさにその状態からのスタートでした。

そして気づけば、インフラエンジニアとして10年以上現場を経験してきました。

この記事では、そんな自分が
「何も分からなかった1年目」に感じたリアルを書いていきます。

これから目指す方にとって、

新卒で入って最初に感じたこと

最初に感じたのは、

「思ったより地味だな…」

という印象でした。

私自身、エンジニアって

「PCの前でずっとプログラムを作っている仕事」

みたいなイメージを持っていました。

もちろん実際にプログラムを書く場面もありましたが、
最初の頃はそれ以上に、

「とにかくドキュメントを読む」

ことが多かったです。

例えば、

• マニュアル
• 手順書
• パラメータシート
• レビュー資料

など、本当に資料が多かった印象があります。

そして、

「どうやって作るのか」
「どういう書き方をするのか」

みたいな“現場のお作法”を学ぶこともかなり多かったです。

そもそも知識がないので、

「まずはマニュアル読んでみて」

という感じでスタートすることが多かったですね。

初めての業務内容

ここからは、実際に私が最初に担当した業務内容について書いていきます。

資料作成や結果報告など、
現場でどんな流れで仕事をしていたのかも合わせて紹介します。

これから新卒、または未経験でインフラエンジニアを目指している方に、

「最初ってこんな感じなんだ」

というイメージを持ってもらえたら嬉しいです。

最初に任されたのは、比較的シンプルな業務でした。

もちろん現場によって差はありますが、
最初はサポート前提で、できる範囲の業務から任されることが多い印象です。

最初の業務

自分が最初に担当したのは、
HULFT（企業間でファイルをやり取りするツール）を使った、
多重転送時のスループット測定でした。

金融系の帳票データを複数同時に転送して、
問題なく処理できるかを確認する試験です。

作業は1人ではなく、ベンダーの方と一緒に進めました。

スループット：どれくらいの速さでデータを送れるか（処理できるか）

例えば、水道の水でいうと、
「1秒間にどれだけ水が流れるか」みたいなイメージですね。

図：多重転送とは？スループットの違いを図で解説

「多重転送」や「HULFT」という言葉も、
未経験の方だと「？」になると思います。

でも大丈夫です。

この業界ではよく出てくる言葉ですが、
未経験なら知らなくて当然です。

実際、私も最初は何を言っているのか全然分かりませんでした。

資料作成

試験が終わったあとは、
結果を資料としてまとめる作業があります。

具体的には、
「想定したスループットが出ているか」や
「どこでボトルネックが出るか」といった内容を整理していきます。

この資料は、ベンダーの方に見せる前提のものです。

正直、この作業が一番難しかったです…。

資料の書き方は現場ごとに多少違いますが、
基本的にはこんな形でまとめることが多いです。

図：多重転送時のスループット測定結果（例）

※かなりざっくりですが、イメージはこんな感じです

• 資料作成のポイント

資料作成で一番大事だと感じたのは「目的」です。

目的がはっきり書けないということは、
何を検証しているのか理解できていない状態になります。

最初はうまく書けなくて当然です。
自分も「何を書けばいいのか分からない」状態でした。

ただ、
　「この作業は何のためにやっているのか？」
を意識するだけで、かなり書きやすくなります。

結果報告

作成した資料をもとに、ベンダーの方へ結果報告を行います。

結果に問題がない場合

　　┗　想定通りの性能が出ていること」を説明して完了となります。

結果に問題があった場合　or　指摘事項があった場合

　　┗　その原因を整理して追加でテストを行ったり、設定の見直しをしたりします。

インフラエンジニアというと、
「設定」や「作業」のイメージが強いかもしれません。

ですが実際は、

作業 + 報告

この2つがセットになっています。

技術はもちろん大切ですが、結果を伝える力も同様に必要になります。

1年経ってどう変わったか

1年働いてみて感じたのは、
業務とは少し違いますが、とにかく通勤時間が長くてつらかったです（笑）

今思うと、往復だけでかなり体力を使っていました。

仕事面で一番変わったのは、
やはり資料作成能力かなと思います。

というのも、
テストを実施したら、

「なぜ問題ないと言えるのか」

を、資料としてまとめて説明する必要があるからです。

それができないと、

・レビューOKがもらえない
・次の工程へ進めない

みたいなことも普通にあります。

なので、想像以上に

「結果を整理して人に伝える力」

が求められる仕事だと感じました。

私は最初はかなり苦手でした。

ただ、現場では意外とこういう経験を早い段階でやることも多いので、
結果的に「伝える力」はかなり鍛えられたと思います。

もちろん現場によっては、
資料作成より作業優先のところもあります。

ただ、早いうちに

・結果を整理する
・相手に伝わるよう説明する

経験をしておくのは、今振り返るとかなり良かったなと感じています。

技術面の変化

最初は、正直ほとんど何も分からない状態でした。

ただ、1年間働く中で、少しずつこんな変化がありました。

最初は本当に何も分からなくて当然ですが、
少しずつ経験を重ねる中で、段階的に理解できるようになっていきました。

ただ、技術面に関しては、

「現場にいるだけで自然と伸びる」

という感じではないかなと思っています。

というのも、現場では基本的に、

「そのチームで必要なこと」

を中心に担当することが多いからです。

そのため、現場が変わると、

「えっ、全然やること違うじゃん…」

となることも結構あります。

実際、同じインフラエンジニアでも、

• Linux中心
• ネットワーク中心
• 監視運用中心
• クラウド中心

など、現場によってかなり違います。

だからこそ、

・自分で調べる
・興味を持った技術を触ってみる
・資格勉強をしてみる

みたいなコツコツ“自分から学ぶ姿勢”も大切だとおもいます。

1つの現場を長く経験したからといって、
別の現場でもそのまま通用するとは限らない。

これが、インフラエンジニアの大変さでもあり、
逆に面白さなのかもしれません。

仕事の進め方の変化

最初の頃は、
本当に「言われたことをそのままやる」状態でした。

手順書通りに作業をして、

・結果が正常か確認する
・違っていたら先輩へエスカレーションする

という流れです。

そして、

「なぜこの結果になったのか」

を、その都度教えてもらっていました。

ここで、今でも自分の中に残っている言葉があります。

それが、

「まず自分を疑え」

です。

最初の頃は、
分からないことや結果が違うことがあると、

「とりあえず聞きに行こう」

という感じでした。

ただ先輩から、

「毎回すぐ聞くだけだと覚えづらいし、
トラブルが起きた時は、まず自分が何をしたか整理した方がいい」

と教えてもらいました。

そこからは、

・自分が何を実施したのか
・どこでエラーになったのか
・何を確認したのか

を、まず自分で整理するようにしました。

その上で、

「ここまで調査しましたが、
この部分が分からなかったので教えてください」

という聞き方に変えました。

これに変えてから、
理解度もかなり上がりましたし、
現場が変わっても周りがしっかり対応してくれるようになったと感じています。

やはり、自分が先輩側になって感じるのは、

「自分で調べた上で質問しているのか」

は意外と伝わるということです。

もちろん、最初から全部できる必要はありません。

ただ、

・この作業は何のためにやっているのか？
・なぜこの結果になったのか？
・もっと効率よくできないか？

を少しずつ考えながら動けるようになると、
理解度はかなり変わっていくと思います。

まとめ

ここまで、私の1年目の体験談を読んでいただきありがとうございました。

あくまで私自身の経験になるので、
実際に皆さんがどんな現場を経験するかは分かりません。

ただ、

「最初の1年ってこんな感じなんだ」

というイメージを少しでも持ってもらえたり、
これからインフラエンジニアに挑戦してみようと思っている方の参考になっていたら嬉しいです。

今回の記事で一番お伝えしたかったのは、

「分からないのは当たり前」

ということです。

未経験の頃は、
とにかく分からないことだらけです。

なので最初のうちは、
先輩社員にたくさん聞いて大丈夫です。

むしろ、実務年数が増えれば増えるほど、
逆に聞きづらくなっていきます（笑）

その中で、個人的にかなり大事だと思っているのが、

「まず自分を疑う」

という考え方です。

何かエラーやトラブルが起きた時、

・自分は何をしたのか
・どこで結果が変わったのか
・何を確認したのか

を、まず整理してみる。

この“振り返り”をするだけでも、
理解度や成長スピードはかなり変わると思っています。

実際、私自身もこの考え方を意識するようになってから、
少しずつ業務理解が深まっていきました。

最初は本当に大変ですが、
分からないことを少しずつ理解できるようになると、
仕事もだんだん面白く感じられるようになってきます。

この記事が、これから挑戦する方の少しでも参考になれば嬉しいです。

最後に、
未経験からインフラエンジニアを目指す方向けの記事や、
実際に働いて感じたことをまとめた記事も書いています。

同じように悩んでいる方の参考になる内容もあると思うので、
よければこちらも読んでみてください。