🏗️

AI 時代のチーム再構成 — ピラミッドの崩壊とシニアの新しい役割

に公開
Productivity
engineering
AIエージェント
Claude Code
teambuilding
idea

はじめに

「PM が仕様を切り、SE が詳細設計を書き、PG が実装する」という分業でチームを回してきました。人数が増えるほど伝達コストが膨らみ、仕様の解釈差で手戻りが出る。そんな日常に慣れ切っていました。

その違和感が言語化できたのは、Claude Code を 参画しているチームのプロジェクト と プライベートの個人プロジェクト の両方で並行運用し始めてからです。個人プロジェクト側では、SKILL や subagent を自分の思想で組み立てられます。意思決定も自分の中で完結します。1 人 + Agent で開発層が一気通貫に回る感覚は、チーム側との対比で浮かび上がりました。

本記事は、個人プロジェクト 3 ヶ月の体験から見えた「ピラミッド型の限界」と、チーム展開時にたどり着く形を提案として書きます。運用パターンと失敗談も交えます。デザインと QA は人間の専門チームが担う前提です。「1 人で全部」ではなく、開発層の内側を再構成する話です。

対象読者

  • 5〜15 人規模のチームリード・テックリード
  • AI Agent をチーム運用に組み込みたいが、人員配置の再設計まで踏み込めていない人
  • PM/SE/PG の役割分担を呼吸で理解している人

前提となるスタンス

  • 本記事はチーム 構成 の話。個人の開発プロセスを扱った前記事「レビューから QA へ — AI 時代の開発プロセス再設計」とは階層が違う
  • 体験論の主体は 個人プロジェクト 3 ヶ月。そこで見えた構造を、チーム展開時の提案として翻訳する
  • デザイン・QA は人間の専門チームが担う前提で、本記事では触れない
  • ジュニア層の育成テーマは別記事に切り出す

ピラミッド型が崩れる理由 — AI Agent が変える 3 つの点

私がイメージしているピラミッドはこの形です。

上から下へ情報が流れる構造です。PM が仕様を書き、SE が設計に落とし、PG が実装する。階層が深いほど、1 つの仕様変更が末端に到達するまでに何度も通訳されます。

この構造が Agent 導入後に崩れ始めた理由は、私の観測範囲では次の 3 つでした。

1. 情報伝達コストが吸収できない

ピラミッドは縦方向の伝達コストを「中間層が通訳する」ことで吸収してきました。PM の抽象的な要件を SE が構造化し、PG が手を動かす。問題は、Agent が PG 層に入った瞬間、この通訳層の前提が変わる点です。

Agent は抽象的な指示を嫌います。曖昧な要件は、そのまま曖昧な実装になって返ってきます。結果として「SE が詳細設計を書く」フェーズを、シニアが自分でやらないと Agent を動かせません。SE と PG の境界が溶けます。

2. 実装速度が人間の数倍になる

PG 層を Agent に任せると、実装速度は数倍に跳ね上がります。「1 スプリント = PG 3 人分の工数」で回していたチームが、「1 スプリント = シニア 1 人 + Agent」で同等以上の結果を出せるようになりました。

ここで困るのは、レビュー速度がボトルネックになる ことです。実装は速く出るが、読む側の人間の処理量は変わりません。レビュー待ちの PR が積み上がり、チームのスループットが「レビューの捌き量」で頭打ちになります。

3. レビュー責務が「届く側」に変わる

3 つ目は、個人プロジェクトを回す中で私が一番驚いた変化です。シニアの仕事が「実装を振り分ける人」から「成果物を受け取る人」に置き換わりました。

個人プロジェクトを始める前は、PG から上がってくる実装を「軌道修正しながら育てる」感覚でレビューしていました。今は、Agent が出した完成品の初版を、シニアが受け取って判断する構図です。育てるレビュー から 判断するレビュー への移行、と呼んでもよい変化です。

前記事「レビューから QA へ — AI 時代の開発プロセス再設計」でも触れたとおり、個人のプロセスレベルでは「レビューから QA へのシフト」が起きています。チームレベルではそれが「シニアの役割変化」として表面化した、という見方です。

新しいチーム構造の提案 — シニア 1 人 + Agent + 専門チーム

個人プロジェクト 3 ヶ月の体験を、チーム展開に翻訳すると、たどり着くのは次の構造です。

縦に積むピラミッドではなく、開発層（縦軸）と専門層（横軸）の 2 軸 に組み替えた形です。

  • 開発層: シニア 1 人と Agent。PM/SE/PG を全部兼ねる
  • 専門層: デザインと QA は独立した人間のチーム

ピラミッドでは PM → SE → PG → QA と縦に積んでいたものを、「開発層」と「専門層」でレイヤーを分けた、と読み替えられます。

開発層の内訳

シニア 1 人は、次の 3 つを並行でやります。

  • PM 的仕事: 要件を文章化する（Issue に落とす）
  • SE 的仕事: 設計方針を決める（.claude/rules に書く）
  • PG 的仕事: Agent に実装を指示し、結果をレビューする

PG の「手を動かす部分」だけが Agent に委譲されています。それ以外の「考える・決める・言語化する」はシニアの仕事として残ります。

専門層はなぜ人間のままか

デザインと QA を Agent に置き換えなかった理由は単純で、Agent が弱い領域だから です。

  • デザイン: ブランド文脈・ユーザー体験の判断は、まだ人間の感性が強い
  • QA: プロダクション環境の観察・ユーザーの非論理的な使い方の発見は、人間の方が速い

ここを「全部 Agent で」と無理に広げると、アウトプットの品質が落ちます。私は広げない判断をしました。広げない線引きを持つことが、逆に開発層の Agent 化を成立させている実感があります。

運用の実装 — .claude/rules / SKILL / 詳細 Issue の 3 層

構造だけ変えても、Agent が勝手に動くわけではありません。運用に必要だったのは、次の 3 層です。

層 役割 更新頻度
.claude/rules プロジェクト全体のルール明文化 月 1 回程度
SKILL 定型作業の手順固定化 新しい手順が必要になったとき
Issue 個別タスクの粒度調整 タスクごと

.claude/rules — プロジェクト全体の前提

設計方針・命名規則・技術スタック・やってはいけないことを 1 箇所にまとめます。Agent はこれを呼吸のように読むので、ここに書けば全タスクに効きます。

.claude/rules/architecture.md
# アーキテクチャ方針

- バックエンドは DDD + クリーンアーキテクチャ
- ドメイン層は外部ライブラリに依存させない
- UseCase は 1 ファイル 1 クラスに限定
- インフラ層の実装は interface 経由で注入する

細かく書きすぎると Agent が身動きを取れなくなるので、「絶対守ってほしいこと」だけ を書きます。判断の余地を残す書き方が肝心でした。

SKILL — 定型作業の固定化

「新規 API を追加する」「新規画面を追加する」のような、何度も繰り返す作業を手順書にします。

.claude/skills/add-api-endpoint/SKILL.md
---
name: add-api-endpoint
description: 新規 API エンドポイントを追加する手順
---

# add-api-endpoint

## Step 1. Issue の内容を確認
...

## Step 2. ルーティング追加
...

## Step 3. UseCase / Repository 実装
...

SKILL 化することで、「この手順は毎回こう」と Agent に毎回教える必要がなくなります。/add-api-endpoint で呼び出せば、同じ手順が毎回走ります。

Issue — 「ジュニアでもわかる」粒度

Issue はシニアが書きます。ここが一番時間を使うところです。粒度のコツは「ジュニアに渡しても手が動く粒度」です。

## 目的
ユーザー詳細ページに「最終ログイン日時」を表示する。

## 画面仕様
- 表示位置: プロフィールカードの「登録日」の下
- フォーマット: `YYYY/MM/DD HH:mm`
- データがない場合: `—` を表示

## 実装メモ
- データは users テーブルの `last_login_at` カラム
- API は `/api/users/:id` のレスポンスに含める
- タイムゾーンは JST 固定

## 完了条件
- [ ] API レスポンスに `last_login_at` が含まれる
- [ ] UI に表示される
- [ ] null のとき `—` で表示される

ここまで書いておけば、Agent が 1 発目から ほぼ完成形 を出してきます。ポイントは「UI/UX の判断」まで Issue 内で言語化しておくこと。Agent に判断させないのが鍵です。

並列投入パターン

Issue が 3 つ揃ったら、Agent 用の worktree を 3 つ並列で走らせます。

[Main pane]
  Issue #12 → Agent 1 (worktree-a)
  Issue #13 → Agent 2 (worktree-b)
  Issue #14 → Agent 3 (worktree-c)

3 つが同時に完成形に近い PR を作ってくるので、シニアはそれらをレビューする役割に回ります。実装の並列度が上がる一方、レビュー側の処理は追いつかないタイミングも出ます。並列度は「自分が読める量」で決める のが現実解でした。

個人プロジェクト 3 ヶ月でわかったこと — PG 委譲とレビュー職化

ここからは個人プロジェクト側で運用した結果、理屈で設計した構造とどう一致したかを書きます。チーム展開時に効くポイントは章末でまとめます。

フロー: Issue 起票 → Agent 投入 → レビュー → マージ

1 タスクの流れはこうです。

  1. シニアが Issue を書く（15〜30 分）
  2. Agent に投げる（クリック 1 回）
  3. Agent が実装し、PR を出す（30 分〜2 時間）
  4. シニアがレビュー（10〜30 分）
  5. 修正指示をコメントで返す（1〜3 往復）
  6. マージ

見てのとおり、シニアが手を動かしているのは 1 と 4〜5 だけ です。個人プロジェクト導入前の私は、同じタスクで 1〜6 を全部やっていました。

時間配分の変化

体感ベースですが、1 日の時間配分が次のように変わりました。

時間帯 3 ヶ月前 現在
実装 60% 10%
レビュー 20% 50%
Issue 整理・設計 10% 30%
ミーティング 10% 10%

実装時間がおよそ 6 分の 1 になり、レビューと「Issue を書く・設計を決める」時間が膨らみました。正直、最初の 1 ヶ月は「自分、何もしていないのでは?」という違和感がありました。

落とし穴 1: Issue の粒度が雑だと全部崩れる

最初の失敗は、Issue を雑に書いたまま Agent に投げたこと でした。「いい感じに」「既存に合わせて」で投げたら、既存コードの最悪の部分を踏襲した実装が上がってきました。

Agent は既存コードを模倣する強度が高いので、雑に書くと 雑なコードの拡大再生産 が起きます。Issue に具体を書く時間を惜しむと、レビューで倍の時間を使って戻す羽目になります。

落とし穴 2: レビューしきれない量の PR を溜める

並列度を上げすぎて、PR が溜まったこともありました。Agent 側はどんどん進むので、レビューが間に合わないと PR が古くなって、他の PR とコンフリクトを起こします。

対策は「Agent の並列度をレビュー側の処理速度で決める」。シンプルですが、これを忘れると崩れます。

想定外の効果: 仕様の言語化が上達した

Agent に投げるには、判断の余地をなくした Issue を書く必要があります。この訓練を 3 ヶ月続けた結果、「曖昧な仕様」と「曖昧でない仕様」の違いが体で分かる ようになりました。

副次効果として、人間のジュニアに仕事を渡すときの指示も曖昧さが減りました。Agent 向けに研ぎ澄ました Issue の書き方が、人間相手にも効きます。

定量的に出せる数字（目安）

厳密な計測ではない前提で、3 ヶ月の変化を数字で出します。

  • PR 数: 3〜4 倍（1 スプリントあたり）
  • レビュー時間: 2〜3 倍（PR 数に比例して増加）
  • 実装時間: 5 分の 1 以下（体感）
  • 仕様の手戻り率: 体感で半分以下

「PR が増えたのにレビュー時間が同等以下で済むのか」と問われると、そうではありません。レビューがシニアの主業務になった というのが正しい表現です。数字上、シニアの稼働の半分はレビューに張り付いています。

チーム展開時に効くポイント

ここまでは個人プロジェクト側の観察です。同じ構造をチームに持ち込むなら、私の経験から効きそうなポイントが 4 つあります。

  • Issue 起票の責任者を決める: 個人プロジェクトでは自分で書けばよいが、チームでは「Issue を仕上げる責任者」を曖昧にするとそこから崩れる
  • .claude/rules をチーム共有のソース・オブ・トゥルースに: 個人だと暗黙でよかった判断を、チームでは明文化しないと Agent の出力がブレる
  • レビュー並列度をシニアの読める量で頭打ちにする: 人数が増えると PR は積み上がりやすく、ボトルネックがそのまま顕在化する
  • 数字はチーム規模で割って読む: 個人プロジェクトの「3〜4 倍」はチーム規模では素直に再現されない。期待値の調整が要る

ジュニアがシニアに育つには — Claude Code が育成ツールになる

ここまで読むと、「ジュニアの居場所がなくなる」と感じる読者もいるでしょう。私も最初はそう考えていました。実装を Agent に任せたら、ジュニアが手を動かして学ぶ場がなくなる、と。

実装の場が減るのは事実

PG 層が Agent に置き換わると、ジュニアが 自分の手でコードを書く場 は確かに減ります。写経・既存コード改修・バグ修正のような「実装量で学ぶ」経路が細ります。

ただし「読む・レビューする・言語化する」は全部訓練になる

代わりに増えるのは、次のスキルを使う場面です。

  • 読む力: Agent が出す PR をコードレベルで理解する
  • レビュー力: 違和感を言語化して修正指示を返す
  • 言語化力: Issue・プロンプトで要件を曖昧さなく書く

この 3 つは、従来シニアが経験から獲得するスキルとして扱われてきました。ジュニアのうちからこの訓練ができる環境は、むしろチャンスだと私は見ています。

Claude Code は育成ツールでもある

Agent と組むと、ジュニアが上位職の仕事を 擬似的に体験できる ようになります。Issue を自分で書き、Agent に投げ、上がってきた PR を自分でレビューする。シニアの仕事の型を、実戦で学べます。

ただし、これを本当に「育成」として機能させるには、次の運用が必要だと考えています。

  • ジュニアが書いた Issue をシニアがレビューする（Issue のレビュー）
  • ジュニアの PR レビューをシニアが再レビューする（レビューのレビュー）
  • ジュニア自身が書いたコードを一定量残す（Agent 任せにしきらない）

詳細は別記事 「Claude Code でジュニア層がシニア層になるまでの道筋」 で展開する予定です。本記事では概観に留めます。

まとめ

個人プロジェクト 3 ヶ月の運用と、チーム側の比較から見えたのは、開発層がシニア 1 人 + Agent で回るという構造の妥当性でした。その代わり、レビューと言語化の質が全てを決めます。

明日から試せる導入 3 ステップ

  1. .claude/rules を書き始める: プロジェクトの前提・禁止事項・設計方針を 1 ファイルに集約する。完璧を目指さず、最低限から始める
  2. 典型作業を SKILL 化する:「新規 API 追加」「新規画面追加」など、繰り返す手順を 1 つずつ SKILL に落とす
  3. Issue 粒度を「ジュニア向け」に揃える: UI/UX の判断まで Issue 内で言語化する。書く時間を惜しまない

本記事で触れなかったテーマ

  • デザイン・QA との協業: 専門層と開発層の接続の具体は別テーマ。機会があれば別途扱う
  • ジュニア育成の具体論: 次記事「Claude Code でジュニア層がシニア層になるまでの道筋」で展開予定

ピラミッドが崩れたからといって、チームが弱くなるわけではありません。崩れた後の形を先に設計しておく ことが、シニアの新しい責務だと感じています。

Discussion