estimate-jira

JIRA チケットの見積もりスキル

このスキルでは、JIRA チケット、機能、プロジェクトの複雑さと作業量を体系的に見積もります。複雑さのレベル、所要時間、依存関係の分析、リスク評価、不明点の特定を含む、一貫性のある専門的な見積もりレポートを作成します。

このスキルを使用するタイミング

ユーザーから以下の依頼があった場合、このスキルを有効にします。

• 「この JIRA チケットを見積もって」
• 「[チケット／機能] の複雑さを分析して」
• 「このプロジェクトの作業量はどのくらい？」
• 「この機能の規模を見積もって」
• 「どのくらいかかる？」
• 「この作業にどんなリスクがある？」

前提条件

• ユーザーが JIRA チケットの内容を提供している（Markdown 形式を推奨）
• 依存関係の分析のため、リポジトリのコードベースにアクセスできる
• プロジェクトのアーキテクチャを理解している（必要に応じて tools/prompts/technology-stack.md を参照）

ワークフロー

ステップ 0：必要なドキュメントを読み込む

分析を始める前に、必ず以下のファイルを読んでください。

1. tools/prompts/guides/jira.md - JIRA クイックリファレンス
2. tools/prompts/technology-stack.md - アーキテクチャの制約とパターン
3. CLAUDE.md - リポジトリの規約とビルド要件

読み終えたら、以下を理解していることを確認してください。

• リポジトリの構造と主要なパッケージ
• ビルドとテストのコマンド
• アーキテクチャ上の制約（例：実行時依存関係がゼロ）

ステップ 1：チケット情報を収集して分析する

次に進む前に、すべて完了してください。

• ユーザーから JIRA チケットの内容を受け取る（Markdown 形式）
• 主な要件、受け入れ条件、制約を抽出する
• 主に影響を受ける領域（パッケージ／ファイル）を特定する
• チケットに記載されている情報と不足している情報を確認する

初期分析の質問：

• どのような種類の作業ですか？（バグ修正、新機能、リファクタリング、ドキュメントなど）
• どのパッケージが影響を受けますか？（community、enterprise、types、website など）
• 関連チケットや依存関係についての記載はありますか？
• 範囲は明確に定義されていますか、それとも曖昧ですか？

ステップ 2：曖昧な点と実装方法の特定

重要：このステップを完了するまで、見積もりに進まないでください。

以下の項目に曖昧な点がないか分析してください：

1. 技術的なアプローチ

   • 有効な実装戦略が複数ありますか？
   • 希望するアーキテクチャ／パターンは指定されていますか？
   • パフォーマンス要件は定義されていますか？

2. スコープの境界

   • 機能のスコープは明確に定められていますか？
   • エッジケースとエラー処理は指定されていますか？
   • 後方互換性は必要ですか？

3. 統合ポイント

   • 既存のシステムにどのように統合すべきですか？
   • フレームワークのラッパー（React／Angular／Vue）に影響しますか？
   • 公開 API に変更はありますか？

4. テストと品質

   • どの程度のテストカバレッジが期待されていますか？
   • ビジュアルリグレッションテストは必要ですか？
   • ベンチマークを追加／更新すべきですか？

5. ドキュメント

   • ドキュメントは必要ですか？
   • 例は必要ですか？
   • 移行ガイドを作成すべきですか？

特定した重要な曖昧点ごとに、以下を行ってください：

• 曖昧な点を明確に記録する
• 考えられる実装方法を列挙する
• 各選択肢が所要時間／複雑さ／リスクに与える影響を記載する
• 先に進む前に、AskUserQuestion ツールを使用して確認する

AskUserQuestion ツールを使用して、曖昧な点を提示してください：

AskUserQuestion ツールを使用して、次の形式で一度に 1～4 件の曖昧な点を提示してください：

• question：曖昧な点についての明確な質問（例：「『xy』モードは視覚的にどのように動作すべきですか？」）
• header：短いラベル（最大 12 文字）（例：「2 軸 UI」）
• options：実装方法の選択肢を 2～4 件提示し、以下を含める：
  • label：簡潔な選択肢名（例：「2 つのナビゲーター」）
  • description：影響の説明（例：「X 軸（下）と Y 軸（右）の両方にナビゲーターを表示します。複雑さは 20％増しますが、UI は分かりやすくなります」）
• multiSelect：false（ユーザーはいずれか 1 つの方法を選択します）

使用例：

AskUserQuestion({
    questions: [
        {
            question: "How should the 'xy' mode work visually?",
            header: 'Dual-axis UI',
            multiSelect: false,
            options: [
                {
                    label: 'Two Separate Navigators',
                    description:
                        'Show both X-axis (bottom) and Y-axis (right) navigators simultaneously - +20% complexity, clearer UI',
                },
                {
                    label: 'Integrated Navigator',
                    description: 'Single unified UI component - High complexity, unclear UX, needs design work',
                },
                {
                    label: 'Not Supported',
                    description: "Only allow 'x' or 'y', defer 'xy' to future ticket - -30% complexity, simpler scope",
                },
            ],
        },
        {
            question: 'Should Y-axis navigator position be configurable?',
            header: 'Position',
            multiSelect: false,
            options: [
                {
                    label: 'Configurable (left/right)',
                    description:
                        'Add navigator.position option - +10% complexity, flexible but may overlap Y-axis labels',
                },
                {
                    label: 'Right Side Only',
                    description: 'Always on right to avoid conflicts - Baseline complexity, simpler but less flexible',
                },
            ],
        },
    ],
});

回答を受け取った後：

• 選択した方法をまとめに記録する
• 選択されたオプションに基づいて見積もりを調整する
• レポートの「実装上の決定」セクションに決定事項を記載する

ステップ 3：コードベースの依存関係と複雑さを調査する

徹底的にコードベースを分析するには、Explore エージェントを使用してください：

• 影響を受けるすべてのファイルとパッケージを特定する
• 既存の類似実装を分析し、パターンを確認する
• 他のシステム／モジュールへの依存関係を確認する
• 更新が必要な関連テストを探す
• 変更が必要なドキュメントを検索する

主な調査項目：

1. コア実装

   • メインロジックはどこにありますか？
   • 該当箇所の既存コードはどの程度複雑ですか？
   • 参考にできる類似機能はありますか？

2. 型システム

   • ag-charts-types の更新が必要ですか？
   • 複雑な型定義が関係しますか？
   • 公開 API の範囲に影響しますか？

3. テスト対象

   • 影響を受けるテストファイルはいくつありますか？
   • 画像スナップショットは必要ですか？
   • E2E テストが必要になりますか？

4. ドキュメントと例

   • 更新が必要なドキュメントページはいくつありますか？
   • 新しい例は必要ですか？
   • フレームワーク別のバリエーションを生成しますか？

5. ビルドの依存関係

   • 再ビルドが必要なパッケージはどれですか？
   • 循環依存のリスクはありますか？
   • ビルドのパフォーマンスに影響しますか？

ステップ 4：構造化された見積もりレポートを作成する

一貫性を保つため、以下のテンプレートをそのまま使用してください：

---

見積もりレポート：[チケット ID／機能名]

日付：[現在の日付] **見積もり担当者：**Claude Code チケットの概要：[1～2 文で簡潔にまとめる]

---

エグゼクティブサマリー

指標	値
総作業量	[X-Y 日]（[X-Y 時間]）
複雑度	[低 | 中 | 高 | 非常に高い]
リスクレベル	[低 | 中 | 高]
確信度	[低 | 中 | 高]

主なポイント：

• [主な実装作業の概要を1～2文で記載]
• [主要なスコープの決定事項または制約]
• [該当する場合、最大のリスクまたは懸念事項]

---

1. 推定複雑度

全体的な複雑度：[低 | 中 | 高 | 非常に高い]

理由：

• [複雑さを左右する要因の説明]
• [このレベルを選んだ理由]

複雑度の内訳：

• 実装：[低／中／高]
• テスト：[低／中／高]
• ドキュメント：[低／中／高]
• 統合：[低／中／高]

---

2. 推定作業時間

合計見積もり：開発者1人で[X-Y 日]

確信度：[低 | 中 | 高]

内訳：

• 調査と設計：[X 時間／日]

  • 要件の把握
  • 設計上の決定
  • 必要に応じた技術検証

• コア実装：[X 時間／日]

  • 主なコード変更
  • 型定義
  • パブリック API の更新

• テスト：[X 時間／日]

  • 単体テスト
  • E2E テスト（該当する場合）
  • ビジュアルリグレッションテスト（該当する場合）
  • ベンチマークの更新（該当する場合）

• ドキュメント：[X 時間／日]

  • ドキュメントページの更新／作成
  • サンプルの作成
  • 移行ガイド（該当する場合）

• レビューと反復：[X 時間／日]

  • コードレビューのフィードバック
  • テストの失敗
  • バグ修正

前提条件：

• [見積もりに影響する主な前提条件を列挙]
• [例：「開発者はキャンバスの描画に精通していると想定」]
• [例：「大規模なアーキテクチャ変更は不要と想定」]

---

3. 依存関係、ギャップ、情報不足

外部依存関係：

• [他チーム／チケットへの依存関係を列挙]
• [ブロック中／ブロックしている項目]

情報の不足：

• [チケットに明記されていない内容]
• [未回答の質問]
• [関係者への確認が必要な領域]

暗黙のスコープ（明示されていないもの）：

• [必要となる可能性が高いが、記載されていない作業]
• [例：「フレームワークラッパーの更新」]
• [例：「ロケール文字列の追加」]

スコープ外（関係者に確認）：

• [想定される可能性はあるが、別途対応すべき項目]
• [例：「基本実装を超えるパフォーマンス最適化」]

---

4. 最もリスクの高い3つの要素

リスク #1：[説明]

カテゴリ：[既知の未知 | 技術的複雑さ | 統合リスク | など]

詳細：

• [リスク要因]
• [想定される影響]

軽減策：

• [リスクを軽減する方法]

---

リスク #2：[説明]

カテゴリ：[既知の未知 | 技術的複雑さ | 統合リスク | など]

詳細：

• [リスク要因]
• [想定される影響]

軽減策：

• [リスクを軽減する方法]

---

リスク #3：[説明]

カテゴリ：[既知の未知 | 技術的複雑さ | 統合リスク | など]

詳細：

• [リスク要因]
• [想定される影響]

軽減策：

• [リスクを軽減する方法]

---

5. 全体的なリスクレベル

リスク評価：[低 | 中 | 高]

根拠：

• [全体的なリスク分析]
• [リスクレベルに影響する要因]
• [既知の未知事項の概要]

リスク要因：

• 技術的リスク：[低／中／高] - [理由]
• スケジュールリスク：[低／中／高] - [理由]
• 統合リスク：[低／中／高] - [理由]
• 要件リスク：[低／中／高] - [理由]

見積もりの確信度：

• [確信度（高／中／低）とその理由]
• [確信度を高めるために必要なこと]

---

推奨される次のステップ

1. [直ちに行う項目]
2. [実装前に必要な調査]
3. [関係者への確認事項]

---

実装方針（確定）

[date] に関する関係者からの確認に基づきます。

1. [Decision Area 1]: [Chosen approach]（[Option letter]）
2. [Decision Area 2]: [Chosen approach]（[Option letter]）
3. [Decision Area 3]: [Chosen approach]（[Option letter]）

注：見積もり中に重要な実装上の選択肢が確認された場合に限り、このセクションを含めてください。

---

レポート終了

---

完了チェックリスト

すべてにチェックを入れるまで、見積もりを完了としてマークできません。

• ユーザーからJIRAチケットの内容が提供されている
• 重要な曖昧点をすべて特定し、ユーザーに確認している
• Explore エージェントを使用したコードベースの調査が完了している
• 見積もりレポートのすべてのセクションが記入されている
• 複雑さのレベルが根拠とともに説明されている
• 時間の見積もりに内訳と前提条件が含まれている
• 上位3つのリスクと緩和策が特定されている
• 全体的なリスクレベルが評価されている
• レポートの完全性と正確性が確認されている

重要なルール

1. 曖昧点の確認を絶対に省略しないでください - 実装上の選択が見積もりに大きく影響する場合は、先に進む前にAskUserQuestion ツールを使ってユーザーに必ず確認してください。誤解を招く見積もりを提示するより、確認のために作業を一時停止する方が適切です。選択肢ごとの複雑さや所要時間への影響を明確に示してください。

2. 曖昧点の確認には必ず AskUserQuestion ツールを使用してください - 実装上の選択肢を確認するために、その場しのぎのテキスト会話を使わないでください。明確な選択肢と影響の説明を添えて、1〜4件の曖昧点を一度に提示する構造化された AskUserQuestion ツールを使用してください。

3. コードベースの分析には必ず Explore エージェントを使用してください - 複雑なコードベースの調査を手作業で行わないでください。Explore エージェントはこの作業に最適化されています。

4. 不確実性について正直に伝えてください - 確信度が低い場合は、そのことを明確に伝えてください。確信度を高めるために必要な情報も含めてください。

5. スコープ全体を考慮してください - テスト、ドキュメント、レビューの反復、フレームワークのラッパーを忘れないでください。これらは総作業量の40〜50％を占めることがよくあります。

6. 未知の要素を考慮してください - 判明している不確定要素に応じて、所要時間の見積もりとリスクレベルを引き上げてください。

7. 単一の数値ではなく範囲で示してください - 特に複雑な作業では、不確実性を反映するために範囲（例：「3〜5日」）で示してください。

8. 前提条件を明記してください - すべての見積もりは前提条件に基づいています。検証できるよう、それらを明確に記載してください。

問題への対処

問題：チケットの情報が不十分

解決策：

• ユーザーに詳細情報を依頼する
• 必要な情報を具体的に列挙する
• ユーザーが追加情報を提供できない場合は、不確実性を大きく見込んだ見積もりを提示する

問題：関連するコード領域が見つからない

解決策：

• Explore エージェントを使用し、検索パターンを広げる
• コードの場所について、ユーザーに手がかりを尋ねる
• レポートに「判明している不確定要素」として記録する

問題：複数の実装方法が有効で、複雑さに大きな差がある

解決策：

• AskUserQuestion ツールを使用して、各方法を選択肢として提示する
• 各選択肢の説明に、複雑さや所要時間への影響を含める
• 該当する場合は、いずれかの選択肢の説明に推奨案を記載する
• 構造化されたインターフェースを通じて、ユーザーに希望する方法を選択してもらう
• 選択した方法を「実装方針」セクションに記録する

問題：見積もりが妥当な期間を超える（例：1人で2週間超）

解決策：

• 作業を複数のチケットに分割すべきか検討する
• リスク評価でこの点を強調する
• サブタスクまたはフェーズの作成を推奨する
• スコープを縮小する選択肢について、ユーザーと相談する

見積もり調整の基準データ

AG Charts の一般的な作業項目には、次の基準見積もりを使用してください。

シリーズの実装

• 新しいシリーズタイプ（AbstractBarSeries、CartesianSeries などを拡張）：10 日／2 週間
  • 含まれる内容：コア実装、型定義、レンダリングロジック、テーマとの統合
  • 含まれる内容：単体テスト、ビジュアルリグレッションテスト、ドキュメントページ、フレームワークのサンプル
  • 例：重なり合う棒／縦棒シリーズ、タイムラインシリーズ、四分円チャート
  • 含まれない内容：非常に複雑なレンダリングアルゴリズム、標準を超える高度なインタラクション

アノテーションの実装

• 新しいアノテーションタイプ：15～20 日（3～4 週間）
  • 含まれる内容：アノテーションのコアクラス、レンダリング、ドラッグ／リサイズ操作、型定義
  • 含まれる内容：包括的なテスト（単体、E2E、ビジュアルリグレッション）、ドキュメント、サンプル
  • 例：テキストアノテーション、図形アノテーション、計測ツール
  • 複雑さを左右する要因：ドラッグ＆ドロップ操作、リサイズハンドル、接続点、スタイルシステム

その他の一般的な作業項目

• 単純なバグ修正（影響範囲が限定的で、根本原因が明確）：0.5～1 日
• 複雑なバグ修正（調査が必要で、複数の領域に関わる）：2～3 日
• 新しいチャートオプション（単純なプロパティで、ロジックが最小限）：1～2 日
• イベント／コールバックの追加：2～4 日（複雑さによる）
• パフォーマンス最適化：3～5 日（調査＋実装）
• 互換性を損なう API 変更：移行ガイドと後方互換性テストのために 20～30％を追加

調整のガイドライン：

• 20～30％を追加：複数のシステムとの深い統合が必要な場合
• 30～50％を追加：機能に大きな未知の要素がある場合、または要件が不明確な場合
• 40～60％を追加：ライセンス確認や高度なテーマ設定が必要なエンタープライズ機能の場合
• 20～30％を削減：最小限の変更で既存のインフラストラクチャを大幅に活用できる場合に限る

関連ドキュメント

• JIRA ガイド - JIRA クイックリファレンス
• JIRA 作成スキル - JIRA チケットの作成
• テクノロジースタック - アーキテクチャ上の制約
• テストガイド - テスト要件とパターン
• ドキュメントガイド - ドキュメント要件
• コード品質ガイド - 品質基準

使用例

ユーザーが次のように言った場合：

• 「AG-12345 を見積もって」
• 「この機能の複雑さはどのくらいですか？」
• 「このチケットの規模を見積もって」
• 「[feature] の実装に必要な工数はどのくらいですか？」
• 「この作業のリスクを分析して」

このスキルでは、次のことを行います：

1. JIRA チケットの内容をリクエストします（まだ提供されていない場合）
2. 要件を分析し、曖昧な点を特定します
3. 実装方法について確認します
4. コードベースを徹底的に調査します
5. 要求されたすべてのセクションを含む包括的な見積もりレポートを作成します
6. リスク、未知の要素、複雑な箇所を明示します

一貫性のある見積もりを作成できるよう、出力は常に構造化されたレポート形式に従います。