parallel-feature-development

並列フィーチャー開発

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

このスキルを使用する場面

• 並列実装のためにフィーチャーを分解する場合
• エージェント間でファイルの所有権の境界を確立する場合
• 並列のワークストリーム間でインターフェース契約を設計する場合
• 統合戦略 (垂直スライス vs 水平レイヤー) を選択する場合
• 並列開発のためのブランチおよびマージのワークフローを管理する場合

ファイル所有権の戦略

ディレクトリ単位

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

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

最適な用途: ディレクトリの境界が明確で、整理されたコードベース。

モジュール単位

論理モジュール (複数のディレクトリにまたがる場合もあります) の所有権を割り当てます:

implementer-1: Authentication module (login, register, logout)
implementer-2: Authorization module (roles, permissions, guards)

最適な用途: フィーチャー指向のアーキテクチャ、ドメイン駆動設計。

レイヤー単位

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

implementer-1: UI layer (components, styles, layouts)
implementer-2: Business logic layer (services, validators)
implementer-3: Data layer (models, repositories, migrations)

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

競合回避のルール

基本原則

1 ファイルにつき 1 人のオーナー。 どのファイルも複数の実装者に割り当ててはいけません。

ファイルを共有しなければならない場合

あるファイルに複数の実装者からの変更が本当に必要な場合:

1. 単一のオーナーを指名する — 1 人の実装者がそのファイルを所有します
2. 他の実装者は変更を依頼する — オーナーに具体的な変更リクエストをメッセージで送ります
3. オーナーが変更を順次適用する — マージ競合を防ぎます
4. 代替案: インターフェースを抽出する — オーナー以外が変更せずにインポートできる別のインターフェースファイルを作成します

インターフェース契約

実装者が境界で連携する必要がある場合:

// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
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: Login feature (login form + login API + login tests)
implementer-2: Register feature (register form + register API + register tests)

長所: 各スライスは独立してテスト可能で、必要な統合が最小限です。 短所: 共有ユーティリティが重複する可能性があり、密結合なフィーチャーでは難しくなります。

水平レイヤー

各実装者がすべてのフィーチャーにまたがる 1 つのレイヤーを構築します:

implementer-1: All UI components (login form, register form, profile page)
implementer-2: All API endpoints (login, register, profile)
implementer-3: All tests (unit, integration, e2e)

長所: 各レイヤー内でパターンが一貫し、自然に専門分化できます。 短所: 統合ポイントが増え、レイヤー 3 はレイヤー 1 と 2 に依存します。

ハイブリッド

結合度に基づいて垂直と水平を組み合わせます:

implementer-1: Login feature (vertical slice — UI + API + tests)
implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)

最適な用途: 共有インフラストラクチャをある程度含む、ほとんどの実世界のフィーチャー。

ブランチ管理

単一ブランチ戦略

すべての実装者が同じフィーチャーブランチで作業します:

• セットアップが簡単で、マージのオーバーヘッドがない
• 競合を避けるために厳格なファイル所有権が必要
• 最適な用途: 小規模チーム (2〜3 人)、境界が明確な場合

マルチブランチ戦略

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

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

• より多くの分離、明示的なマージポイント
• オーバーヘッドが高く、共有ファイルではマージ競合が依然として発生する可能性がある
• 最適な用途: より大規模なチーム (4 人以上)、複雑なフィーチャー

トラブルシューティング

実装者同士が共有コードを待って互いにブロックしてしまう。 その部分を独立したインターフェース契約ファイルとして抽出し、チームリードが所有するようにしたうえで、実装者はそこからインポートするようにします。どちらの実装者も契約を変更せず、それに沿って実装するだけです。

明確な所有権ルールがあってもマージコンフリクトが発生する。 1 つのファイルが 2 人のエージェントに割り当てられているか、あるいは両者によって変更された設定/インデックスファイル（例: index.ts、__init__.py）がすべてを自動インポートしています。すべてのバレル/インデックスファイルに単一の所有者を指定するか、最後にリードがそれらをマージするようにします。

ある実装者が早く完了したが、統合ステップがブロックされている。 ステージングを活用します。完了した実装者が下流の依存関係のスタブまたはモックを作成し、もう一方の実装者が作業を続けられるようにします。統合時に実際の実装に置き換えます。

途中で機能の分解が間違っていたことが判明した。 新規の作業を停止し、リードがファイルを再配分し、その変更を周知します。部分的に書かれたコードの埋没費用は許容範囲です。誤った分割のまま続けるほうが悪化します。

ある実装者が書いたテストが、別の実装者が書いたコードに対して失敗する。 インターフェース契約がずれています。API を所有する実装者が、テスト実装者に通知せずにシグネチャを変更したのです。契約ファイルの変更前には周知を必須とするルールを徹底します。

関連スキル

• team-composition-patterns — 作業を分解する前に、適切なチームサイズとエージェントの種類を選択します
• team-communication-protocols — 実装者間で統合の引き継ぎと計画の承認を調整します