背景

自チームでもっているチケットは、改善要望/バグなど比較的軽微なものが多いです。
そのため、新入社員のオンボーディングのタスクとしてピックしたり、協力していただいているパートナーさんにアサインするケースが多い状況です。
その状況でどうなったかというと、
「手頃なタスクをください」
「手が空いたのでタスクがあればください」
という非同期的な依頼が頻発するようになりました。
そこで、それらの依頼に応えるように自チームのメンバーの1人がタスクの斡旋をしていたというわけです。

加えて、自チームのメンバーがタスクの斡旋をするとしても、
チケット一覧で着手可能かどうかの判別がつきづらかったため、斡旋に時間的なコストがかかっていたこともありました。
自チームのメンバーは本来進めていくべき開発作業も持っていたので、なかなか作業に集中しにくい環境になっていたと思います。

課題

タスクの斡旋の非同期的な依頼が自チームに来るため開発作業に集中できない
チケットが着手可能か判別がつきづらいためタスクを渡しにくい

やったこと

タスクの状態を示す【Ready】【Not Ready】を定義しました。

【Ready】は完了条件が設定されていて着手可能であること
【Not Ready】は完了条件が設定されていない / 仕様の確認が必要 / デザイナーの作業が必要 / CSの確認が必要... など準備が整っていない状態であること
を意味しています。

この【Ready】【Not Ready】のprefixをチケットのタイトルの冒頭につける運用にしました。

例：【Ready】〇〇のCSVをアップロードしようとするとエラーメッセージが出てアップロードできない

ちなみに既存のチケットに関しては、棚卸しのタイミングで【Ready】か【Not Ready】かをまとめて精査しました。
新規で起票されるチケットに関してもテンプレートに【Not Ready】を付与しておくことで、状態がわからないタスクを作らせない運用にしました。

結果

依頼人がチケット一覧をみて着手可能かまだ着手すべきでないかの状態が分かるようになりました
そのため、タスクが欲しい人が自主的にピックするようになったため、斡旋業をする時間がほぼなくなりました

まとめ

今回はチケットが着手可能かどうかを示す点について紹介しました。

その弐のTipsをまとめながら気づいたことなのですが、
組織の中にいる人たちが自律的に動くためには、対象のものを「どういう状態であるのか」と定義することは結構大事なことなのではないかと思いました。
飽くまで経験則ではありますが、逆のケースで考えてみると「これはいまどういう状態なのかわからない」ものって、なんとなく忌避したり、後回しになりやすい。
となると、「どういう状態であるのか」をマメに定義することは、透明性をあげることにつながるのではないか...。

今後、課題とぶち当たったときに「状態を示すことで改善されるか」はひとつの思考のツールとして持っておこうと思います。

それではまた。