誰が何をするのか？エージェンティック・プラットフォームのためのチーム・トポロジー

エージェンティック・プラットフォームは何が提供されるべきかを定義します。チーム・トポロジーは、誰がそれを提供し、チームがどのように連携してそれを実現するかを定義します。このシリーズの最初の記事では、「何が」必要かを問いかけました。つまり、信頼性の高いアプリケーションを大規模に生産するために、どのようなシステム的な機能（コンテキスト、ガードレール、ツール）が必要か、です。その答えはエージェンティック・プラットフォームであり、その核心にはエージェンティック・ファクトリーがありました。これは、エージェントが計画し、コーディングし、テストし、出荷するメカニズムです。しかし、プラットフォームはそれ自体で構築されるものではなく、さらに重要なことに、構築された方法と同じ方法で消費されるものではありません。根本的な問いが残ります。誰が何をするのか？ 真の問題：エージェンティック生産の認知負荷誰が何をするのかを問う前に、なぜ今回この問いが異なるのかを理解する必要があります。アプリケーションを構築することは、かつては時間の経過とともに役割を調整することを意味していました。ある人が設計し、別の人がアーキテクチャに異議を唱え、3人目がテストし、4人目がデプロイする、といった具合です。複雑さは現実のものでしたが、複数の人々に分散され、時間的に広がっていました。それぞれの役割が順次質問を提起しました。エージェントは状況を変えます。彼らは質問をしません。すぐに答えを生成します。疲れることもなく、休むこともなく、待つこともありません。彼らのスピードは彼らの強みであり、罠でもあります。かつて役割が順次提起していたすべての質問を、エージェントを操縦する人間は、プロンプトの短い期間で、事前に、並行して予測しなければなりません。フレームが不適切だと、エージェントは速度を落とさず、迅速に、しかし的外れな出力を生成します。AIによって認知負荷が消えるわけではありません。それは形を変えるのです。まず、予測の負担となります。人間がエージェントを起動する前にすべてを予見しなければ、出力は不十分なものになるでしょう。そして、エージェントは人間のリズムなしに継続的に生産するため、時間の経過とともに持続的な意思決定の流れ、つまり認知スループットの問題にもなります。大規模なエージェンティック生産の本当の課題は、複雑さが増大することではありません。それは、複雑さが一人の人間に、そして一人では吸収できない時間枠に圧縮されることです。これこそがプラットフォームが対処するものです。プラットフォームは、エージェントによって問い合わせ可能になることで、予測負担の一部を吸収します。「セキュリティについて心配しないでください」とは、エージェントがプラットフォームにどのように進めるべきかを尋ね、決定論的なコントロールが下流で結果を強制することを意味します。プラットフォームは思考を排除するわけではありません。人間が担うべき質問の範囲を絞り込み、人間の判断がかけがえのない、争点となる構造的な決定に集中できるようにします。したがって、認知負荷は、スケルトンとペイスが記述するように、単にチーム間で分散する量ではなくなります。エージェンティックな世界では、それは時間の経過とともに調整するスループットでもあるのです。 チーム・トポロジーは分散方法を教えてくれます。私たちはまだ吸収方法を述べる必要があります。それがこの記事の主題です。 チーム・トポロジー、負荷への回答この負荷の問題に取り組むために、私たちは4つのチームタイプと3つの相互作用モードを定義する組織モデルであるチーム・トポロジー1に依拠します。これは偶然ではありません。その根底にある主張はまさに認知負荷であり、チームは吸収できる以上の複雑さを抱えていては効果を発揮できません。スケルトンとペイスは、チーム全体に分散される構造的な負荷について考察していますが、私たちはそれを、上で述べたエージェンティックな生産行為の動的な負荷に拡張します。このモデルは、分散可能なものを分散し、プラットフォームが吸収すべきものを特定するためのグリッドを提供してくれます。私たちの立場を最初に述べましょう。以下に続くのは、エージェントによるアプリケーション生産が向かうべき組織的な目標であるという、前向きな確信です。もはや工場が何を必要とするかではなく、誰がそれを運用するかという問いになります。これこそがエージェンティック・プラットフォームが行うことです。技術的な複雑さを吸収することで、ビジネスチームは自身のドメインの認知負荷のみを担うことができます。開発者は役割を転換し、他の人々が生産を可能にするプラットフォームを構築します。対称的に、アプリケーション生産はエージェントを介してビジネスチームにも開放されます。 維持するものと適応させるものエージェンティックな文脈にチーム・トポロジーを適用するには、私たちの出発点について明確にする必要があります。その名前を主張しながらモデルを骨抜きにするのを避けるため、ここに境界線を引きます。私たちがそのまま維持するもの：認知負荷の指導原理、4つのチームタイプ、3つの相互作用モード、成熟時におけるコラボレーションからX-as-a-Serviceへの移行。私たちが適応させるもの、そしてその理由：ストリームアラインドチームは非技術的（ビジネス）でありうる。なぜなら、プラットフォームが技術的負荷を吸収するからである。彼らはエンドツーエンドの運用責任（実行、インシデント）を負わない。これもプラットフォームが吸収する。イネーブリングは単に一時的なものではない。生産者がもはや開発者ではないため、プラットフォームによって構造的に補償される。認知負荷はもはやチーム間で分散される量だけでなく、時間の経過とともに調整されるスループットでもある。プラットフォームはエージェンティック生産の上流における予測負担を吸収する。これらの適応は、スケルトンとペイスの意図を裏切るものではない。彼らが予期していなかった文脈、すなわちエージェントが生産し、人間がオーケストレーションする文脈にそれを適用するものである。 4つのチームタイプ、1つの目標目標は共有されています。組織の標準に沿った信頼性の高いアプリケーションを大規模に生産することです。しかし、役割は明確に異なります。エージェンティック・プラットフォームに適用された4つのチーム・トポロジーのチームタイプ。各チームは生産チェーンにおいて特定の役割を担います。ストリームアラインドチーム：アプリケーションの生産ストリームアラインドチームはプロダクトチームです。彼らはAIオーケストレーター（最初の記事で説明したエージェンティックファクトリーのエンジン）を動かし、ビジネス意図を定義し、動的なコンテキスト（仕様、プロダクト固有のガードレール、ドメイン知識）を提供します。この変革は深く、これらのチームはもはや開発者で構成される必要がありません。ますます、彼らはエージェントを通じて生産を直接推進するビジネスチーム（ドメインエキスパート、プロダクトマネージャー、アナリスト）となっています。この変化は生産をニーズに近づけますが、リスクも伴います。これらのチームは、アプリケーションを本番環境に投入することの意味合いを常に理解しているとは限りません。これこそが、他のチームタイプが存在する理由です。厳密に言えば、従来のチーム・トポロジーでは、ストリームアラインドチームは、運用やインシデントを含むバリューストリーム全体にわたるエンドツーエンドの責任を負います。しかしここでは、プラットフォームが運用責任（デプロイ、監視、ロールバック）を吸収します。ストリームアラインドチームは「何を」（意図、ビジネス品質）に責任を負い続け、プラットフォームは「どのように」（信頼性の高い本番デプロイ）を保証します。この分割には十分に成熟したプラットフォームが必要です。オンコール業務もそれに応じて分散されます。プラットフォームチームはシステム全体のインシデント（インフラストラクチャ、ガードレール、パイプライン）を処理し、ビジネス上の決定（コンテンツの削除、プロダクトのロールバック）はストリームアラインドチームに残ります。この「何を」と「どのように」の境界は、見た目よりも多孔質です。例えば、ブランドの一貫性はビジネス上の懸念（何を）ですが、その検証はプラットフォームによって自動化されます（どのように）。プラットフォームは最低限を保証しますが、ビジネスの卓越性を保証するものではありません。 プラットフォームチーム：機能の工業化プラットフォームチームは、3つのシステム的柱をX-as-a-Serviceとして提供します。システムコンテキスト：指示、役割、共有ビジネス知識、メモリ、例とパターンシステムガードレール：セキュリティ、信頼性、ブランドの一貫性、規約ツールとスキル：MCPサーバー、CI/CDパイプライン、評価、共有スキルこのモデルはセルフサービスであり、文書化され、バージョン管理され、摩擦なく消費可能です。設計努力は一度行われ、その後すべてのプロジェクトに適用されます。プラットフォームが「成熟している」のは… その言葉が空虚な約束にならないように、以下に観察可能な基準を示します。ガードレールカバレッジ：重要な側面（セキュリティ、信頼性、ブランドの一貫性）が口頭での合意ではなく、自動的にカバーされていることパイプラインの信頼性：デプロイ成功率が測定され、追跡されていること（社内SLA）セルフサービス比率：デプロイの大部分がプラットフォームチームの介入なしに行われていることドキュメントの完全性：公開されているすべての機能が文書化され、付属していること