チケットの書き方アンチパターン #アンチパターン

チケットを使わない開発現場はありません (と信じている) が、正しく活用できていない現場をよく見かけます。依頼内容が不明だったり、どこまで作業しているのか分からなかったり、山積みのゴミチケットのせいでどれを作業するべきか発見するのに時間がかかったり。

チケットをどのように使えば、チームの生産性が上がり、ナレッジ喪失のリスクも減らせるのでしょうか？

これまでの経験談を元に、アイディアをまとめておきます。

前提となるマインドセット

どんな書き方がベストかは、チームによって異なります。定期的なふりかえりで調整しましょう。

例えば、メンバーがすぐ隣にいるチームなら、チケットに不備があってもすぐ聞けます。逆にオフショア開発などでメンバーが離れており、オンデマンドでコミュニケーションが取れない場合は、最初からチケットを詳細に書くほうが早く仕事を進められるでしょう。

ふりかえりの際には、「あの書き方だとわかんないから、次からはこう書いて」と伝えればそれで十分でしょう。

ハイコンテクスト: 省略された言葉で多くの意味が伝えられる状態
- 例: 「foo.rb を直す」
ローコンテクスト: 直接的で論理的な説明を求められる状態
- あいまいさが無いように書く
- 例: 「foo.rb の10行目の引数に A クラスのインスタンスを渡すのは間違い。 B クラスに変更する」
ローコンテクストの方がナレッジ喪失のリスクが低いのでベター
- チーム変更などで、それまでの歴史を知らないメンバーが入った場合でも、当時の依頼内容や作業内容が分かる

チケットをローコンテクストで詳細に書くほうが、作業の間違いが減り、1年後のナレッジ喪失リスクが低くなります。一方で、読み書きのコストは高くなります。

どのくらいのバランスで書くべきか、ふりかえりで決めましょう。

チケットの件名だけ書いてあって、何をやるか内容が書いていないパターン。具体的になにをやればいいのかや、なぜそのチケットが発生したのかも分かりません。

件名: A メソッドを直す
本文: (空)

件名: A メソッドの条件分岐を直す
本文: A メソッドに NULL が渡された時は true を返すのが正しいのに、 if 分岐内で false を返してしまっているので、修正する。

説明文やコメントで、実際にどんな作業をしたのかを書かないと、ナレッジが属人化します。また、システムへどんな変更をしたかの歴史が失われ、後で「なんでこの部分変更されてるの？」といった混乱を招きます。

件名: 同じ記事を別のユーザーが同時に編集すると、先に編集した方の内容が失われる
コメント: 修正完了 → close

コメント: 排他処理を実装。記事を編集開始した時刻から保存する時刻の間に、別の更新が発生した場合、「ほかのユーザーが編集しました」とエラーを出して、上書きするか確認する画面を出すようにした。

そのチケットが未着手なのか、進行中なのか、レビュー待ちなのか、完了しているのかが分からないパターン。

この症状が出ている現場は、以下の問題を抱えている可能性があります。

しばらく作業する予定が無いチケットは、「待ち」ステータスにする
- 他チームのレビュー待ちなど、自チーム内で完結できない状態が長く続いているなら、一度 done にして「他チームのレビューが完了している」など別チケットにしてしまうのもアリ
朝会 (デイリースクラム) やスプリント計画で、確実に Done させるべきチケットを選ぶ
定期的なイベント (スプリントレビュー) で、チケットのステータスが正しいか確認する

ちなみにカンバンの考え方では、同時進行中の作業を減らし、一つ一つのタスクを素早く完了させる方が、生産効率が上がります。（参考: カンバンはどのように動作するか）

チームリーダーなど、一部のメンバーだけがチケットを更新しているパターン。

掃除人に管理コストが集中してしまうため、掃除人のリソースが圧迫されます。また、実際に作業したメンバー自身がチケットを書かないせいで、作業内容が正しく記録されません。