組織再構築：Agentが協働の前提を変えたとき

🚧 本章は開発中です。以下はコア論点の概要であり、完全版は今後のバージョンで公開されます。

第2巻が解決したのは個人の効率の問題です。一人が複数のAgentを並列で指揮し、個人の産出量は数十倍に達し得ます。しかしチーム内の複数の人がこれを始めると、新たなボトルネックが現れます。チームの分業とプロセスは人間の実行速度に合わせて設計されており、Agentの産出速度に耐えられません。

最も直感的な症状はレビューの待ち行列です。Agentが一日に20個のPRを産出しますが、code reviewのプロセスは人が一日に1〜2個のPRを書くペースで設計されています。デプロイウィンドウは一日2回で、PRが滞留し、マージ衝突が頻発します。コードは瞬時に出せますが、組織のプロセスがパイプラインの中で詰まらせています。

プロセスよりも深層にある問題はチーム構造です。従来のチームは機能別に分業しています。フロントエンド2名、バックエンド3名、QA 1名。この分け方は各人の産出量がおおむね同等であり、作業量を人数で均等に分配できることを前提としています。Agentが個人の産出量の差を2倍から10倍に拡大すると、この前提は成立しなくなります。Agentを使いこなす人は大部分の仕事をしているのに同じ給与だと感じ、使えない人は焦りと疎外感を覚えます。問題は誰がより努力しているかではなく、組織構造の設計前提が変わったことです。

Conway's Law は Agent 時代でも依然として有効です。システムのアーキテクチャは組織のコミュニケーション構造を反映します。チーム境界を再定義しないままAgentを大規模に導入すると、産出されるコードは旧い組織境界を反映し、統合の摩擦は減るどころか加速的に露呈します。正しい順序は、まず明確なモジュール境界とインターフェース契約を定義し、その後にAgentを境界内で高速に産出させることです。

本章は構造失効の根本原因分析から始まり、ボトルネック移動の診断を経て、プロセス再設計の具体的原則に至ります。コア論点は、Agent時代の組織のボトルネックはコード産出から組織設計に移動したということです。これを解決するには分業の再定義とプロセスの再設計が必要であり、単により多くの人にAgentを使わせればよいというものではありません。

Harness Engineering Playbook · AgentsZone Community