Issue テンプレ：作業

背景

• なぜ今やるか（期限/依存/リスク）

目的

• この作業で何を完了させるか

スコープ

• 対象（環境/システム/範囲）

非スコープ

• 今回やらないこと

責任分界（任意）

• 判断:
• 実行:
• 確認:

手順

1. （記入）
2. （記入）

期待結果（受け入れ条件）

• （計測可能/第三者が判定可能な形で書く）

確認方法

• 受け入れ条件を確認するコマンド/ログ/画面:
• PR または完了コメントで示す証跡:

チェック

• 影響範囲を確認
• 期待結果を確認

ロールバック

• 戻し方
• 戻す判断基準

完了条件

• （記入）

根拠・未確定点

• 根拠種別（一次情報/調査ログ/運用ログ/二次情報/AI 生成物など）:
• 未確定点:
• 再確認条件:

記入例（抜粋）

• 背景: 監視アラートが誤検知しており当番負荷が上がっている（直近7日で誤検知15回、例）
• 目的: p95 レイテンシのアラート条件を見直し、誤検知を減らす
• スコープ: production の api-latency-p95 アラート（しきい値/期間/通知先）
• 非スコープ: 監視基盤の刷新、全アラートの一括見直し
• 手順: 1) 現状のメトリクス分布を確認 2) しきい値案を作成 3) ステージングで検証 4) 本番反映
• 期待結果: 反映後1週間で誤検知が 15回→3回以下（例）、重大アラートの見逃しが増えない
• 確認方法: しきい値変更 PR、ステージング検証ログ、反映後1週間のアラート履歴
• ロールバック: 旧しきい値に戻す / 通知先を一時停止（条件を明記）
• 完了条件: Runbook のアラート説明を更新し、変更 PR / 反映日時を相互リンクする
• 根拠・未確定点: 監視ログを根拠にする。繁忙期の分布は未確認のため再確認条件に入れる