第1章：チケット駆動の前提（成果物・品質・期限・責任分界）

この章で学ぶこと

• 口頭依存・属人化を減らすために、情報をチケットに集約する
• 成果物（何が出来たら完了か）を先に定義する
• 品質・期限・責任分界を明文化する

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

• Issue に「目的/スコープ/受け入れ条件」を書ける
• 関係者の責任分界（誰が判断/誰が実行）を書ける

本文

チケット駆動の価値は、作業の可視化に加えて、合意形成・意思決定の証跡化と再現性を高める点にある。

最小の構造

• 背景（なぜ今必要か）
• 目的（どうなれば成功か）
• スコープ/非スコープ
• 受け入れ条件（検証可能な形）
• 期限/優先度
• 責任分界（判断者/実行者/確認者）

この構造がないと、レビューや引き継ぎで「口頭の補足」が増え、事故や手戻りにつながる。

注意点（よくある失敗）

• 背景が“要望”だけになり、事実（頻度/影響）が書かれていない
• 目的が“対応する”“改善する”になり、完了後の状態が定義されていない
• 受け入れ条件が主観的（例: 良い感じ）で、第三者が検証できない
• 責任分界が曖昧で、判断が滞留する（誰が決めるかが不明）

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

悪い例

タイトル: 画面を直す
本文: なんか使いにくいので改善してください

良い例

タイトル: 入力フォームの誤操作を減らす
背景: 入力ミスによる差戻しが多い
目的: エラー発生率を下げる
スコープ: 必須項目のバリデーション/文言
非スコープ: 画面全体のデザイン刷新
受け入れ条件（例）:
- [ ] Given: 必須項目が未入力
- [ ] When: 保存を押す
- [ ] Then: 保存されず、どの項目が不足か分かる
責任分界: 判断=PM、実行=開発、確認=CS

チェックリスト

• 背景/目的がある
• スコープ/非スコープがある
• 受け入れ条件が検証可能
• 責任分界（判断/実行/確認）が書かれている

まとめ

• 最小の構造（背景/目的/スコープ/受け入れ条件/期限/責任分界）を揃える
• 完了の定義として受け入れ条件と責任分界を先に書き、口頭補足と手戻りを減らす

次章への接続

• 次章: 第2章