チームをまたぐAI開発を調整する

ツールを取り巻くシステムを拡張する

一人の開発者なら、小さな試作品を自分で見ながら調整できます。組織全体では、一人がすべてのサービス仕様、リリース条件、例外を覚えていることに頼れません。AIを使うほど、これらの関係を明示することが重要になります。

ID管理、請求、データ、プラットフォームの各チームに関わる、架空の顧客エクスポートを考えます。各チームは自分の変更を素早く生成できます。それでも、顧客識別子やデプロイ順序の想定が異なると、組み合わせた機能は失敗します。

機能を、システム全体にまたがる変更として扱います。共有する仕様と、各判断の責任者を特定します。DORAの疎結合チームに関する研究は、少ない調整で作業し、リリースできる能力を重視しています。それはコーディングの速さだけでなく、アーキテクチャと仕事の進め方に依存します。DORAのガイドを参照してください。

共有する仕様を明示する

エクスポートについて、顧客識別子の形式、認可の意味、API応答、互換性を保つ期間を記録します。各仕様の責任を持つチームを特定します。利用側が変更案を知る方法を定めてください。

クライアントを同時に移行できない場合は、互換性を保つ移行を優先します。提供側の実装だけでなく、利用側が期待する動作もテストします。サービス自身のテストは成功しても、別のチームが誤って解釈するデータを返すことがあります。

すべての判断を中央委員会に集めないでください。関連する影響に責任を持つチームへ判断を置きます。不一致が重大なリスクを生む箇所には、共通の制約を使います。

レビューの対応能力を守る

生成が速くなると、レビュー待ちの作業が増える可能性があります。大きな差分、不十分な作業指示書、証拠の不足が、その状態を悪化させます。エージェントを増やしても、リリースまでの時間は改善せず、待ち行列だけが増える場合があります。

仕掛かり作業を制限します。対応できるレビュー担当者に合わせ、変更を小さく保ちます。レビューを依頼する前に、明確な目的、意味のある確認、関連するコンテキストを求めます。待ち時間は、実際のレビュー工数と分けて測ってください。

待ち行列を短く見せるためだけに、レビューの管理策を取り除いてはいけません。まず、繰り返しレビュー作業を生む原因を調べます。共通のテスト環境や、より明確なプラットフォームのインターフェースのほうが、効果的に原因を取り除けるかもしれません。

有用な情報を共有し、シークレットは制限する

最新のアーキテクチャ制約、インターフェース仕様、承認済みのパターン、責任者の情報を、チームとエージェントが使える場所に公開します。各項目に責任者と見直し条件を設定します。

アクセスはタスクに適した範囲に保ちます。共有の知識システムが、すべての顧客レコードや認証情報を、すべてのエージェントへ自動的に開示してはいけません。共通の指針と無制限のデータアクセスは、異なる機能です。

流れ全体で受け入れられた成果を測る

受け入れた要求から、利用可能な変更までの時間を追跡します。失敗した試行、手戻り、インシデントを含めてください。似たサービスを比較し、リスクとタスクの複雑さの違いを考慮します。

DORAの2025年の研究は、AIを組織システムの一部として扱います。この視点で、生成量の増加がどこで役立ち、どこで制約を明らかにするかを調べます。研究報告を参照してください。

ソフトウェアファクトリーは、共有コンテキスト、計画した作業、検証した変更、管理されたリリース、運用からのフィードバックを一貫してつなぐと役立ちます。AI開発の規模を広げるときは、この一連の流れ全体を評価します。