社会人3年目が終わるインフラエンジニアが得たものを雑多に

はじめに

今週末は花金+入社式で会社の周りが地獄になるんだろうな、と陰鬱としている
インフラエンジニアが、そういえば入社4年目になるんだなぁ、と思いながら
自分の今後とかを見据えようと「入社前にやってた事」「入社後にやってきた事」をまとめてみる。

そこから、インフラエンジニアを目指す or やらざるを得なくなった新社会人が
こういう事やれば良いのか、とか何かしらの気付きを得てもらえれば御の字だなぁと思ってます。

この記事の目的なんなのさ

組み込み系を専攻していた僕がWEBの会社に新卒入社して生き抜くために実施した6つのこと
この記事を読んで「いわゆる3年目」を終え4年目になろうとしていて、次の自分のキャリアをどうするか、とか
どういうエンジニアになりたかったんだっけ？と自問自答するようになってきた。
Asis/Tobeじゃないけど
「僕は何がしたくて」、
「段階ごとに何をやったか」
「結果、何が身についたと思うか」
「今までエンジニアやってて個人的に有用だと思うことは何か」

を書いてみようと思います。

なお、僕はインフラエンジニアなんですが、ちょっとばかし特殊なインフラエンジニアでして、恐らく普通のインフラエンジニアはでないです。
(普通なインフラエンジニアってなんですかね？)

物理とか仮想レイヤのサーバ・ミドルウェアとストレージをちょっと触っています。
インフラエンジニアなのにネットワークは触れません。

インフラエンジニアになる前のスキルセット

その前に、インフラエンジニアになる前何がしたかったの？

大学時代は「(漠然と)OSを作る仕事がしたい」と掲げていた目標がありましたが
卒業間際に「どんな要求にも応えるインフラエンジニアになりたい」と変わりました。

根本的な目的(達成欲というか・・・)は　「誰もが使う何かを作りたい・触りたい」でした。
最初は誰もが使う何か=OSだ！と思ってWindowsとかOS作る人になりたいなぁ、とか考えていたのを思い出します。
途中、課題とかで、Web系(当時はPHPとかを触っていた程度ですが)で、Web3層モデルチックなシステムを作ったり
バイトとして、Webページを作っていったりしていると
「これからはWebの時代や！どでかくなるでぇ！そのインフラ触れるエンジニアとかかっけぇやん！」という安易な考えから
インフラエンジニアになりたい、と思っていました。

最初は、俺は一流のプログラマーになるんや！とか息巻いてた感はあります。

大学卒業間際に得たスキルセット

いわゆるIT基礎知識
　基本情報技術レベルな感じで、2進数とかちょっとしたアルゴリズムとか
　コンピュータの中身とか、その他周辺の何がどうなってるのかなどなど。

Google力(トラシュー能力とも言う)
　困ったら調べる。調べ倒す。
　自作PCとか、コードとか、知らない用語出た時とか
　「自分のトラブルを解決するために最適な回答を見つける」ことがGoogle力じゃないかなぁと勝手に思っていたり。

自作PC組むレベルのHW知識
　超雑ですが、自作PCをでっかくしたのがデータセンターで動いてると思ってもらえれば。。。
　それがあるので、HW的な故障があった時でもどこらへんかな？とかアタリをつけやすくなりました。

サーバ・ミドルウェア系を触った経験
　自身の身の回りで困った系を解決するためにLinuxサーバを家において色々やってた。
　習熟度云々よりも「触ったことがあるかないか」と「Linuxサーバで何をやったか(やりたかった事を実現したか)」は生きたなぁ、と。
　　Apache/nginx(ブログやりたかったり、バイトのhtmlコーディング用だったり)
　　Samba　(研究室にいながらにして自宅のファイルを扱いたかった的な)
　　AudioStreaming　( iPhone 16GB しかないのに容量足りなくなって。。。)
　　後はあんまり記憶にないのでちゃんとやってないと思われます。

　　本当はダメでしょうが、PostfixとかDNSとか、ちゃんとしたミドルウェアってあまり触ってませんでした。
　　そこをやっても実りが無い気がした・・・って感じでしょうか。

　　今、エンジニアやっててたまーにDNSとかProxyとか、そこらへんで質問飛んできたりしますけど
　　ぶっちゃけGoogle先生で解決できることがよくある。
　　(解決できないことはね、仕様です。)
　　
サーバ仮想化系の理解
　当時はあまり意識しなくて、概要しか分かってなかったけど
　「1台のサーバのうえでいろんなサーバ動かせるんしょ！」ぐらいな感じのふいんきは掴めていた。
　何をどうやって動かしているかはあんまり気にしていなかった。
　フィーリングで研究室にあったESXiを触っていた・・・ようなぐらい。

コーディング力
　CとかJavaとかPerlとか、「コードを書く」というよりかは、サンプルコードとか
　先輩にもらったコードを元に自分のやりたいことへ変えていくって感じでしたが。。。

入社して得たスキルセット

ヒューマン？系

正直なことを申し上げれば、テクニカル側は大学卒業当時のスキルセットで
入社してから困ることはそうそうなかった。(あまり業務すぎることは書けないので実際にはそうでもないっちゃないですが)

なので、テクニカル的なスキルがメインというよりヒューマン系？スキルが得られたスキルセットになったかなぁ、と
その中で、個人的にこういうスキルを身につけられててよかったなぁと思うの書き下します。
もちろん、全くテクニカル的な要素が無いわけではなかったのでそちらも記載しておきます。

誰が何をやるのか・知っているか・要求しているのか、把握したがる
かっこよく言えばステークホルダーを把握する、がニュアンス的に近いのでしょうか。
自分が今からやる仕事の前後で「誰が何をするのか」、を知るというより、「知ろうとすること」が身についた感じがあります。
これを例えるのが難しいですが・・・、Webサーバを一台作って欲しい、というオーダーに対し
「オーダー元は何のために、どのように使うんだろう？」とか
「Webサーバ・・・nginxだったらAさんに、Apacheだったら知ってる人を探すところから始めるか」とか
「いや、サーバ作るのは良いけど、他のエンジニア(NW担当だったり)は誰だろう？」とか

自分の作業で影響を受ける人とか、助けてくれそうな人とか、知ってそうな人を知っておくとか、結構重要でした。

自分が担当してきた部分頭の中で俯瞰してマッピングする
これってスキルなの？と思ったんですが、案外僕より長く同じ作業を担当している人の何人かは
「作業」には精通していたのですが、その作業を取り巻く「環境」には無頓着でした。

僕がいる会社が特にそうなんですが、「アプリ側は別担当者がやるし、とりあえずインフラ側は言われたことだけやりゃいいか」みたいな。
この人は〜担当！って決まっちゃってる場合はこうなりやすいと勝手に思っていますが
やってきた作業を頭の中でつなげていって、その会社のオレオレシステム構成図とかを頭のなかで作っておく(イメージしておく)と
何かイレギュラーな事が起きても(間違っていなければ)、オタオタすることがなくなります。

個人的な体験ですが、そういうところに気を配ると、色々と疑問が湧いてくるので
他の担当者に聞きにいって仲良くなれるとかありました。
環境と人と会社と、頭の中に色々マッピングしましょう。

時間勝負な時は段階で区切る(諦める)
こう書くとすごいカッコ悪いですし、エンジニアとしては良くないんでしょうが
インフラエンジニアやってると時間に追われることがままあります。
どんなエンジニアでもそうなんですが、何かしら障害が起きた時に対応せざるを得なくなる日が来ます。
障害といっても色々あって、Cドライブがいっぱいでアプリがクラッシュした！とかなら可愛いものの(洒落にはならんのですが)
全く検討が付かないこととか、そりゃもう色々あります。(暗黒微笑)

その時に上記2つのおかげで、「どこまでどう波及するか」、「そのための復旧プラン」、「タイムリミット」なんかを気にかけられるようになりました。
自分の意見をちゃんと言うための材料となって、上の人とかに報告するときに決断も一緒にお願いできたりします。

・・・なんかまだ色々あるんですが気が向いたら第2弾書きます。
ヒューマン？系も書き出してみると色々得たなぁ。(今の仕事特有でないことを祈る)

技術系スキル

データベース系
言わずもがな、OracleとMS-SQL。パフォーマンス・チューニングやったことないけどやらされてました。楽しかった。

自動化系
後述しますが、AnsibleとかServerSpectとか普段、自分がインフラエンジニアとしてやってて
「正直こんなことやってらんねーっす！自分やりたくないっす！」と思っていた部分に対してアプローチできていた。
自分の怠惰な性格と、日々のネットサーフィンが生きた瞬間でした。

いろんな製品のコンセプト
・・・ぶっちゃけた話、その製品特有の知識がふんだんに入っていたりするので
良いかどうかはわからないけれど、「あぁ、こいつはこういうコンセプトのもとに動いているんだなー」とか
何でその製品が使われているかが普段触っているおかげで感覚的に理解できるのは大きいですね。

バレたら怒られる内容は書けないので技術的なスキルを詳しく書けない。悲しい。

社会人になる前となった後で思ったこと

　・モチベーションの波がすごい
　　これが個人的には大事な問題で、僕は、新しいものをやってる時はめちゃくちゃ楽しいんですけどそれが何回も続くとすぐ飽きてしまう。
　　後は、業務にめちゃくちゃ有用だから新しいことを周りに布教しても全くノってもらえなかった時とか、なんでやねん。ってなる。
　　(もちろん、メリットデメリットをちゃんと伝えられてないから、とかそういうのは理解したうえで)
　　こう、息巻いて色々変えてやるぜ！な人は考えて行動しないと自分のモチベが消えていくかも。。。
　　ただ、ぶっちゃけた話入社当時のモチベを退職するまで100％維持できる人は本当に一握りなので
　　消えたところで何も気に病む必要はないと思いますし、たまには休みましょう。

　　ちなみに、モチベーションが消えかけてた時に僕の好きなプロゲーマーが出した本には

「この人って熱いな、ちょっと面白いな」と思う人のそばに行ってみるといい、ということ。彼らが、きっと火をつけてくれるはずです
　　東大卒プロゲーマー (PHP新書)

　　と書いてありました。(ちょっと本からちゃんと引用していないのでニュアンスとか若干違うかもしれませんが。。。)
　　モチベーションを保つ必要があるかないかは人それぞれですが、何かしらにモチベとか情熱持ってる人の近くに行くのは
　　暑苦しい時もあるかもしれませんが、有意義だと思っています。

　・自分の意見とかが通せるようになると面白い
　　個人的に面白いと思っているだけですが
　　「このアプリの仕組みだと、こっち側はこうしないとダメじゃないです？」とか
　　意見を発信するって結構重要なことだよなぁ、と思います。
　　ぶっちゃけ、殺される訳じゃないんでバンバン意見言いましょう。
　　(言えるための知識も必要だとは思いますけど、度胸も必要ですし、やってみましょう)

なんか書いてたらまとまらなくなってきたのでまとめます。

#何が言いたいの？
書いてたらよくわからなくなりました。
そもそもインフラエンジニア向けですら無くなったような気はしますが・・・
いつもはこの時点で消してしまうんですが、たまには外に出しましょうの気持ちでそのまま投稿。

インフラエンジニアになるんだけど何が必要なんだ！とか言う人は
お気楽に、上に書かれたスキルセットがあるかな、とか、なんかそんな感じで見てください。

ある程度、必要最低限のスキルセットに加えて、ちょっと気の利いたヒューマン系？スキルがあれば
IT系エンジニアとして何かしらやっていくことは可能だと思います。

最後に、ニュースじゃなくて良いので、 qiitaとか はてなブックマークとか menthas 見ましょう。
で、自分の分野の話やお？って思ったものは、「自分のため！」ではなく、読み物として見ることをおすすめします。

どっかで糧になりますよ。