こんにちは、テクニカルディレクターの菊池です。
昨今は開発の現場で、Githubなどのチケット（課題）管理システムが多用されるようになってきました。本記事では、Githubなどのチケット管理システムにおけるIssueの書き方、ならびにフォーマットについて説明します。
チケットを作成する目的
Github上でチケットを作成する目的は以下の3つです。
エンハンスメント・バグ修正のタスク管理
1つ目は、エンハンスメント・バグ修正のタスクを管理するためです。
Github上でチケットを作成することで、課題に関するディスカッション、ビジネス部門からの要望など、プロダクトやシステムに関する課題について逐一管理することが可能になります。
タスクのスコープの明確化
2つ目は、タスクのスコープを明確にするためです。
スコープとは、「やりたいこと」から予算や時間、リソースなどを考慮して絞った「やれること」の範囲内で実現できる成果物と、そのためのタスクの実行範囲のことを表します、このスコープが明確になっていないと、そもそものプロジェクトを進めることすら困難になります。
そこで、Github上でチケットを作成することでタスク管理を可視化し、同時にスコープも明確化することが可能となるのです。
過去のタスク履歴の確認
3つ目は、過去のタスク履歴を確認するためです。
そのタスクが「なぜ」「いつ」「どのような背景で」検討されたのか、もしくは改修したのかを追えるようにしておくことは開発において重要です。
チケット作成の前提
実際にGithub上でチケットを作成する際に覚えておくべきことを解説します。
共通事項
まずは「1チケットにつき1PR（プル・リクエスト）」が大原則です。プル・リクエストとは、自分の開発したものをチームで共有するための手順、ルール、マナーのことを指します。
その他には以下も重要です。
- チケット1つあたりのタスクがFatとならないようにする
- 他の人が見ても分かるように記載する
- コミット内にチケット番号を入れるようにする
- Issueの完了条件について明記する
1では、原則として1モジュールや1レイヤーを想定しています。
2は、意識することで結果的にトレーサビリティが向上し、「どのような経緯」で「どんなIssueがあったか」を追うことが可能となります。同様の理由で3も重要で、最低限PR内にラベルを貼ることが必須です。
Issueの識別
続いて、各チームごとに記載すべきIssueの内容を紹介します。
- 開発チーム：エンハンスメント、議論（アーキテクチャに関する議論、調整など）
- QAチーム：バグ報告
- ビジネスサイドチーム：要望、議論（仕様に関する議論、調整など）
この内容をチケットにまとめておくことで、開発も滞りなく行われます。
バグ修正用のIssueの書き方
そして、Issueを書くうえでは、バグの修正も考慮しておく必要があります。
まずは、バグの発生条件を明記しておきます。実際にどのようにバグが発生しているのか、バグが発生しているデバイスや、ブラウザ、OSのバージョン、実際の挙動と期待挙動など、詳細に記しておきましょう。
また、バグが起こっているときのMovieもチケットに貼り付けておくべきです。
Issueのフォーマット
ではいよいよIssueのフォーマットを紹介します。ここではエンハンスメント、バグ修正チケットのフォーマットを英語版で記載します。
エンハンスメント
## Overview
- Write about overview this ticket
## Relationg ticket
- Write the link which related with other ticket no
## Done of condiftions
- [ ] Conditions 1
- [ ] Conditions 2
## Refer
- Share the sharing documents for developer like screen specification and figma url
## Note
- Other sharing comment to developerバグ修正
## Overview
- Write about bug overview
## Relationg ticket
- Write the link which related with other ticket no
## Issue screen or function name
- Write the screen name or url or function name which happens issue
## The conditions of this issue
- Os version
- Device version
- Browser version
## How to reproduce steps
1. Step1
2. Step2
## Expected Result
- Expected result by these steps
## Actual Result
- Actual result by these steps
## Refer
- Share the sharing documents for developer like screen specification and figma url
## Note
- Other sharing comment to developer
- Put the screen shot or movie in this areaラベルについて
Issueの可読性やフィルタリングを可能とするために、ラベルを有効活用することも重要です。ここでは、実際にどのようなラベルが利用されているかを紹介します。
- エンハンスメント：エンジニア開発向けのチケット
- バグ：不具合チケット
- 議論：仕様やアーキテクチャ検討の議論
- 要望：ビジネスサイドからの要望
- 初心者向け開発：初心者エンジニア向け開発
このラベルを活用することで、作業効率の上昇も期待できます。
また、過去のチケットのトレーサビリティを向上させるために、決定事項や議論状況については可能な限りコメント欄で実施することが望ましいということも併せて伝えておきます。
まとめ
本記事を参考に、チケットを有効活用して作業効率UPを目指してみてください。
