実行ではなくガバナンスを軸にした役割の再設計

従来のチームの役割は実行層を軸に設計されている：誰がフロントエンドコードを書くか、誰がバックエンドコードを書くか、誰がテストを書くか、誰が運用を担当するか。Agentが実行層を引き受けるとき、役割の定義は実行層からガバナンス層へと上がる必要がある：誰が何をするか定義するのか、誰がどう行うかをオーケストレーションするのか、誰が正しく行われたか検証するのか。

現在、業界には2つの主な探索方向がある。

Alpha Wolfモデル。 PingCAPにおけるEd Huangの実践がこの方向を代表する：トップレベルのエンジニアがプロダクトやモジュールのエンドツーエンドのオーナーシップを持つ。この人物はプロダクトマネージャー、アーキテクト、リードプログラマー、テストリードの役割を同時にこなし、自分の縄張り内でAgentの群れを指揮する。時間の90%をAIの作業出力の評価に費やし、コードを書くことにはほとんど使わない。

Alpha wolfモデルの利点は意思決定チェーンが極めて短いことだ。1人が完全なコンテキストを持ち、クロスロールのコミュニケーションも不要、承認待ちも不要で、非常に高速にイテレーションできる。Ed HuangはこのモデルでTiDBのPostgreSQL互換レイヤーをほぼプロダクションレベルまで書き直した。

Alpha wolfモデルのボトルネックは人材だ。この役割にはプロダクトセンス、アーキテクチャ能力、コーディング経験、品質意識の組み合わせが必要だ。これらの基準を満たす人材は極めて稀であり、そのような人材は他社で働くよりも自ら起業することを好むことが多い。ほとんどの企業のチームはそのような人材を見つけることも引き留めることもできない。

Product Tri-Ownershipモデル。 コミュニティが提案するもう一つの方向は、スーパー個人の能力を3つの訓練可能な専門家の役割に分解することだ。このアプローチは建設業界からインスピレーションを得ている：建築家が空間を定義し、構造エンジニアが構造を設計し、独立した検査官が検収を行い、建設会社が施工する。Agent時代では、建設会社がAgentだ。

Product Ownerは何をするかに責任を持つ：プロダクトビジョンの定義、ユーザーストーリーと受入基準の管理、優先順位の決定。出力そのものではなく、出力の価値に説明責任を持つ。

Tech Ownerはどうやるかに責任を持つ：詳細設計、Agentワークフローのオーケストレーション、ツール選定。中核的な責任は複数Agentのコラボレーションパターンの設計と最適化だ。タスクタイプが異なればワークフローも異なる。バグ修正のワークフローは新機能のワークフローとは異なり、Tech Ownerがそれぞれに適切なワークフローを設計する責任を負う。

Quality Ownerは正しく行われたかに責任を持つ：品質プロセスの設計、ライフサイクル全体にわたる品質管理、独立した検証。Quality Ownerの存在は共謀の問題を直接的に解決する：コードを生産するAgentとコードを検証するAgentが異なる人物によって管理され、利害が一致しないため、自然な敵対関係が生まれる。

PTOモデルの利点は再現性だ。3つの役割それぞれが、スーパー個人よりも育成しやすい。欠点は組織変革が必要であり、3人の間の緊密な協働のケミストリーと、役割間の境界の調整が必要なことだ。

これら2つのモデルの他に、より緩やかなトレーニングベースのアプローチもある：組織構造は変えず、経験豊富な1人がスキル、エージェント、ワークフローをカスタマイズし、チームメンバーがプロセスに従って実行する。参入障壁は最も低いが、価値の天井も最も低い。