エージェント型プログラミング時代に開発チームを再発明する

ソフトウェアを書く速度が大幅に向上したことは、もはや開発チームが直面する唯一の課題ではない。Cursorのようなツールが、開発環境内でのコード提案から、仕様やチケットを起点とした完全なタスクの実行へと移行するなかで、問題は、何を構築する価値があるのかを組織が見極め、テストし、安全にデプロイし、その後に運用・保守できるかどうかに移る可能性がある。

これが、Hannah Foxwellによる「開発チームを再発明する」と題した講演の中心テーマである。この講演は、エージェント型プログラミングがエージェント自体の能力よりも、人間とプロセスに及ぼす影響に焦点を当てている。Foxwellは、ツールがどれほど高速化しても重要であり続けると考える3つの柱に基づいて主張を組み立てている。

速度不足から能力過剰へ

Foxwellは、年に2回ソフトウェアをリリースしていたチームが、アジャイル、クラウドコンピューティング、DevOps、継続的デリバリーを経て、1日に複数回デプロイするようになるまでの道のりを描いている。かつて遠い目標として語られていた高速化が、組織がまだ活用方法を理解できていない現実へと変わり始めていると、彼女は考えている。

エージェント型プログラミングのモデルでは、エージェントが仕様を分解し、コードとテストを書き、さらにデプロイや監視を支援できる。しかし、この能力はプロダクトマネジメントに逆方向の圧力を生む可能性がある。開発チームが、組織が明確で十分に準備された要件を用意する能力を上回る速度で作業を実行できてしまうからだ。そのためFoxwellは、あらゆるアイデアや依頼を受け入れることが解決策だとは考えていない。それでは、肥大化し焦点の定まらない製品につながる可能性がある。

第1の柱：構築する価値のあるものを作る

Foxwellは、コードは目的ではなく、ユーザーの現実の問題を解決するための手段だと強調する。アイデアを検証するコストが下がるにつれ、長期的な製品内のコミットメントに変える前に、プロトタイプを作成してユーザーと試すことが望ましくなる。

本稿が提示するパターンの一つが、アイデアと検証の距離を縮める「プロトタイプを作るプロダクトマネージャー」である。アイデアが迅速なプロトタイピングの能力を超える場合には、プロダクトマネージャーと開発者を組み合わせる。また、顧客の近くで働き、その問題を解決する権限を持つエンジニアであるフィールドエンジニアの役割や、自身が製品のユーザーである、またはユーザーに近い存在であるために製品の形成に参加する「プロダクトエンジニア」にも言及している。

Foxwellは、チームの規模と構成比を見直す実験も紹介している。6～8人の開発者と1人のプロダクトマネージャーで構成されるチームモデルの代わりに、一部の組織はより小規模なチームを試している。一方、Andrew Ngは逆方向のモデルとして、1人の開発者に2人のプロダクトマネージャーを配置し、1人の開発者がエージェント群を調整できるモデルを提案した。これらのモデルは固定的なルールとして提示されているのではなく、ボトルネックの位置が開発能力から要件の明確さと意思決定の速度へと変化していることを反映した実験である。

一方で本稿は、機能を出荷してすぐ別のタスクに移り、その利用状況を確認しないこと、顧客のあらゆる依頼を受け入れること、最も高い報酬を得ている上位責任者の意見を優先順位の基準にすることなどの慣行に警鐘を鳴らしている。ソフトウェアを書く速度が速くなる環境では、ユーザーリサーチ、ユーザー体験、価値を検証する能力が、実装速度そのものより重要な差別化要因になる可能性がある。

第2の柱：速度には安全性が必要

変更量の増加には、それに対応できる本番化のパスが必要である。Foxwellは、テストカバレッジの不足や手作業の工程がデプロイパスをボトルネックにし、ユーザーに届く前に変更が蓄積する可能性があると警告している。

そのため本稿は、速度と自動テストを結び付け、エージェントを継続的なテストの作成に利用したり、チームによる技術的負債への対応、旧プラットフォームからの移行、コードベースの再構成を支援したりする例に触れている。重要なのは、遅いプロセスの上に人工知能を追加することではなく、新たな変更速度に耐えられるよう本番環境への道筋を再設計することである。

Foxwellは、信頼性と安全性を速度と引き換えにしてよいものではないと強調する。サービスレベル指標、サービスレベル目標、エラーバジェットを活用し、許容される失敗水準を超えた場合に組織が何をするのかを定めた明文化されたポリシーを設けることを提案している。例えば、リリースを遅らせたり、信頼性とレジリエンスにリソースを振り向けたりする。

また、段階的デプロイ、フィーチャーフラグ、A/Bテスト、ブルーグリーンデプロイは、多数の変更をすべてのユーザーに一度にさらすことなく管理するのに役立つと考えている。サイト信頼性エンジニアリングチームや社内プラットフォームチームの役割も見直し、開発チームに安全で整備された経路を提供する、コンサルティングおよびイネーブルメント機能として捉えている。

実際には何が変わるのか？

この講演から導かれる編集上の結論は、エージェントだけで開発チームが小規模になることや、職種が消滅することが証明されるわけではないということだ。確実に起こるのは、ボトルネックの位置が移動することである。コードの生産から、問題の選択、価値の検証、テストの拡大、信頼性の制御、迅速な意思決定へと移る。

未解決の問いは、組織が新たな能力をより良い製品の構築やアイデアの検証に使うのか、それとも機能をさらに積み重ねることで対応するのかという点である。開発者、プロダクトマネージャー、プラットフォームチーム、信頼性チームの新たな比率も、まだ実験段階であり、確立された結果ではない。したがって、エージェント型プログラミングの導入には、コード行数やリリース速度だけでなく、製品品質、インシデント、ユーザー体験への影響を測定することが必要になる。