40代エンジニアがAWS認定資格を取って、その先に何があったか

こんにちは。Kaneyasuです。

今回は資格とキャリアのお話で、私がAWS認定資格を取得した後に見たものを書いていきます。

# 前提条件

- 筆者はSIerです。
- 筆者の年齢は40代で、エンジニアとしてのキャリアは20年以上になります。
- 筆者は元々はアプリケーションエンジニアで、インフラ・ネットワークまわりの知識はムラがありました。
- 転職またいでいますが、当時も現在もAWSパートナー企業に属していたので、元からAWS認定を取得するの意味がある環境でした。

# そもそも資格を取得する目的とは

私が思うにエンジニアが資格を取得する目的は以下のようなものがあると思います。  
下記以外にも、目の前の実務をこなすために必要な知識を得るという目的もあるかもしれませんが、経験上そのような知識が得られる資格は稀なので、本記事では除外します。

- その技術についての知識を深める
- ★ムラのある知識を補完する
- ★未経験の技術に触れる
- ★他のエンジニアとの共通言語を持つ
- ★やりたいことをアピールする

私がAWS認定資格を取得した時は、★印を付けた理由を主な動機としていました。  
付け焼き刃の知識を補完しつつ、未経験の技術に触れることで、他のレイヤーのエンジニアとの共通言語を持つことを求めていました。

# 私のAWS認定の勉強方法

私のAWS認定の勉強方法はこちらのスライドにまとめています。

https://speakerdeck.com/satoshi256kbyte/awsren-ding-zi-ge-woshou-yan-suruniatari-qi-tuitakotoshi-jian-siteitakotonomatome

かいつまんで書くと、以下の通りです。

- AWS認定試験の勉強を始めた当時は、AWS関連の仕事だけをしていたわけではなかったので、頭の切り替えができなくなり、業務や家事に支障が出るのを避けるため、隙間時間は活用しなかった。
- 隙間時間の勉強は合わないと判断し、早めに業務や家事を終わらせ、一定以上のまとまった時間を確保することを心掛けていました。
- やる気が削がれるのを防ぐため、問題は5問・10問単位で解いていました。
- いきなり問題を解く。その後教科書と問題を行き来する。画面を触るのは最後としていました。。
    - 理由は、学習だけに着目すると、問題と回答が一番情報が整理されており、逆に画面は何かをなすのに画面を行き来する必要があり最も整理されていないためです。

# ベテランエンジニアに求められる能力

少し視点を変えさせていただきます。  
前提条件で述べたように、私は40代のエンジニアです。  
私なりにベテランエンジニアに求められる能力を以下にまとめてみました。

- 専門性
- 教育力
- 営業力
- 調整力

私がこれらを揃えているかはさておき、解説していきます。

## 専門性

自分が得意とする技術があり、それに関する知識やスキルを持っていることが求められます。  
ある分野において、この人に任せれば大丈夫と思われるようなエンジニアであることは、市場において重要な要素です。

## 教育力

ここで私が書いている教育力とは、自分の知識を他者に伝える力と、相手の言うことを理解し、適切なアドバイスを行う力を指します。  
ベテランエンジニアは、教科書的な知識＋自分の経験を交えた実践的な知識をミックスしたアドバイスを求められます。  
片方だけでは、相手に響かないことがあります。  
また、知識が不足するとそもそも相談を受ける機会が減ってしまいます。

## 営業力

ここで私が書いている営業力とは、一般的な営業のスキルではなく、プリセールスと呼ばれる工程を遂行する能力を指します。  
プリセールスは、一般的には営業の方が持ってきてくれた話（リード）を技術的に実現可能なものに落とし込み、受注につなげる工程を指します。

![プロジェクトが開始するまでの工程と担当](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/08225da0-02a6-bcb1-496e-475a967ea1f0.png)

プリセールスで行う作業は、以下のようなものがあります。  
これらを営業の方と連携しながら進めていきます。

- 顧客の要件をヒアリングし、技術的な解決策を模索する
- 提案書を作成し、提案内容を顧客に説明する
- 技術的な裏付けを取りつつ、見積を作成する
- 見積内容を顧客に説明し、受注につなげる

この中で、ヒアリングから提案書作成においては、顧客の要件に対して技術的な想像ができるかが重要です。  
解決策がまったく見えないと、プリセールスは成立しません。  
経験があるかどうかはさておき、たくさんの例とその技術的根拠を語れるかが勝負を分けると思います。

## 調整力

マネジメント力ではなく、あえて調整力としました。  
ベテランエンジニアになると、自分自身の作業に集中するだけでなく、社内外の関係者との調整を行うことが求められます。  
特に、アプリケーションエンジニアとインフラエンジニア、フロントエンドエンジニアとバックエンドエンジニアなど、異なるレイヤーのエンジニアとの調整は重要です。  
ここで、技術的な共通言語を持てていないと、正しくスコープを決めることが難しくなります。  
相手のレイヤーの知識を一定以上持っていないと、相手の求めているものを理解できない、自分たちが求めるものが相手に伝わらない、といった問題が発生します。

![スコープを決めるための境目の会話](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/19a75f3d-4a27-c959-4601-d5e5f5aedd65.png)

# AWS認定資格を取得して得られたもの

AWS認定資格の話に戻します。  
本記事はAWS認定後の話がテーマなので、私が最初にAWS認定資格を揃えた2022年から2023年をベースに話を進めます。  
その頃のAWS認定資格は下記12種類です。

- AWS Certified Cloud Practitioner
- AWS Certified Solutions Architect – Associate
- AWS Certified SysOps Administrator – Associate
- AWS Certified Developer – Associate
- AWS Certified Solutions Architect – Professional
- AWS Certified DevOps Engineer – Professional
- AWS Certified Security – Specialty
- AWS Certified Database – Specialty
- AWS Certified Machine Learning – Specialty
- AWS Certified Advanced Networking – Specialty
- AWS Certified Data Analytics – Specialty
- AWS Certified SAP on AWS – Specialty

[参考: 2024 Japan AWS All Certifications Engineers クライテリアのお知らせ](https://aws.amazon.com/jp/blogs/psa/2024-japan-aws-all-certifications-engineers-criteria/)

私がこれらの資格の勉強と受験を経て得たものは以下の表にまとめました。

| 資格名                                | 得られたもの                                   |
|---------------------------------------|-----------------------------------------------|
| AWS Certified Solutions Architect – Professional | 幅広い知識、ムラのある知識の補完、他のエンジニアとの共通言語 |
| AWS Certified DevOps Engineer – Professional    | 幅広い知識、ムラのある知識の補完、他のエンジニアとの共通言語 |
| AWS Certified Security – Specialty             | ムラのある知識の補完、他のエンジニアとの共通言語 |
| AWS Certified Database – Specialty             | 専門分野の更なる知識                         |
| AWS Certified Machine Learning – Specialty      | 未経験の技術                                 |
| AWS Certified Advanced Networking – Specialty   | ムラのある知識の補完、他のエンジニアとの共通言語、未経験の技術 |
| AWS Certified Data Analytics – Specialty        | 未経験の技術                                 |
| AWS Certified SAP on AWS – Specialty            | 未経験の技術                                 |

## 「未経験の技術」に分類した資格を取得して得られたもの

以下の資格がこれに該当します。

- AWS Certified Machine Learning – Specialty
- AWS Certified Data Analytics – Specialty
- AWS Certified SAP on AWS – Specialty
- AWS Certified Advanced Networking – Specialty

AWS Certified SAP on AWS – Specialtyについては、現在はなくなってしまった資格ですが、この資格に求められる知識は、SAPそのものだけでなくオンプレミスからAWSへの移行に関する知識も含まれていました。  
改めて移行というプロジェクトが大変なものであることを感じたのと、これだけで一定のビジネスが成立するということを学びました。  

AWS Certified Data Analytics – SpecialtyとAWS Certified Machine Learning – Specialtyも、機械学習・データ分析・データ分析基盤、それぞれがとても深い分野であると感じつつ、データ分析基盤だけを売りにした製品が存在することに気付きました。  
Specialty系の資格は、その分野だけでビジネスが成り立つことを示していると感じ、自分が生きてきたアプリケーションプログラミング以外でも生きる道があることを知り、視野が広がった感覚を覚えています。

実際に、資格を取ったことで、今までは未経験の分野の案件をやらせてもらったことがあります。  
なお、未経験とはいえまったくの畑違いではなく、少しずつ広げていった感じであることは補足しておきます。  
（陣地は少しずつ広げないと痛い目を見ます……）

例えば以下のようなステップで進んできました。
1. アプリケーションエンジニアとして、サーバーの構築案件に携わる。
2. ファイルサーバー構築案件を経験。
3. その後、自動化案件を担当し、徐々にインフラの領域に入っていく。

未経験の分野の案件は正直なところ苦労が多く実りも少ないですが、仕事の幅が広がることは個人的にも組織的にもプラスになると信じています。  
また、こういった苦労はアドバイスをする際の説得力にもなると思います。
・・・そういうことにしましょう。

## 「幅広い知識」、「ムラのある知識の補完」、「他のエンジニアとの共通言語」に分類した資格を取得して得られたもの

以下の資格がこれに該当します。

- AWS Certified Solutions Architect – Professional
- AWS Certified DevOps Engineer – Professional
- AWS Certified Security – Specialty
- AWS Certified Advanced Networking – Specialty

プリセールス活動のヒアリングと提案初期においては、顧客の要件に対してなんらかのアイデアが出せることが重要です。  
これらの資格を勉強することで、少なくともAWSを用いたシステム構築のパターンを多数知ることができたと感じており、それは私の活動において大きな武器になっています。

アイデアを提案書に落とし込んだり、実際にプロジェクトを進める際には、調べたり質問したり調整したりして進めます。  
この時自分の領域外だとしても、相手との対話のために一定の知識が必要なシーンは多々あります。

エンジニアに求められるコミュニケーション能力は「ウェーイ」といった軽いものではありません。  
技術に関する知識をベースとした、相手への理解を示し、相手の理解を得ることが重要です。  
AWS認定を経て得た知識は、技術的なコミュニケーションを円滑にするためのベースとなっていると感じています。

# 自身の経験とAWS認定資格の知識をミックスする

顧客から、オンプレミスで稼働しているWebシステムがあり、拡張性が問題でビジネスがこれ以上展開できないのでクラウド化したいという相談を受けたとします。  
開発は既存のエンジニアが引き続き行うという前提で、期限もあります。  
あなたならどのような提案をしますか？

教科書通りなら、まずはサーバーをそのままAmazon EC2に移行するでしょうか？  
思いっきりモダンにしてサーバーレスにするのも一つの手です。

私は、まずはApplication Load Balancer＋Amazon EC2＋Amazon RDS、次点でAWS App Runner＋Amazon RDSといった構成が落とし所のような気がします。

教科書通りのまずはサーバーをそのままAmazon EC2に移行する案はなしにしましょう。
なぜなら、単純なAmazon EC2への移行をSIerに期待しているとは思えないからです。

サーバーレスは確かに魅力的で、既存のエンジニアも乗り気になるでしょうが、果たしてやり切れるでしょうか？  
提案内容としては課題を解決しつつ、期限を守り顧客のビジネスを成立させることが求められます。

サーバーレスはアプリケーションの作り方が変わります。  
経験上、既存のエンジニアにインフラとアプリ両方で大きな変化を強いると、生産性が大きく落ちると感じています。  
また、エンジニアに作り直したいかと質問すれば作り直したいと回答が来るかもしれませんが、既存の資産を無意味に捨てるのは得策ではありません。  
既存のシステムは、これまでビジネスを支えた実績があり、信頼のあるコードが多いはずです。  
拡張性＝負荷分散とスケーリングができるように、データベースの外出し、セッションも外出しという感じで、まずはApplication Load Balancer、Amazon EC2、Amazon RDSが当面の目標になると思います。
セッションの外出しについては実装次第ではリスクを伴う可能性がありますが、ぜひやっておきたいところです。
これを成してApplication Load Balancerを導入しておけば、エンドポイントがApplication Load Balancerに移るので、そこから先の分割やリファクタリングがし易くなります。

![現実的な提案内容を考える](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1959433/3a9f3385-d209-68ae-84be-47466c5e84f9.png)

はっきり言って構成自体は無難中の無難な構成ですが、一応の筋は通っていると思います。
一応他の案として、コンテナ技術に意欲があるならば、AWS App RunnerやAmazon ECSも視野に入りますが、各ステークホルダーとしっかり調整が必要そうです。
伴走もありなら可能性はありますね。

2つぐらいの構成案を提案書にまとめるのが良い気がします。
サーバーレス化は現実味がないので最初からカットでよいでしょう。

# まとめ

40代エンジニアがAWS認定資格を取得したところ、ベテランエンジニアに求められる能力の、特に営業力・調整力を補完することができたと感じています。  
エンジニアとして営業・調整活動を行う際は、AWS認定のような教科書的な知識と経験をミックスしたアドバイスが求められることが多いです。  
ご自身がこれまで得た経験をさらに活かすためにも、AWS認定をはじめとした資格を取得することは十分に検討する価値があると思います。