チケット管理

チケット管理とは

チケット管理(issue tracking)は、開発で発生するタスク・バグ・要望を1件ずつチケットとして記録し、状態を追跡する仕組みです。イシュー管理、課題管理とも呼ばれます。

代表的なツールに GitHub Issues、Jira、Backlog、Redmine などがあります。

口頭やチャットで「あのバグ直しておいて」と伝えるだけでは、誰が対応中なのか、いつ直ったのか、なぜそう直したのかが流れて消えてしまいます。チケットは開発の記憶装置として、その情報を後から辿れる形で残します。

チケットに書く要素

とくに大切なのが担当者とステータスです。この2つが正しく保たれていれば、「今このタスクは誰の手元で止まっているのか」が一目で分かります。

よいチケットの書き方

バグ報告は、次の3点が揃っていれば調査が一気に楽になります。

• 何をしたか(再現手順)— 「/login を開き、メールアドレスだけ入力して送信」
• 何が起きたか(実際の結果)— 「500エラーになった」
• 何を期待していたか(期待する結果)— 「入力を促すメッセージが出てほしい」

また、1チケット1テーマが原則です。「ログイン修正と画面改善とリファクタ」を1件にまとめると、レビューも進捗把握も難しくなります。大きすぎるものは分割しましょう。

開発フローとの接続

チケットは他の仕組みと結びつけると威力を発揮します。

• ブランチ名にチケット番号を入れる — feature/123-login-validation のようにすると、コードと背景情報が結びつきます([[ブランチ戦略]])
• コミットメッセージやPRに番号を書く — GitHub なら本文に Closes #123 と書くだけで、マージ時に自動でチケットが閉じます([[Git]])
• スプリントの単位にする — [[スクラム]] ではチケットをバックログの項目として扱い、スプリントに積んで進めます
• 見積もりを載せる — 各チケットにポイントを付けておくと、[[見積もりとベロシティ]] の計測がそのままできます

こうして「なぜこのコードがこうなっているのか」を、コミット→PR→チケットと辿れる状態を作るのが理想です。

初学者向けポイント

• 気づいた小さな改善点も忘れないうちにチケットにしましょう。頭の中のTODOはいつか消えます
• 詰まったら進捗をコメントに残します。翌日の自分と、引き継ぐ人への手紙になります
• 100件溜まって誰も見ないなら、それは記録ではなくゴミ箱です。定期的に棚卸しし、やらないものは明示的に閉じましょう
• 状態を動かすのは作業した本人です。完了したのに「対応中」のままでは、チーム全体の判断が狂います

関連技術とのつながり

• [[スクラム]] — バックログの項目としてチケットを扱う
• [[アジャイル開発]] — 小さな単位に分けて優先順位を見直す進め方と相性がよい
• [[Git]] — コミットやPRからチケットを参照し、経緯を辿れるようにする
• [[ブランチ戦略]] — ブランチ名にチケット番号を含めて対応関係を明確にする
• [[見積もりとベロシティ]] — チケット単位の見積もりが計測の基礎になる

Q: バグのチケットに書くべき3点として適切なものはどれ?
- [x] 再現手順・実際の結果・期待する結果
- [ ] 担当者の氏名・所属・連絡先
- [ ] 使用言語・行数・ファイルサイズ
解説: この3点が揃っていれば、受け取った側は調査をすぐ始められます。

Q: チケットの粒度に関する原則はどれ?
- [ ] 関連する作業はできるだけ1件にまとめる
- [x] 1チケット1テーマにし、大きすぎるものは分割する
- [ ] 1日で終わらない作業はチケットにしない
解説: 複数テーマを1件に詰めるとレビューも進捗把握も難しくなります。分割するのが基本です。

Q: GitHub でPR本文に `Closes #123` と書くと何が起きる?
- [ ] チケットの担当者が自動で割り当てられる
- [x] マージ時に該当のチケットが自動的に閉じる
- [ ] チケットの優先度が最高になる
解説: PRとチケットが紐づき、マージと同時にクローズされます。経緯を後から辿れる状態も作れます。