並行機能開発

機能を並行実装用のワークストリームに分解し、ファイル所有権の境界を確立し、競合を回避し、複数の実装者エージェントからの結果を統合するための戦略。

このスキルを使用すべき場合

• 機能を並行実装に向けて分解する
• エージェント間にファイル所有権の境界を確立する
• 並行ワークストリーム間にインターフェースコントラクトを設計する
• 統合戦略（垂直スライス対水平レイヤー）を選択する
• 並行開発におけるブランチとマージのワークフローを管理する

ファイル所有権戦略

ディレクトリ別

各実装者に特定のディレクトリの所有権を割り当てます：

implementer-1: src/components/auth/
implementer-2: src/api/auth/
implementer-3: tests/auth/

最適な場合: ディレクトリ構造が明確に組織されているコードベース。

モジュール別

論理的なモジュール（複数のディレクトリにまたがる場合がある）の所有権を割り当てます：

implementer-1: 認証モジュール（ログイン、登録、ログアウト）
implementer-2: 認可モジュール（ロール、権限、ガード）

最適な場合: 機能指向アーキテクチャ、ドメイン駆動設計。

レイヤー別

アーキテクチャレイヤーの所有権を割り当てます：

implementer-1: UIレイヤー（コンポーネント、スタイル、レイアウト）
implementer-2: ビジネスロジックレイヤー（サービス、バリデータ）
implementer-3: データレイヤー（モデル、リポジトリ、マイグレーション）

最適な場合: 従来のMVC/レイヤードアーキテクチャ。

競合回避ルール

基本原則

1つのファイルに1人の所有者。 ファイルは複数の実装者に割り当てられるべきではありません。

ファイルを共有する必要がある場合

複数の実装者からの変更が本当に必要な場合：

1. 単一の所有者を指定する — 1人の実装者がファイルを所有する
2. 他の実装者が変更を要求する — 所有者に具体的な変更要求を伝える
3. 所有者が順序立てて変更を適用する — マージコンフリクトを防止する
4. 代替案：インターフェースを抽出する — 非所有者がインポート可能で変更不要な独立したインターフェースファイルを作成する

インターフェースコントラクト

実装者が境界で調整する必要がある場合：

// src/types/auth-contract.ts (team-lead が所有、実装者は読み取り専用)
export interface AuthResponse {
  token: string;
  user: UserProfile;
  expiresAt: number;
}

export interface AuthService {
  login(email: string, password: string): Promise<AuthResponse>;
  register(data: RegisterData): Promise<AuthResponse>;
}

両実装者はコントラクトファイルからインポートしますが、どちらも変更しません。

統合パターン

垂直スライス

各実装者が完全な機能スライス（UI + API + テスト）を構築します：

implementer-1: ログイン機能（ログインフォーム + ログインAPI + ログインテスト）
implementer-2: 登録機能（登録フォーム + 登録API + 登録テスト）

メリット: 各スライスは独立してテスト可能、最小限の統合が必要。 デメリット: 共有ユーティリティが重複する可能性、密結合機能では難しい。

水平レイヤー

各実装者がすべての機能に対して1つのレイヤーを構築します：

implementer-1: すべてのUIコンポーネント（ログインフォーム、登録フォーム、プロフィールページ）
implementer-2: すべてのAPIエンドポイント（ログイン、登録、プロフィール）
implementer-3: すべてのテスト（ユニット、統合、E2E）

メリット: 各レイヤー内で一貫したパターン、自然な専門化。 デメリット: 統合ポイントが増加、レイヤー3はレイヤー1と2に依存。

ハイブリッド

結合度に基づいて垂直と水平を混在させます：

implementer-1: ログイン機能（垂直スライス — UI + API + テスト）
implementer-2: 共有認証インフラ（水平 — ミドルウェア、JWTユーティリティ、型）

最適な場合: ほとんどの実世界の機能（共有インフラがある場合）。

ブランチ管理

単一ブランチ戦略

すべての実装者が同じ機能ブランチで作業します：

• セットアップが簡潔、マージオーバーヘッドなし
• 厳密なファイル所有権により競合を回避する必要あり
• 最適な場合: 小規模チーム（2-3人）、明確に定義された境界

マルチブランチ戦略

各実装者がサブブランチで作業します：

feature/auth
  ├── feature/auth-login      (implementer-1)
  ├── feature/auth-register    (implementer-2)
  └── feature/auth-tests       (implementer-3)

• より高い独立性、明示的なマージポイント
• オーバーヘッドが高い、共有ファイルではマージコンフリクトが発生する可能性あり
• 最適な場合: 大規模チーム（4人以上）、複雑な機能

トラブルシューティング

実装者が共有コードの準備を待つことでお互いをブロックしている。 共有部分をインターフェースコントラクトファイルに抽出して、team-lead が所有し、実装者がそこからインポートするようにします。どちらの実装者もコントラクトを変更しません — コントラクトに対して実装するだけです。

明確な所有権ルールがあってもマージコンフリクトが発生する。 ファイルが2つのエージェントに割り当てられているか、または、すべてをオートインポートするconfig/indexファイル（index.ts、__init__.pyなど）が両者で変更されました。すべてのバレル/indexファイルの所有者を指定するか、lead が最後にそれらをマージします。

実装者が早く完了したが、統合ステップがブロックされている。 ステージングインターフェースを使用します：完了した実装者がダウンストリーム依存関係のスタブまたはモックを作成し、他の実装者が継続できるようにします。統合時に実装に置き換えます。

機能分解が途中で間違っていることが判明した。 新しい作業を停止し、lead がファイルを再配分し、ブロードキャストで変更を伝えます。部分的に書かれたコードのコストは許容可能です — 間違った分割で続行する方が悪いです。

1つの実装者により書かれたテストが別の実装者により書かれたコードに対して失敗する。 インターフェースコントラクトがドリフトしました：APIを所有する実装者が、テスト実装者に通知することなくシグネチャを変更しました。コントラクトファイルの変更前にブロードキャストを必須とするルールを強制します。

関連スキル

• team-composition-patterns — 作業を分解する前に適切なチームサイズとエージェントタイプを選択する
• team-communication-protocols — 実装者間の統合ハンドオフと計画承認を調整する