TypeError:

なぜ「チケット駆動開発」を導入できそうと思ったのか

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

発表する時間は無かったので、「チケット駆動開発がまわりはじめるまでの取り組み」では、 『「チケット駆動開発」を小さくはじめていくことが出来そうだなと思った。』 というスライドを一枚出しただけで、さらっと流しました。

今日は、どのようなやり取りや背景があり、 「チケット駆動開発」を小さくはじめていけそうだと思ったのかについて書きました。

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

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

マネージャーとの 1on1

現職では、管理職と定期的に 1on1 することになっておりマネージャーと対面でお話する機会がありました。

1on1 にてマネージャーから「自分の業務を全てチケットにし、 自分が何をやっているのかをの動きを 他の人にも見えるようにしている働き方はとても良いと思っています」と言われました。 一人チケット駆動開発がマネージャーに届いたことを確認できました。

日次のチームミーティングにてカルチャーショックを受けたことを伝えると、 「チームメンバーが何をやっているのか追い掛けにくい状態のため、 メンバーの状況を自分の中にインプットしてするような 役割も兼ねてチームミーティングを実施しているが、 自分自身の負荷が高いなと感じている」と言われ、 負荷が高そうだなと思っていたことは、実際にそうであるということがわかりました。

進めていることを確認する手段がチームメンバーごとに違っていたり、 全く無い状況についてどう考えているのか聞いてみると、 「各々が使っている手段をそれぞれ追い掛けなければならずとても大変で、 全く情報が出てこないメンバーには個別に打ち合わせの機会を設定しなければならず、 とにかく時間をとられていて大変な状態になっている」と言われ、 チームメンバーをまとめる人の負荷が尋常ではなく高そうだということを感じました。

「自分に対して行っているチケットでの動きをチームに展開していけると良いなと思っています」 ともマネージャーから言われました。

マネージャーは現状に課題を持っているということが確認でき、 チケット駆動開発の導入を推進した場合、 マネージャーからの後押しがありそうで、 一人相撲にならなそうだなと思いました。

チームでの課題感

私の一人チケット駆動開発を見ていたチームメンバーの一人が、 「今まで何度もチームでのタスクを管理しようという試みはあったが、 例えば Trello を使うというような手段が先行してしまい目的を見失ったり、 Trello を使ったとしても運用ルールがなく、 主導していく立場の人もいないため、誰もやらなくなりゴミ箱化することを繰り返している」 と言われ、全員ではないかもしれませんが、 チームが自分達のタスクを管理していきたいという思いを持ってそうだということを感じました。

メンバー間で連携しなければならない部分にて 「誰が、何を、どこまでやっているのか」見えず、 都度集まって状況を確認しなければならないことが大変だと感じているメンバーもいました。

相性が良さそうと感じる人がいた

入社初日のチームミーティングにて、 いつまでに、何をして、どこまで出来ているのかが聞きとれない中、 今日は具体的に何をやって、どこまで出来ていて、 次の動きとしてどのようなことをしようと考えているという情報発信しているメンバーが一人だけいました。 他のメンバーの雰囲気に流されることなく、私も雰囲気を感じ取れるような情報発信をしていることに感動しました。

私の入社初日だけそうだったわけではなく、その人のチームミーティング時の情報発信はいつも同じような調子でした。 自分の進めていることを具体化できていて、 次に進めることもイメージできているということがチームミーティングから聞き取れ、 この人の動きは、そのままチケットにマッピングできそうだなと感じました。

前職で、新卒社員にチケット駆動開発の研修を行ったときに、 一人の新卒社員が、予備校時代に学んだ思考方法とチケット駆動開発がリンクしたらしく、 あっという間に「チケット駆動開発」を自分のもにしていく様子を目の当たりにしました。 「チケット駆動開発によって、自分の動きをより洗練させることができました。 ありがとうございます。プラベートでも Redmine 使うようになりました。」 と言われた経験があり、同じようなことが起きるのではないかという感覚を持ちました。

前向きそうな人がいた

チームでの私の役割は、 これからローンチするサービスの監視基盤を整備することでした。 監視システムを用意しただけでは監視は始まりません。 監視項目を定義し、監視システムに設定していく必要があります。 私だけで完結する内容ではありません。 監視の対象を担当しているメンバーに監視項目を洗い出してもらう必要があります。

試しに一人チケット駆動開発している Redmine に監視項目を洗い出してもらうチケットを作成し、 どのくらい前向きに動いてもらえるかを確認してみることにしました。 チームメンバーの6人に対してチケットを作ってみてチームミーティングで共有した結果、 マネージャー(手も動かしている)ともう一人からチケットに対しての反応がありました。 どちらもチケットから自分の意図を読み取ってくれ、 こういった意図で、こう進めると良い感じですかと聞いてくれました。 チケットで作業を進めていくことに前向きそうな人が2人はいるということを確認できました。

なんだかいけそうな気がした

マネージャー、 チケット駆動開発を前向きにとらえてくれるメンバーが一人、 チケット駆動開発と相性が良さそうなメンバーが一人の合計3人がいれば、 小さくチケット駆動開発をはじめられるのではないかと考えました。

全員ではないかもしれないが、タスクを管理していきたいとは思っていることは確認できたので、 タスクがどのようなものであるかのインプット、 Redmine の運用ルールを整備するところから はじめていけば、進めていけるのではないかと思いました。