チケット駆動開発に対する自身の考え 後編

#ssmjp Advent Calendar 2020 7日目の記事です。

自分なりに6年間ほど「チケット駆動開発」してきて、 現在どのような考えを持つに至っているかについて書いていたら結構なボリュームになったので、 前後編に分割しました。前回に引き続き、分割したもう半分のお話を書きました。

チケット駆動開発がまわりはじめるまでの取り組み

https://speakerdeck.com/zinrai/okr-tidd-case

ゴールを意識する

チケットには終了条件を書くため、 何ができればゴールなのかということを嫌でも意識することになります。 またゴールに辿り着くためには何をしなければならないのかも意識することになります。 漫然と働いていた頃は、働いている日はどういう結果を出せばわからず不安だったり、 休日の終わりに、また苦しい日々がはじまるということで憂鬱でした。 実際にその憂鬱さが、腹痛などの体調不良として体に現れることもよくありました。

チケット駆開発によって作業前にこんな感じになるだろうかという規模感とゴールを見通し、 チケットを進めていくだけという状態を作れるようになってからは、 「ここにあることを粛々と進めていけばゴールに辿り着く」と思えるようになり、 不安や憂鬱さ、体に現れる不調は無くなっていきました。

チケットを起点に認識を合わせる

「ストレージ移行」では、担当者とゴールは何で、 そのために積み上げていかなければならないことは何なのかということを話し合い徹底的にチケット化していきました。 それらのチケットをチームメンバーに展開することで作業規模の認識を合わせることができました。

ISP にいたときに NOC から私の所属している部署に移動してきた人のオンボーディングを経験しました。 最初は、私の抱えている親チケットの業務の中から、難易度が低めなものを割り当て、 割り当てた親チケットのモチベーションとゴールを説明し、そのために積み上げていかなければならないことを説明し、 子チケットの作成を一緒にやっていきました。

メンティが作成するチケットによって、私の伝えたかったことがうまく伝わっているかを確認でき、 メンティからも「認識の齟齬がないか見える形でコミュニケーションできてやりやすかったです」と言われました。

チケット駆動開発が、ゴールやそのために積み上げていくことの 認識を他者と合わせていくために強力に機能するツールであるということを確信しています。

自分と向き合うトリガーを作る

ISP にいたときに、異常なまでにやる気が起きずに放置しているチケットがありました。 そろそろ手を付けなければならないので、何故やる気が起きないのかを冷静に考えてみることにしました。

チケットのゴールを確認し、具体的に何をやっていけばよいだろうかと自問自答してみて、 一つのチケットに複数の「やること」が紛れ込んでいることに気が付きました。 やる気が起きずに放置していたチケットを複数のチケットに分解してみるとあっという間に終わってしまいました。 この体験から、1つのチケットで、1つのことだけをやるとうのは、 作業を進める心理的な負荷も軽減してくれるのだなということを感じました。 自分の中で「やる気が起きない」と感じるチケットが出てきたときは、 何故そう思うのかとうことを自分自身に投げかけるようにしています。

チケットには時間を付けており、1チケットあたりの作業時間は、 最小で3分、最大でも2時間くらいに収まるような粒度にしています。 時間を付け、1チケットに掛ける最大時間の制限を設けることで、 自分が無意識にチケットのゴールでない部分に手を付けようとしていないかの思考を差し込むようにしています。

最近は、1チケットで1時間以上掛かっていると他のタスクが潜んでいるかもしれないことを疑ったり、 タスクの分割を検討したほうがよいかもしれないという信号が自分の中から出るようになっています。

自分がコントロールできること、そうでないことを分離する

誰と一緒に具体的にどのようなことをやっていかなければならないかを チケット駆動開発で見通すことができるようになりました。

自分がコントロールできること、誰かに進めてもらわなければならないことを チケット駆動開発で表現できるようになりました。

「ストレージ移行」の業務から、自分がコントロールするタスク、 外注の方々に行ってもらうタスク、チームメンバーに進めてもらうタスクというものを 全てチケットに分離しながら進めていったことは、その例の一つとなります。

権威 DNS サービスのシステムをリプレイスしたときにシステム連携している AIX の特定のソフトウェアのバージョンが低く、 リプレイスするサーバーとプロトコルが合わず、 現状の構成ではシステム連携ができない状況を上長に相談しました。

上長からは、「若者に社内でこれから消えゆく AIX のパッケージの作り方をキャッチアップしてもらうよりも、 私が、該当ソフトウェアのパッケージ作成を担当するので、そのチケットを作ってください」と言われ、 該当ソフトウェアのセットアップが上司のコントロールするタスクへと分離されました。

チケット駆動開発によって自分がコントロールできる(する)こと、 そうでないことを見える形で分離していけるということを学びました。

「課題の分離」、正しく理解していますか？職場や業務で適切に扱う方法

https://manager-life.net/oyakudachi/thought_mindset/post_5000/

常に状況は変化するし、それに合わせてチケット構成も変えてゆく

チケットを積んでみて、「これでをやりきれば終わる」と思って進めていたら、 進めているうちに「これも必要になることがわかった」「あれも必要なことがわかった」となり 全てのチケットがクローズしたときには、最初に作成したチケットの倍のチケットになっていたは頻繁に起きます。

この経験から、進めていくうちに不確実だったことが、徐々に確実なものになっていくということを学びました。 今は最初から、この通りにやれば終わるといったチケットが出来上がるとは思っていません。 その時点でイメージできていることをとりあえずチケットにしてみよう、 作業を進める中で見えてくることがあるので、そのタイミングで別チケットに分割したり、 新たに発生したチケットを追加していこうというような考えで、日々、チケット駆動開発しています。