フロンティアチームがAIネイティブ開発をどのように再発明しているか

フロンティアチームは、AIを単にコードを速く書くために使っているわけではない。彼らはソフトウェアの構築方法そのものを再設計している。その結果、4.5倍、場合によっては10倍以上の生産性向上を実現している。

6人のエンジニア。76日間。当初は30人の開発者が12～18ヶ月かけて行うと見積もられたプロジェクトが、四半期内に納品された。これは仮定の話ではない。Amazon BedrockチームがAIをコーディングの近道として扱うのをやめ、それを自分たちの働き方の基盤として扱い始めたときに起こったことだ。このチームは、5ヶ月間で過去10年間よりも多くのプロダクションコードを出荷した。

このようなチームと他のチームとの差は急速に広がっている。AIコーディングエージェントはソフトウェアが書かれる速度を根本的に変えたが、それが顧客に届く速度は変えていない。コミットは急増し、CI/CDパイプラインはかつてないほど忙しくなっている。しかし、プロダクションに出荷される機能のペースは同じではない。ボトルネックはエージェントの出力生成能力ではなく、エージェントが適切な判断を下すために必要な知識へのアクセスと、その現実に合わせて仕事を再編成するチームの意欲にある。

私たちはこの問題を解決したチームを「フロンティアチーム」と呼んでいる。彼らはエリート研究室に限定されず、業界や企業規模を問わず存在し、共通の規律を持っている。それは、AI導入をツールの展開ではなく、エンジニアリングへの投資として扱うことだ。どのエンジニアリングチームもフロンティアチームになれる。

AmazonにおけるAIネイティブ開発への3つの道筋

AIネイティブソフトウェア開発は、AIをソフトウェア構築の基盤として扱い、人間の専門家が能力を高めたエージェントを指導する。チームがエージェントをどのように指導するかが結果を左右する。Amazonでは、開発におけるAIの主な推進力は、ドキュメント、調整、運用などの非コーディングタスクに開発者が費やす時間を削減し、技術的負債を解消し、数千の小さな「ツーピザ」チーム間のコーディングの不整合を最小限に抑えることだった。私たちは数百のエンジニアリングチームにわたって実験を行い、少なくとも3つの道筋を特定した。専門家が課題に取り組むパスファインダーイニシアチブ、明確に定義された計画を実行する構造化スプリント、既存のアプローチとAI適応ワークフローでチームを半分に分割するインサイチュ実験である。これらの道筋は構造は異なるが、同じ洞察に収束する。

パスファインダーイニシアチブは管理された実験だった。6人のシニアエンジニアが単一のミッションを与えられた。Amazon Bedrock推論エンジンの再構築である。当初は30人の開発者が12～18ヶ月かかると見積もられたプロジェクトだ。チームは人員を増やす代わりに、最初の数週間をワークフローの再設計に費やし、個別のタスクから目標主導の成果へと移行し、複数のエージェントを並行して実行し、エージェントがオフタイムに独立して作業できるシステムを構築した。プロジェクトは76日で納品された。正規化されたコミット速度で測定した個人の開発者生産性は約20倍に向上した。コミット数は週2回から40回になった。このチームは5ヶ月間で、過去10年間のプロジェクトよりも多くの高品質コードをプロダクションに投入した。

構造化スプリントは別のアプローチをとった。Prime Video Financial Systemsチームは、パスファインダーモデルに触発されて10日間の実験を実施した。6人のエンジニア、1つの部屋、ゼロコンテキストスイッチ、オンコール義務なし、他のプロジェクトなし、限られた会議。シニアエンジニアが3週間かけて複雑さを適切にスコープされたタスクに分解し、詳細な要件を準備した。チームは複雑な機能作業には仕様駆動開発を、要件がすでに明確なタスクには直接エージェント支援開発を使用した。10日間で、ベースラインの96件に対して556件のコミットを生成し、90週間のプロジェクト見積もりを24週間に短縮した。これは約6倍のスループットと4倍の加速に相当する。彼らはAIによる利得を3つの要因の乗算に帰した。低判断作業の加速（1.5倍）、高判断作業への集中（1.5倍）、エージェントが捕捉したドメイン専門知識への即時アクセス（1.5倍）。いずれかの要因を取り除けば、利得は崩壊する。チームは現在、通常業務におけるこれら3つの要因を最適化しようとしている。

インサイチュ実験では、研究された50以上のチームのうち、新しいツールと新しい実践の両方を実装した25チームが、既存のワークフローに単にAIを追加したチームを上回った。Amazon Storesは、典型的な開発チームを対象に、通常のバックログに対して構造化パイロットを実施し、特別な条件も選抜されたエンジニアもなしにKiroと目的に特化したAIツールを使用した。生産性の中央値向上は4.5倍で、一部のチームは正規化されたデプロイ速度で10倍以上の改善を達成した。Perfect Order Experienceは現在、機能を2週間ではなく午後には出荷している。WW Groceryは設計ドキュメントの作成を5日から数時間に短縮した。

異なる道筋、同じ教訓。重要なのはツールだけでなくワークフローである。

フロンティアチームになるための5つのステップ

3つの道筋すべてにわたって、最もパフォーマンスの高いチームは5つの実践を共有しており、そこには共通の論理がある。エージェントのコンテキストへの障壁を減らし、エージェントが独立して行える作業の表面積を増やすこと。

ここでフロンティアチームは以前の習慣から分岐する。従来のアプローチは個々のコード生成の速度を最適化していた。フロンティアチームは別のものを最適化する。正しくプロダクション可能なソフトウェアが顧客に届く速度である。その違いが以下の各実践を推進する。

エージェントコンテキストに投資する。最も先進的なチームは、エージェントステアリングファイルやチームの慣習、コーディング標準、テスト、コードベースナビゲーションに関するガイダンスを通じて、プロジェクトや知識をエージェントが消費しやすくすることに多額の投資を行っている。Bedrockインフラチームは、すべてのコードとドキュメントをモノレポに配置し、AIエージェントが生成したインラインコメントを永続的なメモリとして扱い保持した。このステップをスキップしたチームは、なぜエージェントが同じ間違いを繰り返すのか疑問に思うだろう。

スピードを上げるために減速する。上記の実践には時間がかかり、チームに忍耐が求められる。すべての高パフォーマンスチームは、モデルを学習するにつれて最初は物事が遅くなったと報告している。彼らはクロスファンクショナルな専門知識をエージェント向けの再利用可能なステアリングドキュメントにエンコードし、LLMが推論できるようにリポジトリを再構成し、AI消費のためのコメント追加やコード分割の再アーキテクチャを行った。その学習曲線を乗り越え、期待される成果を最初に定義したチームは、複合的な加速を経験した。すぐに利益を期待してワークフローを変えなかったチームは失望した。最初の2週間は遅く感じられることを覚悟せよ。その後は劇的に速くなると期待せよ。2週目で諦めたチームは複合効果を決して目にしない。

エージェントを監視するのではなく養う。フロンティアチームは、明確な成果を伴う適切にスコープされたタスクの安定したバックログを維持し、複数のエージェントを並行して実行し、出力を非同期にレビューする。ビルダーは、短いバーストで主要な機能を完了し、エージェントがタスクを完了するのを積極的に待っていなくても作業が進むと報告している。あるプリンシパルエンジニアは、エンジニアがコードレビュー、運用サポート、会議の合間にエージェントが作業しているため、「数時間の連続時間」だけで完全な変更を出荷した。

コードが書かれる前に意図を明確にする。構造化された仕様、詳細な要件文書、適切にスコープされたタスク分解のいずれを通じてでも、フロンティアチームはエージェントがコード生成を開始する前に「完了」がどのようなものか明確なコンテキストを持つようにする。このアプローチを使用する一部のチームは、コードのわずか1〜2％しか手書きせず、以前よりも1人あたり週にかなり多くのコミットをプッシュしていると報告している。

「テストを左にシフトする」。フロンティアチームは、エージェントがコードがパイプラインに到達する前にすべての統合テストをローカルで実行し、自己修正できるようにツールを構築する。Prime Videoチームは、問題を早期に捉える自動ガードレール、コンポーネントテスト、パフォーマンステスト、フォーマッターに投資した。コードレビューの焦点は、コードスタイルや命名規則ではなく、インターフェース定義とアーキテクチャ上の決定に移った。

テクノロジーリーダーが今日できること

すべてのチームがこれらの結果を達成するわけではない。コンテキスト構築フェーズをスキップし、AIをドロップイン代替として扱い、仕事の再編成なしに即座の利益を期待するチームは一貫してパフォーマンスが低い。業界全体の開発者がAIコーディングツールを採用しているが、全員が生産性の向上を見ているわけではない。彼らは間違ったツールを使っているのではなく、間違ったワークフローの中で正しいツールを使っているのだ。

主なポイント：

AIを最大限に活用するために仕事のやり方を変える。

3つの要因が掛け合わさって成果を生み出す：AIによる低判断作業の処理、高判断作業への中断のない集中、ドメイン専門知識への即時アクセス。

まずパイロットし、それからスケールする。

実用的な出発点は、広範な展開ではなく、意図的なパイロットである。生産コードを書く前に、最初の数週間をエージェントコンテキスト（ステアリングファイル、仕様テンプレート、モノレポ）の構築に費やすことを厭わない小さなチームから始めよ。チームにワークフローを再編成する権限を与えよ。コミット速度、デプロイ頻度、解決時間、そして開発者満足度スコアを測定せよ。そして、彼らが学んだことを使って、組織の残りの部分のためのプレイブックを構築せよ。

4.5倍から10倍以上の生産性向上を達成しているチームは、単により良い技術を採用したのではない。彼らはそれを使って異なる働き方を理解したのだ。その決断は今日、すべてのエンジニアリング組織が利用できる。もちろん、コードコミット速度は物語の一部に過ぎない。私たちはソフトウェア開発ライフサイクルのあらゆる側面、リリース管理、運用、セキュリティ運用の合理化、EOLアップグレードやソフトウェアエンジニアリングに伴う無数の差異のないタスクへの取り組みを支援したいと考えている。次のブログでは、これらにどのように取り組んでいるかについて説明するので、ご期待いただきたい。

フロンティアチームの詳細 >

AWS Summit New York CityでAIネイティブ開発の詳細を聞く。