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

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

調査・合意形成・実装・ナレッジ化を、チケット（Issue / PR）で再現性高く回すための型を整備する。

まず確認する導線

想定読者

  • Issue / PR を使っているが、起票・レビュー・完了の品質が安定しない人
  • 口頭・チャット依存の進め方から脱却し、引き継ぎ可能な形に整えたい人
  • 複数人での合意形成を、テンプレとチェックリストで再現可能にしたい人

学習成果

  • 良い Issue（背景/目的/スコープ/受け入れ条件）を自力で起票できる
  • 調査ログ・意思決定記録・進捗報告・PR説明を「レビュー可能な状態」で残せる
  • DoR/DoD を運用ルールとして定義し、終わらないタスクを減らせる
  • 完了後の FAQ / Runbook / ADR への流し込みを通じて、作業結果を再利用可能なナレッジへ変換できる

所要時間（目安）

  • 60〜120分（付録のテンプレ集は必要に応じて参照）

読み方ガイド

  • 目次から、いま必要な成果物や判断がどこに書かれているかを把握する
  • 付録のテンプレとチェックリストを先に確認し、本文で意図と注意点を補完する
  • 章末のチェックリストをレビュー観点として運用に取り込む

悩み別ショートカット

前提知識

  • Git/GitHub の基本（Issue / PR）
  • 基本的な開発フロー（ブランチ/レビュー）
  • Issue / PR の基本操作に不安がある場合は、GitHub初心者ガイド を先に確認すると入りやすい

クイックスタート（最小例）

まず 1 枚、最小の Issue と PR 説明を書き、テンプレ運用の型を掴む。

Issue（最小例）:

背景: 入力フォームで誤操作が増えている（問い合わせが増加）
目的: 誤操作率を下げる（問い合わせを減らす）
スコープ: 必須項目のバリデーション/エラー文言
非スコープ: 画面全体のデザイン刷新
受け入れ条件:
- Given: 必須項目が未入力
- When: 保存を押す
- Then: 保存されず、どの項目が不足か分かる
期限/優先度: 影響×緊急度で理由を添える
責任分界: 判断=PM、実行=開発、確認=CS

PR（最小例）:

何を: 必須項目のバリデーション追加
なぜ: 誤操作が多い
影響: 入力フォームの保存時エラー文言が変わる
テスト: 不正入力/境界値/回帰
ロールバック: フラグをOFF
関連: #123

目次

付録

ライセンス

本書は Creative Commons BY-NC-SA 4.0 ライセンスで公開しています。 教育・研究・個人学習での利用は可能ですが、商用利用には事前許諾が必要です。

詳細なライセンス条件

利用・更新・質問窓口

  • リポジトリ: itdojp/issue-driven-work-book
  • 誤記報告や改善提案は GitHub Issues、まとまった修正提案は GitHub PR を利用してください。
  • 更新差分を追う場合は、GitHub の コミット履歴 と PR 一覧 を参照してください。
  • ローカルで検証する場合は、npm test を通してから内容を確認してください。
  • テンプレートやチェックリストを組織で利用する場合は、役割分担、承認フロー、優先度定義、記録粒度を各自の運用ルールに合わせて調整してください。
  • 顧客情報、障害情報、内部判断メモを扱う場合は、公開範囲と保存先を事前に決めてからテンプレートへ転記してください。
Edit this page on GitHub