「Agents は standup しない」 — Mike Spitz (PFF) が見せた post-engineer 組織の 2 ヶ月実証 (AI Engineer Europe 2026)

Mike Spitz の AI Engineer Europe 2026 講演は、 「post-engineer engineering org」 という強い造語を core thesis に据えた組織論。 PFF (Pro Football Focus) は NFL / NCAA チーム向けのデータ分析会社 + consumer 向け fantasy football サービスを併営する 200 人企業 (うち engineers 約 20 人、 完全分散組織で India / Spain / 全米に散らばる)。 100M PV / year、 9M drafts / year を支える事業規模だが、 「sport betting に注力する間に consumer 側で competitors に置いていかれていた」 という stuck な状況にあった。

Mike が 2025 年 11 月に Claude Opus で個人実験を始め、 1 月から 3 月の 2 ヶ月で 2 engineers (strongest front-end + strongest full-stack) と組んで実施した case study が、 講演の中核データ。 結果は数字で表現すれば派手だが、 Mike の主眼は数字ではなく 「engineers が bottleneck でなくなった後、 ceremony はどうなるか」 の組織論側にある。

結果のサマリー — 25x deploy、 10x output、 顧客満足度 +1.1

Case study の 2 ヶ月の数字:

• Deploy 頻度 25 倍: 2 engineers が 1 日 5 deploy、 別の 10-engineer チームは 5 日に 1 deploy
• Output 10 倍: ticket 数 × code complexity の blended metric
• 建設期間が半分: 推定 4 ヶ月の features を 2 ヶ月で release
• 並列度の compounding 効果: 1 engineer が 1 ヶ月で unblocked、 そこから他の work も並列に走る (旧来は 2 人とも 3 ヶ月 block されていた)
• 顧客満足度 8.6/10 — 統計的有意な survey 結果 (旧来は 7-7.5 平均)

Mike は数字の caveat も率直に説明する。 「Small team は big team より速いに決まってる、 multiplier の一部はチームサイズ効果。 だが small tiger team も big team と coordinate する必要があった、 その overhead も含めての 25x」。 そして最も重要な metric は customer satisfaction: 「output が多くても deploy が早くても、 顧客が happy でないなら意味がない」。 8.6 という数字が、 通常 7-7.5 で頭打ちだった PFF の歴史的 ceiling を破った。

「Scrum did not survive」 — Ceremony の全廃

講演の core message が 「scrum did not survive」。 PFF が 2 ヶ月で廃止した ceremony:

• Sprint planning — ticket estimation はもう意味がない (estimation が outcome を予測しない)
• Daily standup — ticket status は PR の状態に bound されて自動更新 (PR open = in progress、 in review = review、 merged = closed)
• Sprint refining — spec → LDD flow で代替
• Retrospective — customer satisfaction survey + deployment frequency 等の development metric で代替
• Project manager の存在 — 「multiple games of telephone」 が不要に

残ったのは huddle 1 種類のみ。 「Every other day、 30-60 分、 engineers + product + design 1 人ずつ。 ここ数日 build したものを共有、 instant feedback、 production への MVP shipping を最速化、 feedback を最大化」。 「これは 2 decades 続いた process を一気に廃止する話、 strange に感じるかもしれない、 だが聞いて欲しい — this meeting の purpose は何だった? 単にみんなが今までやっていたから?」 と Mike は問いかける。

新 workflow — Spec → LDD → 自動 ticket → PR → QA agent

Mike が示す新しい development flow は、 ceremony を捨てた分、 仕様書類の整備に重心が移っている。

1. Spec phase: agent が engineer を interview する形式で spec を作る (agent が questions を投げ、 engineer が answer)。 spec に feedback を返す
2. LDD (Lightweight Design Document) phase: skill が過去の LDD 全てを analyze、 新規 LDD を生成。 これにより 「同じ ethos」 が全 features に共通する。 「Claude Code specific な感じ」 を排除し、 PFF らしい設計を維持
3. LDD distribute: 全 engineers が feedback、 ここで設計議論が完結
4. 自動 ticket 生成: blocking 関係まで自動分析、 並列度を最大化する形で発行
5. PR 自動生成 → PR ベースで ticket 自動更新
6. Staging deploy 後の QA agent: acceptance criteria を chronological に検証、 pass / fail を flagging

次の段階 (Mike が 「next couple months で」 と予告) は self-healing: QA agent が acceptance criteria 未達成を見つけたら、 別の agent が直す PR を 自動生成。 「Agent が agent を直す flow に入る」。 これは Anthropic の Skills loop と Karpathy の autonomous coding vision の中間で、 PFF が実装している 現実 layer。

「 Post-engineer engineering org Mike Spitz (PFF) が AI Engineer Europe 2026 で提示した造語。 過去 30 年の software engineering 文化 (agile manifesto、 software craftsmanship、 標準的な perks: foosball table / sleeping pod) は engineer が bottleneck であることを前提とした optimization。 AI agent が engineering capability の供給を大幅に拡大した今、 bottleneck は engineer ではなく decision-making / spec writing / customer satisfaction の領域に移った。 これに伴って engineering org そのものを再設計する必要があり、 Scrum / sprint planning / daily standup 等の従来 ceremony は捨てて、 spec → LDD → automated execution の new pipeline に移行する組織形態。 PFF の 2 ヶ月 case study で 25x deploy、 10x output、 顧客満足度 +1.1 という結果が示された 」 という時代区分

Mike が講演で繰り返す造語が 「post-engineer engineering org」。 過去の software engineering 文化を彼は以下のように整理する。 「Agile manifesto、 software craftsmanship、 foosball table、 sleeping pod、 他業界では存在しない perks — これらは全部、 engineer が bottleneck だから生まれた」。 Engineer が scarce で expensive で、 だから企業は彼らを最適化することで競争優位を得た。

「だが things are just changing now」。 Engineer が bottleneck でなくなった瞬間、 これらの infrastructure (組織構造、 process、 perks) は 過剰最適化された遺跡 になる。 「engineer は今でも必要、 だが 役割が違う」 — code を書く側ではなく、 spec / LDD / system design / agent guardrail を作る側に移る。

Mike が定義する 「これからの engineer」 と 「これから struggle する engineer」:

• Thrive する engineer: Curious な人。 「things が分からなければ、 自分で時間をかけて figure out する」 タイプ。 自律的に学習・実験する
• Struggle する engineer: Prescriptive spec が必要 な人。 「これをやって」 と細かく指示されないと動けないタイプ。 agent が代替する役割なので、 humans としての add value が減る

これは Karpathy の Software 3.0 / Agentic Engineering ビジョン と完全に符合する区分。 ただし Karpathy が 「未来の話」 として語るのを、 Mike は PFF で 2 ヶ月実施した case study の結果 として語る。

Engineer が残る場所 — Security、 Product feel、 Scale

Mike が 「これは agent に任せられない」 と明確に指摘する 3 領域:

• Security: 「Agents are use shortcuts」 — 効率優先で security を後回しにする傾向。 engineer の判断が必要
• Product feel: 「1 時間で何でも作れる時代になったが、 多くの tools は Claude Code が作ったような brand feel」。 PFF らしい product feel を保つのは engineer の仕事
• Scale and engineering complexity: agent は over-engineer したり 1000 行の不要なコードを書く傾向。 prescriptive な LDD でこれを防ぐのが engineer の仕事

この 3 領域での engineer の価値は agent では代替できない。 「Code review も、 systems design に関する review は engineer がやる、 variable name / style / opinionated な review は agent に offload」 という分業を Mike は推奨。 これは emotional friction (engineer 同士の細かいレビューでの human conflict) を取り除く副次効果もある。

Recommendations — Small company の advantage

Mike が他社に薦める進め方:

1. Boring repetitive task から始める: engineer が hate するもの、 だから buy-in が最大化する
2. Best engineers を最初に: system / 知識を最も持つ engineer から
3. Slow & phased: 全員一斉 onboard は失敗する
4. Non-critical system で experiment: 失敗しても damage が小さい領域から
5. 不要な process を削除: 「why this meeting?」 を問い直す
6. Guardrail を完成させてから autonomous flow へ
7. Engineering culture と patterns を skill に encode: 例えば API は service repository pattern

Mike が強調する structural な advantage: 「Small company は big enterprise より明確に有利。 20 人を scale するのと、 100 / 1000 / 10000 人を scale するのは別の難易度。 だが too shy にも too conservative にもなるな — 数ヶ月遅れは 6 ヶ月遅れになり、 12 ヶ月遅れになる。 compounding する」。 これは Brian Scanlan (Intercom) の 1,400 人組織の取り組み と興味深い対比を生む — Brian は 「medium / large org でも、 best people を full-time に置けば scale できる」 と反論する立場で、 同じ問題への異なる解。

編集所見 — PFF 事例の MEMEX 的位置づけ

この講演を MEMEX で取り上げる視点は 3 つ。

(1) 組織構造の paradigm shift の最も early な実証。 多くの企業は AI tool を導入しているが、 process (Scrum / sprint / standup) は維持している。 PFF は process そのものを捨てた 組織。 これが 2 ヶ月で functioning するという実証は、 「Agile は AI 時代に survive するか」 という業界議論への early data point。 これから 12 ヶ月、 他社が PFF model を copy するかどうかが watch metric。

(2) 「Engineer の役割定義」 が変わる、 という reskilling の signal。 Mike の 「Curious vs Prescriptive engineer」 の区分は、 これからの engineer recruiting / promotion / education の criteria を根本から変える可能性。 これは Karpathy の Software 3.0 や Sholto Douglas (Anthropic) の vibe coding 本番運用 での 「engineer の future role」 議論と通底する。 大学・ブートキャンプ・企業内 training が、 prescriptive な指示で動く engineer を量産する時代の終わり。

(3) Small company の戦略的 advantage が広がる。 PFF の case study は 「200 人規模・20 engineers」 で達成された。 これは Y Combinator / 起業家界隈にとって 「大企業の moat が AI で目減りする」 thesis の補強材料。 一方、 Intercom 事例は 「mature な permission / audit / control を持つ大企業も、 best people を集中させれば同じ adaptation ができる」 という反論。 この 2 つの事例が、 enterprise vs startup の AI competitive dynamics を再定義する出発点になる。

動画の構成

• (00:00) PFF 紹介、 sports data、 200 employees、 20 engineers、 分散組織
• (01:00) 競合に遅れていた状況、 Claude Opus で 2025 年 11 月から個人実験
• (02:00) 「Engineers as bottleneck」 という前提への疑問
• (02:30) Case study 結果 — 25x deploy、 10x output、 8.6/10 顧客満足度
• (04:54) Scrum did not survive 宣言
• (05:30) 廃止された ceremony リストと、 残った huddle
• (07:00) 新 workflow — Spec → LDD → 自動 ticket → PR → QA agent
• (09:00) Curious vs Prescriptive engineer の区分
• (10:00) Engineer が残る 3 領域 — Security、 Product feel、 Scale
• (12:00) Factory metaphor — composable skill 分解
• (13:00) Self-healing 次段階の予告
• (14:00) Recommendations — どう始めるか
• (16:00) Small company の advantage、 大企業との比較
• (17:00) 「Too shy にも too conservative にもなるな」、 締め

出典

• Agents Don't Do Standups: Building the Post-Engineer Engineering Org — Mike Spitz, PFF (AI Engineer Europe 2026, London)
• PFF (Pro Football Focus) 公式