AI時代に成長するエンジニアに必要なスキルとは.pdf

1. AI時代に成長するエンジニアに必要なスキルとは 技育CAMPアカデミア 株式会社スリーシェイク 山田悠之介 2026/2/4 Copyright © 3-shake, Inc. All Rights Reserved.
2. 自己紹介 • 山田悠之介 • 21卒（社会人5年目） • 株式会社スリーシェイク • フルスタックエンジニア ◦ Google Cloudを中心にWebアプリ開発、 生成AI導入の支援 • 筋トレ、キャンプ、ボルダリング 2
3. 私とAIのこれまで 3 2022年 2023年 2024年 2025年 2021年 toB SaaS企業に 新卒入社。 1年目冬から フロントエンドの テックリードに。 スリーシェイクに 入社。インフラ、 生成AI、ML、PL なども担当。 Google Cloud Partner Top Engineer受賞 開発だけでなく 運用にも携わり 始める GitHub Copilot 登場 （タブ補完のみ） ChatGPT登場 GitHub Copilot chat登場 『CLINEに全部賭けろ』 Claude Code登場
4. 目次 1. 生成AI前後でエンジニアの仕事はどう変わったか 2. AIに譲るべきスキルたち 3. 新しく求められるスキルとは 4. 変わらないもの 5. もし今、私が新卒エンジニアだったら 4
5. 注意！ • 本発表の内容を「1年目から」「全員が」「完璧に」できてほしいわけではありません ◦ 私自身何年もかけています ◦ 「私なりの正解」であって、全ての人に求めているわけでもありません • もしレベルが高いなと思ってもプレッシャーを感じる必要はありません 5
6. 生成AI前後でエンジニアの仕事はどう変わったか 01 Copyright © 3-shake, Inc. All Rights Reserved.
7. 生成AI以前の業務のワンシーン • アプリでバグが見つかる ◦ ライブラリの挙動が原因のようだが... • ググってみる ◦ 分からない • ライブラリのドキュメントを見てみる ◦ 分からない • ライブラリのIssueを検索 ◦ 分からない • 最終手段。腹を括ってライブラリの実装を読む。 ◦ 該当箇所を発見。 • 対応方法を検討し、修正。レビューで説明。 ◦ ここまで数日かかった 7
8. 生成AI以後の業務のワンシーン • ある定例 ◦ お客様「ライブラリの機能がよく分からなくて...」 ◦ 私「調べますね！」 • ライブラリをクローンして生成AIに調べさせる ◦ それっぽい箇所が見つかる • 本当にそれが原因なのか確認 • 文面をAIに考えさせてメッセージ送信 ◦ ここまで1時間 8
9. 生成AI以前の開発業務の全体 9 POにヒアリングして要件を決定 要件定義 既存実装を確認しながら 設計、タスク分解、見積もり 設計 何回もググりながら機能を実装 セルフレビュー 実装 PR出してレビューしてもらう 場合によっては何往復もする レビュー これらを全て人の手で行っていた
10. 生成AI以後の開発業務の全体 10 POにヒアリングして要件を決定 （POはAIと壁打ち済み） 要件定義 AIに既存実装を調べさせ、 AIと相談しながら設計 タスク分解と見積もりもAIにさせる 設計 AIに8割書かせて最後は自分で完成 調べ物があればAIにやらせる セルフレビューもAIにやらせる 実装 AIによるレビューが完了したら 人のレビュー レビュー 全ての工程でAIを利用
11. AIに譲るべきスキルたち 02 Copyright © 3-shake, Inc. All Rights Reserved.
12. 1つ1つの技術の詳細を知っている • ライブラリ、言語、サービスについて大抵のことはAIに聞けば分かるようになってしまった • それによって1つ1つの技術について事前に詳細に知っていることの価値は減少 • 特に実装が公開されている場合はコードをAIに読ませればかなり正確 ◦ 実装が公開されていない = 動かさないと分からない場合はAIだけでは完結しない ◦ 実装が公開されていても、AIの出力の精査は必要 • すぐ引き出せる場所に知識を持っておくと高評価ではある ◦ お客様「〇〇を実現したいんですが。」 ▪ 「次回までに調べて提案しますね。」でも問題ないのでまずはこれを目指す ▪ 「××を使えばできそうですね。次回詳細を提案させてください。」 ができると信頼度UP 12
13. 一部のコーディング • どう実装しても問題ないようなコードを書くのはAIの仕事になった ◦ ボイラープレート、テストコード、多言語対応などなど • 仕様に直結する部分については、あまり楽になっていない ◦ 自然言語で細かく指示する or 自分で書く ◦ 重要度の密度は上がっている • 人力のコーディングスキルは引き続き必要ではあるが、ウェイトは確実に減った 13
14. 検索する • 「ググり力」は過去のものに ◦ 大量の情報を処理する能力はAIの専売特許 • ただし「どこを探すと良いか」は まだ知っておいた方が良いかも ◦ 例えばライブラリの挙動であれば ネットの記事だけでなくドキュメントや イシュー、実装も見させる、とか • 裏取りの重要性は増えた 14
15. 新しく求められるスキルとは 03 Copyright © 3-shake, Inc. All Rights Reserved.
16. AIを使いこなす 16 調査、設計、実装、 テスト、レビュー 要約、解説、体系化、 学習コンテンツ作成 ブログ執筆、登壇資料作成 メッセージを考えさせる、 立ち回りのアドバイスをもらう 開発 インプット アウトプット ソフトスキル
17. フルスタックになる • おさらい：1つ1つの技術について 事前に詳細に知っていることの価値は減少 • 技術領域で提供する価値の総量を維持するためには、 複数の領域で貢献することが求められる ◦ FEだけ→BEもやる、 アプリだけ→インフラやMLもやる ◦ = フルスタック化 • 学習コストも下がっているので積極的に越境しよう • ミドルやシニアではさらに上流も同時に担当し、 フルサイクル化することが求められる 17
18. 変化の早さに食らいついていく • VUCAと言われるようになって久しいが、変化速度は加速し続けている ◦ たぶん2010年代前半のフロントエンドの変化よりも、 ここ2、3年のAIの変化の方がやばい • これについていくための覚悟と体力が必要 • ただしここは若手の方が有利 ◦ 新しい領域のスタートラインは全員同じ ◦ ベテランは体力がなかったり、すでに知っている領域の維持も必要 18
19. 変わらないもの 04 Copyright © 3-shake, Inc. All Rights Reserved.
20. コードを読む • コードを書くウェイトは減少したが、 コードを読む重要度は増している • AIにコードを書かせた時 ◦ そのままPRにすることはできない ◦ 完成させるためにはまず読まなければいけない • AIにコードを調査させた時 ◦ 本当にそれが答えになっているか 確認しなくてはいけない • もっと一般的に言えば、AIのアウトプットを検証する必要がある ◦ エンジニアはその一部としてコードを読める必要がある 20
21. 結果にコミットする • 社会人として評価されるのは過程ではなく結果 • AIを使ったかどうかはどうでもよく、プロとしての質とスピードを出せているか ◦ 「AIを使って1時間で完了、ただし低クオリティ」 「AIがそう言っていました」 ▪ これらはマイナス評価でしかない • 一方で「AIなし」は大きなハンデになる。AIを使いこなし、成果に責任を持つこと。 ◦ 高いクオリティ。説明できること。何かあった時に最後まで面倒を見ること。 21
22. 対人コミュニケーション • 前提として第一の足切りはハードスキル（AI力含め）ではある ◦ しかしここはAIによる補助で差がつきづらくなる • 第二の足切りはソフトスキル（コミュ力など） ◦ 開発をAIに任せると、人間には人間同士のやりとりが残る i. ビジネス↔技術の橋渡し、調整、合意など ◦ 1年目では普通ここまでは求められないが、 その一歩として例えば「素直」な人が選ばれる • プロとして結果を出すことにコミットすると決めたらなら、順応しましょう 22
23. 具体化と抽象化 • 具体はわかりやすいが応用が効かない • 具体↔抽象の往復、抽象的なまま考えられる思考が重要 • 業務で得られた具体的な経験を抽象化し、 自分なりの「正解」を見つける。 それを具体に適用し、行動を改善する。 ◦ 例えばレビューでの指摘を分類してみて、 こう言う場合はこう書くを見つける • 「良い抽象化」のためには具体の質と量も重要！ 23 抽象 具体
24. 傾向を掴み、対策する • ぶっちゃけ大抵のことは「傾向と対策」 ◦ どういう設計が良いのか、 どういうコードが良いのか、資格取得、 コミュニケーション、立ち回り • 分からないことは人かAIに聞けばよいし、 それを抽象化して自分のものにして、 具体的な行動を改善していくのは、今後も必要な考え方 ◦ 定期的に振り返りをしよう 24
25. 余談：スキルの抽象度と賞味期限 • スキルには賞味期限がある ◦ 特定の技術についてのスキルはすぐに不要に（賞味期限が短い） ◦ 特定の技術に限らないスキルは長持ち（賞味期限が長い） • ここまでの話で「不要になったスキル」と「新たに求められるスキル」は 具体的な技術の話が多く、賞味期限も短い ◦ AIも！ • 逆に「変わらず求められるスキル」は抽象的なスキルで賞味期限が長い • 「抽象的なスキルほど賞味期限が長く、具体的なスキルほど賞味期限が短い」は AI以前から存在する普遍性の高い法則 25
26. もし今、私が新卒エンジニアだったら 05 Copyright © 3-shake, Inc. All Rights Reserved.
27. 徹底的にAIと壁打ちする • どういうコードが良いのか、 どういう設計が良いのか、 どういう文面のメッセージが良いのか、 誰に最初に話を通すと良いのか • AIの言う通りにする必要は全くないが、 AIへの相談はノーコストなのでガンガンやれば良い 27
28. AIについて発信する • おすすめな理由 ◦ 新しい領域は若手に有利で「第一人者」になりやすい ◦ ベテランも当然インプットしているが、個人では全てを追いきれない • チーム内、社内、社外でAIについて発信することで、新人でも組織や業界に貢献できる • 変化が早いのでネタもどんどん出てくる 28
29. AIを育てる • CLAUDE.mdなどを育てるのも若手の方が有利 ◦ ベテランは感覚レベルに落とし込まれたことが多すぎて、全てを言語化できない ◦ 若手であれば自分の学びをCLAUDE.mdなどにまとめていくことで、 自身の成長とAIの成長がリンクする 29
30. 人とコミュニケーションを取る • ソフトスキルの第一歩としてコミュニケーションを取ろう 30 世間話をする、 雑談チャンネル、 社内部活動、 ランチ、飲み会 挨拶する、出社する、 分報チャンネル 報連相、 会議で発言する、 方向性の確認 接触回数を増やす 相互理解を深める 信頼を積む
31. 大量にインプットする • AIがまとめてくれる時代になったが、自分でインプットすることが重要 ◦ 他者に与えられた情報では理解はできても実感は伴わない = 自分のものにならない ◦ バイアスもかかっている • 枯れた技術は本、流行りの技術はZennのトレンドなど • 類似で「実際に経験すること」も重要 31
32. 領域を限定しない • AIによって特定領域の価値と越境のコストは減少 ◦ 成長し続けるためには領域を 増やしていく必要がある ◦ 対偶として、領域を限定した瞬間に 停滞が始まる（赤の女王仮説） • 与えられた役割に閉じるのはやめよう ◦ 「FEだから（BEはやらない）」 「開発だから（運用は知らない）」 「エンジニアだから（上流は興味ない）」 は終わりの始まり 32
33. 最後に • これらを全て完璧にやる必要はありません • 私も全部完璧にはできていません • でもこれらを意識していれば成長できる（はず） 33
34. 簡単に会社紹介をさせて下さい󰢛 Copyright © 3-shake, Inc. All Rights Reserved.
35. Copyright © 3-shake, Inc. All Rights Reserved. 会社名 株式会社スリーシェイク 設立日 2015/1/15 代表者 代表取締役社長　吉田 拓真 所在地 東京都中央区銀座8丁目21番1号 住友不動産汐留浜離宮ビル 7F　 Mission インフラをシンプルにしてイノベーションが起こりやすい世界を作る Vision 労苦〈Toil〉を無くすサービスを適正な価格で提供し続ける Value エンジニアリングレイヤーに横たわる人、手法、ツールがサイロ化されて労 苦が発生しているプロセスをシンプルにしサービス機能開発に集中できるソ リューション（SRE、DevSecOps、DataOps、HROps）を提供する 会社概要 MVV SRE/DevOps SecOps BizOps HR ・SRE総合支援からセキュリティ 　対策を全方位支援 ・Geminiを用いた生成AIの活用支援 ・ワンストップで脆弱性診断を行う　 セキュリティ対策SaaS ・クラウド型ETL/データパイプ 　ラインSaaSの決定版 ・あらゆるSaaSをノーコードで連携 ・ハイスキルフリーランス 　エンジニア紹介エージェント IT内製化 / 高度化 クラウドネイティブ化 モダナイゼーション ITアジリティ向上
36. GenAI基盤構築支援 データモダナイゼーション支援 クラウドネイティブアプリケーション開発支援 GenAI基盤構築支援 SRE/DevOps内製化支援 事業概要 クラウドネイティブ SRE Platform Engineering Kubernetes(K8s) クラウドセキュリティ AWS、Googleクラウド 戦略策定 設計・構築 組織作り支援 内製化支援 MLOps Gemini、VertexAI 生成AI活用支援 バックエンド開発 （Java、Go、Python、 Typescript） モダンアプリ開発 フロントエンド開発 （Vue、React） パイロットアプリ開発 継続的技術負債解消 データ基盤構築 （BQ、Snowflake） BIツール活用 (Looker) DBRE データ移行支援 （Oracle移行） NewSQL活用 (TiDB、Yugabyte) クラウドネイティブ支援事例 ・SREの考え方を軸にお客様システムのクラウドネイティブ化を推進する事業。 ・お客様と同じチームでアセスメント・戦略策定、設計・構築、継続的運用改善を行う。 ・最終的にお客様に内製化頂けるようになるまでご支援。 ・このご支援の中で適宜CCoE、SREチームなど組織作り支援や育成を行う。 継続的運用改善 戦略策定 設計・構築 組織作り支援 内製化支援 継続的運用改善 戦略策定 設計・構築 組織作り支援 内製化支援 継続的運用改善 戦略策定 設計・構築 組織作り支援 内製化支援 継続的運用改善 トヨタ自動車様 （生産工場のAIプラット フォームのクラウド移行） NTTデータ様 （決済プラットフォームの クラウド移行） radiko様 (配信基盤のクラウド移行) エンジニア人数・比率 ・金融・製造業・ITサービスのお客様を中心に、クラウド移行をご支援 ・クラウド移行の戦略策定〜設計・構築・運用改善まで全て対応 ・クラウドネイティブ対応に合わせ、お客様の内製化支援も実施 2025年9月時点のエンジニア人数・比率 案件種別に応じて複数のエンジニアをアサイン ・SREエンジニア ・アプリケーションエンジニア ・セキュリティエンジニア ・DBRE／データエンジニア ・PM
37. ・CNCF（Cloud Native Computing Foundation）が発表した 　Kubernetesをはじめとするオープンソースプロジェクトの国内 　貢献度ランキングで当社エンジニアがTop10に2名選出 ・2025 Google Cloud Partner of the Year（優れた実績を 　収めたパートナー企業を表彰するプログラム）において、 　Infrastructure Modernization Partner of the Year – Japan受賞 強々エンジニアが集まっています！
38. 4月に学生向けワークショップを開催します！ 興味のある方は是非、下のQRコードからご応募下さい！ • 開催日時：2026年4月2日PM＋3日PM（2Days） • 開催場所： ◦ アプリ：当社オフィス ◦ インフラ：当社オフィス、オンライン何れでも選択可能 ◦ 当社オフィスの場合は別途、交通費支給 • 実施内容 ◦ 座学並びにハンズオンで学べるコンテンツを提供予定です！！ ◦ アプリ：Docker・アプリケーション開発手法について ◦ インフラ：Docker・Kubernetesについて アプリ インフラ