AIで変わるエンジニアの働き方（仮）

AIの力を借りることで、2人分、3人分の仕事ができる時代になりつつあります。では、その成果はどう評価されるべきなのでしょうか。実装がAIに移っていくとき、エンジニアに求められる役割はどう変わるのか。あえてタイトルに（仮）を残したまま、いま一緒に考えたい問いをお持ちしました。

Transcript

1. デブサミ関西2026 AIで変わるエンジニアの働き方、 求められる役割（仮） 2026.08.21 株式会社TRAILBLAZER 共創ソリューション事業部 直井 和久 ©TRAILBLAZER inc. All Rights Reserved. │
2. 直井 和久（なおい かずひさ） 株式会社TRAILBLAZER 共創ソリューション事業部 部長 2000年からSIerでエンジニアとしてのキャリアを始め、2007年に英 語が公用語で有名な国内最大手のEC企業に転職。旅行や公営競技な ど様々なサービスで、プレイングマネージャーとしてサービス企画か らプロダクト開発まで幅広く担当。 2024年7月にTRAILBLAZERに入社、共創ソリューション事業部の部 長として、JR西日本のプロダクト開発を推進。 愛犬アーサーの写真集をコミケで配る昨日49歳になったアラフィフ おっさんです。 ©TRAILBLAZER inc. All Rights Reserved. │
3. 株式会社TRAILBLAZERについて JR西日本グループのデジタル戦略を支えるデジタル子会社 JR西日本グループのデジタル戦略を支えるために2023年10月に設立されたデジタル 子会社です。 デジタルの力でグループの事業共創を加速させ、鉄道運営の効率化や新しい顧客体 験の企画・開発を行っています。 （Gemini調べ） ©TRAILBLAZER inc. All Rights Reserved. │
4. 本日の発表について 40分・2部構成でお話しします 前半20分｜考えの共有 後半20分｜現場の声 働き方・役割の変化について リアルな現場の声をご紹介 自分の考えをお話しします 実感と突き合わせてください ©TRAILBLAZER inc. All Rights Reserved. │
5. Agenda 00｜はじめに ── （仮）の理由 01｜何が変わったか 02｜自分の成果の見られ方 03｜役割が変わる 04｜求められるスキルと組織 ©TRAILBLAZER inc. All Rights Reserved. │
6. 00｜はじめに なぜ、（仮）のままなのか ©TRAILBLAZER inc. All Rights Reserved. │
7. 00｜はじめに タイトルに（仮）が付いたままの理由 AIのスピードが速すぎて、この先どうなるか分からない AIの進化が速すぎて、半年先も見通せない 今日の内容は「答え」ではなく、考えと問い まずはひとつ、お聞きします。 「この1、2年、働き方が変わった気がしませんか？」 ©TRAILBLAZER inc. All Rights Reserved. │
8. 00｜はじめに みなさんに質問です 挙手で教えてください Q1. AI、使ってますか？ Q2. 1日のどのくらい？ チャットで使っている？ 1時間くらい？ 開発でも使っている？ 半日くらい？ それ以上？ ©TRAILBLAZER inc. All Rights Reserved. │
9. 01｜何が変わったか 実装のハードルが下がった ©TRAILBLAZER inc. All Rights Reserved. │
10. 01｜何が変わったか 職種の垣根が溶け始めている コードを書くこと自体は、AIがかなりの部分を担えるようになった 起きていること 生まれる問い 実装ハードルが下がった どこまでAIに委ねる？ 職種の垣根が溶け始めている Specやコードをどこまで把握？ 役割は今も変わり続けている 品質は誰がどう担保する？ ©TRAILBLAZER inc. All Rights Reserved. │
11. 01｜何が変わったか 開発フローはこう変わった PRDの時点で「動くモック」が作れる時代に Before｜AI以前 After｜AI以後 PRD→デザイン→設計→開発 PRD時点でVibe codingのモック 動くものは最後まで見えない ビジネスへの説明がしやすい 説明は資料とイメージ頼み エンジニア観点があれば、実物に 近いベースに ©TRAILBLAZER inc. All Rights Reserved. │
12. 01｜何が変わったか 自分の働き方は、どう変わったか？ 作業はAIに任せて、「人と話す時間と考える時間」に振り切った Before｜これまで After｜最近 考える時間が足りず、結局残業が多かった 作業は裏でAIに任せている。資料は完成度を求めず 、会議でフォロー 20% 50% 50% 80% 会議・1on1 資料作成などの作業 会議・1on1 考える時間 ©TRAILBLAZER inc. All Rights Reserved. │
13. 02｜自分の成果の見られ方 AIが働いた分は、誰の成果か ©TRAILBLAZER inc. All Rights Reserved. │
14. 02｜自分の成果の見られ方 AIが働いた分を、自分の成果にするには？ 「AIに任せた仕事」をどう評価してもらうか AIと一緒に、2人分・3人分のタスクを取って消化する こなした量と質が、そのまま成果として見える ただし「何倍まで取るか」は慎重に ©TRAILBLAZER inc. All Rights Reserved. │
15. 02｜自分の成果の見られ方 開発スタイルで、取れる「倍率」は変わりそう 同じ「何倍も取る」でも、リスクの効き方が違う 内製 × アジャイル ウォーターフォール 2人分・3人分と多めに取れる 数倍取ること自体は可能 スプリント単位で調整しやすい 長期スケジュールは変化に弱い 実績を見て徐々に上げられる 安全マージンで2倍程度が現実的 ©TRAILBLAZER inc. All Rights Reserved. │
16. 02｜自分の成果の見られ方 前提：AIは、突然使えなくなるかもしれない 倍率を上げるほど、止まったときの影響も大きくなる 予算・規約変更・障害など、使えなくなる理由は色々 その瞬間、「取りすぎたタスク」は消化できない 最初から3倍・4倍を約束しない 実績の「積み上げ」で、信頼と倍率を上げていく ©TRAILBLAZER inc. All Rights Reserved. │
17. 02｜自分の成果の見られ方 事業会社で内製開発の場合 生産性が2倍になっても、給料は2倍にならない 2倍生産性が上がったからと言って、給料が2倍になる訳ではな い 売上が上がるようなアウトプットを増やして事業貢献できれば 、還元されるかもしれない ただし、AIにかかるコストとのトレードオフにはなる ©TRAILBLAZER inc. All Rights Reserved. │
18. 02｜自分の成果の見られ方 SIerの場合：人月単価はどうなる？ 「人が1か月働く」前提の値付けと、AIの成果 人月単価は「人が1か月働く」前提の値付け AIと2人分働いたら、請求は1人月？2人月？ 工数ベースから成果ベースへ──値付け自体が論点に または、人月100％稼働の案件を複数掛け持つやり方もあるが 、あまりにもドメインやシステムが違う場合は仕事し辛い気も する。 ©TRAILBLAZER inc. All Rights Reserved. │
19. 03｜役割が変わる HowからWhat／Whyへ ©TRAILBLAZER inc. All Rights Reserved. │
20. 03｜役割が変わる エンジニアの価値は、What／Whyへ 実装ハードルが下がるほど、価値の置き場所が変わる 「どう作るか（How）」の多くをAIが担う 価値は「何を・なぜ作るか」に移っていく 説明責任は、これまで以上に「人」に残る ビジネスへのコミットが強い人が生き残る ©TRAILBLAZER inc. All Rights Reserved. │
21. 03｜役割が変わる 変わっていく役割と、残る専門領域 すべてが置き換わるわけではない 変わっていく役割 残る専門領域 PdM側へ寄る動きが増える セキュリティなどの品質担保 垣根を越えた動き方が当たり前に アーキテクチャなどの希少スキル 「価値に責任を持つ人」へ 「上流の席」は限られている ©TRAILBLAZER inc. All Rights Reserved. │
22. 04｜求められるスキルと組織 個人と組織の設計はセット ©TRAILBLAZER inc. All Rights Reserved. │
23. 04｜求められるスキルと組織 これから求められるスキル・資質 AIと働く前提で、これから重みが増すもの 言語化・概念化の能力 別ロールと動けるコミュニケーション 判断力・問題設定力（評価への反映が課題） 事業への理解・関心とオーナーシップ ©TRAILBLAZER inc. All Rights Reserved. │
24. 04｜求められるスキルと組織 組織：少数精鋭と成長のトレードオフ 個人の変化は、組織の設計とセットで考える 採用・登用の基準は「事業理解・関心」 AIコストと人員数のバランスの意思決定 少数精鋭に寄せるほど、ジュニアが実戦経験を積める場は減る 任せる仕事と余白を意図的に設計して、ジュニアの成長機会を つくる ©TRAILBLAZER inc. All Rights Reserved. │
25. まとめ 変わり続けること自体が、新しい役割 今日お持ちした問いのまとめ 役割もスキルも、変わり続ける （仮）は外れない。少しずつ調整していく 最後にもうひとつだけ。 「あなたは、何倍のタスクを取れますか？」 ©TRAILBLAZER inc. All Rights Reserved. │
26. おまけ このスライド、Claude Fable5純度100％です バレバレだと思いますが、一文字もパワポ編集していません 実際の作業割合はこちら。 9% 1% プロットを考える時間：9割 微修正：0.9割 AI出力：0.1割 ※細部の微修正は手でやった方が早かったですｗ 90% プロットを考える時間 微修正 AI出力 ©TRAILBLAZER inc. All Rights Reserved. │
27. THANK YOU. ©TRAILBLAZER inc. All Rights Reserved. │
28. Developers Summit 2026 KANSAI AIで変わるエンジニアの働き方、求められる役 割（仮） ~AI時代のエンジニアの生存戦略~ 2026/08/21 株式会社TRAILBLAZER 共創ソリューション事業部 Takuji Nishibayashi (@takuji31) ©TRAILBLAZER inc. All Rights Reserved. │
29. 自己紹介 • 西林 拓志(にしばやし たくじ) • 株式会社 TRAILBLAZER (2025/6/1~) • 共創ソリューション事業部 • WESTER AndroidアプリDX改善/技術負 債分析 (〜2026/04) • tabiwa フルスタックエンジニアのような もの (2026/04〜) ©TRAILBLAZER inc. All Rights Reserved. │ 29
30. 自己紹介 • Twitter/GitHub takuji31 • Android (2009〜) • Kotlin (2014〜) • 新しい技術が好き • 生成AIを活用して10年ぶりにWeb・ iOSアプリの開発に再挑戦 • 個人開発ではClaude CodeとCodexを 使って自分がほしいツールを作ってい る ©TRAILBLAZER inc. All Rights Reserved. │ 30
31. AGENDA 1. 生成AI前の（私の）エンジニア生存戦略（〜05:30） 2. 生成AI後の（私の）エンジニア生存戦略（〜10:00） 3. 生存戦略うまくいってる？いってない？（〜17:00） 4. これから（〜20:00） ©TRAILBLAZER inc. All Rights Reserved. │ 31
32. 生成AI前のエンジニア生存戦略 ©TRAILBLAZER inc. All Rights Reserved. │ 32
33. T型の技術屋 ©TRAILBLAZER inc. All Rights Reserved. │ 33
34. 生成AI前のエンジニア生存戦略 身一つでものづくりをする力 • 2010年からソフトウェアエンジニアとして働いている • モバイル開発15年以上 • Androidは1.6からずっと • iOSも6くらいから8くらいまで • バックエンドはPerlとPHPを2010〜2013年頃までと2017年頃にちょっとだけ • フロントエンドは2017頃に半年くらい(+趣味の個人開発) • トレブレ入社前の直近2社でテックリードやアーキテクト（のようなもの）を7年く らいやっていた • ピープルマネジメント、本格的なプロジェクトマネジメントは未経験 • 「技術屋」として新しい技術をどんどん身に付けて、プロダクトの開発に活かす ©TRAILBLAZER inc. All Rights Reserved. │ 34
35. 生成AI前のエンジニア生存戦略 横の繋がりを広げる • コミュニティの勉強会に参加したり、主催したり • 技術者同士の横の繋がりを増やす • 社外知見を積極的に取り入れていく • 外部発信によって自分のプレゼンス向上 ©TRAILBLAZER inc. All Rights Reserved. │ 35
36. 生成AI前のエンジニア生存戦略 その結果、身についたもの • よいソフトウェアを作る力 • 新しい技術を導入、既存の技術を維持、捨てるといった判断 • コードを書く力 • (ジュニアの頃)ガリガリコードを書く→(シニア)熟考の末によいコードを一発 で書き上げる • ライブラリーや設計の良し悪しを見分ける目 • 仕様や設計を作る、読み解く、変える力 • ソフトウェアの問題に気付く力 • 壊れやすいコードや設計 • バグが出そうなコードのニオイ • etc. ©TRAILBLAZER inc. All Rights Reserved. │ 36
37. 生成AI後のエンジニア生存戦略 ©TRAILBLAZER inc. All Rights Reserved. │ 37
38. 生成AI後のエンジニア生存戦略 「作れること」の価値が揺らいだ • コードを書くこと自体はAIができるようになったし、ある程度の専門知識はAIが補 完できるようになっている • スペシャリストとして勝負するだけでいいのか？ • → 生存戦略の前提が崩れた ©TRAILBLAZER inc. All Rights Reserved. │ 38
39. 「狭義のスペシャリスト」から「広義のスペシャリスト」へ転換 ©TRAILBLAZER inc. All Rights Reserved. │ 39
40. 生成AI後のエンジニア生存戦略 AIに教えてもらって知識を広げる(フィクション) • 概念を教わる • 「uvってどういう世界観で動いてるの？」 • 言語の記法を教えてもらう • 「Kotlinの◦◦、Pythonだとどう書ける？」 • コードを題材に解説させる • 「このコンポーネントのコード、どういうことをやってる？」 • 演習形式で学ぶ • 「Svelteの書き方を演習形式で教えて」 • 公式ドキュメント／トレンド調査 ©TRAILBLAZER inc. All Rights Reserved. │ 40
41. 生成AI後のエンジニア生存戦略 結果：フルスタックエンジニアのようなものへ • バックエンド・フロントエンド・モバイルを一気通貫で設計・開発 • 他メンバーのAndroidコードをスペシャリスト観点でレビュー • Android以外も一メンバーとしてレビュー • →AIエージェントを使って専門性をブーストしつつ戦える領域を増やしていく ©TRAILBLAZER inc. All Rights Reserved. │ 41
42. 生存戦略うまくいってる？いってない？ ©TRAILBLAZER inc. All Rights Reserved. │ 42
43. 実際はそこまでうまくいってない ©TRAILBLAZER inc. All Rights Reserved. │ 43
44. 生存戦略うまくいってる？いってない？ うまくいってないところ • 「動かない」ではなく「正しいか分からない」に時間が溶ける • モダンな実装、設計か？ • 既存コードと乖離してないか？ • 変更の影響範囲は？ • AIに聞き直しても判断しきれない • AIの文章はとても読みづらい • ハルシネーションが含まれている可能性 • そもそもドメイン知識が足りてない、仕様理解が足りてない • Androidなら数分の判断が、数時間かかる ©TRAILBLAZER inc. All Rights Reserved. │ 44
45. 生存戦略うまくいってる？いってない？ うまくいってないところ • 気付けない→レビューで手戻り • 書き方 • 既存実装との重複 • 仕様とのズレ • 知識の不足で「もっともらしく見える」AIの出力の間違いに気付けない • 言語、プラットフォーム固有の土地勘 • 仕様理解 • ドメイン知識 ©TRAILBLAZER inc. All Rights Reserved. │ 45
46. 指示はできるが評価の精度が低い ©TRAILBLAZER inc. All Rights Reserved. │ 46
47. ボトルネックは自分の「評価できる力」 ©TRAILBLAZER inc. All Rights Reserved. │ 47
48. 生存戦略うまくいってる？いってない？ 未経験領域ではなぜ評価の精度が低いのか • 良し悪しを見分ける力が不足 • 壊れやすい設計、バグが出そうなコードのニオイに気付けない • 仕様や設計を読み解くのに時間がかかる • →「もっともらしい出力」をそのまま信じそうになる ©TRAILBLAZER inc. All Rights Reserved. │ 48
49. 生存戦略うまくいってる？いってない？ Androidではなぜ評価できるのか • 16年の開発で「見分ける目」と「ニオイに気付く力」が身に付いている • 評価が一瞬で終わるから、手が止まらない • → 同じAI・同じプロンプトでも、速度がまったく違う ©TRAILBLAZER inc. All Rights Reserved. │ 49
50. これから ©TRAILBLAZER inc. All Rights Reserved. │ 50
51. これから これからやること（やっていること） • 評価できる力を育てる • 経験を増やす • 引き続きAIに教えてもらう • 戦える領域を増やす • まずはFE/BE • Androidアプリ開発の軸を中心にその他の領域への応用 • AIを活用すればAndroidアプリと同等のパワーを他の領域でも出せるように • そのうちエンジニアリング以外の領域にも手を出すかも？ ©TRAILBLAZER inc. All Rights Reserved. │ 51
52. これから これからやること（やっていること） • AIに使われるのではなく、AIを使いこなせるようになる • 最新情報のキャッチアップ • 個人開発や業務、コミュニティなどを通じて知見を溜める • 業務に最適化したAIエージェント環境の構築や • AIを高度に活用できることを強みの一つにしていく • コードを書くだけがAIエージェントの使い所ではない • （この資料の作成もAIにインタビューしてもらってアウトライン作った） • 引き続き人間だとできないことを伸ばしていく • 判断をする、責任を持つ • コミュニティに参加して、アウトプットや交流 ©TRAILBLAZER inc. All Rights Reserved. │ 52
53. AI時代のエンジニアの生存戦略、みなさんはどうお考えですか？ ©TRAILBLAZER inc. All Rights Reserved. │ 53
54. AI時代変化激しくてたいへんだけど生き残っていきましょう ©TRAILBLAZER inc. All Rights Reserved. │ 54
55. THANK YOU. ©TRAILBLAZER inc. All Rights Reserved. │