はじめに

こんにちは、LegalOn TechnologiesでCTOをしている深川です。実は来週第一子が出産予定でドキドキワクワクがとまりません。

最近、社内向けに「AI時代の開発チームサイズ」に関するガイドラインを策定しました。AIによるコード生成・テスト・レビューの能力が急速に向上するなかで、開発チームの最適な人数は何名なのか——これは多くの開発組織が直面しているテーマだと思います。

本記事では、そのガイドラインの中から「チームサイズの検討」の部分を切り出し、対外的に共有できる形でお届けします。完璧な正解ではありませんが、同じような課題に向き合う方々の参考になれば幸いです。

AI時代、最大のボトルネックは「合意形成」である

まず前提の認識を共有させてください。

AIによるコード生成・テスト・レビューの能力が急速に向上し、1人あたりの開発スループットが劇的に増大しています。US企業では新規エンジニア採用を停止する動きすら出ており、少数精鋭化はグローバルなトレンドになりつつあります。

こうした時代において、最大のボトルネックは実装ではなく、人間同士の合意形成です。仕様の合意、設計方針のすり合わせ、優先順位の調整——開発サイクルの律速は、これらの人間間のコミュニケーションに移行しています。

組織規模が大きくなるほどマネジメントコストが増加しアジリティが低下する構造的課題は従来から存在していましたが、AIの進化により、この問題を根本的に解決できる可能性が生まれました。

「1人が最速」を出発点にする

私の思考の出発点は、「1人が最速」です。

これは極論に聞こえるかもしれませんが、AIエージェントが自律的にタスクを遂行し、人間は意図・制約・最終判断のみを担うモデルが実現しつつある以上、「1人で十分な実装スループットを出せる」という前提は現実味を帯びてきています。

実際に私自身で社内のとあるプロジェクトの開発を担当し、それなりに基盤が整備できれば1日25本のPRを出せることを実践・検証できました。これは誰かに承認を求めていたり、チームでレビューを待っていた場合には到底実現できなかったでしょう。

他の事例では、Anthropic社のClaude Code責任者であるBoris Cherny氏も、2025年11月以降は一行も手でコードを書かず、100%をClaude Codeで作成しながら1日20〜30のPRを出していると報告しています。

OpenAIでは、2026年2月公開の記事で、3人の小規模チームが約5か月で約1,500件のPRをマージした事例が紹介されています。

この「1人が最速」を出発点として、プロダクトを構成するために必要な以下の能力・要素を勘案し、最適な人数を検討しました。

ドメイン知識
UIデザイン能力
システムデザイン能力
ビジネス継続性（バス係数）
認知バイアスへの耐性
心理的不安・ストレス耐性

結論: チーム編成の原則

最初に結論から言ってしまうと、以下の通りだと結論づけました。

項目	従来	変更後
1ストリームアラインドチームあたりの開発者人数	制約なし	3名以下（2-3名推奨）
1ストリームアラインドチームあたりの所属者数（PdM、デザイナー、QA等含むフルチーム）	制約なし	7名以下
チーム編成単位	機能・プロジェクト単位	bounded context単位
チーム数	少数の大チーム	bounded contextの数だけ存在

この原則をベースとし、「コンウェイの法則」に基づき、システム境界とチーム境界を一致させます。少人数チームがbounded context単位で複数並列に存在する構造を目指しています。

※ ストリームアラインドチームとは: Team Topologiesで提唱されたチーム類型の一つで、ビジネス価値の流れ（ストリーム）に沿ってEnd-to-Endで機能を届けることに責任を持つチームのこと。本記事では、プロダクト開発を直接担うチームをこの意味で用いています。

※ bounded contextとは: ドメイン駆動設計（DDD）における中核概念の一つで、特定のドメインモデルが一貫した意味を持つ境界範囲のこと。日本語では「境界づけられたコンテキスト」「区切られた文脈」と訳される。本記事では、 bounded context の単位がチーム間の重複や干渉が少ない単位であることに着目し、チームの編成単位として利用しています。

開発者はなぜ「3名以下」か

ストリームアラインドチームの開発者は最大3名以下（2〜3名推奨）としました。以下、各人数のメリット・デメリットを整理します。

なお、以降の議論ではコミュニケーションパス数を判断基準の一つとして用います。これはチーム内で発生しうる1対1のコミュニケーション経路の総数であり、メンバー数 $n$ に対して次の式で求められます。

$$ コミュニケーションパス数 = \frac{n(n-1)}{2} $$

例えば3名なら3パス、5名なら10パス、7名なら21パス、10名なら45パスです。人数が線形に増えてもパス数は二次関数的に増大するため、チームサイズが大きくなるほどコンテキスト共有や合意形成のコストが非線形に膨らみます。

1名の場合

AI活用により1人でも十分な実装スループットを出せる（最速）
しかしバス係数が1となり、事業継続性リスクが高い
ドメイン知識・システム設計・UIデザインなど全スキルを1人でカバーするのは難易度が高い
レビューの相互牽制が働かず、品質の属人化が起きやすい
相談相手がおらず心理的な孤立感が大きい
確証バイアスが顕著に作用する。自分の仮説を裏付ける情報ばかりを集め、反証を見落としやすい。他者からのフィードバックがないため修正機会がない
ダニング＝クルーガー効果により、自身の判断の質を過大評価するリスクがある

2名の場合

バス係数が2になり最低限の冗長性を確保できる
ペアプログラミング的な相互レビューが可能
ただしスキルの多様性（バックエンド／フロントエンド／インフラ等）を十分にカバーしにくい
1人が休暇・離脱すると実質1名体制に戻るリスクが顕在化しやすい
同調バイアス（共有情報バイアス）が発生しやすい。2名では互いの意見に同調する圧力が強く、各自が持つ独自の情報が表出しにくい
アンカリング効果により、先に意見を述べた側の判断に引きずられやすい

3名の場合（推奨）

「1人が最速」という原則を維持しつつ、事業継続性・スキル多様性・品質担保・心理的孤立感の解消を満たすバランスの良い最小単位です。

バス係数が十分に確保され、1人が不在でも2名で継続運用できる
スキルセットの補完（例: バックエンド・フロントエンド・インフラ／SRE）が現実的に成立する
コミュニケーションパス数は3（= n(n-1)/2）で、オーバーヘッドが極めて小さい
一方、AIエージェントの並列実行に伴うコンフリクトは、3名体制でも無視できない課題である。実感としては、コンフリクトを人手で管理可能なのは2名が上限であり、3名ではHarness Engineering（後述）によるコンフリクト検知・自動解消の仕組みが前提となる
認知バイアスの相互補正が最も効率的に機能する人数。3名であれば多数決的な視点が成立し、確証バイアスや同調バイアスを相互に指摘・修正できる。一方でグループシンクが発生するほどの集団圧力はまだ小さい

4名以上の場合

コミュニケーションパス数が6以上に急増し、コンテキスト共有コストが非線形に増大する
同一リポジトリでのAIエージェント並列実行によるコンフリクトが顕著になる
リンゲルマン効果（社会的手抜き）——「誰かがやるだろう」が発生しやすくなる
グループシンク（集団浅慮）のリスクが高まる。集団の調和を維持しようとする圧力が強まり、異論や少数意見が抑制される
傍観者効果により、問題を認識しても行動が遅れやすくなる
権威バイアスが構造化しやすい。シニアメンバーの意見に無批判に従う傾向が強まり、ジュニアメンバーの独自の気づきが埋もれる
AI時代においては、人数追加による限界生産性の向上が従来以上に小さい

プロダクトチームサイズはなぜ「7名以下」か

開発者3名 + PdM・デザイナー・QA等の他ロール含めて最大7名以下という上限を設けました。根拠は以下の通りです。

心理学的根拠: ミラーの法則

人間が短期記憶で保持できる項目数は7±2個とされます（ミラーの法則）。チームメンバー全員の状況・文脈を把握し続けられる上限が7名程度であり、この人数を超えるとコンテキスト保持の認知負荷が急増します。

コミュニケーション理論: 2-pizza rule

Amazon社の「2枚のピザで足りるチームサイズ」原則に一致します。7名のコミュニケーションパス数は21（= 7×6/2）で、まだギリギリ全員が直接対話可能な範囲です。8名以上になると28パス以上となり、コミュニケーションコストが非線形に増大します。

役割分担をした場合のシミュレーション

現実にはスポットで人が増えたり減ったりもします。その場合にも7名は若干のバッファがあります。

開発者3名 + PdM 1名 + デザイナー 1名が基本構成（計5名）
QA・データアナリスト・ドメインエキスパートなどが兼任または部分参加する場合を考慮し、+2名のバッファ
この構成でbounded context単位のEnd-to-End開発が自己完結できる

8名以上になると

7名でも結構ギリギリですが、8名以上になるとさらにそれは加速します。

会議の調整コストが増え、全員が同期的に議論する機会が減る
「誰が何を知っているか」の把握が困難になり、情報の断片化が起きる
8名が必要な場合には、bounded contextが大きすぎる可能性があり、ドメイン分割を再検討すべきシグナルとも言える

補足: AI時代における役割変化

AI時代においては開発者だけでなく、プロダクトマネージャー・デザイナー・QAもこれまでと異なる仕事の仕方が要請されると考えています。

プロダクトマネージャー: AIが仕様案・ユーザーストーリー・影響分析を即座に生成できるため、PdMの役割は「仕様を書く人」から「意思決定と優先順位の最終判断者」にシフトする。開発サイクルの律速が合意形成である以上、PdMには原則として即レスが求められる。開発者やAIエージェントからの確認・判断依頼に対するレスポンスの遅延が、そのままチーム全体のスループット低下に直結するため
デザイナー: AIによるUIモック生成・デザインバリエーション提案が可能になり、デザイナーの役割はピクセルレベルのUI制約から以下に移行する。
- 満たすべきUI・UX要件を言語化し、スキルとして提供する
- UX戦略・ブランド一貫性の担保・ユーザーリサーチ
QA: AIがテスト生成・回帰テスト・探索的テストの一部を担うことで、QAの役割は手動テスト実行からテスト戦略設計・品質基準策定・リスクベースの優先順位付けへとシフトする

※ なお、当社ではQAではなくQuality Engineerという職種として定義・運用しています。

これらの役割変化により、従来は専任で必要だったポジションが兼任・部分参加で成立する可能性が高いと考えています。7名はあくまで上限であり、実態としては3〜5名が最適解となるケースも多いと想定しています。

例外について

もちろん、すべてのケースにこの原則が当てはまるわけではありません。

構造的な例外

Team Topologies におけるストリームアラインドチーム以外のチームは異なる動き方が要求されるため、上記の原則は当てはまらないことがあります。

コンプリケイテッドサブシステムチーム（例: AI/ML基盤、専門ドメインエンジン、セキュリティ基盤など）は高度な専門知識が必要なサブシステムを担当するため、3名の原則の対象外。ただし7名以下の上限は適用を推奨する。
プラットフォームチーム（全チームに共通基盤を提供するチーム）も同様に、3名の原則の対象外。ただし7名以下の上限は適用を推奨する。

一時的な例外（期限付き）

プロジェクトの状況次第では上記の原則は当てはまらないことがあります。

新規プロダクト立ち上げ期: bounded contextの境界が未確定であり探索的に開発を進める必要がある場合。ただし猶予期間中にドメイン分割と移行計画を策定する
大規模マイグレーション: 既存システムのリアーキテクチャやデータ移行など、一時的に複数のbounded contextにまたがる作業が必要な場合
緊急対応: 重大インシデントへの対応のため一時的にチームを増強する場合

こういった状況に応じた例外で大事なのは、例外を「永続化させない」ことです。例外には必ず期限と収束条件を設けるべきだと考えています。

「1名」でも問題ないケース

前述の通り、1名体制には事業継続性・認知バイアス・心理的孤立感といったリスクがあります。しかし、それらのリスクを許容してでもスピードを最大化すべき局面は存在します。以下の条件が揃う場合、意図的に1名体制を選択することも合理的です。

スピードが事業継続性より優先されるフェーズ: 新規プロダクトの初期PMF検証やプロトタイピングなど、属人化のリスクを取ってでもグイグイ進めた方が事業価値が高い場合
個人のケイパビリティが十分に広い: バックエンド・フロントエンド・インフラ・ドメイン知識など、当該bounded contextに必要なスキルの大半を1人でカバーできる
バイアスを自己制御できる強い意志を持つ: 確証バイアスやダニング＝クルーガー効果のリスクを自覚し、AIレビューやデビルズアドボケート的な仕組みを自ら構築できる
フィジカル・メンタルの耐久性が高い: 長期間安定的に稼働でき、バス係数1のリスクが実質的に低い（お身体にお気をつけください）

ただしこの判断は、「この人なら大丈夫」という属人的な信頼ではなく、事業フェーズとしての合理性に基づくべきです。PMF検証が完了してプロダクトがスケールフェーズに入った時点で、3名体制への移行計画を策定することを推奨します。

開発者3名体制を支えるために必要なこと

「3名にしろ」と言うだけでは何も変わりません。チームサイズの縮小は、それを支える基盤があって初めて成立します。ここでは概要だけ触れます。

開発モデルの転換: Human-steered, AI-executed

開発モデルを「人間が舵を取り、AIが実行する」モデルへの転換することは必須です。人間の役割は意図・制約の定義、ドメインモデル設計、品質基準の策定、最終判断などに限定すべきでしょう。AIの役割は仕様策定支援、実装、テスト生成、コードレビュー、リファクタリング、デプロイなどの実行全般です。

ただし、私はドメインモデルとデータモデル（テーブル設計）は人間が必ずレビューすることを強く推奨しています。修正コストが大きくOne-way doorであることが多いこと、ビジネスの意図と構造の整合性はコンテキストが全て言語化できないことが多く人間にしか判断できないケースが多いことが理由です。

Context Engineering

AIエージェントが正しい判断を下せるよう、ドメイン知識・ビジネスルール・開発ガイドを構造化し、エージェントが参照可能な形で整備する取り組みです。bounded contextごとに「コンテキストパッケージ」を定義し、新規メンバーやAIエージェントが最小限のオンボーディングで開発に参加できる状態を目指しています。

コンテキストパッケージとは、あるbounded contextで開発するために必要な知識・ルール・前提条件を集約したドキュメント群です。新規メンバーが「これを読めば開発を始められる」、AIエージェントが「これを参照すれば正しい判断ができる」状態を実現するための構造化された知識単位であり、具体的には以下の要素で構成されます。

ドメインモデル: エンティティ・値オブジェクト・集約の定義、用語集（ユビキタス言語）、ドメインルールと不変条件
データモデル: テーブル定義（ER図）、マイグレーション履歴、データ整合性制約
開発ガイド: 当該bounded context固有の命名規則・パターン・禁止事項
APIインターフェース: 他bounded contextとの境界インターフェース定義、イベントスキーマ
ビジネスルール: ワークフロー、法的要件、エッジケースとその対応方針の一覧
テスト戦略: 受入基準テンプレート、テストポリシー、品質基準

コンテキストパッケージは静的なドキュメントではなく、開発と並行して継続的に更新されるリビングドキュメントとして運用します。チームが更新責任を持ち、EMがメンテナンス状況を監視する体制を取ります。

Harness Engineering

AIエージェントの実行環境・ツールチェーン・ガードレールを標準化し、プロンプトなしでも安全かつ高品質にタスクを遂行できる仕組みを構築することです。CI/CDパイプラインにAIレビュー・セキュリティスキャン・テスト自動生成を組み込み、人間の介入なしでも品質ゲートが機能する状態にします。

Closed-loop Operations

AIエージェントが人間の介入なしにフィードバックループを完結できるオブザーバビリティを確立する取り組みです。プロダクト開発は作って終わりではなくむしろスタートです。運用しながら開発するのはなかなか大変です。そのときに3名体制において人間の認知負荷を最小化するための重要な要素と位置づけています。

具体的には、アラート検知→ログ解析→原因特定→修正PRの作成→テスト→デプロイという一連のオペレーションサイクルを、AIエージェントが自律的に回せる状態を目指します。人間は異常の最終判断やエスカレーション対応に集中し、定型的な障害対応はエージェントに委譲することで、少人数でも安定した運用体制を維持できます。

マネジメント方式の転換: ControlからOrchestrationへ

少人数多チーム体制では、マネジメントの役割も「管理（Control）」から「指揮（Orchestration）」へ転換する必要があります。コンテキストパッケージを育てる際にいちいちチーム間で合意形成していると育たないためです。そのためには各チームで自律して判断できる構成にする必要があります。

また、人数が減ると一人一人の稼働ロスの影響も大きいため、情報吸い上げなどの生産性の低いミーティングを減らし、各チームの自律的運営を前提とした、チーム間の連携・リソース配分・障害の除去に注力する形が望まれます。

一方で、AIが知らない間に変更して、知らない間に変更がリリースされていて影響を及ぼす、というリスクは今後飛躍的に高まります。どういう変更が、いつ反映されたか、それは意図したものか、品質基準を満たしているかを把握し、ステークホルダーに正しく伝える責務はこれまで以上に重要となることが予想されます。

このOrchestration型マネジメントへの移行にあたり、特に以下の3点が重要だと考えています。

Agentic Workflowの標準化

SDLC（ソフトウェア開発ライフサイクル）の各フェーズにおいて、AIが担う部分と人間が担う部分を明文化したAgentic Workflowテンプレートを定義します。要件定義・設計・実装・テスト・レビュー・デプロイ・運用の7フェーズそれぞれで、AIエージェントの自律実行範囲と人間の判断ポイントを標準化することで、チームごとのバラつきを抑え、少人数でも一貫した開発サイクルを回せるようにします。EMはこのテンプレートを自ら実践・説明できるレベルに達していることが前提です。

スキルセットの補完戦略

3名体制ではスキルの多様性を意図的に設計する必要があります。バックエンド・フロントエンド・インフラ／SREといった技術領域のカバレッジだけでなく、ドメイン知識の深さやAIエージェント活用の習熟度も考慮してチーム編成を行います。その際には、チームごとのAI活用成熟度を定量評価し、AI-native化の進捗を可視化することも推奨されます。チーム縮小に伴い余剰となるメンバーは、新規bounded contextの担当、プラットフォームチーム、In-house FDE（Forward Deployed Engineer）への参加など、キャリア意向を踏まえた配置転換を行い、組織全体としてのケイパビリティを維持・向上させます。

成果指標の再定義

従来のベロシティやコード行数といったアウトプット指標は、AI時代においてはもはや生産性の代理指標として機能しません。DORAメトリクス（デプロイ頻度・リードタイム・変更失敗率・復旧時間）を出発点としつつ、アウトカムベースの指標に移行し、ビジネスインパクト（ユーザー価値を届けるスピードと品質）を重視します。

おわりに

正直に言えば、この方針に対して社内でも不安の声はあります。「3名で本当に回るのか」「自分のポジションはどうなるのか」——当然の反応だと思います。

そのため、当社ではいきなり全チームに適用するのではなく、フェーズゲートを設けながら段階的に実施し、定量データに基づいて判断するアプローチを取っています。そして何より、チーム再編はあくまで組織構造の最適化であり、メンバー個人の価値や能力の否定ではないということを伝えたいです。マネージャーですら正解がわからない不確実な環境ですが、一人ひとりのキャリアに真摯に向き合うことが必要だと私は考えています。

同じような課題に向き合っている方々にとって、少しでも参考になれば嬉しいです。ご意見やフィードバックがあれば、ぜひお聞かせください。