正解が消えた開発現場で、どう後輩を育てればいいのか？~ AI時代における「若手のストレス」と「メンターの限界」に向き合う ~

2026-08-27
エンジニア育成に向き合う ～先輩たちの悩みと知見共有会～ @ファインディ株式会社
https://findy.connpass.com/event/402630/ #techbaton_findy

Transcript

1. 正解が消えた開発現場で、どう後輩を育てればいいのか？ ~ AI時代における「若⼿のストレス」と「メンターの限界」に向き合う ~ TECH BATON in 東京 @ ファインディ株式会社 みきてぃ / きたはら (mkitahara) 2026-08-27
2. ⾃⼰紹介 みきてぃ / きたはら (mkitahara) @mikity01985 所属 役割 Fintech 企業 (約 3年) • 元モバイルアプリチーム責任者 • 現新規事業開発チーム責任者 ◦ ◦ • Androidアプリエンジニア • PjM / PdM • EM • テックリード / PM • 採⽤‧広報⾒習い (⾮公式) EM テックリード 経歴 学⽣時代 • 理学部化学科 → 化学系⼤学院 → 新卒IT未経験でIT業界へ SES‧受託 (約6年) • • ソフトウェア開発全般 10名未満の会社の社内環境整備 EdTech (約6年) • • 成⻑組織でのAndroid開発 CRE‧PM‧PO 等も経験 2
3. 今回のテーマ エンジニア育成に向き合う 3
4. 【構造変化】AI時代のエンジニア育成が直⾯する壁 AIで開発が激変した今、若⼿とメンター双⽅が直⾯する育成の課題がある • 開発現場の急激な変化 ◦ ◦ • AIの台頭により、詳細設計‧実装‧テストの⽣産性が爆発的に向上 ⼀⽅で、現場では「若⼿が育たない」「教え⽅がわからない」という課題が急増 技術論の裏にある⼈と組織の課題 ◦ ◦ 学習ステップとメンタルの構造変化が起きている 教わる側と教える側（メンター）の両⾯から構造と対策を⾒ていきたい 4
5. 【構造変化】かつての開発⼯程と育成‧成⻑モデル 正解がある「下流の泥臭い経験」が、若⼿の成⻑の⾜場であり達成感の源泉だった • 従来の学習ルート（ボトムアップ学習） ◦ ◦ • 詳細設計‧実装‧テスト（下流）→ 要件定義‧基本設計（上流）の順に経験 実装の摩擦や障害対応という「痛み」を通じて、上流の勘所を逆算して体得できた 若⼿の達成感とメンターの指導環境 ◦ ◦ 仕様という「正解」があり、苦労して動かせた瞬間に強い達成感‧⼿触り感があった コードやテストという「客観的な模範解答」が存在し、迷いなく評価‧指導できた 5
6. 【構造変化】AIがもたらした変動：主戦場の強制シフト 下流がAI化されたことで、エンジニアの主戦場は初⼿から「上流⼯程」へシフト • ⼯程の時間圧縮と要求の変化 ◦ ◦ • 詳細設計〜テストはAIで即時完了し、技術的品質（動くコード）は底上げされる エンジニアに求められる価値が「要件定義‧基本設計」へと⼀気に⼿前に移動 事業的品質向上の難易度と⼯程の依存関係 ◦ ◦ 事業的品質（本当に解くべき課題か）は、基本設計以前の質に100%依存する 「綺麗なコードで、誰も欲しがらないゴミを爆速で作る」リスクの増⼤ 6
7. 【現場の苦悩】「暗黙知の補正」の消滅 ⼈間同⼠の対話による仕様補正が効かず、指⽰者の解像度がそのまま成果物の質へ • ⼈間 to ⼈間 ◦ ◦ • 上流の検討が⽢くても、実装段階の対話や忖度で仕様の不備を補正できた 後⼯程が前⼯程の粗さをカバーするクッションとして機能していた ⼈間 to AI ◦ ◦ AIは (基本的に) 渡された「認知‧⽂脈‧⾔語化の解像度」通りにしか出⼒しない 初⼼者に、最初から「⾼度な⽂脈⾔語化⼒」が求められるパラドックスが発⽣ 7
8. 【現場の苦悩】若⼿を襲う「3つのストレス」 正解を解く楽しさを失い、階段を踏む猶予もないまま正解のない霧の中に 放り出されている • 原初的成功体験の喪失 ◦ • 正解のない霧の中への放流 ◦ ◦ • 「⾃⼒でコードを書いて動かした！」という⼿触り感や達成感を得にくい 「正解のあるパズル（How）」から「正解を創る仕事（What/Why）」への急激なシフト 段階的な成⻑ステップを踏めないまま、答えのない事業課題の翻訳に向き合う不安 理想のエンジニア像とのギャップ ◦ 「技術を極めたい」想いと、「仕様調整やドメイン理解ばかり」の現実の乖離 8
9. 【現場の苦悩】メンターを襲う「指導‧評価の限界と疲弊」 模範解答と育成ロードマップを失い、答えのない壁打ちで指導コストが激増している • 評価基準の喪失 ◦ • 育成ロードマップの崩壊 ◦ • 上流の問いには客観的な正解がなく、メンター⾃⾝も確信を持って評価‧指導しにくい 抽象的な課題解決⼒は成⻑が⾮線形であり、再現性のある階段を設計できない 認知的疲労と診断の困難化 ◦ ◦ AI⽣成コードにより若⼿の思考がブラックボックス化し、躓きポイントが⾒えない 技術指導ではなく「答えのない事業壁打ち」が続き、指導側の脳のスタミナが枯渇 9
10. 【現場の苦悩】⾒落とされがちな構造的リスク 平時はAIで動かせても、「有事の突破⼒」と「育成の⼆極化」というリスクが潜む • 有事突破⼒（基礎体⼒）の空洞化 ◦ ◦ • 平時はAIで動かせても、本番障害や性能劣化時にシステム挙動を推論してデバッグする 筋⼒が育たない AIがお⼿上げになった瞬間に⼿詰まりになる「崖っぷちリスク」 AIネイティブ格差による成⻑の⼆極化 ◦ ◦ AIを壁打ち相⼿に⾃⾛する層と、⼿触り感を失い⽴ちすくむ層に分断 ⼀律の研修やOJTが通⽤しなくなり、個別対応の負荷が増⼤ 10
11. 【これからのアプローチ】「教える」から「共に探究する」へ メンターが正解を教える先⽣を降り、AIを挟んで設計妥当性を⼀緒に検証する 伴⾛者になる • 指導スタンスの転換 ◦ • 現場で実践できる伴⾛アプローチ ◦ ◦ • メンターも正解を持たなくていい。「なぜその設計にしたか」を⼀緒に探究する コンテキストレビュー：PRではなく「AIに渡す前の指⽰⽂‧設計⽅針」を壁打ち AI出⼒の論評会：「なぜこのコードを採⽤したか」「事業‧技術リスクは何か」を⾔語化 痛みの疑似体験 ◦ 壊れた環境のトラブルシューティングやカオス演習を意図的に実施し基礎体⼒を養う 11
12. 【これからのアプローチ】属⼈化を防ぐ「組織的インフラと評価軸の再定義」 個⼈に背負わせず、組織の資産を活⽤するとともに評価基準をアップデートする • 組織資産による⽂脈の追体験 ◦ ◦ • ADR（設計意思決定記録）：過去の「なぜこの設計にしたか」のログを教材化 ポストモーテム（障害記録）：組織の過去の失敗‧痛みを安全に疑似体験 評価軸のアップデート ◦ ◦ 「早く動くものを作ったか」ではなく、 「前提を疑えたか」「考慮漏れのリスクを⾔語化できたか」を評価 正解がない中での「適切な問い⽴て‧リスク指摘」そのものを称賛する⽂化へ 12
13. 【まとめ】AI時代のエンジニア育成の全体像 下流のAI化がもたらした構造変化を捉え、指導スタンスと組織の仕組みを アップデートする • 開発現場の構造変化 ◦ ◦ ◦ • 現場への影響 ◦ ◦ • かつては、正解がある下流（実装‧テスト）の泥臭い経験から、上流の勘所を逆算して学べた 現在は、下流がAI化され、初⼿から「正解のない上流（要件‧基本設計）」が主戦場へ強制シフ ト ⼈間同⼠の対話による仕様補正が効かず、指⽰者の「⽂脈の解像度」に結果が直結 若⼿：⾃⼒で動かす達成感を失い、段階を踏めないまま正解のない霧の中で⽴ちすくむ メンター: 模範解答や育成計画を失い、答えのない壁打ち対応で認知的疲労が限界に達する これからの対応案 ◦ ◦ 伴⾛型へ: 先⽣を降りてAIを挟む「共同探究者」となり、プロンプト前の設計意図を壁打ちする 組織インフラと評価: ADRや障害記録で⽂脈を追体験させ、「問いとリスクの⾔語化」を評価する 13
14. ご静聴ありがとうございました 14