Teamworks

Agent Teams チーム体制構成

目標

選定する体制は常に以下の3軸を満たすこと:

• 高品質 — 欠陥・手戻りを最小化する実装品質
• 最適コスト — 不要なメンバー・工数を排除（YAGNI）
• ユーザー満足度最高 — Product Design SectionのUATで品質検証

⚠️ HARD-GATE（必須制約）

チーム体制をユーザーへ提示し、明示的な承認を得るまで、以下を一切実行してはならない:

• コードの記述・編集
• ファイルの作成・変更
• スキャフォールディング
• その他すべての実装作業

プロジェクトの見た目の複雑さに関わらず、すべてのケースに適用される。

実行ワークフロー

1. 分析 — プロジェクトのコードベース・要件・タスクを把握する
2. Section選定 — 後述の「利用可能なSection」を参照し、必要なSectionを選択する（1つ以上、複数可）
3. メンバー設計 — 選定した各SectionのSection Leaderを必ずアサインし、タスク量・難易度に応じてメンバーの役割・人数を決定する
4. 体制提示 — 以下のフォーマットでユーザーへ提示する
5. 承認取得 → 承認後に実装フェーズへ移行

提示フォーマット

## 提案チーム体制

### プロジェクト規模
| レベル | 判定根拠 |
|--------|----------|
| Level X: [レベル名] | [具体的な判定理由] |

### 選定Section
- **[Section名]**: [選定理由]

### メンバー構成
| ロール | 人数 | 担当タスク | 利用Skills | MCP Servers | AgentType |
|--------|------|-----------|------------|-------------|-------------|
| [ロール名] | [N]名 | [タスク詳細(箇条書き)] | [Skills] | [MCP Servers] | [AgenType] |

### タスク配分

[ロール名] ├── [タスク1] └── [タスク2]

### コミュニケーション経路
[Section間・メンバー間の報告・連絡の流れ]

### 体制根拠
[この体制を選んだ理由・考え方]

### 品質検証
| チェック項目 | 結果 |
|--------------|------|
| [項目] | [結果] |

---

## 承認

上記のチーム体制で実装を開始してよろしいでしょうか？

- [ ] はい、承認します
- [ ] いいえ、修正が必要です：___________

アンチパターン

「シンプルだから体制提示を省略する」は厳禁。

手戻りを生む典型的な失敗例:

• Section LeaderなしでSectionを構成する
• 目標3軸（品質・コスト・満足度）を考慮しない
• Sectionへの依頼タスクが不明確
• 不要なメンバーを追加する（YAGNI違反）
• 体制承認なしに実装を開始する
• メンバー構成には利用Skills、MCP Server、AgentTypeの不記載

利用可能なSection

各Sectionには必ず Section Leaderを1名 アサインすること。

1. Product Design Section

2. Product Build Section

メンバープロフィール

Product Design Section

Product Owner（1名固定）

• 役割: Section全体リード。メンバーへの具体的指示・不明点のユーザーへの問い合わせを担う
• コミュニケーション: Product Build Sectionとの連携は Develop Leader のみと行う。Build Sectionメンバーへの直接指示は禁止
• AgentType: analyzer
• Skills: ultrathink, sequential-thinking
• MCP Servers: perplexity

E2E Member（上限3名）

• 役割: Product OwnerからアサインされたE2Eテストタスクを高品質・高効率で実行する
• コミュニケーション: Product Owner のみへ報告。他メンバーへの直接指示は禁止
• AgentType: qa
• Skills: ui-ux-pro-max, chrome-devtools
• MCP Servers: zai-mcp-server, chrome-devtools

Product Build Section

Develop Leader（1名固定）

• 役割: Section全体リード。メンバーへの具体的指示・Product Ownerからの指摘対応・メンバー課題へのフィードバックを担う。不明点はMCP Serverを介してWeb調査し、まとめた内容をメンバーへ共有する。Developer間の作業を調整する。メンバーの実装コードに対してレビューを実施する。
• コミュニケーション: Product Design Sectionとの連携は Product Owner のみと行う。Design Sectionメンバーへの直接指示は禁止
• AgentType: multi-agent-coordinator
• Skills: ultrathink, sequential-thinking, tailwind-design-system, ui-ux-pro-max, vercel-react-best-practices, error-handling-patterns, fastapi-templates, microsoft-agent-framework
• MCP Servers: perplexity, context7, zai-mcp-server

Frontend Developer（上限3名）

• 役割: UI/UX・React・Tailwindなどフロントエンド実装を担う
• 制約: 同一ファイルへの複数名同時編集は禁止
• コミュニケーション: Develop Leader のみへ報告。他メンバーへの連絡は必ず Develop Leader を経由する
• AgentType: frontend
• Skills: tailwind-design-system, ui-ux-pro-max, vercel-react-best-practices, error-handling-patterns, chrome-devtools
• MCP Servers: perplexity, context7, github, zai-mcp-server, chrome-devtools

Backend Developer（上限3名）

• 役割: Python・Java・データベース設計などバックエンド実装を担う
• 制約: 同一ファイルへの複数名同時編集は禁止
• コミュニケーション: Develop Leader のみへ報告。他メンバーへの連絡は必ず Develop Leader を経由する
• AgentType: frontend
• Skills: fastapi-templates, microsoft-agent-framework, error-handling-patterns
• MCP Servers: perplexity, context7

System Architect（1名固定）

• 役割: システムアーキテクチャ設計専任。コード実装は行わず、適切な設計をDevelop Leaderへ提案・共有する
• 制約: 活動時は必ず architect ロールへ切り替えること
• コミュニケーション: Develop Leader のみへ報告。他メンバーへの連絡は必ず Develop Leader を経由する
• Skills: fastapi-templates, microsoft-agent-framework, tailwind-design-system, ui-ux-pro-max, vercel-react-best-practices, error-handling-patterns
• MCP Servers: perplexity, context7

Progressive Disclosure（段階的体制選定）

プロジェクトの複雑さに応じて、体制を段階的に構築すること。

複雑さレベル判定

判定フロー

1. 変更ファイル数は3以下か？
   → Yes: Level 1（Buildのみ、1名）
   → No: 次へ

2. UI/UX変更または新規画面は必要か？
   → Yes: Design Section追加

3. データベース設計またはAPI設計の変更は必要か？
   → Yes: Build SectionにBackend Developer追加

4. 新技術導入またはアーキテクチャ変更は必要か？
   → Yes: System Architect追加

5. E2EテストまたはUATは必要か？
   → Yes: Design SectionにE2E Member追加

適用例

Validationチェックリスト

体制提案前に必ず以下を確認すること。

必須チェック（すべて満たすこと）

自己検証プロンプト

体制提案前に以下を自問し、回答を記述すること：

「この体制で実装した場合、品質・コスト・満足度のどれが損なわれる可能性があるか？」

• 品質リスク: ___________
• コストリスク: ___________
• 満足度リスク: ___________

「ユーザーがこの体制を見て、納得せずに修正を求めるポイントはどこか？」

• 予想される質問: ___________
• 事前準備すべき回答: ___________

Key Principles