ジュニアエンジニアを戦力化する

Transcript

1. Tech LT — Engineering Strategy ジュニアエンジニアを 戦力化する AI時代の人材戦略と開発基盤 3体のAIレビュアーと型安全monorepoが、採用市場を変える ジュニアエンジニアを戦力化する 1 / 13
2. 01 — 業界の現状 みんな、ジュニアを採らなくなった。 “ AIがあればジュニアレベルの 仕事はいらない — よく聞く話 そして起きていること ジュニア採用枠が減少 シニア争奪戦が激化、採用単価が高騰 教育コストへの忌避感 「育てるより即戦力」志向が強まる 人材市場の二極化 シニアは取り合い、ジュニアは行き場が減る ジュニアエンジニアを戦力化する 2 / 13
3. 02 — 我々の戦略 逆を行く。 ジュニアを戦力化できる会社は、採用市場で勝てる。 競合がいない ジュニア採用を諦めた会社が増えた今、ブ ルーオーシャン 母集団が大きい シニア争奪戦より、母数の多いジュニア市 場で勝負 自社化が早い 自社の基盤と文化に最適化された即戦力に 育つ 「採らない」会社が増えるほど、僕らの優位性が上がる。 ジュニアエンジニアを戦力化する 3 / 13
4. 03 — これまでの障壁 でも、ジュニア採用には大きな懸念があった。 稚拙なコードが本番環境に入るリスク ジュニア採用における、最大かつ最後の懸念事項 結果として起きていたこと 01 レビュー負荷の集中 シニアが指摘で1日溶ける 02 心理的コスト 「自分で書いた方が早い」 03 ジュニアの停滞 PRが出てこない・育たない 04 採用ROIの悪化 結局シニアを採るしかない ジュニアエンジニアを戦力化する 4 / 13
5. 04 — 転換点 では、何が変わったのか ? 技術的なブレイクスルーで、懸念が前提から消えた。 01 3体AIレビュー Codex × Claude × Gemini 品質ゲートを自動化 02 レビュー革命 AIが主役、人間が判断役 シニア時間を奪わない 03 型安全 monorepo TypeScript + monorepo AIが教師になる土壌 ジュニアエンジニアを戦力化する 5 / 13
6. 05 — 技術的ブレイクスルー ① 3体AIレビューで、品質ゲートを自動化 ジュニアのPRには、3つのAIが多角的にレビューに入る Codex 実装の妥当性 ロジックバグの検出 テスト網羅性 実装の選択肢提示 Claude 設計と可読性 設計の一貫性 コードの読みやすさ リファクタ提案 Gemini セキュリティ・規約 セキュリティリスク プロジェクト規約遵守 依存関係の確認 観点の重複ではなく分担。一定品質を通過した PRだけが、人間レビューに上がってくる。 ジュニアエンジニアを戦力化する 6 / 13
7. 06 — 技術的ブレイクスルー ② 人間レビューが、ボトルネックでなくなった レビューの主役が、人間から AIに入れ替わった BEFORE 人間 主導 レビュー時間 数時間〜数日 シニア負荷 高い(指摘の8割は機械的) フィードバック速度 遅い ジュニアの心理 「怒られる前提」 AFTER AI 主導 レビュー時間 分単位 シニア負荷 判断のみ(残り2割) フィードバック速度 圧倒的に速い ジュニアの心理 「人間に出す前に直せる」 → シニアの時間を奪わずに、ジュニアを増やしても破綻しない。 ジュニアエンジニアを戦力化する 7 / 13
8. 07 — 技術的ブレイクスルー ③ 型安全 × monorepo が、AIの教師になる 土壌が整っていたことが、 AI活用を圧倒的に効かせた TypeScript 型安全 ▸ ジュニアの地雷が激減 型がコンパイル時にエラーを未然に防ぐ ▸ AIの提案精度が上がる 型情報からAIが正確な実装を生成できる ▸ リファクタリング耐性 ジュニアでも壊さずに変更できる monorepo ▸ AIが全体コンテキストを把握 サービス横断の規約・パターンを理解した提案 ▸ 「規約に従って」が効く プロジェクト固有のルールにAIが追従できる ▸ 学習リソースが一箇所 ジュニアが参照する実装例が常に新鮮 型安全 × monorepo は、AI時代の最強の開発基盤。 ジュニアエンジニアを戦力化する 8 / 13
9. 08 — 運用面の打ち手 「人」と「タスク」の設計でも、ジュニアに寄せた。 技術基盤だけでは足りない。運用と設計の前提を変えた。 リモートNG・対面前提 ジュニア期間は、出社マスト しょうもないミスは対面で潰す Git操作、PR運用、コミット粒度。隣で見れば 3秒で直る チーム開発のお作法を伝える リモートだと暗黙知が伝わらない。身体で覚えてもらうフェーズ 質問ハードルを構造的に下げる 「ちょっといいですか」が言える距離感 設計は先に、タスクは下流から ジュニアに渡すタスクを意図的に絞る 設計はシニアが先に固める 判断を伴う上流は渡さない。設計済みの箱に実装を埋める 下流タスクをメインに割り当てる API実装、画面実装、テスト追加。スコープが閉じている仕事 AIと相性のいい粒度に切る AIが補助できる単位に分解。自走と学習の両立 ジュニアが「動ける範囲」を、人と設計で先に整える。 ジュニアエンジニアを戦力化する 9 / 13
10. 09 — 技術基盤のもう一段 フロント↔バックを RPC で繋いだら、 IDE のAIが化けた。 型が一気通貫で繋がる構成は、 AIにとっても最高に読みやすい。 Frontend TypeScript 型情報がそのまま使える RPC 型安全に通信 Backend TypeScript 型定義が単一の真実 IDE × AI Cursor Composer 2 型がフロント →バック一気通貫 AIが境界を越えて文脈を理解できる。曖昧な推測 が消える。 Composer 2 が活きる構成 安くて速い。ジュニアでもガンガン回せる経済性。 ジュニア × AI の相乗効果 IDE内で完結。質問とコード生成が地続きで進む。 ジュニアの隣に、安くて速い AIペアプロ相手が常駐している状態。 ジュニアエンジニアを戦力化する 10 / 13
11. 10 — 成果 結果として、何が起きたか。 ジュニアが本番にコードを入れても怖くない 3体AIレビューで品質ゲートが効く。事故は起きない前提。 シニアの時間を奪わない 判断だけ。指摘はAIに任せ、人間は設計議論に集中できる。 ジュニアが速く育つ AIによる短サイクルのフィードバックループ。自走力が上がる。 採用市場で勝てる 「ジュニア歓迎」を掲げられる。競合がいないブルーオーシャン。 ジュニアエンジニアを戦力化する 11 / 13
12. 11 — 結論 これは「育成」の話ではなく、 「人材戦略」の話。 AIは、人間を置き換える道具ではなかった。 AIは、ジュニアを戦力化するための、最強の武器だった。 基盤さえ整えれば、ジュニア採用は最強の人材戦略になる。 3体AIレビュー × 型安全monorepo = ジュニア戦力化 ジュニアエンジニアを戦力化する 12 / 13
13. 12 — Closing 一緒に、逆張りしませんか ? 「ジュニアは採らない」会社が増えるほど、僕らの優位性は上がる。 Thank you. ジュニアエンジニアを戦力化する 13 / 13