チケット管理のコツ
仕事柄いろんなチームのチケット管理を見るのだが、往々にして残念な感じである。そうならないためのコツを簡単にまとめたので、より良いチケット管理を目指してほしい。
チケットは遠慮なく捨てろ！
一番多く見られる事象はチケットの数が多すぎるという問題です。小規模チームなのに数万件程度のチケットが溜まっていることなんてザラです。
とはいえ、溜まっているチケットが見られることなんて未来永劫ありません。遠慮なく捨てましょう。
どれくらいの数まで減らすべきか？
理想は、チーム全員がチケット全てを記憶できる程度まで減らすべきです。それぞれのチケットの重さにもよりますが、だいたい50〜100件までと考えると良いです。それ以上の数になると誰も内容を把握できなくなるため、そもそもとしてチケットの管理ができなくなります。
減らす時の基準はどうすべきか？
多くのチームにおいて、この基準がないことが一番の問題です。この話はいつかまた別の機会で書きたいと思います。
一般的には下記の基準で判断します。
重複しているものはひとつにまとめる
既に実現済みのものは当然に捨てる
別の手段で実現済みのものも当然に捨てる
実現予定日が未来すぎるものは捨てる
特定の期間内に実現すべき目標に関連しないものは基本的に捨てる
チケットを増やさないためにはどうすべきか？
チケットの数が増えてしまう原因は大きく下記の二つです
チケットを定期的に棚卸ししていない
勿体無い症候群
定期的な棚卸し（あなたがPMであれば最低でも週に一度）はスケジュールに入れてしまいましょう。また、日々チケットを確認する際に合わせて捨ててしまうのも良いと思います。
また、チケットを捨てることに勿体無さを感じる人はたくさんいますが、本当に大事なことは何回も出てくるので特に気にしなくて大丈夫です。捨てた後も何回も出てくるものは、多分本当に大切なことです。
終わったチケットは消すな！
完了したチケットを消してしまうケースが見受けられますが、これは絶対にダメです。少なくともアーカイブにしましょう。
過去のチケットを見ることのみで得られる情報がある
対応したチケットを眺めることで達成感が得られる
というのが主な理由です。ですので、アーカイブもあまりオススメしていません。「完了」リストなどに移しておくだけの運用が望ましいです。
また、現在進行形のチケットを置いておく場所と、完了済みのチケットを置いておく場所（私は墓場と呼んでいる）を分ける運用もオススメです。Trelloなどの場合はチケットの数が物理的に増えるととても重たくなってしまうので、一定の区切りごとに墓場に移動していくと良いです。
チケットを作る人はPMだけにしろ！
PM以外の人もチケットを作ることがあるチームが多いと思います。とはいえ、これはあまりオススメしません。
PMがチケットの全容を把握できなくなる
誰が読んでも理解できるチケットを書くことができる人は少ない
というのが主な理由です。どちらかというと後者に問題があります。何が書かれているのかよくわからないチケットが沢山生まれてしまい、それが管理を圧迫するというケースがよくあるのです。
そのため、チケットを作成できる人はPMだけにするのが望ましいです。
PM以外のメンバーがチケットを作りたい場合はどうするか？
そもそも、このシチュエーションが発生してしまうこと自体がマネジメントの失敗ともいえます。とはいえ、顧客要望をチケット化したいケース（これは詳細を後述します）や、エンジニアメンバーがバグなどの緊急対応を行う場合など、一定やむを得ないケースも存在します。
やむを得ないケースの場合は、「PM以外が追加したチケット」のようなリストやラベルを作っておき、後からわかる形にしておくのが望ましいです。そうすることで、チケットの不備を早めに修正できますし、チケットの全容把握も楽になります。
顧客要望をチケットにするな！
顧客要望をチケットにするケースは散見されますが、これは下記の理由から本当にオススメしません。
実際に対応するかわからない段階でチケットが作成されてしまい、ゴミになる
チケット化されたことで、対応してくれると勘違いするメンバーが出てくる
要望と実際のタスクはそもそも異なる
また、顧客要望を営業メンバーなどがチケット化するルールのチームもありますが、これは本当にやめた方が良いです。上述のようにPMだけがチケットを作る方が良いですし、慣れていないメンバーにチケットを作らせるのは本当に時間の無駄です。
顧客要望は可能な限り簡単に誰でも書ける場所を作り（チャットのチャンネル等が望ましい）、特にフォーマット等も決めず、適当に書き込んでもらう形が良いです。不明点などがあればPMが適宜確認すべきです。記載内容の質の担保はPMが行うべきです。
PM以外はチケットを移動させるな！
チケットをカンバン形式で管理する場合、PM以外のメンバーもチケットの移動を行うことがあるかと思いますが、これもオススメしません。
PMが状況を把握し辛くなるというのが主な理由です。そのチケットの対応が終わった時点で、「対応完了」とでも書き込む運用が結果的に楽です。
レスポンスが遅いチケット管理ツールは使うな！
レスポンスの遅いチケット管理ツールをやむなく使っているケースが見られます。しかし、これはオススメできません。
チケット管理は日々の活動であり、それなりに多くの数を毎日確認し、コメントし、ステータスを更新します。としたときに、レスポンスが遅いというだけでその作業の生産性を大きく下げてしまいます。
迷った場合はTrelloを使うと良いです。レスポンスの速さは正義です。
チケットには仕様を書くな！
チケットに仕様を書く運用をしているチームもありますが、これはオススメしません。仕様はストックされるべき情報ですが、チケットはあくまでもフロー情報です。つまり、極論ではありますが、チケットが全て消え去ってしまったとしても仕様はどこかで確認できるようにすべきです。
もちろん、仕様の議論等をチケットで行うことは全く問題ありません。ですが、ストックされるべき情報をチケットのみに記載するということは避けなければなりません。
チケットにはWhyとWhatを絶対に書け！
無が書かれているチケットをよく見ますが、これは本当にダメです。チケットはフロー情報とはいえど、少なくともチケットの生存期間において、そのチケットがなぜ存在し、何を期待されているかがわかる必要があります。
としたときに、少なくともWhyとWhatが書かれていることが望ましいです。
[なぜやるか]
ユーザー数を計測する仕組みがないため、KPIをリアルタイムでウォッチすることができない。
[なにをやるか]
ユーザー数を計測する仕組みを作る。その際、可能な限りリアルタイムで数値を取得できる仕組みとする。
また、Howについてはチームの方針次第ですが、無くても良いと考えています。誰がどう考えてもそのHowに辿り着く場合は記載しても良いと思いますが、いくつかのHowが考えられることが通常であり、それらはチケットを実現する人が考えるべきだからです。
おわりに
今回記載したのはとても基本的なことですが、これを行うだけでチケット管理がかなり楽になるはずです。ぜひトライしてみてください。
P.S. チケット管理等々のプロジェクトマネジメントの諸々を教えてほしい、、、みたいな企業さんがいればよしなにお仕事をください、、、！
個人で学びたい、、、みたいな人はまずはお友達になりましょう！
まいにちのご飯代として、よろしくお願いします。