ログイン画面のバグを例に考えてみます。月曜日にテスターが「ログインのスピナーが回り続ける」と書きました。火曜日にはサポート担当が「パスワード画面の後でサインインできない」と書きました。水曜日には開発者が、トークン更新のタイムアウトに触れた3件目の報告を見つけました。
チケットは3件、担当者は3人、バグは1つです。それぞれのチケットが答えの一部を持っています。1件目には手順があり、2件目には待っているお客様がいて、3件目にはログがあります。全体像を誰も見られないまま、同じ問題を誰かが3回トリアージすることになります。
重複は不注意の表れではありません。違う人が同じことを違う言葉で表現すると起こるものです。幸い、起票前に短い検索をするだけで大半は防げます。残りも、いくつかの習慣で管理しやすくなります。
単純なキーワード検索では見逃す理由
「スピナー」で検索しても「サインインできない」は見つかりません。「ログイン」で検索しても「認証」は見つかりません。トラッカーは時間とともに大きくなります。探しているチケットは、すでにクローズされていたり、名前が変わっていたり、数百件の新しいチケットの下に埋もれていたりします。
そのため、検索には少しコツが要ります。数分でできる手順を紹介します。
起票する前の6つの手順
- 自分のタイトルではなく症状で検索する。 ユーザーが目にする言葉を使います。画面に出たメッセージ、画面の名前、失敗した操作などです。
- エラー文言で検索する。 例外名やステータスコードがあれば、それで検索します。開発者はこうした文字列をチケットに貼ることが多く、完全一致でヒットしやすくなります。
- 類義語を試す。 クラッシュ、フリーズ、ハング、スピナーは同じ不具合を指すことがあります。ログイン、サインイン、認証も同様です。
- 領域で絞り込む。 使っていた機能のコンポーネントやラベルで絞り込むと、読める量まで一覧が減ります。
- クローズ済みのチケットも含める。 直ったはずのバグが再発したならリグレッションです。古いチケットには経緯が残っていて、原因が書かれていることもあります。
- リンクをたどる。 探しているチケットは、すでに見つけたチケットからリンクを1つたどった先にあることがあります。
重複か、関連か、別物か
似たチケットが必ずしも重複とは限りません。違うものまで統合すると、バグが隠れてしまいます。
- 重複: 症状も原因も同じ。チケットは1つの問題を説明しています。
- 関連: 症状は同じで原因が違う、または領域は同じで症状が違う。別々のままにして、リンクでつなぎます。
- 別物: 用語が似ているだけ。そのままにします。
判断できないときは、関連としてリンクしておきます。リンクは数秒で済みます。統合は、あとでその領域の担当者が、より詳しい立場で判断できます。
一致するものが見つかったら
以前のチケットを見つけたことは終わりではなく、始まりです。その一致を役立つものにしましょう。
- 新しい情報を足す。 自分のビルド、手順、ログ、ほかのお客様にも影響しているという一言などです。チケットにとって、証拠は多いほど助かります。
- 「自分も」のチケットは作らない。 「自分も再現しました」と伝えるためだけに2件目を作ると、証拠がまた分散します。1件目にコメントしてください。
- 再オープンは慎重に。 一致したチケットがクローズ済みで、まだ再現できるなら、チームの運用に従います。再オープンするか、元のチケットへのリンク付きで新規に起票します。
- 迷ったら意見をもらう。 確信が持てないときは、自分のチケットを起票して候補を関連としてリンクします。判断はトリアージ担当者に任せます。
チームとして重複を減らす
個人の検索も役立ちますが、チームの習慣のほうがさらに効きます。トラッカーは共有の記憶であり、次の人が見つけやすい書き方をして初めて機能します。
- タイトルの書式を決める。 ある領域のチケットが似た形で並べば、まとまって表示され、重複が目立ちます。
- コンポーネント用のラベルを少数に絞る。 一貫して使えば、フィルターが期待どおりに働きます。
- 重複はリンクしてクローズする。 残すチケットを指し示しておけば、履歴を後から追えます。
- トリアージで新着をざっと見る。 昨日以降に届いたものを5分眺めるだけで、新しいうちに重複のペアを見つけられます。
簡単な具体例
PDFへのレポートのエクスポートでクラッシュしたとします。最初の検索「エクスポート クラッシュ」では何も見つかりません。そこで画面のメッセージ「ファイルを生成できませんでした」で検索すると、「大きなレポートでPDFボタンが反応しない」というチケットが現れます。言葉は違いますが症状は同じで、手順も一致しています。
新しいチケットは作りません。ビルドとログの1行をコメントに書き、同じエクスポート画面に触れているもう1件のチケットをリンクします。所要時間は2分、新しいチケットは増えず、次にそれを開く開発者には全体像が見えます。
BugItが役立つ場面
トラッカーを丁寧に検索するのは根気のいる作業で、急いでいるときほど飛ばされがちです。BugItはそれを代わりに行います。バグを説明すると、BugItは下書きをお見せする前に、トラッカーから似たチケットを検索します。検索は読み取りだけです。各候補に近さのスコアを付けて判断の助けにし、関連するチケットは下書きに載せるので、リンクはワンクリックです。手早く済ませるバグ報告では検索を省略します。
これは手がかりであり、結論ではありません。下書きは起票前にご自身で確認します。BugItは一般的な個人情報をできる範囲でマスクします。そして、FILE ITと入力するまで、トラッカーには何も書き込まれません。
詳しくは bugit.dev と taskivator.com/bugit をご覧ください。
まとめ
重複は、同じ問題を別の言葉で表すことから生まれます。症状とエラー文言で検索し、類義語を試し、クローズ済みも含めて、リンクをたどりましょう。一致するものが見つかったら、新しいチケットを作らず、そこに証拠を足します。2分の検索で、同じバグを何度も直し、トリアージし、説明する手間を省けます。