こんちは。
最近はフロントエンドより開発プロセスの改善が好きなとよしーです。
年末ですね。
年末だというのに自分は風邪を引いたり、縁石につまづいて頭から血を出したりしてさんざんな日々です。
さて、そんな満身創痍な自分はここ数週間、チケット管理について改善活動を試みてきたので、
今回はそのTipsを紹介しようと思います。
もしかしたらシリーズ化するので「その壱」と題しています。
課題
まず自チームの以前のチケット管理の課題についてこのようなものがありました。
- 開発着手時に、担当の開発者が「チケットのゴールはどうすべきか」と関係者に逐一確認することでリードタイムが発生していた
すなわち、チケットのゴールが見えづらい状況でした。
例えば、不具合内容は書いてあるが、この不具合が治った期待値が記載されていないといったことが散見されていました。
やったこと
そのような課題を解決するために、下記を試みました。
- チケットテンプレートに完了条件を追記
- 既存のチケット(80件くらいある...)の完了条件を定めるため、各関係者にインタビューの旅に出た
【1.チケットテンプレートに完了条件を追記】
チケットテンプレートに完了条件を記載しておくことで、これ以上完了条件が見えないチケットが起票されるのを防ぐために行いました。
「どこまでやればこのチケットはOKなのか」というゴールを定めて、成果物の透明性を見えるようにしました。
ちなみに自チームではスクラムを採用していないですが、アイデアとしてはスクラムの「Doneの定義」あたりを参考にしています。
【2.既存のチケットの完了条件を定めるため、各関係者にインタビューの旅に出た】
いままで既存のチケットに関して管理をしていなかったわけではないです。
定期的にチケットの棚卸しはしていたのですが、「やる/やらない」の判断で留まっていた感じでした。
なので、いかにチケットを着手できる状態にするか...という考えのもと、各関係者に
「このチケットの目指すゴールってなんですか」
と問いかけるためアマゾンの奥地へと向かったのだった...。（うそです）
そもそもなぜやるのか？
- 余計なリードタイムをなくすことで、ユーザーに早く価値を届けるため
です。
結果
-
新たに起票されるチケットは、完了条件が書かれるようになりました。
-
既存チケットに関して各関係者にインタビューしてみると
「これもう治っているな」
「これもうクローズしちゃっていいやつですね」
といった声もいただき、少々チケットの母数を減らすこともできました。 -
嬉しかったこととして、チケット起票以前の不具合発見フェーズで「こうなっていてほしい」と期待値を書いてくださる人もちらほら出てきました。
「こうなっていてほしい」を不具合発見フェーズで書くことで、ユーザーの価値はほんとにこの期待値なのか？という対話が生まれる可能性があります。
こういう文化がどんどん浸透していくといいなと思っています。 -
めっちゃ体感で恐縮ですが、チケット着手時の手戻り率が減った気がします。
すなわち着手から実装完了までのリードタイムが短くなった気がする。
これを計測してなかったのは反省。
まとめ
以上、チケット管理の改善Tips その壱でした。
今回は完了条件を書くことについて取り上げました。
「当たり前だよそんなの」と思う方もいるかもしれませんが、いかなる状況でも当たり前のことを当たり前にやることが意外とむずかったりするのです。
自分は、それをいかに仕組み化するかが大事だと思っています。
加えて、自分は対症療法的な改善のアプローチも大事だとは思いますが、
予防医療的な改善のアプローチも大事だと思います。
要は、未然に無駄やバグを防ぐアプローチです。
システムも予防医療的な視点で未然にバグや無駄を防ぐアプローチを今後も考えていきたいですね。
それではまた。