【資料公開】生成AI時代のチーム設計―役割と協働の再構築

みなさんこんにちは。@ryuzeeです。

2025年11月29日にBacklog World 2025で「生成AI時代のチーム設計―役割と協働の再構築」というテーマで登壇した際のスライドを公開します（下書きのまますっかり忘れていました……）。

もはや生成AIを使わないプロダクト開発組織やチームを見つけるほうが難しい状況です。生成AIを使うようになると、プロセスはもちろんのことチーム構造にも大きな影響を及ぼします。この講演では主にチームの観点での変化について解説しました。

お役に立てば幸いです。

以下は、スライドの内容のサマリーです。

プロダクトの価値は、チームの外側で決まる

生成AIの利用の有無に関係なく、私たちが目指すのはプロダクトの成功です。そこで重要となる原則は以下です。

プロダクトの価値は、作り手ではなく、顧客やユーザーが決める

どれだけ「頑張って作ったか」「高度な技術を使ったか」は、価値の直接的な指標にはなりません。もちろん生成AIを使っているかどうかも関係ありません。価値があるかどうかは、常にチームや組織の外側で決まります。

だからこそプロダクト開発の本質は

何が正しいかを事前に決め打ちしない（できない）
仮説を置き、素早く作り、チームの外側に出して、頻繁に検証する
フィードバックをもとに方向修正し続ける
ダメならとっとと捨てる

という活動の繰り返しになります。

そして、このループを回し続ける主体は個人ではなくチームです。技術が重要であることに疑問の余地はまったくありませんが、技術を使うのは人間であり、価値を届ける主体となるのも人間です。 1人でできることには限りがあるので、複数の人間が集まってチームを作り、目標の達成のために協力します。これは不変です。

良いチーム設計とは何だったのか（AI以前）

AI以前からチーム構造として一貫して重要だったのは、次のような特徴です。

小さくて、自律的で、クロスファンクショナル
プロダクトをエンドツーエンドで届けられる
価値のストリームに沿って構成されている
チーム間の関係性が意識的に設計されている

これはスクラムやアジャイルだけでなく、チームトポロジーが示してきた考え方とも一致します。

重要なのは、チーム構造とアーキテクチャは連動する、すなわちコンウェイの法則です。チームの境界を間違えるとフロー全体の速度が遅くなります。

チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計

著者／訳者：マシュー・スケルトン、マニュエル・パイス、原田騎郎、永瀬美穂、吉羽龍太郎
出版社：日本能率協会マネジメントセンター
発売日：2021-12-01
単行本：280ページ
ISBN-13：9784820729631
ASIN：4820729632

生成AIは「増幅器」

DORAのレポートにもあるようにAIは増幅器です。

高いパフォーマンスを出しているチームや組織は生成AIによってさらにパフォーマンスが向上し、逆にうまくいっていない組織は問題が増幅され、パフォーマンスが低下します。

つまり

もともと健全なチームや技術基盤がある組織では、少人数でも大きな成果が出やすくなる
そうでない組織では、問題のある状態が加速する

ということが起きます。

生成AIの使い方以前に、土台となるチームの設計や健全性が問われると理解しておくとよいでしょう。

AIがチーム構造に与える3つの大きな影響

生成AIがチーム構造に与える影響はさまざまですが、個人的に大きいと考えているのが以下の3点です。

スキル境界の曖昧化: AIによって多能工化が進み、「役割」を固定しにくくなる
認知負荷の再分配: 実装の作業負荷が軽くなる一方で、問題設定や判断、合意形成の負荷は人間に残る（増える）
文脈共有の高速化: 仕様、コード、議事録、調査結果などの生成や共有が圧倒的に速くなる

結果として起きるのが、

チームを小さく保つほうが有利
メンバーの出入りがしやすくなる

という変化です。

また、これにあわせて作業の仕方も変わります。

モブプログラミングの重要性の向上

小さいチームで作業を進めるときに有利なやり方がモブプログラミングです。コードを書く行為自体は生成AIが大部分を行うようになったので、従来のように複数のチームメンバーが並列でコーディングを行う必要性が減りました（生成AI以前はコーディングが律速要因だったので、並列化せざるを得なかっただけです）。

一方で、生成AIから望み通りの成果を得るためには、生成AIに与えるプロンプトやドキュメントの精度が非常に重要です。この部分を分業してしまうと品質のばらつきが出やすいので、複数のメンバーでペア作業をしたり、全員でモブをするのが合理的な選択になります。

チーム内に複数のペアを作ると、コードのマージの問題が起こりやすいため、それに時間を使うくらいであれば、全員で協働作業するほうがムダもなく、知識の共有もスムースです（とくに、既存のコードベースに課題が多い場合、1つの要求に対応するために多数のファイルを変更するといったことが起こりやすく、結果的に多くのコンフリクトを誘発します）。

すなわち