本記事は、AWS Ambassador Advent Calendar 2022の11日目の記事です。
タイトルにある「AWS技術者」は、
「AWSを活用してシステム基盤の設計・構築・運用ができるエンジニア」
を意味する、ぐらいにお考えください。
また、エンタープライズ色の強い内容になっていますので、その点ご了承下さい。
ちょうど去年の今頃、クラウドを仕事に活かしていけるエンジニアを
なるべく速く育成するにはどうすればいいのか、というテーマでよくディスカッションしていました。
それがきっかけで、昨年は「長く使えるAWSの技術は何か？」というタイトルで記事を書きました。
2022年もAWS技術者の育成に関しては、色々と思うところがありました。
よい機会ですので振り返ってみたいと思います。
数年前のAWS技術者育成を目的としたトレーニングのイメージ
数年前は、「AWS認定ソリューションアーキテクト - アソシエイト(SAA)」などを題材に
- AWSのグローバルインフラストラクチャの概要
- 出題範囲にあたるAWSサービスの概要や機能、使い方
- 代表的なデザインパターン
- AWSのベストプラクティス、Well-Architected Frameworkの内容
- 業務上のTips
- それに加えてEC2、VPC、RDS、ELB、Auto Scaling、Lambdaあたりをハンズオンで体験(サービスをトレーニング要件に応じてカスタマイズ)
のような内容で行われるトレーニングをよく見た気がします。
AWS認定試験の対策にもなりますし、講義で解説した内容をハンズオンで体験もできるので、
AWS技術者の育成の第一歩はこれぐらいでいいと思っていた時期が私にもありました。(例の画像)
が、近年の実務の状況を踏まえると、上記だけでは足りなくなっていると思います。
何が？
AWSのサービス自体年々増えますが、同時にアプリケーション開発のためのツール自体も変遷、進化し続けています。
AWS技術者を目指すエンジニアに「武器を持たせてあげる」上では、そういった「AWSで開発・運用を行うために、新たに必要になってきた前提技術」の学習機会も、併せて提供し続ける必要があります。
例を挙げます。
コンテナ
エンタープライズの領域でも、ここ数年コンテナ技術が当たり前に利用されるようになってきています。
これからAWSを学びたいという方々には、
ECSやEKSといったコンテナオーケストレーションツールを利用する前提として、
コンテナイメージの作り方も知ってもらう必要があります。
Dockerが一番情報量も多く学びやすいですが、最近AWSから「Finch」も発表されましたね。
こういった開発ツールの動向にも追随し、エンジニアにトレーニング機会を提供したり、
社内で勉強会を盛んに行ったりすることは、
「エンジニアの方々に、自社で長く働いでもらう」ためにも重要な取り組みだと思います。
IaCツール
IaC(Infrastructure as Code)の考え方に基づくツールは、クラウド環境の運用には欠かせないものとなっています。
AWSは古くからCloudFormationを提供しており、最近はCDKもよく聞きます。3rd Partyツールもあります。
エンタープライズ向けのAWS技術者の方々に、クラウド環境の構成管理ツールを1つだけ学んでもらうとすれば、
私は現時点ではTerraformを推します。
理由として、数年前と比較して、用途によってクラウドプロバイダーを使い分けている、マルチクラウドのユーザーさんが多いからです。
Terraform Providerはクラウドプロバイダーによって異なりますが、HCL言語の文法やTerraformのCLIツールの使い方など、共通化できる部分も多いため、マルチクラウド環境においても、エンジニアの学習コストを抑えることができます。
もちろん、「うちはAWSしか使っていない」というケースもあるでしょうし、「ユースケースやチームのスキルレベルに応じてツールを使い分けた方が効率が良い」という考え方もあると思います。
そういった場合はCFnやSAM、CDKを利用されるでしょうし、そのトレーニング機会を提供すればよいでしょう。
言いたいのは、AWSのトレーニングだけをエンジニアに受けてもらって満足し、IaCツールのような必要性の高いツールの習得はエンジニアの自己研鑽に頼る、みたいなのはやめましょう、ということです。
改めてきちんと学んでもらった方がよいこと
ツールの使い方だけでなく、クラウドやオンプレ関係なく、昔から行われてきたことであっても、
改めて学び直し、または知識のアップデートをした方がいいなあと感じている事項もあります。
情報セキュリティマネジメント
情報セキュリティ管理の取り組みは、クラウドコンピューティングが登場する前から行われていました。
AWSをはじめとするクラウドプロバイダーも情報セキュリティ管理には多額の投資と努力をしていますし、
責任共有モデルですので、AWS利用者の方々も情報セキュリティの維持には常に関心を持たれていると思います。
近年気になっているのは、AWSが提供するセキュリティ/ガバナンス系の設定をすべて行う＝情報セキュリティ対策完了、ではないですよね？、ということです。
Security HubでCIS AWS Foundations Benchmarkを利用し、適合性チェックで不適合が0件になったとします。
ただし、それはAWSが検知できる範囲で、且つBenchmarkで定義された基準を満たしているだけであり、
情報システム/サービスで取り扱う情報資産の脆弱性がすべてなくなったわけではありません。
サイバーセキュリティの攻撃手法も年々高度化するばかりですので、
その攻撃手法であったり、情報セキュリティマネジメントのすべてをエンジニアが個人で理解することは不可能です。
しかし、情報セキュリティのリスクアセスメント手法である、
- 情報資産の洗い出し
- 脅威の明確化
- 脆弱性の識別
- 対策(管理策)検討
という基本的な取り組みについては、各エンジニアが進め方を理解し、実務で実践できるよう、
トレーニング機会を提供すべきだと思います。
運用
運用を考えない情報システム/サービスはないと思います(と信じたい)。
が、ここでもさきほどのSecurity Hubの例と若干似ているのですが、
CloudWatchやSystems Managerといったサービスの設定だったり、
トイルの削減(自動化)には一生懸命取り組むが、
運用として本当にやるべきことの全体像の明確化や設計が疎かになっていないか？という点は気になっています。
よって、そもそも「運用」とは何か、何をすべきなのかを社内でトレーニングを行ったり、
勉強会を行ったりという取り組みは、非常に重要かと思います。
実は、わたしも今年「運用」について改めて学び直そうと思い、以下の本を読んでみました。
ITIL はじめの一歩 スッキリわかるITILの基本と業務改善のしくみ
対話形式で、身近な題材を元にしたとてもわかりやすい内容で、ITILの概要を理解することができます。
「運用とは、ビジネスそのもの」と痛感させられる内容です。
まず、このあたりから始めてみてはいかがでしょうか。
というわけで
まとまりのない内容になってしまいましたが、
AWS技術者を育てるためには、AWS自体について学んでもらうだけでは不十分で、
周辺ツールであったり、セキュリティや運用といった「きほんのき」も含めて、
学習機会を提供し続けることが重要と考えます。
あと、トレーニングや勉強会で学んだ内容は、やっぱりOJTで実践して身に付くものなので、
そういった「学んだことを実務で活かす機会」を技術者に提供できるかどうかも会社としては大事と思ったり。
とりあえず、私も技術者としては日々勉強、おじさんとしては若い(若くなくても)エンジニアへの学習機会の提供をと、今後もがんばっていきたいと思います！