こんにちは。ファインディ株式会社でテックリードマネージャーをやらせてもらってる戸田です。
ファインディでは要件定義から設計・タスク分解・Issue生成までをAIに任せるカスタムコマンドを開発しています。
このコマンドの中にはAIがタスク分解を行うステップがありますが、分解の粒度が適切でなければ、実装がしやすいどころか混乱の元になります。大きすぎるタスクはレビューが困難になり、タスクを細かく分割しすぎると実装が中途半端でビルドが通らないPRが生まれます。
そこで、AIがタスクを分解する際の判断基準として、具体的なルールを定めました。この記事では、そのタスク分解ステップで使っているルールを紹介します。
AIのタスク分解の粒度が重要な理由
AIに実装タスクを分解してもらうとき、「タスクを小さくする」という方針だけを与えても、粒度の判断基準が曖昧では適切な出力は得られません。分割しすぎて中途半端なコードが生成されビルドが通らないPRが生まれたり、逆にまとめすぎて障害発生時にrevertの影響が広がりすぎたりします。
どちらも「revertの単位を意識していない」という同じ原因から来ているため、「revertできる単位か」という1つの軸を判断基準の中心に据えました。
タスク分解の基本原則
AIが設計するすべてのタスクは「独立してrevertできる最小の意味ある変更単位」であるべきです。具体的には次の4条件を満たします。
- アプリケーションを壊さずにマージできること
- 実装とテストが含まれていること
- 他のタスクに影響を与えずにrevertできること
- レビュアーが2〜3時間以内にレビューできること
この原則に沿うことで、障害が起きたときに「どのPRを戻せばいいか」の判断が明確になり、レビューの粒度も自然と揃います。
分割判断の3ステップフローチャート
AIは2つの変更（タスクAとタスクB）を同じタスクにまとめるか分けるかを、次の3ステップで判断します。どれか1つで「高凝集」と判断された時点で同じタスクにまとめ、3つすべてを通過してはじめて別タスクとして分離します。
ステップ1: 動作の独立性（Independence Check）
「タスクAがなくてもタスクBは正常に動作するか？」
「動作しない」なら高凝集と判断し、同じタスクにまとめます。APIエンドポイントとルーティング設定はその典型で、ルーティングなしではAPIを呼び出せません。一方、ユーザー検索機能と通知機能はそれぞれ独立して動作するため、別タスクに分離できます。「動作する」なら次のステップへ進みます。
ステップ2: 機能の完結性（Completeness Check）
「タスクAだけをマージしても、意味のある機能として完結するか？」
「完結しない」なら同じタスクにまとめます。メール送信ロジックだけをマージしても、それを呼び出すイベントトリガーがなければ誰にもメールが届きません。一方、ログ改善は単体でデプロイしても既存機能に価値を加えます。「完結する」なら次のステップへ進みます。
ステップ3: revertの影響範囲（Revert Impact Check）
「タスクAをrevertしたら、タスクBも壊れるか？」
「壊れる」なら同じタスクにまとめます。実装コードをrevertすればテストが壊れるため、実装とテストは常にセットです。一方、feature flagの追加とその有効化は独立しており、有効化だけをrevertしても追加コードは残ります。「壊れない」なら別タスクに分離できます。
タスクサイズの定量指標
3ステップの判断に加えて、サイズの上限も定義しています。AIが生成するタスクがこの範囲を超える場合は、さらに分割できないかを検討します。
| 指標 | 理想 | 最大 |
|---|---|---|
| 変更ファイル数 | 3〜10個 | 15個 |
| 変更行数（テスト含む） | 200〜500行 | 1,000行 |
| テストコード量 | 実装の0.5〜2倍 | — |
ただし、凝集度が高い変更であれば、サイズが目安を超えていても無理に分割しません。サイズはあくまで補助指標です。
凝集度パターン集
3ステップの判断を素早く行うために、「常にセットにすべきもの」と「常に分離すべきもの」をパターンとして定義しています。
常に同じタスクにまとめるべきもの
次の4パターンは絶対に分離しません。
- 実装コード ⇔ テストコード（テストなしの実装はマージしない）
- APIエンドポイント ⇔ ルーティング設定（両方ないと動作しない）
- データモデル ⇔ マイグレーション（スキーマとコードの整合性を保つ）
- サービスクラス ⇔ インターフェース定義（型の整合性を保つ）
常に別タスクに分けるべきもの
次のパターンは必ず分離します。
- リファクタリング ⇔ 新機能追加（バグ発生時の原因特定を容易にする）
- feature flag: 「実装（デフォルトOFF）→ 有効化（テストユーザー）→ 有効化（全ユーザー）→ 削除」の各段階
- 依存ライブラリの更新 ⇔ 新機能追加（ライブラリ更新の影響を独立して検証する）
- パフォーマンス改善 ⇔ 新機能追加（改善効果を独立して計測する）
- データマイグレーション ⇔ 新機能追加（高リスクな操作を独立して実行する）
- 互いに依存しない複数の機能（それぞれ独立してrevertできる）
具体例: ユーザー通知機能の分割
ユーザー通知機能を実装する場合、AIは次の3つのタスクに分けて設計します。
| タスク | 内容 | ファイル数 | 行数 |
|---|---|---|---|
| データ層 | Notificationモデル・マイグレーション・モデルテスト | 3個 | 約240行 |
| ロジック層 | 通知送信サービス・ユニットテスト | 2個 | 約450行 |
| API層 | エンドポイント・ルーティング・スキーマ・統合テスト | 3個 | 約340行 |
「機能全体を1つのタスク」にすると変更ファイルが10個超・1,000行超になりレビューが困難です。加えて、API層に不具合が起きたときデータ層まで巻き込んでrevertする必要が生まれます。API層をrevertしてもデータ層には影響しないため、独立してrevertできる粒度に分解することが重要です。
タスクリストを評価する5つの観点
AIがタスクリストを生成した後、次の5つの観点で自己評価を行います。
- 粒度チェック: 各タスクが適切なサイズか、大きすぎるものや小さすぎるものがないか
- 凝集度チェック: 実装とテストが同じタスクにあるか、APIとルーティングがセットになっているか
- 独立性チェック: 各タスクを単独でrevertできるか、マージ後にアプリケーションが正常動作するか
- 依存関係マッピング: タスク間の依存関係が明確か、並列実装できるタスクが識別されているか
- 改善提案: 問題があればどのタスクを分割・統合すべきかの具体的な推奨
この評価がPRを作る前の段階で完了するため、レビュー時の分割議論がなくなります。
実行例
今回紹介したスキルを実行したログです。
⏺ 承知しました。クリーンアーキテクチャアプローチで進めます。
それではタスク分解フェーズに進んで、task-breakdownスキルを使って
タスク分解を評価・調整します。
⏺ Skill(task-breakdown)
⎿ Successfully loaded skill
⏺ 評価対象タスク（code-architectが提案した5タスク）:
Task 1: [Data] ドメインモデルの追加
変更ファイル: 3個, ~80行
依存: なし
Task 2: [Logic] CSVパーサーの実装
変更ファイル: 3個, ~100行
依存: Task 1
Task 3: [Logic] バリデーターの実装
変更ファイル: 3個, ~120行
依存: Task 1
Task 4: [Logic] ユーザーインポートサービスの実装
変更ファイル: 3個, ~180行
依存: Task 1, 2, 3
Task 5: [API] 管理者用一括登録エンドポイント
変更ファイル: 3個, ~100行
依存: Task 1, 2, 3, 4
⏺ [粒度チェック]
✅ 全タスクのファイル数: 3個（基準: 3〜10個）
✅ 全タスクの行数: 80〜180行（基準: 200〜500行以内）
⚠ Task 4: メール連携部分を分離できる可能性あり（現状は許容範囲）
⏺ [凝集度チェック]
✅ 全タスクで実装コードとテストコードが同一タスクに含まれている
✅ APIエンドポイントとルーティング設定がTask 5に含まれている
⏺ [独立性チェック]
✅ Task 1マージ後: アプリケーションは正常動作する
✅ Task 2マージ後: アプリケーションは正常動作する
✅ Task 3マージ後: アプリケーションは正常動作する
✅ Task 4マージ後: アプリケーションは正常動作する
✅ Task 5マージ後: アプリケーションは正常動作する
✅ 全タスク: 独立してrevert可能
⏺ [依存関係マッピング]
Task 1（モデル）
├── Task 2（CSVパーサー）─┐
└── Task 3（バリデーター）┤
└── Task 4（サービス）── Task 5（API）
並列実装可能: Task 2とTask 3
⏺ [改善提案]
現在のタスク分解は非常に良好です。このまま進めることを推奨します。
良い点:
- 各タスクのサイズが適切（3ファイル, 80〜180行）
- 各タスクマージ後もアプリケーションは正常動作する
- Task 2とTask 3の並列実装で開発効率を高められる
⏺ 最終判断: 現在のタスク分解をそのまま採用
各タスクが3ファイル・80〜180行に収まっており、並列実装できるタスクまで特定されています。この評価があることで、実装に入る前にタスク分解の妥当性を確認でき、レビュー時に分割を再検討する手戻りが起きません。
まとめ
AIにタスクを分解してもらうとき、粒度の判断基準を明確に与えることが重要です。3ステップのフローチャートと凝集度パターン集を組み合わせることで、AIが一貫した粒度でタスクを設計できるようになります。
AIが作ったタスクリストを見るとき、「このタスクを単独でrevertできるか？」という問いで評価してみてください。その問いへの答えが、適切な粒度かどうかを教えてくれます。
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。
