チケット駆動の仕事術：良いIssueとPRで回すタスク管理・報告・合意形成

ケーススタディ（通し例）

テンプレがどのように連鎖するかを、1つのケースで示す。

注記: ここでの Issue 番号/PR 番号/指標は例示（架空）であり、実運用に合わせて読み替える。

通し例: 入力フォーム改善（誤操作率の低減）

前提（トリアージ）

  • 種別: type:feat
  • 優先度: priority:P1（問い合わせ増加のため優先対応）
  • これは障害対応ではないため、Severity（incident-response）ではなく priority を使う

1) Issue作成（親Issue）

## 背景

- 未入力のまま保存してしまい問い合わせが増加（直近2週間で20件、誤操作率 5%）

## 目的

- 誤操作率を 5% → 1% 以下に低減し、問い合わせを減らす

## スコープ

- 入力フォームの必須項目バリデーション
- エラー文言の具体化（どの項目が不足か）

## 非スコープ

- 画面全体のデザイン刷新
- 文言ポリシーの全画面統一

## 受け入れ条件

- [ ] Given: 必須項目が未入力
- [ ] When: 保存を押す
- [ ] Then: 保存されず、どの項目が不足か分かる
- [ ] 計測: 誤操作率が 5% → 1% 以下（2週間移動平均、例）

## 影響

- リスク: 既存の自動入力が弾かれる可能性
- 依存: 文言ポリシー（別Issue）と整合が必要

## 責任分界（例）

- 判断: PM
- 実行: 開発
- 確認: CS

2) 分割（子Issue）

  • 子Issue A（bug）: 不正入力時に500になる（入力チェック不足）
  • 子Issue B（feat）: フロントで即時エラー表示（UX改善）
  • 子Issue C（task）: 変更後の監視（誤操作率/エラー率）を追加

依存: A→B→C の順（まずサーバ側の安全を確保し、次にUX、最後に運用/監視）。

3) DoR/DoD（入口/出口の合意）

  • DoR: 背景/目的/受け入れ条件/非スコープ/リスクが揃っている
  • DoD: 受け入れ条件を満たし、ロールバックが定義され、必要なドキュメント更新が終わっている

付録テンプレ: DoR/DoD

4) 進捗報告（定型で更新）

## 現状

- 子Issue A は再現できた。原因はサーバ側の必須項目チェック不足
- 子Issue B は実装中（feature flag で切替）

## 次にやること

- サーバ側のバリデーションを追加し、テストを整備
- E2Eで主要導線を確認

## ブロッカー

- 文言ポリシー（レビュー待ち）

## 期限

- YYYY-MM-DD（例）

## 次回更新予定時刻

- YYYY-MM-DD HH:mm（例）

## 支援依頼

- 文言ポリシーの決定（レビュー30分）

5) PR（レビュー可能な説明）

付録テンプレ: PRテンプレ

## 何を

- サーバ側の必須項目バリデーションを追加（不正入力で500にならない）
- エラー内容を項目単位で返す

## なぜ

- 不正入力が混入すると500になり、利用者も運用も原因が分からない

## 影響

- 影響範囲: 保存API（入力エラー時のレスポンスが変わる）
- リスク: クライアント側で想定していないエラー形式だと表示が崩れる

## テスト

- 単体: 必須/境界値のテスト追加
- E2E: 作成→保存→エラー表示→再保存

## ロールバック

- feature flag をOFF（Runbookに手順を追記）

## 関連Issue

- #123（親Issue、例）

6) 完了（クローズとナレッジ化）

完了の定義には「ドキュメント更新」を含める（Runbook/FAQ/ADR などに転記し、運用で再利用できる形にする）。

結論: 必須項目チェックを追加し、不正入力時に500にならないようにした
変更: PR #456
影響: 入力エラー時のレスポンス形式が変わる（互換性に注意）
運用: Runbook を更新（リンク）。監視ダッシュボードを更新（リンク）
ADR: バリデーション方式の決定を記録（リンク）
計測: 誤操作率 5% → 1.2%（暫定、今後2週間で再評価）

7) ADR（意思決定記録）

付録テンプレ: ADRテンプレ

関連（次に読むと良い）

Edit this page on GitHub