創業者が生成AIで一気に機能を作り、6万行のプルリクエストを本番へ入れようとする。速さに興奮する経営者と、レビュー、セキュリティ、保守を担うCTOの間に摩擦が起きる。The Pragmatic EngineerのGergely Oroszは2026年8月、キャリア休止中または検討中のエンジニアリングリーダー約20人へ聞き取りを行った。
“リーダーの離職増加”を示す中心的な数字は、個人的に話を聞いたCTO級10人のうち6人が退職へ向かっているというものだ。 無作為抽出の業界統計ではなく、離職や休止を考える人へ焦点を当てた取材である。業界全体の離職率が60%という意味ではない。
それでも、AI生成コードの量が増える一方、共有理解、品質、責任の仕組みが追い付かないという問題は、複数の2026年調査にも表れる。個別の強い逸話を一般化せず、どの組織条件で負担が増えるのか、経営者と技術責任者が何を合意すべきかを考える。
“6/10”は離職率ではなく、筆者が話したCTO級の小規模な聞き取り
Oroszの記事は、キャリア休止中、または真剣に検討しているエンジニアリングリーダー約20人への対話をまとめた。その入口として、個人的に尋ねたCTO級10人のうち6人が退職へ向かっていると述べる。対象者の選び方から、離職意向が高い人を多く含む。
理由はAIだけではない。仕事の悪化、会社の将来、長時間労働、より柔軟なfractional CTOへの移行、個人事業、燃え尽きなど複数が挙がる。AIネイティブ化への非現実的な期待や人員削減圧力はその一部である。
したがって“2026年にエンジニアリングリーダーの60%が辞める”とは書けない。一方、当事者の具体的な摩擦を発見する定性調査として価値がある。次に大規模な離職率、職務満足、採用期間で検証すべき仮説を示している。
6万行のAI生成PRは、速度ではなく責任の境界を壊す
記事に登場するあるCTOは、創業者がAIで6万行のプルリクエストを作り、生産性が上がったと喜ぶ場面を語る。問題は行数そのものではなく、誰が設計を理解し、問題を見つけ、障害時に対応するかが決まっていないことだ。
創業者は役職上、優先順位や品質基準を上書きできる。通常ならテスト不足で止める変更も、“経営者が作った”ことでレビューが弱くなる可能性がある。障害が起きると、オンコールや保守は技術組織へ戻る。生成の楽しさと運用の責任が別の人に分かれる。
AIコードを禁止すれば解決するわけではない。小さな変更、十分なテスト、設計文書、所有者、ロールバックを求める。同じ基準を創業者にも社員にも適用する。速く試す実験環境と、顧客へ出す本番環境を分けることが必要だ。
- 生成責任：誰が指示し、変更の目的を説明できるか
- 検証責任：テスト、セキュリティ、レビューを誰が行うか
- 運用責任：障害時に誰が調査し、切り戻すか
- 廃棄責任：実験コードをいつ削除し、負債を残さないか
複数調査が示すのは、生成量より共有理解への不安
Augment Codeが219人のエンジニアリングリーダーへ行った調査では、コードの48%がAI生成と回答され、55%が自社コードベースへの共有理解を失うことを懸念した。これは全企業の厳密な平均ではないが、理解が新しいボトルネックになっている兆しだ。
Madronaが49人のプロダクト・エンジニアリングリーダーへ聞いた調査でも、コード生成は広く普及し、次の課題がレビュー、統合、品質へ移る。コードの行数を開発速度の代理にすると、手戻り、障害、理解の時間が見えない。
ベンダー調査には、自社サービスの必要性を強く見せる動機がある。サンプルの業種、企業規模、回答者を確認し、一つの割合を普遍化しない。社内では、AI生成比率より、変更から本番までの時間、レビュー待ち、障害、修正、理解度を測る。
経営者とCTOは、“AIを使うか”ではなく本番へ出す条件を合意する
最初に、AIで作ったプロトタイプがどの段階まで自動で進めるかを決める。ローカル実験、社内デモ、限定ユーザー、本番でゲートを分け、データ、認証、決済、安全に関わる変更ほど人の承認を増やす。
次に、成果指標を出力量から顧客価値へ変える。生成行数、トークン量、PR数は活動であり成果ではない。リードタイム、利用率、解約、障害、復旧時間、保守コストを同じ表に置く。速さが品質や事業価値へつながったかを見る。
最後に、異論を遅さと扱わない。技術責任者がリスクを説明でき、経営者が期限と市場機会を説明できる場を定例化する。どちらかが拒否権だけを持つのではなく、実験範囲と失敗時の回復策を合意する。リーダーが辞めるまで摩擦を個人問題にしないことが、AI時代の経営責任である。
「エンジニアリングリーダー 離職 AI」を調べるときに確認したいこと
検索結果を読むときは、まず「エンジニアリングリーダー 離職 AI」に関する情報を、誰が、いつ、どの条件で公表したのか確認したい。本稿ではThe Pragmatic Engineer『The Great Engineering Leader Career Break』、Augment Code State of AI-Native Engineering 2026、Madrona 49 engineering leaders surveyを照合した。企業の公式発表は企画内容や提供条件を確かめる一次情報になる一方、自社の施策を説明する資料でもある。魅力的な表現を、そのまま第三者による効果検証と読み替えない。
次に、数字の分母、対象期間、対象地域、比較相手をそろえる。発表資料に人数や割合があっても、購入者全体なのか調査回答者なのか、単月なのか累計なのかで意味は変わる。記事やSNSで短く引用される過程では、但し書きが落ちやすい。元ページの表題だけでなく、調査概要、注記、利用条件まで戻り、公開されていない成果は「不明」と残す。
施策の流れは「大量生成 → レビューが滞留 → 責任者が疲弊」と整理できる。ただし、前の段階の人数が多ければ、後の段階も成功したとは限らない。認知、参加、利用、継続、売上、ブランド想起は別の指標である。自社で参考にするときは、どの一段を改善したいのかを決め、その前後だけでも計測する。ニュースの話題量を事業成果の代用にしない。
最後に、2026年9月8日時点の公開情報であることを意識したい。期間限定企画は終了し、商品、料金、対象店舗、ランキング、調査結果は後から更新される場合がある。実際に参加・購入・契約する際は公式の最新案内を確認する。企画分析として読む場合は、当時公表された事実、そこから導く解釈、まだ測られていない効果を三つに分けると、表面的な成功事例の模倣を避けられる。
- 確認できた事実：公式資料に日時、条件、対象、数字が明記されている
- 本稿の解釈：確認できた事実から、体験や事業の仕組みを読み解いている
- まだ分からないこと：売上、継続率、因果関係など、公開資料だけでは判断できない
- 実務での次の一手：自社の顧客と目的を決め、小さな検証で差を確かめる
この事例を、単発の話題づくりではなく継続的なブランド接点として考えるなら、AIエージェントPoCの成功指標とAI企業に編集者が必要な理由もあわせて読むと、判断の軸を置きやすい。
エンジニアリングリーダーの離職増加は、現時点で業界全体の統計として確定した話ではない。6/10は筆者が話したCTO級の小規模な聞き取りで、6万行PRも一人の証言である。それでも、生成量と検証能力の差は複数調査が示す。役職に関係なく本番ゲートをそろえ、顧客価値、障害、保守まで測ることが、技術責任者へ負債を押し付けない最低条件になる。
Sources / 参考資料