はじめに

こんばんは、mirukyです。

「配属初日、GitHubのGitコマンドとブランチ運用が、まったく分からなかった。」

これは1年前の私の話です。

git branchって何？ pullとfetchの違いは？ mainにpushしちゃダメなの？——先輩のやり取りを横で見ながら、何一つ理解できない自分に焦りだけが募っていました。

2025年4月に25卒としてエンジニアのキャリアをスタートし、もうすぐ2年目を迎えます。この1年間、AWSとAIに"全振り"して走り続けた結果、AWS認定12冠を達成し、Qiitaに記事を書き、Pythonを学んでAWS Lambdaにデプロイして、少しずつ「できること」を増やしてきました。

この記事を書いているのは、4月から新しい環境に飛び込む26卒の君に、「1年前の自分」が知りたかったことを届けたいからです。AI時代にエンジニアとして配属されることの不安、何から手をつければいいか分からない焦り。その気持ちは、ほんの1年前の私自身です。

いま、AIツールを使っている開発者は全体の76%を超えています（Stack Overflow Developer Survey 2024）。GitHubではPythonがJavaScriptを抜いて最も使われる言語になり、AIプロジェクトは前年比で倍近くに増えました（GitHub Octoverse 2024）。

2026年にキャリアを始める君は、AIが当たり前の世界に最初から飛び込む世代です。これはチャンスでもあり、使い方を間違えれば足をすくわれるリスクでもある。

「先輩」としてではなく、 同じ道を走り始めたばかりの"仲間" として。私が1年間で見つけた「武器」を、実体験を交えてお届けします。

目次

新卒1年目の全記録——走り続けた365日
「ジュニアエンジニア不要論」なんて気にするな
武器① AWS認定資格で"技術の地図"を手に入れる
武器② AIコーディングツールを"正しく"使いこなす
武器③ インフラの視座で"全体を俯瞰"する
武器④ アウトプット駆動学習で"知識を固定"する
武器⑤ 失敗を恐れず、打席に立ち続ける
明日から始める90日ロードマップ

1. 新卒1年目の全記録——走り続けた365日

1-1. 入社前——文系大学生がエンジニアを目指すまで

私は歴史学科卒の、文系大学生中の文系大学生です。大学で情報系の講義は一切受けていません。

ただ、大学2年の頃から就職のためにCSの基礎学習を独学で始めていました。ITパスポートから始めて、基本情報、応用情報と積み上げ、気がつけばネットワークスペシャリストや情報処理安全確保支援士試験にも合格していました。AWS認定もCloud Practitioner（CLF）とSolutions Architect - Associate（SAA）を大学時代に取得し、LPICも3まで取りました。

振り返ると、大学時代の自分は「理論の理解」にひたすら時間を費やしていたんだと思います。でも、実務経験はゼロ。「資格は持ってるけど、現場で何ができるかは分からない」、そんな不安を抱えたまま、社会人になりました。

1-2. 入社〜夏——何もできない自分との戦い

2025年4月、エンジニアとしてのキャリアがスタートしました。

最初に面食らったのが、冒頭に書いたGitとブランチ運用です。大学時代に資格の勉強はしていたけれど、チーム開発の経験はゼロ。git branch、git merge、プルリクエスト、レビュー依頼。言葉は知っていても、手が動かない。「ブランチ切って」と言われて「え、何を……？」と固まった日のことは今でも覚えています。（LPICでは丁度この部分に関する学習しなかったんですよね、、。）

6月頃には、Pythonをガッツリ学び直して、AWS Lambdaにデプロイすることに挑戦しました。 大学時代にPython3エンジニア認定基礎試験は取っていたけれど、実際にコードを書いてクラウド上で動かすのは初めて。Boto3でS3を操作するLambda関数を書き、API Gatewayと繋いで簡単なAPIを作る。たったそれだけのことに何日もかかりましたが、自分の書いたコードがAWSの上で動いた瞬間の感動は、今でも忘れられません。

「資格の知識」が「動くもの」に変わった、あの体験が私のエンジニアとしての原点です。

1-3. 秋〜冬——AWS資格学習の再開と怒涛の12冠

夏場は実務とプログラミングの基礎固めに集中していましたが、10月からAWS資格の学習を再開しました。

ここからの勢いは自分でも信じられないものでした。大学時代のCLF・SAAの学習で培った基礎と、半年間の実務経験が噛み合い始めた感覚があったのです。

11月にSolutions Architect - Professional（SAP）を取得。続けてSecurity Specialty（SCS）、Advanced Networking Specialty（ANS）、Data Engineer Associate（DEA）と、12月までに4つの試験に合格しました。

そして1月。1日に3試験を受ける日もありました。 AI Practitioner（AIF）、Machine Learning Engineer Associate（MLA）、Machine Learning Specialty（MLS）を同日受験。さらに別の日にCloudOps Engineer Associate（COA）とDeveloper Associate（DVA）を同日受験。最後にDevOps Engineer Professional（DOP）を取得して、2026年1月24日、AWS認定12冠を達成しました。（この過程の詳細は「【25卒AWS12冠】新卒1年目が6ヶ月でAWS12冠を達成した話」にまとめています）

大学時代のCLF・SAA取得から数えると約6ヶ月分の学習期間。社会人になってからの集中期間だけで言えば、10月〜1月の約4ヶ月でした。

1-4. そして今——2年目のスタートラインに立つ

全冠取得後、Qiitaへの技術記事投稿も始めました。一番多くいいねをいただいた記事は363いいね（「Claude Codeで行うべきセキュリティ設定 10選」）。自分の中に溜まったナレッジを言語化してまとめることで読者に届くものがある、という実感を得られました。

結構運もありますが、歩みを止めなくてよかったと思っています。

なぜ資格に"全振り"したのか
資格取得は「ゴール」ではなく「地図」です。AWSの全体像が分からない状態だと、目の前のサービスしか見えません。認定試験の学習を通じて200以上のAWSサービスの位置づけを把握することで、「なぜこの構成なのか」が理解できるようになりました。資格それ自体より、学習プロセスで得られる"技術の地図"に価値があります。

2. 「ジュニアエンジニア不要論」なんて気にするな

2-1. AI時代の"空気"

最近、ネット上で「AI時代にジュニアエンジニアは不要になる」という議論を目にすることが増えました。

AIコーディングツールの進化は確かに目覚ましい。GitHub Copilotの利用者は年々増え続け、OSSの開発者の73%がAIツールを使い始めています（GitHub Octoverse 2024）。「AIが書けるのに、なぜ新人を雇う必要があるのか？」——そんな声が上がるのも分かります。

さらに、Anthropicの2026年3月の経済調査レポート「Labor market impacts of AI」では、プログラマーのAI代替可能性が75%と評価されました。22〜25歳がAI影響の大きい職種に就く割合は約14%低下しているというデータもあります。

こういう数字を見ると、正直、不安になりますよね。

2-2. でも、私はこう思う

そんなもの、気にしなくていい。

なぜなら、AIはあくまで「道具」であって、それを使いこなすのは人間だからです。

METR（2025年）のランダム化比較試験では、熟練のOSS開発者がAIツールを使ったにもかかわらず、タスク完了が19%遅くなったという結果が出ています。しかも開発者自身は「20%速くなった」と感じていた。つまり、AIを正しく使いこなすには、基礎力と経験が必要なのです。この研究については「Anthropicの研究が証明してしまった事実、「AIコーディングツールは開発者を退化させている」」でも詳しく考察しています。

出典：METR RCT（arXiv: 2507.09089）

AIが生成したコードをそのまま受け入れるだけの人材は、確かに厳しい時代になるかもしれません。でも、基礎を理解し、AIの出力を検証・改善できる人材は、むしろこれまで以上に求められている。

「ジュニアだからこそ」AIネイティブとして育つチャンスがあります。最初からAIと一緒に学び、AIの限界を体感しながら自分の力を伸ばしていける。これは、AIなしの時代にキャリアを始めた世代にはない強みです。

不要論なんて、走り続けている人間には関係ない。大事なのは、手を止めないことです。

AIの「体感」と「実測」は違う
METR研究の最も重要な教訓は、AIツールの効果は「体感」と「実測」で大きくズレるということです。「速くなった気がする」ではなく、実際に品質や速度を検証する習慣をつけましょう。AIは「銀の弾丸」ではなく、使い方次第で武器にも足かせにもなります。

3. 武器① AWS認定資格で"技術の地図"を手に入れる

3-1. なぜAWS認定が"新人の武器"なのか

新人エンジニアにとってAWS認定資格が効果的な理由は3つあります。

① 技術の全体像が"体系的に"身につく——AWS認定の学習は、ネットワーク・セキュリティ・DB・コンピュート・ストレージを横断的にカバーします。資格1つで「クラウドインフラの地図」が手に入ります

② 学習のペースメーカーになる——「いつか勉強しよう」では永遠に始まりません。試験日を予約すれば、締め切り駆動で確実に学習が進みます

③ 客観的な証明になる——業務経験の浅い新人が「AWSできます」と口で言っても説得力に限界があります。認定バッジは第三者に検証可能な実力証明です

2025年1月時点で、アクティブなAWS認定資格は142万件以上、認定資格を持つ個人は105万人以上です。クラウド市場でAWSは依然として最大のシェアを持ち、この資格の価値は今後も続きます。

出典：AWS認定

3-2. 新人におすすめの取得順序

まずは Cloud Practitioner（CLF） から始めましょう。Foundationalレベルなので2〜3週間あれば十分取得できますし、AWSの全体像を掴む最初の一歩として最適です。

次に目指すべきはSolutions Architect - Associate（SAA）。これが最重要です。設計・構成の基本が身につき、業務に直結する知識が最も多い。学習期間は1〜2ヶ月が目安です。

3番目はAI Practitioner（AIF）。AI/ML/生成AIの基礎をカバーするFoundationalレベルで、2026年のエンジニアには必須の教養です。私は936点で合格しましたが、正直これはAIに興味がある人なら楽しく学べる試験だと思います。

その後は Developer Associate（DVA） でアプリ開発・CI/CDの視点を広げ、 CloudOps Engineer Associate（COA） で運用の知識を固める。この順番が、私の経験から最もバランスが良いと感じています。

その次にSolutions Architect - Professional（SAP）ですね。今思うと、SAPは実務に最も役立った資格でした。頭の中である程度AWSサービスを組み合わせた設計図が描けるようになると思います。

AWS Skill Builderを活用する
AWS公式の学習プラットフォーム「AWS Skill Builder」には無料コースが豊富にあります。特に各認定試験の「Exam Prep」コースは試験範囲を効率よくカバーしており、学習の軸として最適です。AWS Free Tierを使えば、実際のAWS環境でハンズオンも無料で行えます。座学だけでは身につかないので、必ず手を動かしましょう。

3-3. 私が12冠を取ったときに学んだこと

12冠を通じて最も痛感したのは、「試験と試験の間隔を空けないこと」の重要性です。

私は大学時代にCLFとSAAを取った後、約1年間もAWS資格の学習を中断してしまいました。これが唯一の反省点です。社会人になって10月に学習を再開したとき、かなりの知識が抜けていました。

逆に、10月から1月にかけて集中的に受験したら、点と点が線になる感覚がありました。継続して学習・受験することで「AWSのベストプラクティスが身に染みて理解できる」ようになるのです。

教材はUdemy、CloudTech、CloudLicenseの問題集を組み合わせて使っていました。序盤はCloudTechで設計図的な理解を深め、後半はCloudLicenseで本番に近い問題に慣れる。Udemyは最初から最後まで並行して使いました。この 「3本柱のうち2本を使い分ける」 やり方が、私にはうまくハマりました。

もう一つ大事なのは、不合格を恐れないことです。1回落ちたところで何も失いません。むしろ、不合格のスコアレポートが弱点を教えてくれる最高の教材になります。試験日を先に予約して、逆算で学習計画を立てる。「準備ができたら受ける」は永遠に来ません。

4. 武器② AIコーディングツールを"正しく"使いこなす

4-1. 2026年の主要AIコーディングツール

新人エンジニアが今すぐ使えるAIコーディングツールはいくつかあります。

Kiroは、AWSが提供するAI搭載の統合開発環境（IDE）です。最大の特徴はスペック駆動開発——自然言語で要件を伝えると、要件定義・設計・実装タスクを自動生成し、段階的にコードを実装してくれます。無料枠（月50クレジット）でも十分に試せますし、VS Codeとの互換性もあるため移行しやすい。CLIからも使えるので、ターミナル派にもおすすめです。

Claude Codeは、Anthropic製のターミナルベースのコーディングエージェント。複雑な実装やリファクタリング、マルチファイル編集に強いです。従量課金ですが、その実力は折り紙付き。（セキュリティ面が気になる方は「Claude Codeで行うべきセキュリティ設定 10選」も参考にしてください）

GitHub Copilotは、日常的なコーディング支援に最適。インラインでコード補完してくれるので、手に馴染む感覚が早い。学生やOSSコントリビューターなら無料で使えます。

CursorはVS CodeベースのAI統合エディタ。フロントエンド開発や素早いプロトタイピングに向いていて、無料枠もあります。

出典：Kiro

4-2. 新人が陥りやすいAIツールの"アンチパターン"

ここは正直に、自分の反省を込めて書きます。

一番やりがちなのが、「コピペマシン」になることです。AIの出力をそのまま貼り付けて、動くからOK。でも、自分が何を書いたのか理解していない。これを続けると、いざAIなしでコードを書こうとしたとき、何も出てこなくなります。必ず1行ずつ読んで理解してから採用しましょう。

次に 「エラーの丸投げ」 。エラーが出たら即AIに投げる。これも危険です。まず公式ドキュメントで3分だけ自分で調べてからAIに聞く。この3分が、長期的な実力を大きく左右します。

「設計の丸投げ」 も要注意。アーキテクチャ設計はAI任せにせず、自分で考えた上でAIに壁打ち相手になってもらう。AIはレビュアーとしては優秀ですが、プロジェクトの文脈を完全に理解しているわけではありません。

そして 「レビューなしでマージ」 。必ず自分の目でレビューする。これは鉄則です。

4-3. "正しい"AIとの付き合い方

AIコーディングツールを「武器」にするための原則をまとめます。

① 「AIは優秀なジュニアメンバー」と考える——出力は必ずレビューが必要。信頼するが、検証する

② 基礎を先に固める——AIの出力が正しいかどうかを判断するには、自分自身の基礎知識が必要。DNS・TCP/IP・HTTPの仕組み、Linuxの基本操作、Gitのコマンドは、AIに聞く前に自分で理解する

③ AIを「学習のブースター」として使う——分からないコードをAIに「これは何をしているか説明して」と聞くのは非常に効果的。ただし、AIの説明が正しいかを公式ドキュメントで必ず裏取りする

④ Kiroを活用する——スペック駆動開発で要件を明確にしながらコードを生成できるため、「何を作りたいか」を言語化する訓練にもなる。無料枠で十分に試せるので、AWSを使うなら真っ先に導入すべきツールです

METR研究の教訓
METR（2025年）の研究では、熟練のOSS開発者がAIツールを使ったにもかかわらず、タスク完了が19%遅くなりました。原因は、AIの出力の検証・修正にかかるオーバーヘッドです。AIは「銀の弾丸」ではない。特に新人のうちは「AIに頼る割合」を意識的にコントロールし、自力で解ける範囲を少しずつ広げていくことが大切です。

5. 武器③ インフラの視座で"全体を俯瞰"する

5-1. なぜ新人にインフラの知識が重要なのか

アプリケーション開発志望の方も、インフラの基礎知識は必須です。理由は明確で、すべてのコードはインフラの上で動くからです。

デプロイで「動きません」としか言えないのか、ネットワーク・権限・ポートを切り分けて原因を特定できるのか。パフォーマンスが悪いときに「アプリが遅い」で止まるのか、CPU/メモリ/ネットワーク帯域を確認してボトルネックを特定できるのか。セキュリティグループを「全開放」してしまうのか、最小権限の原則に基づいて適切にアクセス制御できるのか。

この差は、インフラの基礎を知っているかどうかだけで決まります。

5-2. 新人が最初に押さえるべきAWSサービス

AWSには200以上のサービスがありますが、最初に押さえるべきはコアサービスです。

コンピュートはEC2とLambda。インスタンスタイプの選び方とサーバーレスの概念を理解すれば、大半のユースケースに対応できます。ストレージはS3とEBS。オブジェクトストレージとブロックストレージの違いを押さえましょう。ネットワークはVPCとRoute 53で、サブネット・セキュリティグループ・DNSの基本を。データベースはRDSとDynamoDBで、RDBとNoSQLの使い分けを。セキュリティはIAM——これは全サービスの基盤です。ユーザー、ロール、ポリシーの仕組みは最優先で理解してください。監視はCloudWatchで、ログ・メトリクス・アラームの設定を。IaCはCloudFormationまたはCDKで、インフラのコード管理を。そしてAI分野ではKiroとBedrockを触ってみましょう。

5-3. ネットワークとセキュリティは"最初に"理解する

1年間インフラに携わってきた実感ですが、ネットワークとセキュリティの基礎は、他のどの知識よりも先に身につけるべきです。

理由は単純で、トラブルの大半がネットワークとセキュリティに起因するから。

VPCのサブネット設計、セキュリティグループのインバウンド/アウトバウンドルール、NATゲートウェイの仕組み、IAMポリシーの評価ロジック。これらを理解しているだけで、トラブルシューティングの速度が圧倒的に変わります。

私は大学時代にネットワークスペシャリストを取得していたことが、業務でかなり活きました。TCP/IPやOSI参照モデルの知識は、クラウドの時代でも不変です。AWS認定とは別に、ネットワークの基礎体力を鍛えておくことを強くおすすめします。

Pythonで手を動かすとインフラが身近になる
私が6月にLambda関数を書いたとき、IAMロールの設定やVPCの接続設定でかなり苦戦しました。でも、その過程で「なぜこの権限が必要なのか」「VPC内のLambdaはなぜNATが必要なのか」が腹落ちした。コードを書いてデプロイすることは、インフラを学ぶ最高のハンズオンです。

6. 武器④ アウトプット駆動学習で"知識を固定"する

6-1. なぜ「書く」ことが最強の学習法なのか

技術記事を書くことの効果を、新人エンジニア目線でまとめます。

まず理解の深化。「分かったつもり」が「書こうとすると書けない」で露呈します。書くことで理解の穴が見つかる。

次に知識の定着。認知科学の研究では、学んだ知識を他者に説明・整理することで理解が深まる効果（プロテジェ効果）が確認されています。記事を書くことは「不特定多数に教える」行為です。

ポートフォリオとしての価値も大きい。技術記事は最強の実力証明。GitHubのコードより、記事の方が採用担当者に伝わりやすいこともあります。

言語化能力も鍛えられます。技術を分かりやすく伝える力は、チーム開発で不可欠。ドキュメント力、レビュー力に直結します。

そしてフィードバック。いいねやコメントで「何が刺さるか」が分かる。読者視点が身につきます。

6-2. "新人だからこそ"書く価値がある理由

「新人の自分が書いても誰も読まないのでは？」——これは完全に誤りです。

新人の視点が最も新人に刺さります。ベテランの記事は前提知識を省略しがちで、初心者にはハードルが高い。でも、新人が書いた「ここでハマった」「これが分からなかった」は、次の新人にとって何よりもありがたい情報です。

「間違いがあったら恥ずかしい」——間違いを指摘してもらえるのが最大の学習機会です。コメントで教えてもらえることもありますし、そのやり取り自体が成長につながります。

「既に同じ記事がある」——2026年の環境で書く意味があります。AWSもAIツールも日々アップデートされています。同じテーマでも、今の時点での体験には固有の価値があります。

「文章が下手」——最初から上手い人はいません。10本書けば確実にうまくなります。私自身、最初の記事と今の記事を見比べると、明らかに成長しています。

6-3. 記事投稿を続けるコツ

① 「自分が困ったこと」をそのまま記事にする——エラーの解決方法、ハマった設定、比較検討の結果。一番書きやすいのは「昨日の自分」に向けた記事

② 完璧を目指さない——「もう少し調べてから」で投稿が遅れるより、80%の完成度で公開して、フィードバックを受けて改善する方が成長が速い

③ シリーズ化する——「AWS CDK #1」「#2」「#3」のようにシリーズ化すると、ネタ切れしにくく、読者も追いやすい

④ 週1本を目標にする——多すぎず少なすぎず。1年で50本書けば、それだけで立派なポートフォリオ

7. 武器⑤ 失敗を恐れず、打席に立ち続ける

7-1. ネットでよく見る"やらかし"と、基礎力で回避できたこと

1年目のエンジニアに多い失敗談として、ネット上でよく話題になるものがあります。

たとえば、検証環境でAWSリソースを消し忘れて、月末に想定外の請求が来るという話。これはSNSやQiitaでも定番のネタですが、私はAWS認定の学習過程でBudgetsの存在を知っていたので、AWSアカウントを作った直後にアラートを設定していました。おかげで、このミスは回避できました。

セキュリティグループの全開放も、新人あるあるとしてよく目にします。しかし、大学時代にネットワークスペシャリストを取得する過程で最小権限の原則が染みついていたので、ポートの設定は最初から慎重に行う習慣がありました。基礎的なネットワーク知識は、こういう場面で確実に効いてきます。

CloudFormationのスタック削除で依存関係を壊すという事例も、インフラ初心者の間でよく共有されています。私はSAPの学習でCloudFormationの依存関係やスタックの挙動を理解していたので、削除前に必ず依存関係を確認する運用を最初から取り入れることができました。

こうして振り返ると、「資格の勉強なんて実務で役に立たない」という声に対して、明確に反論できます。基礎知識は、踏まなくていい地雷を踏まないための防具です。

7-2. 成長は"快適な場所の外"にある

コンフォートゾーン外へ行こう！！

1年目を振り返って確信しているのは、成長は「できないこと」に挑戦した瞬間に起きるということです。

分からないAWSサービスを触ることになったとき。初めてQiitaに記事を投稿するとき。知識が足りないと分かっている資格試験を受けるとき。PythonでLambdaを書いてデプロイしようと決めたとき。

すべて不安でしたが、打席に立たなければヒットは生まれない。

失敗のコストは、思っているより低い
検証環境での失敗は、本番障害を防ぐための投資です。記事の間違いは、コメントで教えてもらえる学習機会です。資格試験の不合格は、弱点を教えてくれる最高のフィードバックです。「失敗するかもしれない」から行動しないことの方が、はるかにコストが高い。

8. 明日から始める90日ロードマップ

君が明日からすぐに行動できるよう、具体的な90日間の計画を提案します。

8-1. 1ヶ月目——環境構築と基礎固め

まずは「開発者としての環境」を整えましょう。個人のAWSアカウントを作成してFree Tierで触り始める。Kiroをインストールして、スペック駆動開発を体験してみる。GitHub Copilot（学生なら無料）を有効化して、日常的にAIツールに触れ始める。

学習面では、AWS Cloud Practitionerの勉強をAWS Skill Builderで開始。Linuxの基本コマンド（ls, cd, grep, chmod, ssh, curl）を毎日使う習慣をつける。そしてGitのコマンド（clone, add, commit, push, pull, branch）を手に馴染ませる。私が一番最初に苦労したポイントだから、ここは強調します。

Qiitaのアカウントを作成して、「自分が困ったこと」を最初の1記事として投稿してみてください。完璧じゃなくていい。

8-2. 2ヶ月目——資格取得と実践

AWS Cloud Practitionerを受験・取得して、次にSolutions Architect - Associateの学習を開始しましょう。

ハンズオンでは、VPC構築やEC2+RDSのWebアプリ構成を自力で組んでみる。Python+Lambdaで簡単なAPIを作ってデプロイしてみるのもおすすめです。私が6月にやった体験は本当に大きかった。Boto3でS3を操作するだけの簡単なものでいいので、「自分のコードがクラウドで動く」感覚を味わってほしい。

Kiroに設計の壁打ちをしてもらう習慣をつけ始めましょう。TCP/IP、DNS、HTTPの基礎もこの時期にしっかり理解しておくと、後が楽になります。

学習内容を2〜3本記事にまとめることも忘れずに。

8-3. 3ヶ月目——応用と習慣化

Solutions Architect - Associateを受験。IaCとしてCloudFormationまたはCDKでインフラをコード化する練習を始める。IAMポリシーやセキュリティグループの設計を実践する。

AIツールの活用も本格化させましょう。Claude CodeやKiroでコードの生成→レビューの流れを確立する。記事投稿は週1本ペースを目標に。シリーズ化も検討してみてください。

3ヶ月間の成長を振り返り、次の目標を設定する。ここまで来れば、確実に景色が変わっているはずです。

完璧にこなす必要はない
このロードマップは「理想」です。業務や個人の事情で、すべてを予定通りに進めるのは難しい。大事なのは**「完璧にやる」ことではなく「続ける」こと**です。週に1時間でも、月に1記事でも、止まらなければ確実に前に進みます。

おわりに

ここまでお読みいただきありがとうございます。

この1年間で私が見つけた5つの武器をまとめます。

① AWS認定資格：技術の地図を手に入れる最速の手段。CLF→SAA→AIF→DVA→COAの順で、業務に直結する知識を体系的に獲得できる。試験と試験の間隔を空けず、継続して学ぶことが最大のコツ

② AIコーディングツール：Kiro・Claude Code・GitHub Copilotを"正しく"使いこなす。AIは優秀なジュニアメンバー。信頼するが、必ず検証する

③ インフラの視座：ネットワーク・セキュリティ・IAMの基礎は、あらゆるトラブルシューティングの土台。全体を俯瞰できると、見える世界が変わる

④ アウトプット駆動学習：記事を書くことで理解が深まり、ポートフォリオになり、言語化能力が鍛えられる。新人だからこそ書く価値がある

⑤ 打席に立ち続ける勇気：失敗のコストは思っているより低い。成長は快適な場所の外にしかない。打席に立たなければヒットは生まれない

1年前、Gitコマンドの前で途方に暮れていた私が、ここまで走ってこられたのは、先輩方の技術記事とコミュニティのおかげです。今度は私が、この記事を次の世代に渡すバトンにしたい。

4月から新しい環境に飛び込む君へ。

不安で当然です。分からなくて当然です。

「AIがあるからジュニアはいらない」？——そんなことはない。AIを使いこなし、基礎を磨き、手を動かし続ける新人エンジニアを、この業界は待っている。

私も、まだ2年目のスタートラインに立ったばかりです。先輩面するつもりはありません。ただ、同じ道を走る仲間として、こう言わせてください。

一緒にがんばりましょう。

ではまた、お会いしましょう。

参考リンク

調査データ

AWS

AIコーディングツール

研究

筆者の関連記事