AIコーディングエージェントの普及で、実装は確実に加速しました。
一方で、速く「書ける」ことと、速く「出荷できる」ことは別です。生成が加速するほど、検証（テスト・レビュー・リリース判定）が律速になりやすく、ここを人手で吸収しようとしてもスケールしない局面が増えます。

本稿では、AIが標準化する直前のアジャイルを旧来モデルとして振り返りつつ、AI時代に不足しがちな点を整理します。
その上で、最小単位として Three Amigos（Business / Development / Testing） を固定化し、PdM・QAエンジニア（Quality Engineering）・フルスタックエンジニア の3ロールで回す少数精鋭チームを提案します。

旧来モデルとしてのアジャイルを振り返る

AIが一般化する前、現場の多くは「小さなクロスファンクショナルチーム」に収束していきました。そこには明確な合理性がありました。

小さいチームは同期コストを下げる

チームが大きいほど、意思決定の待ち時間と認識合わせのコストが増えます。
アジャイルが「小さなチーム」を重視してきたのは、速度の源泉がコード量ではなく 意思決定と学習の速度 だと分かっていたからです。

AWSによると、需要が増えてもチームを大きくするのではなく、複数チームへ分割することで、機動性と自律性を保つと言われています。

As demands for a product or service grow, rather than expanding the team to many more members, we look for ways to split teams into separate two-pizza teams…

小さいだけでは足りない：職能横断で手戻りを減らす

小さなチームでも、要件・実装・テストが分断されていると、工程間の受け渡しが増えて手戻りが発生します。
そこでアジャイルは「価値提供に必要な職能をチーム内に揃える」方向へ進みました。

この文脈で参照しやすいのが Three Amigos です。Agile Allianceによると、Three Amigosは「開発の前・中・後」でインクリメントを検討するための主要な視点だと言われています。

Three amigos refers to the primary perspectives to examine an increment of work before, during, and after development.

旧来モデルの合理性は、ここまでで概ね説明できます。

小さくして同期コストを下げる
職能を揃えて手戻りを減らす
短い反復で学習速度を上げる

AI標準化で露出する課題

AIが入ってまず起きるのは「実装が速くなる」ことです。
しかし、その次に露出するのが「品質の律速」です。

実装が速くなるほど、品質管理がボトルネックになる

IT Revolutionは、検証と妥当性確認が制約なら、コード生成を速めても全体の生産性は上がらないと指摘しています。

If verification and validation are your constraints, generating more code faster does nothing to improve overall productivity.

platformengineering.org も、AIで出力が加速すると品質管理が支配的ボトルネックになる、と整理しています。

Quality control becomes the new dominant bottleneck in your development lifecycle, limiting your ability to harness AI's potential.

この2つを「現場の症状」に落とすと、だいたい次に収束します。

PR/差分が増え、レビュー待ち行列が伸びる
テストを増やさないと品質が落ち、CIが重くなる
仕様・設計の揺れが増え、説明と合意のコストが増える

「人を増やして吸収」が効きづらくなる

AI時代に「人を増やす」が効きづらい理由はシンプルです。

人が増えるほど、認識合わせの回数とコストが増える
AIは“高速に差分を作れる”ので、同期すべき対象（仕様・設計判断・PR）が増える
結果、増員が「局所最適の延命」になりやすい

提案：Three Amigosを「チーム最小単位」として固定化する

本稿でいうThree Amigosは、次の3ロールにマッピングします。

Business：PdM（価値・優先度・合意形成）
Development：フルスタックエンジニア（実装・統合・運用）
Testing：QAエンジニア（品質戦略・自動化・ゲート設計）

重要なのは「3人に限定しろ」ではありません。
ただし、AI時代に“出荷”を回す最小単位を設計するなら、まずこの3視点を固定し、必要に応じて衛星ロール（デザイン、セキュリティ、SRE、法務など）を追加する方がスケールしやすい、と考えます。

PdM（Business）

課題定義、価値仮説、優先度付け
受け入れ基準の最終決定（何を満たせば“出荷”か）
コンテキストの保全（暗黙知を明文化し、誤解余地を減らす）
リリース判定の説明責任

QA（Testing / Quality Engineering）

ここでいうQAは「最後に手で検証する人」ではなく、品質をゲートとしてシステムに埋め込む人です。
品質の議論を「気合」や「頑張って読む」から引き剥がし、テストとCIに落としていきます。

品質戦略（どこを、どの層で、どのコストで守るか）
テスト自動化の設計と実装（E2E/API/ユニットの配分）
CIに統合して品質ゲート化（落ちるものは出荷できない）
フレーク対策、テストデータ、計測、可観測性の整備
探索的テストで「仕様化しづらい違和感」を拾う

ポイントは、AI時代に「テストを手で回す人」を増やしてもスケールしにくいことです。
スケールさせるなら、品質は“人数”ではなく“仕組み”で守る必要があります。

フルスタック（Development / AI活用前提のEngineering）

AI時代のフルスタックは「何でも屋」ではなく、端から端までの整合性を崩さない実装者です。
そして、今後の重要ポイントはテスト駆動開発（TDD）です。

実装（フロント・バック・インフラ統合まで）
テスト容易性を落とさない設計（境界、依存、契約）
TDDを前提に、回帰テストを“資産”として増やす
変更のドリフト（AIが少しずつ壊す）を、テストで早期検知する
CI/CDを壊さない（速さの前提を守る）

ここでいう「テストエンジニアが不要になる」は、“テスト実行係”が不要になり得るという意味です。
一方で、品質戦略と品質ゲート設計（Quality Engineering）は残り、むしろ重要度が上がります。

プロジェクトが大きくなったときのスケール戦略

「3人の最小単位」は、小規模プロダクトだけの話ではありません。
むしろ大きなプロジェクトほど、チームを大きくするより 小さな単位を複製して束ねる方がスケールしやすいです。

現時点の現実解：Three Amigosを複製して束ねる

Three Amigos（3人）は固定化する
上位でPjM（またはプログラム管理）が、巨大タスクを分割し、各チームへ配る
チーム間の依存関係は最小化しつつ、必要な同期だけを設計する

スケールの具体策として分かりやすいのが Scrum of Scrums です。Atlassianによると、Scrum of Scrumsは複数チームを共通のゴールへ向けて調整するスケールドアジャイル手法だと言われています。

Scrum of Scrums is a scaled Agile technique for coordinating multiple teams working toward a common goal.

現時点の運用モデルと将来展望

現時点では、各ロールが手元のPCでAIと対話し、成果物を持ち寄る運用が現実的です。
この形で壊れやすいのは「合意のズレ」と「品質ゲート不在」です。なので、最小限これだけは固定します。

受け入れ基準はテスト可能な形に落とす（曖昧語を減らす）
品質ゲート（CI）で合否を出す
人間レビューは観点固定で薄くする（全部読まない）

OpenAIは、AI支援が計画からデプロイまでSDLC全体に及び得る、と述べています。

The entire software development lifecycle is potentially in scope for AI assistance…

最小チームで回す作業分解（例）

PdM：課題と成功条件を一枚にする（AIで叩き台 → 人間が確定）
3者：短いThree Amigosセッションで、受け入れ基準と境界条件を確定
QA：受け入れテスト/契約テストを先に作る（AIで雛形 → 人間レビュー）
フルスタック：AIで実装 → テストが通るまで閉ループ
PdM：価値としてOKか（デモ/探索）を最終確認

将来の展望：AIが「チームの一員」になる可能性

ここまでは「各人が手元のPCでAIと個別にやり取りする」前提で書きました。
この形は導入が簡単で、今すぐ始められるのが強みです。

ただ、AIコーディングエージェントが標準化していくと、AIは“個人の道具”から“チームの共通戦力”へ移る可能性があります。
具体的には、次のような状態です。

チームに 共有のAI（専属エージェント） が所属する
チームコンテキスト（仕様、決定、テスト、運用）を保持し、役割横断で補助する
実装だけでなく、レビュー観点の提示、テスト生成、CI修正提案までを一体で回す

この場合、Three Amigos（3人）は維持しつつ、運用上は 「+AI」で4人体制に近い働き方になります。
一方で、AIが強くなるほど「技術」より「運用設計」の比重が上がります。最低限、次の設計は避けて通れません。

参照できる情報範囲（アクセス権限）
変更できる対象の範囲（操作権限）
監査ログ（誰が、いつ、何を、どこまで変えたか）
失敗時のロールバックと責任境界

AIを“人員”として数えるかどうかは、組織のガバナンス次第です。
しかし、AIが仕事を担う割合が増えるほど、最小単位の設計は「人を増やさずにスループットを守れるか」に収束します。その観点で、Three Amigosは将来像にも接続しやすい形だと考えます。

派生としての三人構成を軽く紹介する

本稿の提案は Three Amigos（Business / Development / Testing）です。
ただし、目的によって「三人の最小単位」を別に設計する流派もあります。ここでは派生として軽く触れます。

例：Product Trio（PdM・デザイナー・エンジニア）

Product Trio（PdM・デザイナー・エンジニア）は、主に Discovery（何を作るか）を前進させる最小意思決定単位として語られます。

Product Talkによると、Product Trioは「PdM・デザイナー・エンジニア」で構成されると言われています。

A product trio is typically comprised of a product manager, a designer, and a software engineer.

また、SVPGのMarty Caganは、生成AIの進展により平均的なプロダクトチームが8人規模から3人（PdM・デザイナー・エンジニア）へ縮小していく可能性に言及しています。

…over the next 3-10 years we’ll continue to see the average product team drop from something like 8 people… down to 3…

本稿はこの系譜を否定も採用もしません。
言いたいのは、出荷の律速（テスト/レビュー/運用）を強く意識するなら、Three Amigos（Business/Development/Testing）を最小単位として設計する方が説明責任を持ちやすい、ということです。

デザイン（UX）関与の設計

本稿の主張は「デザイナーを不要にする」ではありません。
主張は、Three Amigos（PdM/QA/フルスタック）を“出荷の最小単位”として固定し、デザインやUXの関与はプロダクト特性に応じて設計する、というものです。

実務上は、次の選択肢が現実的です。

プロダクトの競争優位がUXに強く依存するなら、デザイナーをチーム内（または強いマトリクス）へ寄せる
UIがデザインシステムや既存フレームワークで強く制約されるなら、デザインは組織上位で共通化し、各チームはガードレール内で自走する
デザイン作業の“制作”はAIや外注に寄せ、重要テーマだけデザインレビューやDiscovery同席を確保する

中央集約は、需要が増えたときに待ち行列が生まれやすい点が注意です。
「制作物を受注する中央組織」ではなく、「デザインシステム・ガイドライン・レビュー観点」を供給する中央組織、という設計の方が崩れにくいです。

おわりに

AIで実装は加速します。
だからこそチームの競争力は「誰が速く書くか」ではなく、次に移ります。

何をゲートで固定するか
どこに人間の判断を集中させるか
増員に頼らず、プロセスでスループットを守れるか

Three Amigosを最小単位として固定化し、AIに作業を割り当て、テストとCIで合否を出す。
この設計は、AI時代の少数精鋭化に対して、再現可能な道筋になり得ます。

参考リンク

Agile Alliance: Three Amigos
https://www.agilealliance.org/glossary/three-amigos/
AWS Executive Insights: Amazon's Two Pizza Teams
https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/
IT Revolution: The Revenge of QA
https://itrevolution.com/articles/the-revenge-of-qa-how-ai-code-generation-is-exposing-decades-of-process-debt/
platformengineering.org: The AI quality bottleneck every platform team will face
https://platformengineering.org/blog/the-ai-quality-bottleneck-every-platform-team-will-face
OpenAI: Building an AI-Native Engineering Team
https://developers.openai.com/codex/guides/build-ai-native-engineering-team
Product Talk: Core Concept: The Product Trio
https://www.producttalk.org/product-trio/
SVPG: A Vision For Product Teams
https://www.svpg.com/a-vision-for-product-teams/
Atlassian: Scrum of Scrums
https://www.atlassian.com/agile/scrum/scrum-of-scrums