8
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

  • この記事は、オンプレミスのインフラエンジニアだった私がクラウドネイティブ技術を約2年学んで感じた「インフラエンジニア」というキャリアについて、完全なる私見を述べたものです。
  • クラウドとオンプレミスという2つの似て非なる環境を経験して、今後インフラエンジニアはどうなっていく必要があるのかを文章に残しておきたいと思いました。

これまでのキャリア

本題に入る前に、このような記事を書くことになった私のキャリアとマインドを簡単に紹介します。

オンプレミス時代

入社から約6年間ほど、主にオンプレミスのインフラを設計・構築する専門部署で働いていました。やっていた業務はというと、以下のような感じ。

  • NW機器やサーバ・ストレージ機器の設計・実装
  • 物理機器の新規設置、お引越し、それに伴うラッキング作業
  • OA環境の整備(Active Directory / ウイルス対策 など)
  • その他、アプリケーション開発ではないことを様々...

基本的にインフラを作ってテストが終わればアプリ開発チームに環境を引き渡すので、アプリケーションの設計・構築は関わらない(役割的には支援という名の問い合わせ対応)というのが主でした。

そんな中で私はこのように考えることが増えていきます。

「なんか流行りのインフラ技術を全然できてないからやばい気がする・・・」

その当時から話題に上がっていた「コンテナ」や「Kubernetes」、「パブリッククラウド」というようなものを業務で一切使っていないことが、自身のエンジニアキャリアに大きな問題を生むのではないかという漠然とした不安を感じるようになったのです。

しかし、実際にこれらを入門ハンズオンなどで触ってみても、正直あんまり良さが分かりません。「早く環境が用意できること」は確かにそうだけど、それだけ...?

今の業務ではこの不安を解消することができないと感じ、弊社のオープンチャレンジ制度を活用して思い切ってジョブチェンジすることにしました。

ジョブチェンジ

異動した先は、クラウドネイティブと呼ばれる技術に関する研究開発および案件支援を行う組織です。
ここでは以下のような技術に関して、最新動向を調査・検証したり、事業部の案件にテックリードとして参画して設計・実装をしたりしています。

  • コンテナ/ Kubernetes
  • terraform
  • Observability
  • CI/CD
  • パブリッククラウド(AWS)
  • GitOps

2年も経つと、これらがアプリ開発の現場においてなぜ主流になっているのかをよく分かるようになりました。
(ついでに異動前に感じていた不安を取り除くこともできたので異動は大成功でした。)

でもこれが分かったのは、上記の技術を使ったからではなく、
「アプリ開発って何をやっているのか」
をなんとなく理解し、興味を持つことができたからだと思っています。

クラウドとインフラの境界線

前置きが長くなりましたが、ここからが本題です。

従来のシステム開発では、インフラ開発とアプリ開発が分断しており、極論ですがアプリ開発が何をやっているのかを把握していなくても仕事ができます。
(異論あるかもしれませんが、少なくとも私はそうでした。)

しかし、クラウドの世界においてインフラとアプリの境界線はかなり曖昧です。しかもサーバレスやSaaSの普及により、従来のインフラ層は抽象化されることが多くなってきました。(そして今後さらに加速するはず)
そのため、アプリ開発と並走してインフラも作り改善していくという形に開発の仕方が変わり、よりアプリとインフラは互いを理解・協力しながら仕事をする必要が出てきました。

クラウドにおけるインフラエンジニアの役割とマインド

こうなってくると、インフラエンジニアに求められる役割やマインドは大きく変わってきます。

今まではインフラを作って渡せば終わりだったものが、アプリ要件を読み解き、柔軟かつ素早く設定に落とし込むことが役割として求められます。

そのため、
アプリ開発が何をやっているのか、どういう困り事が発生しうるのか
ということを理解し、発生する課題をアプリエンジニアと一緒に解消していくことにモチベーションを持つことができるかどうかがマインドとして求められるようになりました。

クラウドを前提とするシステム開発においては、インフラ「だけ」を専門分野として、アプリ開発に関わらないという働き方は限界があるのです。

インフラエンジニアのマインドチェンジ

従来のインフラエンジニアがクラウドを主戦場にしていくには、前述のマインドへの変化が必要になってきますが、これが中々難しいです。
完全に個人的な意見になってしまいますが、以下の現状・思想があると思っています。

アプリ開発のことを知らなくても仕事はできる

繰り返しになりますが、インフラだけを作るという観点で見れば、このスタンスでも仕事できます。
これは決して怠惰だというわけではなく、インフラだけでも多くのことを考え・設計する必要があるからです。

アプリ開発のハードルを勝手に上げてしまっている

「幽霊の正体見たり枯れ尾花」ということわざがありますが、まさにこの通りで、
自分が業務で扱ったことが無いものを過剰に警戒してしまいます。
「独力で業務で扱うレベルのコードを読めるようにならないといけない」とか思います。

この2つが重なると、マインドチェンジは中々難しいです。
アプリエンジニアがインフラを兼任するという例が良くあるのは、インフラエンジニアのマインドチェンジが難しいという理由があるからだと思っています。

でもクラウドを勉強しないといけないという雰囲気

昨今、クラウド流行の波を察してか、インフラエンジニアのキャリア形成としてとりあえずクラウドを学ばせるという風潮があります(特に資格取得の推奨など)。
私はこの流れは非常にもったいないと思っています。

前述の通り、クラウドでインフラエンジニアをやるのであれば、アプリ開発のことを知ろうというモチベーションが必要です。これが無い人がクラウドを学ぶと、インフラのスコープから抜けられないので、「VPCがプライベートネットワークを作っていて、EC2がVMwareの代わりなんだな」ぐらいの知識しかつかず、ただの資格ホルダーになる可能性があります。

確かにIaaSとしてクラウドを利用する際には役立つかもしれませんが、インフラがさらに抽象化されるであろうもうちょっと先の未来ではどうでしょう。

この状態は、インフラエンジニアを、そして雇用する企業を不幸にしています。

インフラエンジニアってもっと幅広くて強いよ

ここまで長々とインフラエンジニアの今後をただ憂いているように見えるかもしれませんが、そうではありません。

インフラエンジニアは、
クラウドにこだわらなくても、もっと幅広くて強い仕事だろう
という事が言いたいのです。

・広大なWAN環境や企業内のLAN環境
・大量のデータやクリティカルなデータを扱う物理サーバやストレージ
・データセンター内での物理機器ラッキングやケーブリング
・OA機器周辺の機能

上記はあくまで一例です。インフラといっても色んな業務・役割があり、強みがあり、そして奥深いです。どんなにクラウドで抽象化されたって、それを支えているのはオンプレミスで動くインフラ技術です。

これらを扱うエンジニアはクラウドと同等、なんならより重要な価値を持っていると思います。
そしてこれらを追求していくことも、インフラエンジニアとしてのキャリアの1つだと思うのです。

とりあえず流行だからクラウドをやる/やらせるのではなく、インフラエンジニアとして強みとモチベーションを再認識して、それに合ったキャリアと企業としての戦術を組んでいくのが、皆が幸せになれる道なのではないでしょうか。

さいごに

結局のところ、自分の歩く道は自分で決めるものです。

良いインフラエンジニアライフを!!!

8
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?