AWS Top Engineersの応募基準って、パッと見だと直感的に把握するのは難しいですよね。私もスタートからく、くらいてりあ？となりました。なのでこの記事では、内容をできるだけかみ砕いて、何をすればTop Engineersになれるのかというのをより具体化していこうと思います。
そもそもAWS Top Engineersって何？
ご存じない方もいらっしゃるかと思うので、簡単に説明します。まず前提としてAWSパートナー企業に所属していることと、特定の認定資格を取得している必要があります。そのうえで以下の2つどちらかを満たすことでAWSから選出されます。
・会社を超えてパブリックに技術力を発揮した活動を行っている方
・技術力を発揮したその他の重要な活動や成果がある方
応募までの簡単な流れと必要条件
フロー図にしてみたので、まずはこれを見ていただけると掴みやすいです。
応募は毎年２月頃~３月頃にかけて専用の申し込みサイトがオープンするので、そこから下記3点を満たした上で応募します。
①カテゴリーを絞る
応募には8つのカテゴリーが存在しますが、2022年の受賞者のデータだとServicesが110名、それ以外すべて合わせても46名となっているため、基本的にはこのServicesを目指せばよいかと思います。この記事でもServicesを目指すていで書いていきます。
※注意点 自分の会社がパートナー条件を満たさないとカテゴリー選択できない場合があるようです。大きめのパートナー企業なら基本的に問題なさそうですが、なりたてのパートナー企業様などは注意する必要がありそうです。不明な場合は会社に確認しましょう。
②AWS認定資格を取得する（しておく）
カテゴリがServicesの場合以下の2つを取得しておく必要があります。要領さえ掴めば決して難しくはないので、２つ合わせて１か月もあれば取得可能です。
・AWS Certified Solutions Architect – Professional
・AWS Certified DevOps Engineer – Professional
資格の取得方法に関しては以下でも記事を書いておりますので参考にしてください。
③AWS関連の活動内容を提示する
ここが一番重要であり、Top Engineersになれるかなれないかのポイントです。下記の公式サイトから抜粋した７つのカテゴリーから最低２つのカテゴリの内容を提示します。また２つのうち１つは パブリックな活動（社外向け） である必要があります。加点式のため提示できるカテゴリの数は多いほうがよいですが、カテゴリ内で求められるのは量ではなく質であるとのことです。
| 活動カテゴリー | 提出する内容 | パブリックなものになりえるか | 提示のしやすさ（3段階） |
|---|---|---|---|
| ブログ | ブログの件数, ブログ URL, ブログの内容は Level 200 以上である事が条件 | 〇 | ★★★ |
| ホワイトペーパー / 書籍リリース | リリースの件数, リリースが確認できる URL (ご自身が関わられている事が確認できる部分も含む), 対象のリリースは Level 200 以上である事が条件 | 〇 | ★ |
| 外部登壇 | パブリック登壇の件数, 登壇が確認できる URL, 対象の登壇の内容として Level 200 以上である事が条件 | 〇 | ★★ |
| 案件対応 (公開事例含む) | 案件の属性 (公開事例 or 非公開), 案件概要の説明, ご自身が対応された内容で特筆すべき技術的複雑性 / 工夫ポイント / 他アピールできる部分の説明 | △(公開事例なら？) | ★★ |
| ソリューション公開 | ソリューション公開の件数, ソリューション公開が確認できる URL, ソリューションの説明, ご自身が関わられた内容の説明 | 〇 | ★★ |
| Well-Architected レビュー | レビューの件数, レビュー実施時の ARN, ハイリスク改善対応内容の説明 | × | ★ |
| 技術リードとしての活動 | 社内エンジニア育成活動 / 社内登壇 / その他アピールできる活動内容 (MSP / Competency / SDP / SRP / FTR の対応や社内 AWS サポート対応等) の説明 | 〇 | ★★ |
Level200...?ほわいとぺーぱー...?うぇるあーきてくてぃど...?っとなってる人が私には見えたのでこの③の項目はかみ砕いて次の項目で詳しく説明します。
7つの活動内容では具体的に何をすればよいのか
7つの活動の詳細
ブログ（狙いやすさ：★★★）
ひっかかるのはLevel 200というところだと思います。これは 「トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル。」 と公式サイトに記載されています。逆にLevel 100では 「AWS サービスの概要を解説するレベル。」 です。つまり効果的な使用例と実際の動作 を解説できているかというのがポイントになるかと思います。イメージしにくい方もいると思うので例を考えてみました。
Lv200に到達できている：あるサービスを運用していますが、XXXような問題があります。その問題の解決策としてAWS XXXを導入して改善を図りました。実際に設定した内容はXXXです。結果XXXような改善をすることができ、さらにXXXのような利益を生むことができました。
Lv200に到達できていない：新サービスとしてAWS XXXがリリースされました。XXXはOOOのようなサービスです。XXXはOOOのような環境であれば生かすことができそうですね。XXXのような環境を運用している人はぜひ導入を検討してみましょう。
こんな感じでしょうか？要するに単なる解説ではなく、具体的な使用例をイメージして導入してみるって感じでしょう。ハンズオンを組み込めばいいのか？と言わればそういう話でもなさそうです。わかりやすそうなところだと、自分が携わってる仕事で新しい試みとしてAWSのサービスを導入するってのがよさそうですね。
ホワイトペーパー / 書籍リリース（狙いやすさ：★）
ホワイトペーパーはAWSとAWSコミュニティによって作成されたオフィシャル的な技術情報のことです。書籍はまだしもこれに介入するのはなかなか難易度が高そうです。
外部登壇（狙いやすさ：★★）
社外のコミュニティで実際にパワポなどを使いながらプレゼンすることです。これは機会を探す必要があります。jaws-ugあたりが有名ですが、他にもいろいろあるようです。jawsは初心者支部などもあるようなので、まずはそういうところから入っていくのがよいかもしれません。
案件対応（狙いやすさ：★★）
これは実際に自分があたっている業務でやったことですね。項目に特筆すべき技術的複雑性とあるので、より高度な内容であるほど得点も高くなるのではないかと思われます。つまり自分がやっている仕事の難易度が高ければ高いほどこのカテゴリでは点数を狙いやすくなりそうです。また、案件の注目度も高いほうがよさそうです。あとは事例の公開非公開ですが、AWSにどちらのほうがメリットがあるかと考えれば公開されてるものの方がよいでしょう。
ソリューション公開（狙いやすさ：★★）
案件との違いが少しわかりにくいかもしれませんが、案件はCier、ソリューション公開は自社でサービス持ってる企業というイメージでよいかと思います。つまり、AWSのサービスをどのように活用して該当のサービスを提供しているのかというところになります。また、自社に向けたサービスも公開すれば、該当するのはこちらのソリューションになるかと思います。
Well-Architected レビュー（狙いやすさ：★）
案件やソリューションに対してWell-Architectedに沿ってレビューをした場合に記載できる項目になります。社内外問う記述はないので、社内でもいけるかもしれません。(そもそも概念として社内でのレビューが認められていれば) 件数プレス以下２点が提出の内容になります。
・レビュー実施時のARN：ARNはサービスを一意なものとして特定できる情報です。
・ハイリスク改善対応内容の説明：高いリスクがあるものに対してどのような改善対応を提案、実施したかという内容になるかと思います。
技術リードとしての活動（狙いやすさ：★★）
社内での技術リードとしての活動を提出します。その他アピールできる活動内容の用語だけそれぞれまとめておきます。
・社内エンジニア育成活動：どのような相手にどのような内容で育成し、どのような実績をつむことができたか的な内容を記載すればよいのではないかと思います。ここも自分がそれなりの立場であればハードルは高くないでしょう。
・社内登壇：外部登壇の社内バージョンです。こっちは外部より大きくハードルが下がるかと思います。
■その他アピールできる活動内容
いろいろな略語が記載されていますが、これすべてパートナー企業が認定される内容のようです。各プログラムの認定の過程までに対してどのような貢献をしたかが、問われるのだと思います。個人レベルではどうこうしにくいカテゴリでもあるのでここでは割愛します。最後の社内AWSサポートはおそらく社内で内部的に解決できる仕組みを設けてそこでの実績が問われるものでしょう。
７つの活動に対する戦略
まず前提としてこのTop Engineersですが、それなりに難易度が高めだと思います。というのもTwitterで落ちた報告を多数みかけたからです。認定資格の落ちた報告をあまりみないことを考えればおそらく正しい情報だと考えてよいでしょう。つまり、よほど恵まれたAWS案件やソリューションに携われているか、高レベルのアウトプットができている人でないとなれることはできないでしょう。
どう狙っていくかを順位付けしてみました。上から順にそって考えていけばよいと思います。
①案件とソリューション
自分がそれなりのお仕事に携われていれば、それだけで優位です。この利を生かして②や③に軽く派生させていけばよいかと思います。
②ブログ、外部登壇
外部登壇は勇気がいりますが、自分の行動次第でどうにかなるカテゴリです。①がクリアできない人はここに全身全霊をかけることになりそうです。
③ 技術リードとしての活動
社内でも動きをみせておくとよいでしょう。自分から能動的に動いてもいいですし、機会を常にうかがってみつけたらGOする感じですね。登壇と似てるかもしれません。
④ 書籍、ホワイトペーパー、Well-Architectedレビュー
ここはちょっと難しいかもです。機会があればということろでしょう。
まとめ
最後にポイントを３つに絞ってまとめます。
・AWS Top Engineersとはパートナー企業に所属している人で特定条件を満たしたうえで応募するとなることができる制度である。
・応募にはパートナー企業であること、特定資格を取得していること、7つある活動内容から2つ以上を満たすことが必要である。
・高度なAWSのお仕事に携われているならそこに全身全霊。携われてないなら自分で考えて、高度な案件やソリューションに匹敵するアウトプットが必要である。
以上です。個人的には目標にもなるし、それと同時にスキルものばせるのでとてもいい制度だなと思いました。せっかくパートナー企業に所属してるなら目指してみても良いのではないでしょうか。2023年もがんばりましょう✨
Discussion