タスク分解診断

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

このスキルを使う場合

以下の場合にこのスキルを使用してください：

• タスクが大きすぎて見積もりできない
• どこから始めたらよいかわからない
• 依存関係でブロックされている
• タスクが膨らみ続けている（スコープクリープ）
• エピックまたは機能を分解する必要がある

以下の場合は使用しないでください：

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

核となる原則

目標はより多くのタスクではなく、正しいタスクです。 完全に理解できるほど小さく、価値を提供するのに十分な大きさで、ブロックを避けるのに十分な独立性を持つタスク。

クイックリファレンス：認知的制限

制限	閾値	意味合い
ワーキングメモリ	7±2項目	タスクあたりの最大概念数
コンテキスト切り替え復帰時間	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、トレードオフ、改定見積もり
• スパイク後に実装するパターン

分解パターン

縦スライシング（機能に推奨）

機能: ユーザープロフィール管理

スライス1: 基本プロフィールを表示（4時間）
  - UI: プロフィール表示
  - API: GET /profile
  - DB: プロフィール読み込み

スライス2: プロフィール名を編集（6時間）
  - UI: 編集ダイアログ
  - API: PATCH /profile/name
  - DB: プロフィール更新

各スライスは独立してデプロイ可能

ウォーキングスケルトン（新規システム用）

最小限のエンドツーエンドを最初に：
1. Hello World ページ
2. 1つの GET エンドポイント
3. 単一テーブル
4. 基本的なデプロイ

その後、段階的に拡張

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

ステップ1: 最小限のサービスA（1時間）- ハードコードされた応答
ステップ2: 最小限のサービスB（1時間）- シンプルな変換
ステップ3: 統合（2時間）- 通信することを検証

合計: 決定ポイントまで4時間

見積もり手法

複雑度サイジング（フィボナッチ）

ポイント	意味
1	自明、1時間以下
2	シンプル、1～2時間
3	標準、2～4時間
5	中程度、4～8時間
8	複雑、1～2日
13	非常に複雑、2～3日
21	大きすぎる、分解が必須

3点見積もり法

O = 楽観的（すべてが完璧）
L = 可能性が高い（通常の場合）
P = 悲観的（大きな問題がある）

PERT見積もり: (O + 4L + P) / 6

アンチパターン

ビッグバンデリバリー

何もデリバリーする前にシステム全体を構築する。 修正: 縦スライス、段階的価値。

価値のない技術タスク

「データベースを設定」、「サービスレイヤーを作成」。 修正: 機能タスクに含める：「ユーザーが製品を表示できる（DBを含む）」。

研究の永遠化

制限のない調査。 修正: 成果物を伴うタイムボックス化されたスパイク。

完璧な分解

開始前に過度に分析する。 修正: 次の2週間を分解。後の作業の詳細は後で明確になる。

分解チェックリスト

タスク開始前に：

• すべての要件をワーキングメモリに保持できるか？
• 期間は2～3日以下か？
• 明確な受け入れ基準が存在するか？
• 依存関係を特定し、可能な限り解決したか？
• 独立して完了できるか？
• 検証可能な価値をもたらすか？
• 見積もりの確信度は高いか？

いずれかが「いいえ」の場合 → さらなる分解が必要です。

関連スキル

• github-agile - 分解されたタスクを問題として追跡
• system-design - アーキテクチャ境界を理解
• requirements-analysis - 不明確な要件を明確化
• code-review - 実装後にレビュー