task-decomposition

タスク分解診断

認知能力の限界を尊重し、明確な境界を設け、並行作業を可能にすることで、圧倒的な開発タスクを管理しやすい単位に変換します。適切に分解されたタスクは、完了率が3倍高く、欠陥が60％少なくなります。

このスキルを使うタイミング

次の場合にこのスキルを使います：

• タスクが大きすぎて見積もれないと感じる
• どこから始めればよいかわからない
• 依存関係によって作業が止まっている
• タスクが拡大し続ける（スコープクリープ）
• エピックや機能を分解する必要がある

次の場合はこのスキルを使わないでください：

• タスクがすでに小さく明確である
• 実装作業を行っている
• アーキテクチャの意思決定が必要である（system-design を使う）

中核となる原則

目標はタスクを増やすことではなく、適切なタスクを作ることです。 完全に理解できるほど小さく、価値を届けられるほど大きく、作業を妨げないほど独立したタスクにします。

クイックリファレンス：認知能力の限界

上限	しきい値	意味
ワーキングメモリ	7±2項目	1つのタスクで扱う概念の最大数
コンテキスト切り替えからの回復	23分	タスクの切り替えを最小限にする
調査するファイル数	最大15～20個	タスクの範囲を制限する
完了率が低下するまでの日数	2～3日	タスクはこの期間内に収める

タスク期間別の成功率

期間	完了率
2時間未満	95%
2～4時間	90%
4～8時間（1日）	80%
2～3日	60%
1週間	35%
2週間超	<10%

診断状態

TD1：大きすぎて理解できない

症状： 見積もりに大きなばらつきがある、すべての要件を頭の中に保持できない、追跡すべき概念が7つを超える

対策：

• INVEST 基準を適用する：独立性（Independent）、交渉可能（Negotiable）、価値がある（Valuable）、見積もり可能（Estimable）、小さい（Small）、テスト可能（Testable）
• 垂直スライスを使う（各スライスは単独でデプロイ可能）
• ウォーキングスケルトンを適用する（まず最小限のエンドツーエンドを作る）

TD2：明確な着手点がない

症状： 有効な開始点が複数ある、行き詰まる、すべてがつながっているように見える

対策：

• リスクを先に解消する：不確実性が最も高い項目から始める
• トレーサーバレット：最小限の概念実証
• ウォーキングスケルトンを見つける：すべてのレイヤーを通る最も薄いスライス

TD3：依存関係の問題

症状： 「X待ちでブロックされている」、ダイヤモンド型の依存関係、調整のオーバーヘッド

対策：

• インターフェース契約：API を定義し、実装中はモックを使う
• フィーチャーフラグ：独立してデプロイし、準備ができたら有効にする
• 抽象化によるブランチ化：レイヤーを作成し、実装を差し替える

TD4：完了条件が明確でない

症状： いつまでも「ほぼ完了」のまま、完了を検証する方法がない

対策：

• 受け入れ基準を定義する（Given／When／Then）
• 優先順位付けを促すためにタイムボックスを設定する
• 明示的な対象範囲外項目を定義する

TD5：スコープクリープ

症状： タスクが拡大し続ける、「せっかくだから」という追加

対策：

• スコープを凍結し、追加項目は新しいタスクとして作成する
• 実用最小限のバージョンを定義する
• 問題を解決する最小限のバージョンをリリースする

TD6：まずスパイクが必要

症状： 見積もりのばらつきが4倍を超える、新しい技術、複数のアプローチ

対策：

• タイムボックス付きのスパイク（最大8時間）
• 成果物：選択肢、POC、トレードオフ、見直した見積もり
• スパイクしてから実装するパターン

分解パターン

垂直スライス（機能に推奨）

Feature: User Profile Management

Slice 1: View basic profile (4h)
  - UI: Profile display
  - API: GET /profile
  - DB: Read profile

Slice 2: Edit profile name (6h)
  - UI: Edit dialog
  - API: PATCH /profile/name
  - DB: Update profile

Each slice is independently deployable

ウォーキングスケルトン（新しいシステム向け）

Minimal end-to-end first:
1. Hello World page
2. One GET endpoint
3. Single table
4. Basic deploy

Then flesh out incrementally

トレーサーバレット（アーキテクチャの検証）

Step 1: Minimal Service A (1h) - Hardcoded response
Step 2: Minimal Service B (1h) - Simple transformation
Step 3: Integrate (2h) - Prove they communicate

Total: 4 hours to decision point

見積もり手法

複雑さの規模（フィボナッチ数列）

ポイント	意味
1	ごく簡単、1時間未満
2	簡単、1～2時間
3	標準、2～4時間
5	中程度、4～8時間
8	複雑、1～2日
13	非常に複雑、2～3日
21	大きすぎるため、分解が必要

3点見積もり

O = Optimistic (everything perfect)
L = Likely (normal case)
P = Pessimistic (major issues)

PERT estimate: (O + 4L + P) / 6

アンチパターン

ビッグバンデリバリー

何も提供する前にシステム全体を構築すること。 対策： 垂直スライスで段階的に価値を提供します。

価値のない技術タスク

「データベースをセットアップする」「サービスレイヤーを作成する」。 対策： 機能タスクに含めます：「ユーザーが商品を表示できる（DB を含む）」。

終わりのない調査

範囲を定めない調査。 対策： 成果物を定めたタイムボックス付きのスパイクを行います。

完璧な分解

着手前に分析しすぎています。 対処法： 今後2週間分を分解します。後の作業の詳細は、進めるうちに明らかになります。

分解チェックリスト

タスクを開始する前に：

• すべての要件を作業記憶に保持できますか？
• 期間は2～3日以内ですか？
• 明確な受け入れ基準がありますか？
• 依存関係を特定し、可能な限り解消していますか？
• 独立して完了できますか？
• 検証可能な価値を提供しますか？
• 見積もりの確度は高いですか？

いずれかが「いいえ」の場合 → さらに分解する必要があります。

関連スキル

• github-agile - 分解した作業をイシューとして追跡します
• system-design - アーキテクチャ上の境界を理解します
• requirements-analysis - 不明確な要件を明確にします
• code-review - 実装後にレビューします