AI時代のオンプレ-クラウドキャリアチェンジ考

「インフラエンジニアのネクストキャリア戦略会議　～オンプレからクラウドへのキャリアチェンジ～」で発表した資料です。

■参考資料
・Being Glue
・Claude Code deletes developers' production setup, including its database and snapshots — 2.5 years of records were nuked in an instant
・Fixing Claude with Claude: Anthropic reports on AI site reliability engineering

■株式会社スリーシェイク関連情報
・公式Note
・事業説明デック
・中途採用募集中ポジション一覧

Transcript

1. AI時代のオンプレ-クラウドキャリアチェンジ考 インフラエンジニアのネクストキャリア戦略会議 株式会社スリーシェイク 志羅山祐太郎 Copyright © 3-shake, Inc. All Rights Reserved.
2. 2 • 株式会社スリーシェイク Sreake事業部マネージャー • 岩手県出身、長野県在住 • 趣味：登山、スキー、クライミング、飲み歩き • 大事にしていること：つながり（チーム、友達、地域） • X / GitHub / Zenn : yuu0w0yuu 志羅山 祐太郎 Shirayama, Yutaro
3. 新卒 インフラエンジニア 2社目 コンサルタント/エンジニア 現職 スリーシェイク 2015 2018 2023 2026 インフラの基礎 インフラの基礎 運用・ビジネススキル インフラの基礎 運用・ビジネススキル クラウドネイティブ・組織 データセンター 楽しい・寒い スクリプト 書くの楽しい UNIX構築 楽しい TCP/IP 難しい！ 面白い！ 運用大変 修羅場 クラウドを もっとやりたい チーム・組織横断 の仕事が好き 採用 AWS AI駆動開発 EM/PM コンテナ SRE 技術領域を クラウドに 変えたい 上流にも 挑戦したい 3 これまでのキャリア Amazon Bedrockが 発表された年
4. 今日お話すること 4
5. 5 このままいくとマネジメントになりそうだが、今のオンプレ中心の軸で進んでいいのか？ オンプレからクラウドに挑戦したいけど、何が活かせるか？どんなハードルがあるのか？ AIによって人間に求められる役割が変わっている時代、「手を動かす」キャリアデザインは可能なのか？
6. 6 「キャリア戦略の観点」「発表者の”どうだったか？”」を WILL-CAN-MUSTの枠組みで語ってみる WILL CAN MUST 働き方・業態・領域 ピボット戦略 時代が・組織が 求めるもの 出典：【Will-Can-Mustシート】リクルートの活用事例～メンバーの本当に実現したいことを対話する方法
7. 7 • オンプレ領域で深い専門性やポジション(技術エキスパート、PM等)を確立している方の視点での話 • 事業会社視点のキャリアの話（発表者が現職含めクライアントワーク中心のキャリアのため） あまり触れない(触れられない)ところ
8. WILL 3つの観点：働き方・業態・領域 8
9. 9 キャリアチェンジの原動力として何を燃やすか？
10. 10 • 「何かを作った」という達成感？ • エンジニアとしての市場価値低下に対する不安の解消？ • マネジメントをやる前提での現場感覚の維持？ ①働き方：「手を動かす」ことを通じて何を得たいのか？
11. 11 • 「何かを作った」という達成感？ • エンジニアとしての市場価値低下に対する不安の解消？ • マネジメントをやる前提での現場感覚の維持？ ①働き方：「手を動かす」ことを通じて何を得たいのか？ 簡単なタスクはAIがやった 方が低コストでは？ ”手を動かせること”が市場価値の 向上につながるのか？ （「手を動かす」の再定義） 自分が想定する世界で マネジメントに求められる 現場感覚はどのくらいのレベル？
12. 12 • 「何かを作った」という達成感？ • エンジニアとしての市場価値低下に対する不安の解消？ • マネジメントをやる前提での現場感覚の維持？ ①働き方：「手を動かす」ことを通じて何を得たいのか？ 変化の激しいAI時代において、「やりたい」という”反応的”な動機を見直し、 「どの領域でどう動かしたいのか？」を整理して”統合的”なモチベーションへ昇華することも必要 簡単なタスクはAIがやった 方が低コストでは？ ”手を動かせること”が市場価値の 向上につながるのか？ （「手を動かす」の再定義） 自分が想定する世界で マネジメントに求められる 現場感覚はどのくらいのレベル？
13. 13 ②業態：次は自社開発か？クライアントワークか？ 自社開発 クライアント ワーク • 特定のシステムやドメイン・課題に深く取り組むことの優位性 • 一方で市場の変化や新技術に素早く反応できる適応力が必要 • 自社に閉じたスタックやドメインに「選択肢の少なさ」というリスクを感じる可能性も（個人差） • 実際転職するとして、事業会社のインフラエンジニアの場合、自社の大規模プライベートクラウドを持っているような会 社がメインとなり、ポジションの母数も少ない印象 • 様々な顧客や技術スタックを経験できることによるスキルの多面化（特にソフトスキル）の優位性。SI経験がポータブル スキルとして活かしやすい側面も • 一方で、プロジェクトごとの条件の変化や「どうにかなるもの」「どうにもならないもの」を切り分け受け入れる 適応力が必要 • AI代替・内製化が進めば優先的に削減されるのも外注コスト。攻める領域や入り込み方を工夫する必要あり
14. 14 ②業態：次は自社開発か？クライアントワークか？ 自社開発 クライアント ワーク • 特定のシステムやドメイン・課題に深く取り組むことの優位性 • 一方で市場の変化や新技術に素早く反応できる適応力が必要 • 自社に閉じたスタックやドメインに「選択肢の少なさ」というリスクを感じる可能性も（個人差） • 実際転職するとして、事業会社のインフラエンジニアの場合、自社の大規模プライベートクラウドを持っているような会 社がメインとなり、ポジションの母数も少ない印象 • 様々な顧客や技術スタックを経験できることによるスキルの多面化（特にソフトスキル）の優位性。SI経験がポータブル スキルとして活かしやすい側面も • 一方で、プロジェクトごとの条件の変化や「どうにかなるもの」「どうにもならないもの」を切り分け受け入れる 適応力が必要 • AI代替・内製化が進めば優先的に削減されるのも外注コスト。攻める領域や入り込み方を工夫する必要あり どちらがいい悪いではなく、自身の志向にあった業態を理解・選択する必要がある
15. 15 • 結局、それぞれの辛さがある ◦ オンプレ：オンサイト縛り（リリース、駆けつけ）、重厚なリスク対策（手順書等） ◦ クラウド：変化の速さ、フルスタック化、AI淘汰・活用 ▪ クラウドはインフラエンジニアでもソフトウェアエンジニア的素養が必要で、向き不向きはある • クラウド転換は王道なのか？ ◦ 相対的に希少性が高く・代替可能性が低いオンプレ領域でエンジニア/PMの道に進むのも全然あり ◦ クラウドの絶対的な優位性はない。価値観や趣向の要素も強い ③領域：クラウドはBetterなのか？
16. 16 WILL CAN MUST 働き方・領域・業態 ピボット戦略 時代が・組織が 求めるもの • 「手を動かす」ことの解像度を上げる • 業態と自分の適正度の解像度を上げる • 「クラウド」に対する価値観を見直してみる WILLのまとめ
17. 17 ちなみに発表者の場合… • なぜ当時(2022-23頃)クラウドを選んだか？ ◦ 「これからはクラウドの時代」と言われ続けて数年、自然とネクストキャリアとして 関心が向いていた ◦ 前職時代に地方移住。オンプレ×コンサル軸で職位を上げるといずれ厳しくなる予感があった • どういう業態の会社を見ていたか？ ◦ 過去のキャリア的に、事業会社のクラウド領域のエンジニアとしてはスキル・経験不足感。 志向もクライアントワーク寄りだったので、過去の経験を活かせるクライアントワークを中心 に見ていた ◦ 中でも、クラウドのインフラ・コンテナを得意領域としているクライアントワークの会社 として、現職がマッチした(ちなみにスリーシェイクは事業会社出身のエンジニアも多いです)
18. CAN キャリアピボット戦略：ポータブルスキルと自己開示 18
19. 19 その先に、何を持っていけるか？
20. 20 キャリアピボットで重要なこと ポータブルスキルレバレッジ ◦ まずは持っているスキルでしっかりバリューを出した上で、新領域のキャッチアップコスト として上手く切り崩し、変換できるか ▪ このスキルが、新しい環境において希少であればあるほどよい（例：ハードスキルが 強い組織におけるソフトスキルなど） ◦ 「技術キャッチアップはすぐに終えて化けそう」という期待値をいかに持ってもらえるか 自己表現・自己開示 ◦ 「自分が何者で、何を考えていて、何ができるのか？」を自分から周囲に発信できるか ◦ まわりの人たちとのWin-Winな関係構築に尽力できるか
21. 21 これまでの経験から、AI時代のポータブルスキルを探す 低レイヤー知識 構造化思考 守りの勘所 グルーワーク* ネットワークやCPU/メモリレベルの知見に基づく「中身を覗ける目」は、領域が変わっ てもトラブルシューティングや性能改善において非常に重要 設計書や議事録、パワポなどの成果物の「構造」にこだわった経験が、コミュニケーション やAI時代の情報設計に活きる AI駆動開発の広まりとともに、システムの信頼性のリスクも高まる。オンプレで培った 「守りの勘所」は、さらに需要が高まるSREの実践の礎としてクラウドでも重宝される AI革命により、ボトルネックは調整や越境、ラストワンマイル推進に移動。 SIの現場で培ったグルーワークスキルはそこにマッチする *Tanya Reilly - Being Glue
22. 22 ちなみに発表者が苦労したこと… キャッチアップが大変 ◦ 一気にインプットする必要があった(EKS/コンテナ/Terraform/Git/OSSなど) ▪ 特にコンテナ、Git：過去の経験からのギャップが大きい ▪ Kubernetes特有の概念やエコシステム（HelmやArgoCD）：高抽象度 ◦ 分からないことは分からないと発信し、周りの助けをたくさん借りた バリューを出せるようになるまでの動き方が難しい ◦ 周りの技術レベルの高さに圧倒され、最初は「試用期間で切られる」と本気で思っていた ◦ 細かいことが分かっていなくても価値になるスキルは転職直後から役に立った（交通整理など） ▪ ポータブルスキルでバリューを出しつつ、作った貯金をキャッチアップで切り崩しながら食らいつくという やり方で初期を乗り切った ◦ 「（元出社ベースで）リモートワーク経験があること」と「ゼロベースでリモートスタート」は別種目
23. 23 活きた経験・特性 • 活きた経験 ◦ クライアントワーク（特にコンサル時代）：泥臭さ耐性、越境労働、グルーワーク ◦ 障害対応経験：心臓がキュッとなる経験、「ヤバい」の勘 ◦ インフラ知識：仕組みや動作に関する基礎がインメモリで存在している優位性 ◦ 他拠点キャリア：いろんな環境を経験していることが抽象思考の土台に • 良い面もあった個人的特性 ◦ 多動：いろんな分野への興味、実際に手を動かしたい欲（AIの恩恵を受け、領域拡大へ） ◦ そもそも思考：「そもそもこれって」「そもそもこの仕組みって」のような探索習慣は汎用性が高い
24. 24 WILL CAN MUST 働き方・領域・業態 ピボット戦略 時代が・組織が 求めるもの • ポータブルスキルを見つけ、キャッチアップの原資に • 分からないことは分からない。自己表現・発信 • ソフトウェア開発スキルは必須。とりあえずGitとIaC CANのまとめ
25. MUST 時代が、組織が求めるもの：インフラとマネジメント 25
26. 26 難しいキャリアチェンジに、AI時代をうまく追い風に
27. 27 「時代の要請」に関する2つの仮説 • インフラエンジニア文脈のスキル ◦ AI利用の広まりに伴って、AIに任せにくい領域への注目度が高まっている ▪ 安全なProduction環境の運用、仕組みの整備、AI代替性が低い領域(ex. DB)など • マネジメント文脈のスキル ◦ 「作ること」自体の価値がコモディティ化し、ボトルネックがソフトスキルの領域に移動。 マネジメントがもたらす価値がより重要に
28. 28 「時代の要請」に関する2つの仮説 • インフラエンジニア文脈のスキル ◦ AI利用の広まりに伴って、AIに任せにくい領域への注目度が高まっている ▪ 安全なProduction環境の運用、仕組みの整備、AI代替性が低い領域(ex. DB)など • マネジメント文脈のスキル ◦ 「作ること」自体の価値がコモディティ化し、ボトルネックがソフトスキルの領域に移動。 マネジメントがもたらす価値がより重要に 時代や組織が求めることと自身の得意や方向性を接続すること⇒強いキャリア突破力につながる
29. 29 • インフラ領域におけるAI代替性の相対的な低さを活かす ◦ 最終的な判断や破壊的操作を任せられるか？ ◦ インパクトが大きい領域に対する責任を負えるか？ ◦ コンテキスト化できていない暗黙知やその場の状況を統合したインシデントコマンダーができるのか？ パターン1：インフラエンジニアとAI Claude Code deletes developers' production setup, including its database and snapshots — 2.5 years of records were nuked in an instant Claude CodeのTerraform操作によって数年分のデータを消失 Fixing Claude with Claude: Anthropic reports on AI site reliability engineering Anthropic講演「LLMのSRE代替は難しい」
30. 30 • インフラ領域を軸にプラットフォームエンジニアリングやAIのSRE(AIRE)を実践する ◦ ソフトウェア開発の民主化によって、「ソフトウェアも書けるインフラエンジニア」という切り口でのSREの 間口は以前より広くなった ◦ AI駆動開発の広まりによって生まれる課題の解決と、プラットフォーム（≒インフラ）視点でのキャリア形成は 方向性が似ている ▪ AIを安全に開発に活用するプラットフォームの整備、開発者体験の向上 ▪ AI駆動開発が生む信頼性の揺らぎへの手当て パターン1：インフラエンジニアとAI
31. 31 • インフラ領域を軸にプラットフォームエンジニアリングやAIのSRE(AIRE)を実践する ◦ ソフトウェア開発の民主化によって、「ソフトウェアも書けるインフラエンジニア」という切り口でのSREの 間口は以前より広くなった ◦ AI駆動開発の広まりによって生まれる課題の解決と、プラットフォーム（≒インフラ）視点でのキャリア形成は 方向性が似ている ▪ AIを安全に開発に活用するプラットフォームの整備、開発者体験の向上 ▪ AI駆動開発が生む信頼性の揺らぎへの手当て パターン1：インフラエンジニアとAI インフラエンジニアとしての「守りの勘」「土台志向」を 「AI時代のプラットフォームエンジニアリング・SRE」というポジションに変換する
32. 32 パターン2：マネジメントとAI そもそも 時間が足りない 会議が多くて 空き時間が細切れ 現場の仕事や 他チームの仕事への 解像度が低い
33. 33 • ルーティンワークを効率化し時間を作る ◦ 議事録作成・報告作成・タスク管理などの定常業務をAIで効率化し、より難しいテーマに多く時間を使う ◦ クラウドはフォーマット制約度が（オンプレよりも）低く、AI効率化可能な形に持っていきやすい パターン2：マネジメントとAI そもそも 時間が足りない 会議が多くて 空き時間が細切れ 現場の仕事や 他チームの仕事への 解像度が低い
34. 34 • ルーティンワークを効率化し時間を作る ◦ 議事録作成・報告作成・タスク管理などの定常業務をAIで効率化し、より難しいテーマに多く時間を使う ◦ クラウドはフォーマット制約度が（オンプレよりも）低く、AI効率化可能な形に持っていきやすい パターン2：マネジメントとAI そもそも 時間が足りない 会議が多くて 空き時間が細切れ 現場の仕事や 他チームの仕事への 解像度が低い • コンテキストスイッチを克服し、アウトプット変換効率を上げる ◦ 少ない時間で高速に細かくアウトプットを出す（簡単なPRならPM/PdMでも作れる） ◦ 中断せざるを得ない場合でも、セッションが残っているので作業を簡単に再開できる
35. 35 • ルーティンワークを効率化し時間を作る ◦ 議事録作成・報告作成・タスク管理などの定常業務をAIで効率化し、より難しいテーマに多く時間を使う ◦ クラウドはフォーマット制約度が（オンプレよりも）低く、AI効率化可能な形に持っていきやすい パターン2：マネジメントとAI そもそも 時間が足りない 会議が多くて 空き時間が細切れ 現場の仕事や 他チームの仕事への 解像度が低い • コンテキストスイッチを克服し、アウトプット変換効率を上げる ◦ 少ない時間で高速に細かくアウトプットを出す（簡単なPRならPM/PdMでも作れる） ◦ 中断せざるを得ない場合でも、セッションが残っているので作業を簡単に再開できる • 手触り感を維持し、影響範囲を広げる ◦ 自身もAIを使ってコードベースとの接点を増やし、現場のエンジニアの目線に近づくことで 「手触り感のあるマネジメント」を実現する ◦ 他部署・他領域の知見や言語に高速にオンボーディングし、コラボレーションハブとしての価値を高める
36. 36 • ルーティンワークを効率化し時間を作る ◦ 議事録作成・報告作成・タスク管理などの定常業務をAIで効率化し、より難しいテーマに多く時間を使う ◦ クラウドはフォーマット制約度が（オンプレよりも）低く、AI効率化可能な形に持っていきやすい パターン2：マネジメントとAI そもそも 時間が足りない 会議が多くて 空き時間が細切れ 現場の仕事や 他チームの仕事への 解像度が低い • コンテキストスイッチを克服し、アウトプット変換効率を上げる ◦ 少ない時間で高速に細かくアウトプットを出す（簡単なPRならPM/PdMでも作れる） ◦ 中断せざるを得ない場合でも、セッションが残っているので作業を簡単に再開できる • 手触り感を維持し、影響範囲を広げる ◦ 自身もAIを使ってコードベースとの接点を増やし、現場のエンジニアの目線に近づくことで 「手触り感のあるマネジメント」を実現する ◦ 他部署・他領域の知見や言語に高速にオンボーディングし、コラボレーションハブとしての価値を高める 「手を動かせなくなりそう」というマネジメントのイメ－ジは、AIを活用することで 「手触り感」と「マルチチャネル」を強みとするイメージに塗り替えることが可能
37. 37 WILL CAN MUST 働き方・領域・業態 ピボット戦略 時代が・組織が 求めるもの • AI時代のインフラとマネジメントの需要に着目 • インフラ：AIRE・プラットフォームエンジニアリングへ • マネジメント：AIを活用したプレイングマネージャへ MUSTのまとめ
38. まとめ 38
39. 39 Will? Can? Must? 改めて、クラウドでやりたいこと・実現したいキャリア、自身 の志向を整理する AIエージェントで効率化・新規学習を試しつつ、インフラやPM などの自身のスキルを再現可能な体系に整理・深化する ポータブルスキルを棚卸し、ソフトウェア開発の知識を触って 学び始める(GitやIaC) 今日からできること 上手く重なれば キャリアチェンジの 強い原動力に
40. 会社紹介 40
41. 41 ミッション：「複雑化し続けるインフラの世界を技術力でシンプルにする」 SREの思想をベースにしたクラウド領域の伴走型支援で 「顧客の内製化」を実現する支援事業を展開しています SRE / DevOps ・プラットフォーム構築 / 運用高度化 　 Google Cloud / AWS / Kubernetes / IaC ・信頼性 / 生産性 / DevEx向上 　 SRE / o11y / CI/CD / Platform Engineering ・セキュリティ強化 　 アセスメント / SIEM / WAF / CSIRT Application Modernization AI / ML DBRE ・アプリケーションモダナイゼーション 　 API / マイクロサービス / リファクタリング ・開発プロセス改善・高度化 　 AI駆動開発 / 開発環境 / CI/CD ・組織組成・強化 　 アジャイル / スクラム / チームトポロジー ・生成AI導入 / 活用 　 ワークショップ / RAG ・AIエージェント開発 　 MCP / A2A / 既存システム連携 ・モデル開発環境構築 　 MLOps / データフライホイール ・データベース構築 / 移行 / 性能改善 　 PostgreSQL / MySQL / Spanner / TiDB ・データ基盤構築 　 Looker / Snowflake / BigQuery / Redshift スリーシェイク公式Note Sreake事業部 採用中ポジション情報 事業部説明資料(SpeakerDeck)
42. Thank you 42