第2章：良いIssueテンプレ（背景/目的/スコープ/受け入れ条件）

この章で学ぶこと

• 受け入れ条件を Given-When-Then などで書く
• スコープ境界（やらないこと）で期待値を揃える
• 不具合・改善・作業でテンプレを使い分ける

成果物（書けるようになるもの）

• 不具合・改善・作業の Issue テンプレを使って記述できる
• 関連テンプレ: 不具合 / 改善 / 作業

本文

Issue の品質は、受け入れ条件の明確さで大きく左右される。受け入れ条件がない Issue は、完了が定義できず、終わらないタスクになりやすい。

受け入れ条件は「完了の判定基準」であり、「作業項目」ではない。実装メモや設計案は補足として書けるが、完了判定は受け入れ条件で行える状態にする。

受け入れ条件の例（Given-When-Then）

• Given: 既存ユーザーでログイン済み
• When: プロフィール更新を実行
• Then: 成功メッセージが表示され、DB が更新される

テンプレを固定すると、レビュー観点も固定できる。

テンプレの使い分け（最小）

• 不具合: 期待結果/実結果に加え、再現手順/環境/ログを揃える（第3章）
• 改善: 背景/目的/スコープ/非スコープ/受け入れ条件を揃える
• 作業: 手順/期待結果（受け入れ条件）/ロールバック/完了条件を揃える

具体例（悪い例→良い例）

悪い例

受け入れ条件: 良い感じになること
スコープ: いい感じに

良い例

背景: 入力不備による差戻しが多い
目的: 入力不備の差戻しを減らす
受け入れ条件:
- [ ] Given: 入力が不正
- [ ] When: 保存を押す
- [ ] Then: 保存されず、どの項目が不正か分かる
非スコープ: デザイン刷新、文言統一の全体対応

チェックリスト

• 受け入れ条件が検証可能な形になっている
• 非スコープが明記されている
• 想定読者（利用者/運用者）が意識されている

まとめ

• 受け入れ条件は検証可能な形（Given/When/Then など）で書き、完了判定を固定する
• 非スコープを明記し、期待値のズレを抑止する
• 不具合・改善・作業でテンプレを使い分け、レビュー観点を固定する

次章への接続

• 次章: 第3章