はじめに
みなさんも似たような感覚をお持ちかと思いますが、昨今ではAIエージェントがコードの多くを書くようになり、実際にコードを書く機会がかなり減ったなと感じます。
多くのチームで取り組み、まだまだ発展途上にある「チームとしてどう開発を進めるか」というテーマについて、現時点での私個人の考えをまとめたいと思います。
なお、この記事を書こうと思った背景としては、主観ではあるもののAIを活かそうとするほど、これまでのチーム開発ナレッジは効いてくると感じていることにあります。変わるのは実装の担い手であって、チームで価値を届ける活動の根本は変わらないような感覚があるからです。
※ 以降の内容は定量的な計測に基づくものではなく、複数の現場で開発を進めてきた中での個人的な体感と見解です。あくまで一個人の意見として気楽に読んでください。
全体像
中心にあるのは「人間とAIの役割分担」で、それを成立させる土台としてハーネスエンジニアリングがあり、さらにアーキテクチャとチームの形が乗り、最後にそれらを回す仕組みとしてチーム開発のイベントが効いてくると考えています。（具体的なフレームワークがあるとわかりやすいので、自分が良く採用しているスクラムのフレームワークをベースに書いていきます）
土台としてのハーネスエンジニアリング
AIに実装を任せられるのは、その出力が信頼できる状態になっているからです。その状態を作るのがハーネスエンジニアリングです。私はこれを、AI駆動開発のための足場づくり、つまり Dockerfile や CI を整えるのと同じレイヤーの仕事だと捉えています。AIエージェントの実行環境を整備する、開発の土台です。
構成要素はおおよそ以下の3つになりそうかなと考えています。
-
権限・ガードレール層 —
settings.local.jsonの allow/deny など、AIに許す操作と禁じる操作の定義 -
ガイダンス層 —
CLAUDE.mdや開発ルール、AIに渡すコンテキストとメモリの設計 - 自動化・検証層 — CIに組み込んだAIレビュー、自動PR作成、テストループ
人間とAIの役割分担
ハーネスの土台が効いてくると、エンジニアは実装作業そのものから離れられます。基本方針として、エンジニアはコードを書く役ではなく、AIエージェントの旗振り役に徹する。人間が集中すべきは、判断、問題の発見、そしてAIに渡すコンテキストの整備です。
ここで重要になるのが上流のデザインスキルです。プロダクトロードマップ、技術戦略、アーキテクチャ設計、ストーリーデザイン。これらは品質の高いものほどAIへの良質なインプットになり、そのままアウトプットの品質に直結します。AIが実装を担うほど、人間の価値は「何を、どんな制約で作るか」を定義する側へ移っていきます。
実際に業務委託でお仕事を受けているある会社では、プロダクトロードマップの整理、ストーリーの書き方をPOの役割を担う方にコーチングしてインプットの品質を上げたことで、私が実際に開発を行う際にはそのストーリーをそのまま放り込んで実装し、そのアウトプットをレビューするような流れができているので、なおのことこのコンテキストの整備が大事だなと考えています。
組織規模や事業フェーズに応じたアーキテクチャ
AIに読ませるために最近はモノレポ回帰の動きも強まっていますが、モノレポであってもマイクロサービスであっても、その方針を決める変数の1つとしては組織規模があるかと考えています。
エンジニアが数人の組織なら、マイクロサービス化はかえってコスト増になることが多いかもと感じています。
分散トランザクションや運用の複雑さは、AIが肩代わりしてくれない領域が大きいので、素直にモノレポを選んだ方が結果としてスピードが速いなと感じます。一方、数百人から数千人規模になると、サービスごとのデプロイ独立性やディレクトリ権限の管理といった旧来からの要請が効いてきて、マイクロサービス化のメリットが上回ります。もちろん分割しすぎれば管理コストが跳ね上がるので、ここはエンジニアのバランス感覚が問われるなと感じています。
そしてここにAI駆動開発が加わったことで、AIがコンテキストとして読む範囲という変数が増えたと考えています。読む範囲を狭めた方が精度もスピードも出やすい。これはコンテキストエンジニアリング（ルールで読み取り範囲を絞る）でも、物理的な分割（マイクロサービス化）でも実現できることは理解しています。
ただ、AI駆動開発はプロジェクト背景やプロダクト全体像のインプットがあってこそ機能します。そこで効くのが、物理的な分割と、論理的な読み取り範囲を切り離して設計すること。
サービスは分割しつつ、全体を理解させたいときは親ディレクトリに各リポジトリを配置してそこを起点に読ませる。
全体像を理解させる手段としては、コードを総なめさせるより、すでに全体構成を表現している成果物を入口にする方が速いと考えています。docker-compose や Dockerfile、k8s のマニフェストなどはオーケストレーションの定義そのものなので、アーキテクチャ全体を素早く把握できます。
ここは定量比較をしたわけではなく体感ベースですが、docker-compose / Dockerfile / k8s のYAMLを読み込ませると、AIの理解の精度が上がると感じています。これらのファイルは運用のために必ず保守されるので、README やアーキテクチャ図と違って陳腐化しにくい、という副次的な利点もあります。
チーム構成の考え方
チームサイズは、大きすぎず小さすぎず。人間同士のコミュニケーションパスは人数に対して $n(n-1)/2$ で増えるため、人数が多いほどコミュニケーションコストが膨らんでスピードが落ちます。スクラムガイドが示すように、エンジニアだけでなくプロジェクト推進に必要な各職能を含めた10人以下が一つの目安だと考えています。
ここでAIエージェントをメンバーとして数えるかどうか、という点も検討するべきかと思いますが、自分は数えていないです。
人間とエージェントの関係は基本的に1対1の指示と応答で、エージェント同士が勝手にやり取りすることはないからです。つまり「人間は10人以下に保ちつつ、各人が複数のエージェントを従える」構造であれば、コミュニケーションコストの爆発を避けながら、チームの実効的な生産能力を上げられると考えています。
ただAI駆動開発におけるチームマネジメントで注意した方が良い要素の1つとしては、各人がバラバラのツールを使ってしまう状況を発生させないようにしたいと考えています。
「AさんはGemini CLIのFlashモデルでコードだけをAIに任せる。BさんはCodexで、設計や作業記録までmdファイルに書かせる」といった具合に、使い方は放っておくと各自のローカルでバラけます。これを放置すればチームとしての一貫性が失われるので、AIの使い方も大枠は揃えておきたい。ただし、ガチガチに固めるとエンジニアが力を発揮しにくくなるので、縛りすぎないバランスが必要だなと思っています。この「大枠は揃えつつ、縛りすぎない」を実現する仕組みが、たとえばスクラムイベントのようなアジャイル的な考え方にあるかと考えています。
チーム開発の根本は変わらない
AIがメンバーのように加わっても、チーム開発を回すイベント群は不要になるどころか、むしろ重要性を増しているなと実際にチーム開発を行っていて感じているところです。
なぜなら、AIの不確実性を扱い、使い方の大枠を揃え、継続的に改善するための場として機能するからです。各イベントは、AI駆動開発では次のように捉えることができると考えています。
- Refinement — 従来の「ストーリーを理解可能な粒度に分解する場」に加えて、AIに読み込ませるコンテキストを整備する場になります。ストーリー、受け入れ条件、参照すべき設計情報の品質が、そのままAIの出力品質につながる。
- Sprint Planning — 人間とAIエージェントの作業分担を計画する場。どこを人が判断し、どこをAIに委ねるか。
- Daily — やること自体は大きく変わらないですが、ここで挙がった情報がAIへのフィードバックの起点になります。「A画面のAPIコールが多すぎて、あるチケットのブロッカーになっている」とわかれば、その調査や修正をAIに投げる。つまり、人間が問題を発見し、AIに解決を委譲するという形に変容していると考えています。
- Retrospective — 振り返りの対象に、チーム活動に加えてAIの使い方やハーネスそのものの改善が加わります。土台は一度作って終わりではなく、ここで継続的に改善していきます。
イベントの形は変わりません。変わるのは、その中で人間とAIがどう役割を分けるかです。
おわりに
変わったのは、実装の担い手とコードを書くスピードです。変わらないのは、チームで価値を届けるために何を作るべきかを定義し、計画し、振り返って改善する、という営みの根本です。AIという強力な道具が入ったからこそ、その道具をチームとして安定して扱うために、旧来のチーム開発の知見が効いてくる。これが現時点での個人的な結論です。