レベルアップ！つよつよエンジニアを目指すには？

学び方指南シリーズの最後は、「⁠AWSについてつよつよのエンジニアになるには？」です。

前々回は入門者向け、前回はオンプレミス環境を知っている技術者向けにお話をしてきましたが、今回は、「⁠既にAWSを知っている人が、つよつよエンジニアを目指すにはどうすべきか」についていくつかの方策を提案します。

今回は、少し難しい話なので、AWS初心者や、エンジニアとしての経歴が浅い人には、とっつきづらいかもしれません。その場合は、飛ばし読みして、「⁠そのうち、こういう用語をわかるようになればいいんだなあ」程度で読んでください。

そもそも⁠、「AWSについてつよつよのエンジニア」はどう定義するか

そもそも論として、「⁠AWSについて、つよつよのエンジニア」とはどのような人を指すのでしょうか。

僕は、「AWSなどを使って『適切な』システムを設計できる人」だと考えています。これは、どういう意味かというと、あるプロジェクトがあったとして、そのプロジェクトに対して、「⁠最も適切である」システムを設計できることです。「⁠AWSなど」を使ってと書いたように、必要であれば、他のクラウドベンダーや、オンプレミスでの構築や併用を提案できることも含みます（他のクラウドやオンプレでの構築は他者にお任せするとして！⁠）⁠。言い換えれば、「⁠AWSのサービスを適切に選択でき、AWSの得意なことも、『⁠不得意なこと』も知っていること。そして、それを組み合わせられること」です。

AWSについて詳しいエンジニアには、いくつかの段階があります。たとえば、「⁠Amazon EC2は、サーバー機能を貸すサービスである」「⁠Amazon S3はオブジェクトストレージを貸すサービスである」といったように、サービスの内容や、どのようなサービスがあるのかについて知っている段階から始め、簡単なシステムが構築・運用できること、複雑なシステムを構築・運用できることなど、スキルアップしていきます。

初心者向けの回で書いたとおり、AWSは、AWSを使うのが目的ではありません。実現したいプロジェクトがあって、それに対して、AWSを選択するものです。ですから、主役は、あくまでプロジェクトであり、そのプロジェクトに対して、適切な仕組みを提案できることが必須条件なのです。

AWSは、クラウドベンダーの中でも大きなシェアを誇っており、使いやすく、サービスも豊富です。でも、世の中で、すべてのアイスが僕の好きなチョコミント味ではないのと同じように、AWSが向いていることとそうでないことがあり、別の選択をすることだってあるのです。

AWSを適切に選択するためには、AWSについてよく知っているだけでなく、他のクラウドベンダーの簡単な知識や、オンプレ構築の知識が必要です。また、その分野の専門知識も必要です。たとえば、データベースであれば、MySQLやPostgreSQLなどのRDBMSの知識、キーバリューなどのNoSQLの知識やNewSQLなどの最新の知識も必要でしょう。AIであれば、個々の学習モデルや、活用方法も知らねばなりません。

「ウヒャー！大変だ！」と思ったあなたは正解です。世の中で「この人は強いなあ……」と思う人ほど、「⁠私はたいしたことないです」とおっしゃるのは、こうした理由なのでしょう。

「AWSのサービスを知っている」だけでは、「⁠つよつよ」までまだまだ遠いのです。AWSを中心とした、巨大な知識体系を我が物とせねばなりません。そして、それは大変な道のりなのです。

クラウドネイティブを改めて解説

つよつよとなるためには、AWSについても、なんとなく、ボンヤリ使うのではなく、「⁠使いこなす」ことが求められます。そして、その根幹になる思想の一つがクラウドネイティブという考え方です。

ここで改めて、クラウドネイティブについて解説しておきましょう。

クラウドネイティブは、AWSに限らず、クラウドコンピューティング全般に適用される考え方です。CNCF（Cloud Native Computing Foundation）というクラウドを推し進める組織が定義している言葉です。意識することで、システムをクラウド前提の作りにすることができ、「⁠クラウドを使いこなす」ことがしやすくなります。

こまかいところは、公式の定義（https://github.com/cncf/toc/blob/main/DEFINITION.md）などを見てもらうとして、クラウドネイティブの重要なキーワードは、「⁠コンテナ」「⁠サービスメッシュ」「⁠マイクロサービス」「⁠イミュータブルインフラストラクチャ」「⁠宣言型API」「⁠マルチテナンシー」「⁠サーバーレス」の7つです。
（⁠註：2025年7月現在、ローカライズが間に合っていないのか、英語版では7つ、日本語版では5つとなっている）

それぞれを簡単に解説していきましょう。

コンテナ

「プログラムの実行環境を隔離できる仕組み」です。コンテナを使うと、全部を一緒くたに入れていた個々のソフトウェアを、独立した状態で扱えるようになります。コンテナは、コピーしたり、作成と破棄が容易なので、現在では、サーバーだけでなく、開発現場でも多く使われるようになりました。

コンテナの代表的ものがDocker社のDockerです。また、コンテナを管理するものとして、Kubernetes（クーベネティス）があります。

マイクロサービス

マイクロサービスは、小規模で独立したソフトウェアコンポーネントです。大きな一つのものを作るのではなく、小さいマイクロサービスをつなぎ合わせて、大きなシステムを作るという考え方です。

AWSは、まさにマイクロサービスと言えるもので、たとえば、サーバーを立てる時にも、サーバー機能は、Amazon EC2というサービスですが、サーバーのストレージは、Amazon EBS、IPアドレスはElastic IPアドレスと言ったように、個々の機能に分かれています。

このように、個々に分かれていることで、障害が起こった時にも、他に波及しませんし、組み替えなどが容易になります。

サービスメッシュ

サービスメッシュは、複数のマイクロサービス間の通信を観測するものです。つまり、コンテナやサービス間の通信が正しいかどうかを観測したり、セキュリティの機能を付けたりします。

コンテナ・サービス間に挟み込むようなものなので、元々のサービスを改造するのではなく、追加する形で導入できます。

イミュータブルなインフラストラクチャ

イミュータブル（不変）なインフラストラクチャとは、「⁠一度作ったインフラを変更しない」という考え方です。このように言うと、「⁠一度作ったものを後生大事にする」ように聞こえるかもしれませんが、逆です！！わかりにくい！！

たとえば、サーバーを立てたときに、オンプレミスの環境では、一度作ったサーバーのOSやミドルウェアを時々アップデートします。反対勢力により、アップデートがあまり行われない現場もありますが、多くの良心的なエンジニアは、アップデートに連動したコードの面倒な書き換えに快く同意し、OSやミドルウェアのアップデートが行われることでしょう！（理想）

イミュータブルインフラストラクチャは、そうではなく、「⁠一度作ったものは、アップデートせずに、捨てて、新しいバージョンのものを作る」という考え方です。作って古くなったら、ポイ。新しいものを使う、ということです。僕はこれを「作っては捨てる」と呼んでいます。

これは、オンプレミスというよりも、非クラウド環境の場合、大変面倒な作業ですが、クラウドならば、画面でポチポチやればできることなので、可能なのです。自社のシステムのコードの面倒な書き換えが必要なのは同じですが、インフラエンジニアは簡単に作業できます。ゆえに、「⁠おまえらは楽かもしれないが、我々は大変である」とより深い恨みを買う可能性もあるので、時々、チョコレートなどを渡しておくと現場がスムーズに回ります。

宣言型API

APIとは、Application Programming Interfaceの略で、複数のソフトウェアプログラムが情報を交換するために使用する方法です。実際は、定義なのですが、実装時に、キーを使うことが多いので、APIキーのことを略して「API」と呼ぶこともあります。今回話すのは、キーではない、定義の方のAPIです。

APIには、手続き型と宣言型があり、手続き型は、個々のやることを随時命令する形式です。たとえば、常に5つのコンテナを立てて置きたい場合、「⁠コンテナを5つ作ってください。これを使って作ります」という書き方なので、もしコンテナが死んでしまった場合、作成などは命令されてないならば、そのままです。もし、死んだ場合に、代役を立てたいのであれば、監視して、代役を作成する旨を記述しておかねばなりません。

宣言型の場合は、「⁠コンテナが5つあるようにしてください（方法は問わない⁠）⁠」です。なので、コンテナが死んでしまった場合、ソフトウェアが自動的に代役を立てて、継続されます。つまり、Kubernetesの仕組みそのものです。CNCFは、Kubernetesと関係の深い団体なので、わかりやすいですね。

手続き型ではなく、宣言型であることによって、ソフトウェアが自律的に動き、人間の手間が減るようにしていきましょうという考え方です。

マルチテナンシー

マルチテナンシーとは、ソフトウェアやインフラなどのリソースを、複数のユーザーやテナント（開発ベンダーやサービスの提供元など）が共有する考え方です。

現在、電子的なものは、肥大化一直線で、増えるばかりです。人材不足を、IT技術で補う傾向も強く、リソースが足りなくなってきています。たとえば、AIで使うようなものは、物理的なGPUが手に入りづらくなっていることは有名ですし、サービスで提供されているものも、リソースの奪い合いです。

こうした時に、マルチテナンシー的な考え方をすることによって、少ないリソースを共有して、効率よく使うことができます。

たとえば、AWSのAmazon RDSなどはわかりやすい例でしょう。巨大なシステムを皆で共有する仕組みになっています。

サーバーレス

サーバーレスは、勘違いされることも多いのですが、サーバーがレス（不要）という意味ではなく、ユーザーがサーバーを意識しない仕組みです。代表的なのが、AWS Lambdaです。

ユーザーは、自前でサーバーを意識することなく、関数をポイっと置くと、それをすぐに使えるようになります。

クラウドネイティブの現実と⁠、理想の乖離

このようにいろいろ書いてきましたが、僕自身も、「⁠現実として、いろいろ難しいよねぇ……」とは思っています。

そもそも、現場のすべてがクラウドで運用されているわけではないですし、会社によっては、非クラウドの比率の方が高いケースもあるでしょう。そのような場合に、「⁠クラウドに合わせて設計なんて面倒くさい」と思われてもしかたないです。

しかし、せっかくクラウドを使うのであれば、こうしたことを取り入れていくことで、クラウドを使いこなし、「⁠人の手間」を減らせることも事実です。

今回の前半で「つよつよエンジニアの定義」でもお話しましたが、主役はプロジェクトであり、AWSはその土台です。ですから、クラウドネイティブを取り入れることは、絶対ではなく、「⁠プロジェクトとしてやった方がいいこと」や「会社として取り組んだ方がよいこと」であるかどうかを考えながら、進めていくと良いでしょう。

つよつよのエンジニアを目指していくこと

このように、AWSについて、つよつよのエンジニアを目指していくのは、なかなか大変です。

一足飛びに、つよつよを目指さずとも、「⁠AWSそこそこエンジニア」でも十分戦闘力が高いですから、まずは、そこそこを目指すのも良いでしょう。

そのためには、まずはAWSについて詳しくなることですね。AWSについて詳しくなるには、以下のサイトが有名です。こうしたサイトや、AWS Summit（年に一回行われるAWSのイベント）や、ユーザー会（ユーザーが集まって意見交換する会。JAWSが有名）を活用しながら、レベルアップしていきましょう。資格試験などを通して学んでいくのもおすすめです。

【公式】

AWSホワイトペーパーとガイド: https://aws.amazon.com/jp/whitepapers/; AWSが提供するドキュメント
AWS Black Belt Online Seminar: https://aws.amazon.com/jp/events/aws-event-resource/archive/; AWS提供のオンラインセミナー
AWS の最新情報: https://aws.amazon.com/jp/new/; AWS最新情報がわかる
Amazon Web Services ブログ: https://aws.amazon.com/jp/blogs/news/; 公式ブログ

【非公式】

DevelopersIO: https://dev.classmethod.jp; AWSのパートナー企業であるクラウスメソッド社のブログ。

次回は、実践編として、AWSの構成例をベースにAWSの学び方を解説していきます。