「人を増やす＝分業」という前提が揺れている
AIエージェントを本格的にチーム開発に持ち込んだとき、何が起きるのか。理論や予測ではなく、実際の現場からの記録が出てきた。
Zennに投稿されたエンジニアの記事「人を増やす＝分業はもう古い？AIエージェント前提の開発チームを5ヶ月運用して考えたこと」は、SES案件で6名の即席チームをAIエージェント込みで運用した経験をもとに書かれている。読んで引っかかったのは、「AIツールを導入したらどう便利になったか」という話ではなく、「同じツールを渡しても、人によって結果が大きく割れた」という観察の部分だ。
ここからは、その記事の内容を整理しつつ、実務的な含意と構造的な読み方を重ねていく。
現場で何が起きたか——6名・5ヶ月の実録
前提として、著者が置かれていた環境を確認しておく。
- 案件: フルスクラッチのシステム構築（0→1）
- 体制: プロパー（自社社員）なしの即席SES 6名
- 配布ツール: Claude（Teamプラン）と GitHub Copilot
- 追加条件: 外国籍メンバーも在籍し、コミュニケーションにやや難しさがあった
著者はまず、ガイドライン・ルール、アーキテクチャの土台、設計テンプレートを整備した。そのうえで、設計・実装・単体テスト（UT）・結合テスト（IT）の各フェーズを、各メンバーがAIエージェントを使いながら回す、という進め方を取った。
結果として起きたのは「成果のばらつき」だ。同じガイドライン、同じAIツールを配っても、Issueの消化量、成果物の量、ガイドラインの遵守度、他人の実装ミスや設計ミスへの気づきかた——これらが、メンバーによって見事に割れた。
「多く消化する人」と「少ない人」、「他人の領域のミスまで見抜ける人」と「自分のミスにも気づきにくい人」が、同じツールを使って並走した。
差を生んだのはツールではなく人だった
この観察の何が重要かというと、「AIツールを導入すれば均質な成果が出る」という期待に、現場レベルで反証しているからだ。
AIエージェントへの期待の一形態として、「誰でも同じように使えるようになる」というものがある。プロンプトさえ整備すれば、経験の差が縮まる、という発想だ。しかし著者の観察は逆を示している。同じエージェントを渡されても、ガイドラインを素通りする人がいれば、わざわざ指摘して品質を底上げする人がいる。実装ミスをスルーする人がいれば、別担当の領域でも見抜ける人がいる。
ここからは見方の話になるが、これは当然といえば当然だ。AIエージェントは「実行」を加速するツールであって、「判断」を代替するツールではない。何が正しいアウトプットかを評価できない人は、AIが間違った方向に走っていても気づけない。ツールが高精度になるほど、逆説的に「出力を評価できる人」の価値が上がる構造がある。
「分業」から「評価・監督」へ——構造的に何が変わっているか
著者はここから、より大きな問いを立てる。「人を増やせばその分だけ作業を分担できる」という、従来型の分業の前提が揺らいでいる、という指摘だ。
これは実務的に重い話だ。SESや受託開発の現場では、「ヘッドカウント（人数）」が仕事の処理能力の代理指標として使われてきた。人を積めばアウトプットが増える、という前提でプロジェクトが設計される。しかしAIエージェントが実装層を担えるようになると、「作業を回す」だけならエージェントでも回る。人数を増やすことの価値が、単純な分業量では測れなくなる。
著者が現場で「効いていた」と感じた資質は以下だ。
- Web領域の最新動向や実践知を持っている
- 基礎知識がしっかりしている
- 経験があり、スタンダード（定石）を理解している
- そして、それらを使おうとする姿勢を持っている
これらを持つ人こそが、AIの成果物を評価・レビューできる人だ、と著者は言う。AIが出した設計・実装を評価し、ガイドラインに照らし、他人の領域のミスまで見抜ける。この役割が希少になっていく、という見立てだ。
元記事（著者が参照していた別の記事）では「ジュニア層の需要が減る一方でシニア層は黄金期を迎える」という非対称が指摘されており、著者の肌感覚もこれと一致していたという。厳しい話ではあるが、「AIが下支えする領域と経験浅い人の貢献領域が重なってしまう」という構造は、否定しにくい。
実務として何を考えるか
ここで、開発チームのマネジメント側が考えるべき点を整理したい。
パイプライン設計の重要性
著者は、ガイドラインとテンプレートの整備を「ループの土台づくりの入り口だった」と振り返っている。「各自がエージェントをその都度使う」段階から一歩進んで、誰がやっても一定品質になるワークフローをどう設計するか——ここが今後の勝負どころになる。
記事で言及されているのが「35分問題」だ。人間が取り組んでも35分を超えるような長いタスクになると、エージェントの成功率が急に落ちるという観測がある。だからこそ、タスクを適切な粒度に割り、検証ポイントを挟む設計自体が、人間の担う価値になる。「何をエージェントに任せ、どこで人が介在するか」を設計できる人間が必要になる、ということだ。
実際に著者の直近案件では、開発メンバーにプログラミング作業そのものを担当させず、レビューに徹する前提でワークフローを組んだという。カバレッジを90%以上にするだけでなく、「そのUTは本当に意味のあるテストになっているか」「カバレッジを満たすためだけのおかしなテストになっていないか」を見抜く観点を共有し、要所だけを人が監督する形に寄せた。これは「human-on-the-loop」的な運用の、現場での具体的な実装例だ。
上流・横断への重心移動
著者が「重要度が上がる」と整理した領域は以下だ。
- ビジネス（業務）の理解
- システムが「振る舞うべき仕様」の理解
- 負荷・チューニング
- リファクタリングの重要度の見極め
「正しく動くコードを書く」より「何が正しいかを定義し、評価する」側の価値が上がっている——この感覚は、現場に近い人ほど共感するだろう。実装が速くなればなるほど、「何を作るか」「それは本当に正しいか」の判断にボトルネックが移る。
次に来る問い——タスクの振り先が人からエージェントへ
著者は最後に、より先の話として「人にタスクを振る行為そのものが消えるかもしれない」という問いを置いている。著者自身、現在はHermes Agentをローカルで動かし、Slack連携も含めて検証しているという。プロジェクトに合わせて振る舞いを最適化できるエージェントが一般化したとき、マネジメントの対象が「人」から「エージェント」に移る可能性がある、という話だ。
これはまだ実験・過渡期の話だ。現状では「エージェントに任せた結果をレビューできる人間」が不可欠なフェーズにある。ただ、5ヶ月の現場経験から著者が言うのは「その方向に少しずつ針が動いているのは確か」ということだ。極端なシナリオを今から断言するのは早いが、「方向性としてはあり得る」と想定しておくのと、しておかないのでは、組織設計の準備が変わってくる。
実務的に次の論点として浮かぶのは、こんな問いだ。「エージェントを監督・評価できる人材を、どうやって育て、確保するか」。レビュー能力は短期間でつくものではない。経験・知識・姿勢の掛け合わせが必要なら、今からそういう人材をチーム内で育てておくか、採用基準を変えておくか——そこに手を打てていない組織は、AIツールを導入しても恩恵を受けにくい構造になる。
まとめにかえて
この記事から得られる読み軸を一つ置くとすれば、こうなる。
AIツールの導入効果を語るとき、「ツールの性能」と「使う人の評価能力」を分けて考えているか。
AIエージェントは実装を加速する。しかしその出力が正しいかどうかを判断するのは、今のところ人間だ。ツールが高度になるほど、「評価できない人」と「評価できる人」の差は広がりやすい。これが、著者が6人・5ヶ月の現場で観察したことの本質だと思う。
「人を増やすか」ではなく「どんな仕組みと、どんな役割の人を置くか」——この問い自体は新しくないが、AIエージェントの普及によってその答えの構造が変わりつつある。現場から出てくる、こういう解像度の観察を積み重ねることが、今は重要だ。
