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

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

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

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

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

どれくらいの詳細度にするかはチームのふりかえりで決める

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

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

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

一般的にはハイコンテクストよりローコンテクストの方がベター

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

詳細度とコストはトレードオフ

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

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

的確なキーワードを含めることで検索性が上がる

• 修正対象のコンポーネント名や、エラーメッセージ等をチケットに書くと、後で検索しやすくなる
• チケット管理システムによってはタグやラベルといった機能も活用できる

アンチパターン

チケットの説明文を書かない

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

NG な例

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

OK な例

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

改善ポイント

• 説明文は書きましょう
• 「何を」「いつ」「どのように」変更するかが書かれていると Good

作業した内容を書かない

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

NG な例

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

OK な例

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

改善ポイント:

• 作業内容はできるだけ残しましょう
• 「何を」「どのように」変更したかを確実に書きましょう

ステータスを更新しない

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

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

• タスクをひとつひとつ確実に Done する習慣がない
• 大量の「進行中」チケットが慢性的に登録されている

改善ポイント:

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

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

「チケット掃除人」だけが更新している

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

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

改善ポイント:

• 「作業完了したら、チケットをクローズする」という習慣をメンバーに植え付けましょう
  • 理想的なチームは、各メンバーが自律的にタスクを Done します