| name | jira-estimate-epic |
| description | 作業の見積もりをJiraのエピックチケットとして起票する際に使う。要件・コードベース調査結果をもとに、役割別工数内訳(実装者/レビュー者/内部結合テスト作成者/内部結合テスト実施者)を持つフォーマットの見積もりエピックのドラフトを作成し、確認を得てから起票する。 |
| user-invocable | false |
Jira見積もりエピック作成スキル
使うタイミング
- 「〜の見積もり準備」「見積もりチケットを作って」等の指示を受けたとき
- 過去の見積もりエピックのフォーマットに沿った新しい見積もりエピックを
作りたいとき
手順
1. 調査
- 元チケット(見積もり依頼元)の内容を確認する
- 関連する Slack / Confluence などの一次情報を確認する
- ドキュメントの記述だけで判断せず、必ず一次情報(Slackスレッドなど)
に当たる。同じ用語が複数の異なる意味で使われているケースがあるため
注意する
- 用語の意味に少しでも疑いがあれば、コードベースの検索結果だけで
結論を出さず、Slack検索等で裏を取る
- 対象コードベースを調査し、変更が必要になりそうな箇所・
既存の類似実装パターンを特定する
- 不確定要素を「確認事項」としてリストアップする
- 各確認事項には「誰(どのチーム)に確認するか」
「回答によって対応方針・工数がどう変わるか」を必ずセットで書く
- 対応方針が分岐しうる場合(例: 新規環境追加 vs 既存設定の書き換えで
済む、等)は両方のケースを明示する
- 確認先は基本的に個人名よりチーム名(「インフラチーム」等)の方が好まれる
- 過去の見積もりエピックを 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)
内部結合テスト実施者 (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への起票は他者から見える操作のため)
- 「見積もりの内容自体が妥当か(工数感やタスクの過不足)」は
コードベース調査だけでは判断できないことが多い。ユーザー自身の
ドメイン知識での最終確認を必ず挟む
