task-management

タスク管理

価値： コミュニケーションとフィードバックです。作業を明確で追跡可能な単位に分割すると、意図が見えるようになり、進捗を測定でき、引き継ぎも円滑になります。小さなタスクによってフィードバックループが短くなり、問題を早期に発見できます。

目的

明確な受け入れ基準を備えた適切な構造のタスクに作業を分解し、タスク間の依存関係を管理し、一貫したライフサイクルを通じてステータスを追跡する方法を学びます。その結果、どのタスクも曖昧さがなく、適切な範囲に収まり、不必要にブロックされない順序に並んだ作業分解が得られます。

プラクティス

トップダウンで分解し、ボトムアップで実行する

大きな目標を、各タスクが単一の成果物を表すまで段階的に小さなタスクへ分割します。末端のタスクから順に実行します。

1. 目標（エピックまたは機能）から始めます
2. 目標の達成に必要な子タスクを3～7個特定します
3. 各子タスクについて、「1人のエージェントが1回のセッションで完了できるか」を確認します。できない場合はさらに分解します
4. 末端のタスクは数分から数時間で完了できるものにし、数日かかるものにはしません

例：

Epic: User Authentication
  Story: Registration flow
    Task: Create registration command handler
    Task: Build registration form component
    Task: Add email verification automation
  Story: Login flow
    Task: Create login command handler
    Task: Build login form component

推奨事項：

• 動詞と成果を使ってタスクに名前を付けます（「登録ハンドラーを作成する」など）
• 末端のタスクは、1回の集中したセッションで完了できる小ささにします
• すべての末端タスクに受け入れ基準を含めます

避けるべきこと：

• 何時間も進捗が見えなくなるほど大きなタスクを作成しないでください
• タスク管理のオーバーヘッドが作業量を上回るほど細かく分解しないでください
• 曖昧な名詞だけのタスクにしないでください（「認証」だけでは何をすべきか分かりません）

受け入れ基準を検証可能な記述として書く

すべての末端タスクに、達成または未達を判定できる基準が必要です。動作には「Given／When／Then」を使い、成果物にはチェックリストを使います。

1. タスク完了時に満たされているべき状態を記述します
2. 各基準は個別にテストできるようにします
3. 重要なエッジケースを含めます

例：

Task: Create registration command handler

Acceptance Criteria:
- [ ] Given valid registration data, when command is processed,
      then UserRegistered event is stored
- [ ] Given a duplicate email, when command is processed,
      then command is rejected with a clear error
- [ ] Given a password under 12 characters, when command is processed,
      then validation fails before reaching the handler

避けるべきこと：

• 主観的な判断が必要な基準（「うまく動作する」など）を書かないでください
• エラーケースを省略しないでください。バグはそこに潜んでいます
• 無関係なタスク間で汎用的な基準をコピー＆ペーストしないでください

依存関係を明示する

タスクBがタスクAの完了まで開始できない場合、その依存関係を宣言します。依存関係グラフを使って、ブロックされていない作業を見つけます。

1. タスクを作成する前に、「別のタスクの成果物に依存しているか」を確認します
2. 使用しているツールに依存関係を記録します
3. 全リストを確認するのではなく、ブロックされていないタスクや着手可能なタスクを常に検索します

依存関係のパターン：

• 順次： スキーマ -> リポジトリ -> サービス -> API エンドポイント
• 分岐： 1つの設計タスクによって、複数の実装タスクが開始可能になる
• 合流： 統合テストの前に、複数のタスクを完了する必要がある

推奨事項：

• 依存関係の連鎖はできるだけ短くします。長い連鎖は作業を順次実行にしてしまいます
• 並行しても問題のない分解を優先します（同時に実行できるタスク）

避けるべきこと：

• 循環依存を作成しないでください
• 暗黙の順序を前提にしないでください。すべての依存関係を明示します
• タスクを不必要にブロックしないでください（Bは本当にAを必要としているのか、それともAのインターフェースだけでよいのかを確認します）

スライスからタスクへの分解

GWT（Given-When-Then）シナリオ（例：イベントモデリングから）を使って垂直スライスに取り組む場合、各タスクがテスト可能な動作の増分を表し、RED-GREEN-COMMIT サイクルをひととおり完了するようにスライスを分解します。

1. 各 GWT シナリオを、少なくとも 1 つのタスクにします
2. 各タスク = 1 つの TDD サイクル：失敗するテスト 1 つ + その実装 + コミット
3. タスクは次の順に並べます。
   • ウォーキングスケルトンの依存関係を先にする — 複数のシナリオで必要となるインフラストラクチャや配線（それぞれを独立した TDD サイクルにします）
   • 受け入れシナリオのタスク — 各シナリオを 1 つのタスクとし、最も外側の失敗するテストから始めて、掘り下げるサイクルを通じて完了します
4. 各タスクには次の内容を含めます。
   • 説明： 動詞 + 成果（例：「TDD を通じて入金シナリオをエンドツーエンドで実装する」）
   • 受け入れ基準： GWT シナリオから直接記載します
   • 推定スコープ： 影響を受ける可能性のあるファイル（ミューテーションテストのスコープ設定に役立ちます）

例：

Slice: "Customer deposits funds"
  Task 1: Walking skeleton — wire request-to-response path (RED: acceptance
    test hits endpoint and gets 404 → GREEN: route exists, returns stub →
    COMMIT)
  Task 2: Deposit scenario — deposit $100 into verified account (RED:
    acceptance test asserts balance increases → drill-down into command
    handler, event persistence, projection — each inner cycle is
    RED-GREEN-COMMIT within this task → outer acceptance test passes → COMMIT)

アンチパターン： 複数の種類や動作を 1 つの RED フェーズにまとめ、その後に別個の GREEN フェーズを設けるタスクは作成しないでください。これは TDD を装ったウォーターフォールです。「すべてのドメイン型を作成する」の後に「すべてのハンドラーを実装する」というタスクを続けると、各タスクを完全な TDD サイクルにするのではなく、フェーズをタスク間に分割することになります。

パイプライン追跡メタデータ

パイプラインモードで実行する場合、タスクには次の追跡フィールドが追加されます。

• slice_id — タスクを元の垂直スライスに紐付けます
• gate_status — pending、passed、または failed（品質ゲートの結果を示します）
• rework_count — 品質ゲートの失敗後にタスクが差し戻された回数

これらのフィールドは、スタンドアロンモードでは情報提供のみを目的とします。パイプラインモードでは、オーケストレーターがこれらを使ってスライスの進捗を追跡し、タスクが何度も手戻りを繰り返しているかどうかを検出します。

一貫したライフサイクルでステータスを追跡する

タスクは固定された状態の間を移動します。状態遷移は明示的です。

ライフサイクル： Open -> Active -> Closed

1. Open： タスクが定義され、着手を待っている状態です。依存関係によってブロックされている場合があります。
2. Active： 作業中の状態です。集中を保つため、エージェントごとに一度に Active にするタスクは 1 つだけにします。
3. Closed： 作業が完了し、受け入れ基準を満たした状態です。必ず理由を記録してください。

ルール：

• 作業を開始する前にタスクを Active にします
• すべての受け入れ基準を満たした場合にのみ、タスクを Closed にします
• 監査証跡のため、クローズ理由を記載します
• タスクを中止する場合は、理由（「X に置き換えられた」または「不要になった」）を添えてクローズします

利用可能なツールに適応する

このスキルは、利用可能なあらゆるタスク追跡ツールで機能します。最適な選択肢を検出して使用してください。

1. ハーネスネイティブのタスクツール（Claude Code TodoWrite、Codex tasks）：そのまま使用します。エージェントのワークフローに統合されています。
2. dot CLI（.dots/ ディレクトリ）：ファイルベースで、バージョン管理されています。dot ready を使って、ブロックされていない作業を確認します。PR を作成する前に、フィーチャーブランチ上でタスクをクローズします。
3. GitHub Issues：チーム間の可視性を確保するために使用します。PR を Issue にリンクします。
4. ファイルベースの代替手段： リポジトリのルートに TASKS.md を作成します。Markdown のチェックリストを使用し、変更とともにコミットします。

ツールにかかわらず、方法論（分解、基準の明確化、依存関係の追跡、ライフサイクルの管理）は同じです。ツールは入れ替え可能ですが、規律は欠かせません。

適用に関する注記

すべてのモードで推奨事項です。タスク構成と依存関係の追跡は、自己管理で行います。

厳守事項：

• タスクをクローズする際はクローズ理由が必須です：[RC]

制約

• 「エージェントごとにアクティブなタスクは1つ」：エージェントごととは、実行コンテキストごとを意味します。並列ワークツリーを使うパイプラインモードでは、各ワークツリーが個別のコンテキストになります。複数のワークツリーを管理する人間のオペレーター1人がこのルールに違反することはありません。複数の「アクティブな」タスクを持つ単一のエージェントコンテキストは違反になります。
• バイナリ形式の受け入れ基準：「バイナリ形式」とは、主観的な判断を介さずに、外部の観察者が達成・未達成を検証できることを意味します。「コードがきれいである」はバイナリ形式ではありません。「すべての関数が50行未満である」はバイナリ形式です。「テストに合格する」もバイナリ形式です。「コードがベストプラクティスに従っている」はバイナリ形式ではありません。基準を満たしているかどうかについて議論が必要なら、それはバイナリ形式ではありません。

パイプラインの並列化ルールについては、テンプレートディレクトリにある CONSTRAINT-RESOLUTION.md を参照してください。

検証

このスキルに沿って作業を完了した後、次の点を確認してください。

• すべての作業単位に、受け入れ基準を伴うタスクが対応している
• 依存関係が未解決の間に作業したタスクはない
• エージェントごとのアクティブなタスクは、常に1つに制限されていた
• クローズされたタスクには、理由が記録されている
• タスク階層をたどることができる（親子関係が明確である）
• 未完了のタスクに、残作業が正確に反映されている

基準を満たしていない項目があれば、先に進む前に該当するプラクティスを見直してください。

依存関係

このスキルは単独で動作します。ワークフローを強化するには、次のものと連携します。

• **tdd：**各タスクは1つ以上のTDDサイクルに対応します。タスクの受け入れ基準は、レッドフェーズで作成するテストになります。自動モードでは、タスクの依存関係に基づいて、エージェント間で作業をどのように委任するかを決めます。
• **architecture-decisions：**主要な構造タスクでは、関連するADRを参照してください。

依存関係が見つからない場合は、次のコマンドでインストールしてください。

npx skills add jwilger/agent-skills --skill tdd