インフラエンジニアになる：未経験プログラマの受け口となるのか？

　元来、未経験エンジニアの多くはプログラミング学校や、フリーランスプログラマの影響を受けているケースが多く、最初からインフラエンジニアを志望していることはレアです。

　その一方でプログラマよりひと足早く人材不足に見舞われているインフラエンジニア。前職の人材紹介事業を見ていても、プログラマの道を諦めてインフラエンジニアにシフトするケースは数多く見られました。プログラマを諦めつつもIT業界に残る選択肢として昨今の一部若手インフラエンジニアは構成されている模様です。ちょっとご縁がありまして予定より前倒しの投稿です。

　有料設定していますが、最後まで無料でお読みいただけます。もしよければ投げ銭感覚で応援をお願い致します。

インフラエンジニアとは何か知ってて就職している気があんまりしてない

　インフラエンジニアが何かをきちんと理解しないと、キャリアが明後日の方向に飛んでいきます。

　6年くらい前になるでしょうか。自社でインフラエンジニアを新卒採用して良いということになり、募集をかけたことがあります。まだまだ会社も事業の認知も課題が多かったので来る者拒まずで面接をしていました。そうすると何社もお祈りされてヤケになった人が来られるわけですが…

「何の仕事をするか調べてから来たほうが良いよ」とリリースした思い出です。

インフラエンジニアとは何か

　2020年現在、よくあるインフラエンジニアの求人は大きく下記のように分類されるかと思います。

　ネットワークエンジニアやサーバエンジニアは兼務することも多いです。ここ10年くらい流行っているパブリッククラウド（AWS, Azure, GCPなど）を扱う可能性があるのはサーバエンジニア、SRE、DevOpsです。SRE、DevOpsについてはパブリッククラウドから入ったエンジニアも多く、オンプレミス環境を肉眼で見たことすら無いケースもあります。

　ではインフラエンジニアのお仕事の歴史をダイジェストで見ていきます。

IT革命が後押ししたインフラエンジニア（00年代）

　2000年代前半。IT革命に後押しされ、インフラは電話線から（一瞬ISDNを掠め）DSLを経て光ファイバへ。個人宅でも「ヲタクのもの」「インターネットというものがあるらしい」という90年代後半から、「趣味はネットサーフィンです」「インターネットを引かないと不便らしい」というマインドに引き上げられた頃、ISPに就職するというのは花形でした。当時はISPも今より数が多かったです。私のインターネットデビューはhi-hoでした。

　2000年代中盤。私が所属していた研究室やキャンパスからも多くのISP就職者を輩出していました。当時はサーバオペレーションをすると言っても、シェルスクリプトができればOKという牧歌的な側面がありました。せめてperlは覚えてみたら？とアドバイスしてもsedとawkでログ処理したりして、頑なにプログラムを書かないまま卒業してISPに行ったOBも居ました。

　IT革命にて一財産築いた当時の40歳以上の方々の中には「インターネットインフラは生活基盤。俺達の繁栄は永遠だ！」と息巻いていました。皆さん良い車乗ってましたね。その後は直ぐに価格競争になったり、技術スピードと投資についていけずに何処かへ行った方が多いわけですが。

　従来のオンプレミスの環境は築城に似たところがあります。堅牢なデータセンターを契約し、ネットワークエンジニアがネットワークを敷設し、サーバエンジニアがサーバをラックマウントする。負荷テストなどを経てOKとなったら初めてプログラマの書いたソースコードを受け入れます。そのためオンプレミスのインフラエンジニアの中ではネットワークエンジニアとサーバエンジニア、そしてその上のプログラマという形で分水嶺があるのです。

仮想化、パブリッククラウドが変えたインフラエンジニア(10年代)

　2010年頃になるとネットワークやサーバも仮想化し、それまでは物理のみをオペレーションしていれば良かった時代が陰っていきます。大手ISPにゴリゴリのネットワークエンジニアとして2000年代前半に就職した先輩が、この頃には「ネットワークの面倒だけ見てても食っていけない」と仮想サーバも含めたオペレーションについて話していたのを思い出します。

　2012年頃にはAWSがベンチャー界隈から流行り始めます。それまで不安定なイメージのあったパブリッククラウドでしたが、徐々に信頼を得ていきます。私がAWSのヘビーユーザーになったのもこの頃でした。クラウドデザインパターンが登場した頃でした。オンプレミス環境からの移行に当たってAWS用語を片っ端から調べ、対応付けながら構築していきました。オンプレミス環境をそのままパブリッククラウド上に再現するエンジニアを、私はその能力を区別するためにパブリッククラウド第1世代と読んでいます。

　2010年代中盤になると、AWSを使うからにはマネージドサービスを使って技術的導入コストを下げ、可用性を上げようという風潮が出来上がります。これがパブリッククラウド第2世代。サーバ構築コストが低く、プログラマが片手間でインフラを構築するDevOpsが台頭してきます。

　DevOpsの台頭で焦ったのはオンプレミスインフラエンジニアです。それまではある程度のサービスを維持するとなるとネットワークエンジニアとサーバエンジニアが必須でした。そのためパブリッククラウドが何者か分からないうちは「パブリッククラウド？誰とも知らない人が相乗りするんでしょ？何が起きるか分からないおもちゃでしょ？」と高みの見物だったわけです。ところがおもちゃだと思っていたパブリッククラウドが使えるようになってしまった。そして緩やかに仕事を失っていった人がこの頃に確認されるようになりました。

　そして2010年代後半はサーバレスが持て囃されるようになります。サーバは持つものではない、（何だか詳しくは分からないけど）問い合わせたら返ってくる従量課金サービスだ、という認識が拡がっていきます。こうなると主な構築担当はインフラエンジニアではなくAPIを叩くプログラマになります。これがパブリッククラウド第3世代。サーバの構築にしても、ansibleやIaCありきの現場も増えてきました。

　この頃になると「インフラ=パブリッククラウド」が若手エンジニアの中では前提となってきます。その結果、オンプレミスを志す人が減少したという背景があります。職務経歴書を見てみてもAWSの資格は持っているけども実務経験が無いインフラエンジニア志望者が増加しているのも特徴的です。

　一方、優秀なオンプレミスのインフラエンジニアはAWS、Azure、GCPなど事業者の中の人として高待遇を受けていくというのも確認されるようになっていきました。

インフラエンジニアと世代間干渉

　インフラエンジニア市場の興味深いところは、どの世代もある程度の需要があるところにあります。そして時折、世代間でマウントし合うという現象も見られます。「インフラエンジニアデビューしました。AWSで○○を運用してます！」というテックブログに対し、「それはインフラとは言わない」というオンプレミスおじさんが出てきて部下がプルプルしていました。お互いに背景も違いますし仲良くやれば良いんじゃないですかね。

プログラマを諦めてインフラエンジニアになる方への注意事項

　よくよく考えて頂きたいポイントが3つあります。

注意点1：用語、知識ドメインの違い

　オンプレミス環境で働くとなった場合、新規に覚える用語はかなり多いので覚悟が必要です。

　プログラマとは違い、資格が有効である傾向にあります。日系大手企業の方の履歴書を見ると資格コレクターかな？という程に集められています。資格を持つことで給与のインセンティブが働く企業もあります。資格がなくても入社はできるケースはありますが、資格の勉強が嫌いな人には向いてないんじゃないかと思える程度には皆さん資格をお持ちです。

注意点2：日常生活から見えにくいが故のモチベーション維持

　プログラマへのジョブチェンジを考えている若手インフラエンジニアと接していると、他のインフラエンジニアやプログラマが気になって仕方がないようです。

　まずはパブリッククラウドへの憧れ。既にインフラエンジニアではあるものの、オンプレミスばかり担当になることに閉塞感を感じるタイプです。

　次に自社メディア・自社サービスへの憧れ。これはプログラマが抱く感情と似ています。ただし市場的にインフラエンジニアを専任で置いている自社サービス企業は一握りです。有名サービスであれば既に手練が居るか、丸っとMSPに外注しています。

　以前、職務経歴書にある有名ゲームタイトルのインフラエンジニアを担当していたと書かれていた方の面接をしたことがあります。しかしどうも歯切れが悪い。よくよく深堀りをすると「当該ゲームタイトルには社内の神々とも言える凄腕エンジニアがチームを組んでおり、介入する余地はない。自分は神々から持て余した雑用や開発環境のセットアップを担当していた」と。

　次にプログラマへの憧れ。インターネットが浸透しきった現在では、入社後ほどなくして直接ユーザーが触れる部分に関わりたいと思う方が少なくありません。親も知っている大手ISPに社名ベースで入ったものの、その後思い直して急にReactを始めたりするレイヤの振れ幅が大きい人は一定数居られます。全くの未経験から始めるよりは業界経験がある分有利ですが、根本的にプログラマとインフラエンジニアは別の職種であることにはお気をつけください。

　影の立役者であるが故に華やかさに憧れる側面はあるのかな、と思ったりしています。

注意点3：企業によってはオペレータから出られないところがある

　夜間アクセスがピークだったり、尋常ではなく処理が重く、且つ重要なバッチ処理がある現場もあります。緊急対応のために24/365で交代制を引く企業はあります。ここで最前線に立つのがオペレータです。

と上流にシフトしていくのがよくある大手インフラ・SIerでよく見られるキャリアパスです。

　このオペレータの業務内容はもどかしいケースが多いです。例えば一般的なMSPの場合、アラートが上がるとマニュアルを見て一次対応しますが、マニュアル以外のケースは契約者に連絡を取って承諾を得なければ契約に反するリスクがあります。また、同じく一般的なデータセンターで何か障害があったと顧客から連絡があった場合、ステータスランプの確認と電源のON/OFFくらいしかできません。いずれもそれ以上のサービスであるOS以上の運用契約がないとこれ以上はできません。

　加えてこのオペレータとしての就業中のうち、平常時の過ごし方が所属企業に寄って全く異なります。端的に言うと平常時にスキルアップに向けた課題を出したり経験を積ませるのが望ましい企業であり、各々がスマホで遊んでるのがよろしくない企業です。

　就職・転職時の企業選びでは教育やキャリアパスに対する理解がどうか、実例としてはどうなっているかを確認されることをオススメします。AI、自動化によって削減されるリスクも予想される職種であるため、スムーズにオペレータからステップアップすることを意識して損はないでしょう。

　シフト勤務で且つ守りの要素を持つ業務というのはどうも満足感を得やすい傾向にあるようです。夜勤など不規則な時間もあり、他者比較もできないまま時が経ちやすい人も多いのでくれぐれもご注意ください。

まとめ：インフラエンジニアとしてスタートするために

　プログラマと同じく基礎を学ぶための情報系への進学はオススメしたいところです。コンピュータサイエンス、ネットワークの基礎、オンプレミス・仮想化・パブリッククラウドの習得・演習とできれば手習い的オペレーション経験。これらを一通り手掛けることをオススメします。

　私も何度か外部講師として呼んでいただいたことがあるのですが、一般社団法人高度ITアーキテクト育成協議会（AITAC）は、現代に必要な知識習得・技術演習によって次世代を担うインフラエンジニアの育成を目的とした団体です。経験者のリラーニングにもオススメです。企業によってはAITACへの加盟や学習機会の後押しもあるのでご確認ください。