こんにちは、システム開発部の田中です。
ユニファでは、システム開発部だけでなく、全社的にJIRAというAtlassian社製のBTS(Bug Tracking System)を使っています。 その中で、私が日ごろ意識しているチケットの作り方について、まとめてみます。
作成編
チケットを作ることをためらわない
本当に瑣末なものでない限り、何か調査をするときは、チケットを作るようにしています。 あとで自身で振り返るときにも有用です。
タイトル編
多少長くなっても、タイトルを見ただけで把握できるようにする
これは私の経験ですが、タイトルは、短く超簡素よりも、多少長くても具体的な方が良いと思います。
一覧画面でチケットが文字に埋没してしまいそうですが、 日本語の単語は割と目でgrepしやすいので、ざっと流し見ているときに引っかかる要素が多い方が有利であるように感じます。
また、日ごろお世話になっているRubyの「名前重要」もあって、変なタイトルはつけないようにしています。
何をするのかを明確にする
タイトルを見ただけで、「何をするチケットなのか」を明確にしています。
タイトルを見たひとから、 「だから何?」 と言われないように心がけています。
「ほげほげが起きた」のような現状を書いただけのタイトルでは、「それは修正するの? 仕様確認なの?」と思われてしまいます。
エラーログを貼り付けるだけにしない
エラーが起こった時のチケット作成では、Howよりも、WhenとWhatを盛り込むようにしています。
どんなエラーが起こったかの詳細は、「説明」の広い枠の方に放り込めば見やすいので、 タイトルには、「いつ」「何が」起こったかを残しておくと、あとで拾い上げやすいです。
検索を意識する
「この単語を入れておけば、あとで検索でひっかかりやすそうだな」のように、あとで検索したときのことを意識してタイトルに盛り込んでおくと、将来誰かの役に立つ可能性が上がります。
説明編
「説明」を書く
「説明」は空白にせず、書きます。
(タイトルで言いたいことが全て言いきれている場合を除く)
背景とゴールを書く
なぜこのチケットが作られたのか、という背景説明を書きます。
あとで自分が見た時、あるいは他のメンバが見た時に、スムーズにチケットの内容を把握してもらえます。
特に、コンテクストなしで内容を把握するためには、書いてあることが理解の全てになってしまうため、妥協すべきではない、と感じています。
ひょっとしたら、やろうとしていたこととは別のアプローチをアドバイスしてもらえるかもしれません。
私は、よく箇条書きで、
背景
- Aが起きた
- AにはBが必要になった
- BにはCが必要になった
- Cをやる
ゴール
- Cをリリース
という書き方をしています。
画像を使う
百聞は一見にしかず、ということで、スクリーンショットや手書きした図の写真などを説明欄に挿入しています。
画像は文字情報よりも情報量が多い分、とても有用だと感じています。
チャットを貼り付けるときに、スクリーンショットにしない
チャット内容が、そのままチケットにとって役に立つときがありますが、その際も、スクリーンショットを撮ってペタリではなく、コピペで貼り付けるようにしています。
理由は、JIRAに文字を認識させて、あとで検索できるようにするためです。
まとめ
今回まとめてみて改めて、以下の要素が大事なのではないかと思いました。
- 理解しやすいこと
- 記録に残っていること
- あとで検索しやすいこと
以上です。