タスク分析スキル
Issue仕様の構造化
Issue仕様を以下の観点で構造化して把握する。
機能要件の抽出
- •目的: この変更で何を達成するか
- •ユーザーストーリー: 誰が、何を、なぜ行うか
- •受け入れ条件: 完了の判定基準
- •制約条件: 技術的・ビジネス的な制約
技術要件の抽出
- •変更種別: 新規追加 / 修正 / 削除 / リファクタリング
- •影響範囲: フロントエンド / バックエンド / インフラ / DB
- •データモデル変更: スキーマ変更の有無
- •API変更: エンドポイントの追加・変更の有無
コードベース調査の手法
ドメイン概念の検索
- •Issue内のキーワードからドメイン概念を抽出する
- •
src/domain/配下で関連するエンティティ・値オブジェクトを検索する - •
src/domain/ports/で関連するPortインターフェースを確認する - •
src/domain/usecases/で関連するUseCaseを確認する
既存パターンの調査
- •類似機能の実装を見つける（同じ種類のエンティティやユースケース）
- •ディレクトリ構造とファイル命名のパターンを把握する
- •テストの書き方のパターンを把握する
- •NestJSモジュールのDI設定パターンを把握する
影響範囲の調査
- •変更対象ファイルのimport/exportを追跡する
- •Prismaスキーマの関連テーブルを確認する
- •NestJSモジュールの依存関係を確認する
タスク粒度の判断基準
適切な粒度
- •1つのテストファイルで検証できる範囲
- •1つのDDD層内で完結する変更
- •diffが概ね200行以内に収まる変更
- •レビュアーが短時間で理解できる変更
粒度が大きすぎるサイン
- •複数のDDD層にまたがる変更が1タスクに含まれている
- •テストケースが10個以上必要になる
- •変更ファイルが5個以上ある
粒度が小さすぎるサイン
- •単体ではテストできない（依存する実装が別タスク）
- •変更がインターフェース定義のみで振る舞いがない
- •他のタスクと必ずセットでないと意味がない