task-decomposition

タスクの分解

概要

タスクの分解では、複雑なタスクを、明確な依存関係、工数見積もり、並列化の機会を備えた、管理しやすく明確に定義されたサブタスクに分割します。階層型作業分解構成（WBS）、依存関係グラフの作成、クリティカルパス分析、タスクの規模設定、並行実行の機会の特定を扱います。複数段階の実装計画、プロジェクトの見積もり、自律ループで選択するタスクの決定に不可欠です。

開始時に宣言: 「タスク分解スキルを使って、依存関係と見積もりを含む構造化された階層に作業を分解します。」

トリガー条件

• 複雑なタスクをサブタスクに分解する必要がある
• 作業項目間の依存関係をマッピングする必要がある
• 計画のために工数を見積もる必要がある
• 並列化の機会を特定する必要がある
• /decompose コマンドが呼び出された
• 複雑な計画について、計画スキルから移行する
• 自律ループでタスクを選択するための指針が必要である

---

フェーズ 1：スコープの定義

目標： 分解の明確な境界を定義します。

1. 全体の成果物と受け入れ基準を定義する
2. 範囲の境界（対象となるもの、対象外となるもの）を特定する
3. 分解の粒度を決定する
4. ステークホルダーとその要件を特定する
5. 制約（時間、リソース、依存関係）を定める

粒度の決定表

コンテキスト	目標レベル	典型的な期間	理由
自律ループ（Ralph）	L3-L4（タスク／サブタスク）	15 分～4 時間	ループの反復ごとにタスクは 1 つ
スプリント計画	L2-L3（ストーリー／タスク）	0.5～2 日	スプリントに適した作業項目
ロードマップ計画	L0-L1（エピック／機能）	2～8 週間	大まかなマイルストーンの追跡
バグ修正	L3-L4（タスク／サブタスク）	15 分～2 時間	対象を絞った具体的な修正

粒度レベル

レベル	名称	典型的な期間	例
L0	エピック	2～8 週間	「ユーザー認証システム」
L1	機能	2～5 日	「OAuth2 ログインフロー」
L2	ストーリー	0.5～2 日	「Google OAuth プロバイダーの統合」
L3	タスク	1～4 時間	「Google コールバックハンドラーを実装する」
L4	サブタスク	15～60 分	「OAuth トークン応答を解析する」

停止 — 以下を満たすまでフェーズ 2 に進まないでください：

• 成果物と受け入れ基準が定義されている
• スコープの境界（対象／対象外）が明確である
• 目標とする粒度レベルが選択されている
• 制約が特定されている

---

フェーズ 2：階層的な分解

目標： INVEST 基準を満たすツリー構造に作業を分解します。

1. 最上位の作業ストリーム（エピックまたは主要コンポーネント）を特定する
2. 各作業ストリームを機能またはマイルストーンに分割する
3. 機能を実装可能なタスクに分解する
4. 「2 時間ルール」を適用する — 集中して作業するタスクが 2 時間を超えないようにする
5. 各タスクに明確な完了条件があることを確認する
6. MECE（相互に排他的で、全体を網羅している）になっているか確認する

タスクの INVEST 基準

基準	質問	悪い例	良い例
Independent（独立性）	他の作業を待たずに実行できますか？	「DB の準備ができたら認証を実装する」	「モック DB を使って認証を実装する」
Negotiable（交渉可能性）	アプローチに柔軟性がありますか？	「キャッシュに Redis を使う」	「ユーザーセッション用のキャッシュ層を追加する」
Valuable（価値）	完了すると価値が得られますか？	「フォルダー構造を設定する」	「ユーザー登録エンドポイントを作成する」
Estimable（見積もり可能性）	工数を見積もれますか？	「パフォーマンスを改善する」	「ユーザー検索クエリ用のデータベースインデックスを追加する」
Small（小規模）	1 人で 2 時間未満に完了できますか？	「ダッシュボードを構築する」	「売上データ用のダッシュボードのグラフコンポーネントを作成する」
Testable（検証可能性）	完了したことを検証できますか？	「改善する」	「/api/users の応答時間を 200ms 未満にする」

MECE 検証

確認項目	質問
相互排他性	あるタスクが別のタスクと重複していませんか？（重複していないこと）
網羅性	すべてのタスクを合わせると、成果物全体をカバーしていますか？（カバーしていること）
孤立タスクがないこと	すべてのタスクが成果物に貢献していますか？
抜けがないこと	必要な作業なのに、対応するタスクがないものはありませんか？

停止 — 次の条件を満たすまで、フェーズ 3 に進まないでください。

• すべての作業ストリームが特定されている
• タスクが INVEST 基準を満たしている
• MECE による網羅性が検証されている
• 2 時間を超えるタスクがない

---

フェーズ 3：依存関係のマッピング

目標： タスクの依存関係を示す有向非巡回グラフ（DAG）を作成します。

1. タスク間の入力／出力の依存関係を特定する
2. 依存関係の種類を分類する
3. 有向非巡回グラフ（DAG）を作成する
4. クリティカルパス（最長の依存関係の連鎖）を特定する
5. 循環依存関係を解決すべきエラーとして記録する
6. 外部依存関係（API アクセス、承認、サードパーティ）を明示する

依存関係の種類

種類	記号	意味	例
Finish-to-Start（FS）	A -> B	A が完了するまで B を開始できない	「ビルドが成功する」の後に「デプロイ」
Start-to-Start（SS）	A => B	A の開始と同時に B を開始できる	「コードの作成」の開始時に「ドキュメントを作成」
Finish-to-Finish（FF）	A =>> B	A が完了するまで B を完了できない	「開発」の完了後に「テスト」が完了する
Start-to-Finish（SF）	A ~> B	A が開始するまで B を完了できない	まれ — 引き継ぎのシナリオ

依存関係の表記形式

Task 1: Set up database schema
Task 2: Create data access layer         [depends: 1]
Task 3: Implement API endpoints          [depends: 2]
Task 4: Write unit tests for DAL         [depends: 2]
Task 5: Write API integration tests      [depends: 3, 4]
Task 6: Create frontend components       [depends: none]
Task 7: Connect frontend to API          [depends: 3, 6]
Task 8: End-to-end testing               [depends: 5, 7]

Parallel tracks:
  Track A: 1 -> 2 -> 3 -> 5 -> 8
  Track B: 1 -> 2 -> 4 -> 5 -> 8
  Track C: 6 -> 7 -> 8
  Critical path: 1 -> 2 -> 3 -> 7 -> 8

循環依存関係の解決

検出	解決方法
A が B に依存し、B が A に依存している	循環が解消されるよう、より小さなタスクに分割する
A が B のインターフェースに依存し、B が A のインターフェースに依存している	先にインターフェースを個別のタスクとして定義する
コンポーネント間の結合度が高い	抽象化レイヤーのタスクを追加する

停止 — 次の条件を満たすまで、フェーズ 4 に進まないでください。

• すべての依存関係がマッピングされている
• 循環依存関係が存在しない
• クリティカルパスが特定されている
• 外部依存関係が明示されている

---

フェーズ 4：並列化の計画

目標： 同時に実行できる、独立したタスクのクラスターを特定します。

1. 独立したタスクのクラスター（相互に依存関係がないもの）を特定する
2. リソースの種類（読み取り、書き込み、ビルド、テスト）ごとにタスクをグループ化する
3. リソースの制約に基づいて、最大並列数を決定する
4. 各並列トラック内のタスクを順序付ける
5. 同期ポイント（マージゲート）を計画する

リソースに基づく並列数の上限

リソースの種類	最大並列数	理由
コードの読み取り／分析	無制限	副作用がない
ファイルの作成／編集	3～5	マージコンフリクトを防ぐ
ビルド／コンパイル	1	リソースの競合
テストの実行	1～2	状態とポートの共有
データベースのマイグレーション	1	性質上、順次実行
ドキュメント	無制限	ファイルが独立している

並列化パターンの選択表

パターン	使用する場面	例
独立したクラスター	共有状態のない作業ストリーム	バックエンド、フロントエンド、インフラ
レイヤー別	レイヤーごとに異なるファイルを扱う	API、サービス、データ
機能領域別	独立した垂直スライス	認証、プロフィール、請求
タスクの種類別	コード、テスト、ドキュメントが異なるファイルを扱う	実装、テスト、ドキュメント作成

同期ポイント

  +------+     +------+     +------+
  |Task A|     |Task B|     |Task C|
  +--+---+     +--+---+     +--+---+
     |            |            |
     v            v            v
  ======================================
     SYNC GATE: All Complete
     Verify: no conflicts, tests pass
  ======================================
                 |
                 v
          +----------+
          |Next Phase|
          +----------+

停止 — 次の条件を満たすまで、フェーズ 5 に進まないでください。

• 独立したクラスターが特定されている
• リソースの制約が考慮されている
• 同期ポイントが定義されている
• 最大並列数が決定されている

---

フェーズ 5：見積もりと優先順位付け

目標： 各タスクの作業量を見積もり、実行スケジュールを作成します。

Tシャツサイズから時間への換算

サイズ	時間	確信度	例
XS	0.5-1h	高	変数名の変更、誤字の修正
S	1-2h	高	シンプルなエンドポイントの追加、テストの作成
M	2-4h	中	既知のパターンを使った機能の実装
L	4-8h	低	調査が必要な新機能
XL	8h+	非常に低	さらに細分化する必要があります

見積もりのヒューリスティクス

シナリオ	乗数	理由
既知のパターン	基本見積もりの1.2倍	不確定要素に備えて20%のバッファを確保
未知のパターン	基本見積もりの2倍	まず調査用のタスクを追加
統合作業	各要素の合計の1.5倍	統合は各要素単体より難しい
初めて扱う技術	「知っていれば」の見積もりの3倍	学習曲線を考慮
バグ修正	調査を2時間に制限	その後、見積もりをやり直す

三点見積もり

Expected = (Optimistic + 4 * Most Likely + Pessimistic) / 6

Example:
  Optimistic:  2 hours (everything goes smoothly)
  Most Likely: 4 hours (normal development pace)
  Pessimistic: 10 hours (major unexpected issues)
  Expected:    (2 + 16 + 10) / 6 = 4.7 hours

優先順位付けの判断表

要素	重み	評価方法
クリティカルパス上にある	最高	ここでの遅延はすべての遅延につながります
他のタスクをブロックしている	高	ブロック解除でスループットが向上します
ビジネス価値	高	ユーザーへの影響
リスクの低減	中	不確定要素のリスクを早期に低減します
クイックウィン	中	労力が少なく、士気が高まります
あれば便利	低	中核となる作業が完了してから取り組みます

---

作業分解構成テンプレート

# WBS: [Project Name]

## 1. [Work Stream A]
### 1.1 [Feature]
- [ ] 1.1.1 [Task] — Est: 2h — Deps: none — Priority: P0
- [ ] 1.1.2 [Task] — Est: 1h — Deps: 1.1.1 — Priority: P0
- [ ] 1.1.3 [Task] — Est: 3h — Deps: 1.1.1 — Priority: P1

### 1.2 [Feature]
- [ ] 1.2.1 [Task] — Est: 1h — Deps: none — Priority: P0
- [ ] 1.2.2 [Task] — Est: 2h — Deps: 1.2.1, 1.1.2 — Priority: P1

## 2. [Work Stream B]
### 2.1 [Feature]
- [ ] 2.1.1 [Task] — Est: 1h — Deps: none — Priority: P0
- [ ] 2.1.2 [Task] — Est: 4h — Deps: 2.1.1 — Priority: P0

## Summary
- Total tasks: N
- Estimated total effort: Xh
- Critical path duration: Yh
- Max parallelism: Z tracks
- External dependencies: [list]

---

クリティカルパス分析

クリティカルパスの見つけ方

1. すべてのタスクを、所要時間と依存関係とともに列挙します
2. 順方向パス：最早開始時刻（ES）と最早終了時刻（EF）を計算します
3. 逆方向パス：最遅開始時刻（LS）と最遅終了時刻（LF）を計算します
4. フロート = LS - ES（フロートがゼロのタスクはクリティカルパス上にあります）
5. クリティカルパスは、依存関係グラフ上の最長の経路です

最適化戦略

戦略	適用場面	効果	リスク
並列化	クリティカルパス上の独立したタスク	カレンダー上の所要時間を短縮します	低
ファストトラッキング	順次実行するタスクを重ねて実行	所要時間を短縮します	中 — 手戻りが発生する可能性があります
クラッシング	クリティカルなタスクにリソースを追加	所要時間を短縮します	中 — 調整コストが発生します
スコープの縮小	必須ではないタスクを削除	作業全体を減らします	低 — 必須ではないという判断が正しい場合
先行調査	未知のタスクがパスをブロックしている場合	見積もりのリスクを低減します	低

---

アンチパターン／よくある間違い

アンチパターン	失敗する理由	正しいアプローチ
見積もれないほど大きなタスク	「バックエンドを構築する」はタスクではありません	見積もれる単位（2時間未満）になるまで細分化します
依存関係の見落とし	実装中に表面化し、手戻りの原因になります	すべての依存関係を事前に洗い出します
循環依存	アーキテクチャが不明確であることを示しています	インターフェースのタスクを設けて循環を解消します
すべてのタスクを順次実行	並列化できません	独立したタスクのまとまりを特定します
分解せずに見積もる	L0レベルで推測するため、常に間違います	リーフレベルで見積もり、合計します
外部依存関係を無視	予期せず進行が妨げられます	明示して、対応を計画します
過剰な細分化	有益な情報ではなくノイズになります（フォームにサブタスクが50個など）	意味があり、テスト可能な単位で止めます
クリティカルパスを無視	重要度の低いタスクを優先してしまいます	常にクリティカルパスを優先します
見積もりを更新しない	学びが増えるにつれて見積もりにずれが生じます	各フェーズの後に見積もり直します
受け入れ基準のないタスク	完了を検証できません	すべてのタスクに完了の定義を設けます

---

合理化を防ぐガード

依存関係のマッピングを省略しないでください。2時間を超えるタスクを残さないでください。まず細分化せずに見積もらないでください。すべてのタスクに依存関係、見積もり、受け入れ基準が必要です。

次のように考えていることに気づいたら：

• 「細分化しなくても全体を見積もれる……」— いいえ。まず細分化してください。
• 「依存関係は明らかだから、マッピングする必要はない……」— マッピングしてください。隠れた依存関係は失敗の原因になります。
• 「このタスクは8時間で問題ない……」— 細分化してください。XL タスクは分割する必要があります。
• 「小規模なプロジェクトではクリティカルパスは重要ではない……」— 重要です。優先すべき項目がわかります。

---

サブエージェントへの委任機会

タスクのパターン	委任先	タイミング
細分化中に特定された並列実行可能な末端タスク	Agent ツールを介した並列サブエージェント	タスク間に共有依存関係がない場合
タスク境界のアーキテクチャ分析	planner エージェント	細分化によって横断的な懸念事項が明らかになった場合
細分化の完全性の検証	spec-reviewer エージェント	タスクツリーが完成したものの、未検証の場合

出力テーブルでは、細分化した各タスクに parallelizable: yes/no フラグを付けてください。委任時には dispatching-parallel-agents スキルのプロトコルに従ってください。

---

統合ポイント

スキル	関係	タイミング
planning	上流 — 細分化する計画を提供	複雑な計画で WBS が必要な場合
task-management	下流 — 細分化したタスクを受け取る	実行状況を追跡する場合
dispatching-parallel-agents	下流 — 並列実行可能なクラスターを受け取る	並行実行する場合
autonomous-loop	下流 — WBS からタスクを選択	Ralph のタスク選択
executing-plans	下流 — WBS からバッチを作成	計画を実行する場合
subagent-driven-development	下流 — サブエージェント向けに独立したタスクを受け取る	実装を委任する場合
spec-writing	補完 — 仕様が細分化の指針となる	要件を把握する場合

---

具体例

例：「ユーザー認証の追加」の細分化

# WBS: User Authentication

## 1. Core Auth
### 1.1 Token Management
- [ ] 1.1.1 Implement JWT generation — Est: 1h — Deps: none — P0
- [ ] 1.1.2 Implement JWT validation — Est: 1h — Deps: 1.1.1 — P0
- [ ] 1.1.3 Implement refresh token rotation — Est: 2h — Deps: 1.1.2 — P1

### 1.2 Auth Middleware
- [ ] 1.2.1 Create auth middleware — Est: 1h — Deps: 1.1.2 — P0
- [ ] 1.2.2 Add role-based access control — Est: 2h — Deps: 1.2.1 — P1

## 2. Auth Endpoints
### 2.1 Registration
- [ ] 2.1.1 POST /auth/register endpoint — Est: 1h — Deps: 1.1.1 — P0
- [ ] 2.1.2 Email validation — Est: 30m — Deps: none — P0

### 2.2 Login
- [ ] 2.2.1 POST /auth/login endpoint — Est: 1h — Deps: 1.1.1, 1.2.1 — P0
- [ ] 2.2.2 POST /auth/refresh endpoint — Est: 1h — Deps: 1.1.3 — P1

## Summary
- Total tasks: 8
- Estimated total effort: 10.5h
- Critical path: 1.1.1 -> 1.1.2 -> 1.2.1 -> 2.2.1 (4h)
- Max parallelism: 3 tracks (Token, Middleware, Endpoints)
- External dependencies: none

---

スキルのタイプ

RIGID — 細分化の各フェーズを順番に実施してください。すべてのタスクで INVEST 基準を満たし、依存関係、見積もり、受け入れ基準を明示する必要があります。数日かかる作業では、依存関係グラフとクリティカルパス分析が必須です。