jira-estimate-epic

name	jira-estimate-epic
description	作業の見積もりをJiraのエピックチケットとして起票する際に使う。要件・コードベース調査結果をもとに、役割別工数内訳(実装者/レビュー者/内部結合テスト作成者/内部結合テスト実施者)を持つフォーマットの見積もりエピックのドラフトを作成し、確認を得てから起票する。
user-invocable	false

Jira見積もりエピック作成スキル

使うタイミング

• 「〜の見積もり準備」「見積もりチケットを作って」等の指示を受けたとき
• 過去の見積もりエピックのフォーマットに沿った新しい見積もりエピックを 作りたいとき

手順

1. 調査

1. 元チケット(見積もり依頼元)の内容を確認する
2. 関連する Slack / Confluence などの一次情報を確認する
   • ドキュメントの記述だけで判断せず、必ず一次情報(Slackスレッドなど) に当たる。同じ用語が複数の異なる意味で使われているケースがあるため 注意する
   • 用語の意味に少しでも疑いがあれば、コードベースの検索結果だけで 結論を出さず、Slack検索等で裏を取る
3. 対象コードベースを調査し、変更が必要になりそうな箇所・ 既存の類似実装パターンを特定する
4. 不確定要素を「確認事項」としてリストアップする
   • 各確認事項には「誰(どのチーム)に確認するか」 「回答によって対応方針・工数がどう変わるか」を必ずセットで書く
   • 対応方針が分岐しうる場合(例: 新規環境追加 vs 既存設定の書き換えで 済む、等)は両方のケースを明示する
   • 確認先は基本的に個人名よりチーム名(「インフラチーム」等)の方が好まれる
5. 過去の見積もりエピックを Jira で検索し、フォーマットを確認する (searchJiraIssuesUsingJql 等でプロジェクト内の過去エピックを探す。 なければユーザーに実例を1つ聞く)

2. フォーマット

見積もりエピックの description は以下の構成に従う。

関係者 ← 見出しレベル1。テキストに underline 装飾

背景 ← 見出しレベル1。underline

対応内容 (合計h) ← 見出しレベル1。underline

※ 合計h 切り上げてXh ← 8h(1人日)単位に切り上げる

実装者 (Xh) ← 見出しレベル2。underlineなし

キャッチアップ (8h) ← 見出しレベル3。underlineなし

仕様 (Xh) ← 確認事項をここに列挙(上記4節参照)

DB作業 (Xh) ← 該当する場合のみ

実装 (Xh)

レビュー者 (Xh)

• キャッチアップ (2〜4h)
• PRレビュー (Xh)
• 内部結合テスト項目レビュー (Xh)
• 内部結合テスト実施レビュー (Xh)

内部結合テスト作成者 (Xh)

• キャッチアップ (2〜4h)
• 作成 (Xh)

内部結合テスト実施者 (Xh)

• キャッチアップ (2〜4h)
• 実施 (Xh)

関連ドキュメント ← 見出しレベル1。underline

備考 ← 見出しレベル1。underline

「関係者」セクションは具体的な個人名ではなく、大まかな関与区分 (例:「技術内部」「XXチーム」)で書かれることが多い。

3. 工数のルール

• 実装者のキャッチアップは複雑さによらずデフォルト8hを起点とする
• レビュー者・内部結合テスト担当のキャッチアップは2〜4h程度を目安にする
• 合計工数は8h(1人日)単位に切り上げ、切り上げ前後の値を 「※ Xh 切り上げてYh」の形で明記する

4. Jira作成時の注意 (ADF)

• createJiraIssue を markdown経由 (contentFormat: "markdown") で 作成すると、見出しレベル1のunderline装飾は再現できない

• underlineを最初から正しく反映したい場合は contentFormat: "adf" を使い、 見出し (heading, level: 1) の content 内テキストノードに marks: [{"type": "underline"}] を付与してADFを直接組み立てる

  {
    "type": "heading",
    "attrs": { "level": 1 },
    "content": [
      { "type": "text", "text": "関係者", "marks": [{ "type": "underline" }] }
    ]
  }
  

• 見出しレベル2・3にはunderlineを付けない

5. 起票前の確認

• 作成前に必ずドラフトをチャット上でユーザーに提示し、確認を得てから createJiraIssue を実行する(Jiraへの起票は他者から見える操作のため)
• 「見積もりの内容自体が妥当か(工数感やタスクの過不足)」は コードベース調査だけでは判断できないことが多い。ユーザー自身の ドメイン知識での最終確認を必ず挟む