最近電気シェーバーを買い替えたらひげそり体験がとても良くなりました、デジタルトランスフォーメーション事業本部DX共通開発部開発基盤グループのリーダーの西田和史です。
今日は、この4年間ずっと抱えていたチケットハンドリングの問題をどう解決したかの話を書こうと思います。
2019年: Issue 50個
4年前、自分がSpeeeに入社した当時はあまり真っ当にIssue管理がされていませんでした。
チーム内で統一されたカンバンなどはなく、Issueの品質もバラバラで、昨日書かれたものもあれば3年前にかかれて実はもう意味がないIssueがあったり、descriptionがないチケットも相当数ありました。
僕の入社後は、しばらく1人チームでしたのでその期間もチケットの棚卸しや整理などは行っていませんでした。
2020 ~ 2021年: Issue 200個
この時期、開発基盤に所属するSREは2~3名程度になり、イテレーションの中でカンバンを使うことを意識するようになりました。
また、過去に一度話に出た問題をまた現状把握・調査から始めるようなことが何度か起こっていたため、些細なことでも極力Issueに書き出して、今すぐ解決できないまでも将来スムーズに解決できるようにしました。
その結果、Issueの数は200個ぐらいまで増えるのですが、これがむしろ次の問題の原因になり始めていました。
2022年: Issue 300個
この頃にはIssueが300を超えかけていましたが、Issueの数に起因して次のような問題が発生していました。
- 数が多すぎてIssueを把握しきれない問題
Issueが多すぎてバックログの整理コストが非常に高いため、メンバーの誰もIssue全体を把握していませんでした。結果、すでにIssueが存在するにも関わらず重複するIssueが切られたり、非常に近しいIssueがあるにも関わらず相互に紐づけされないことが多発しました - 認知負荷の増大
眼の前にかかえている問題の数が多すぎて、開発基盤が取り組むべき問題の全体を把握することが非常に困難でした。全体を捉えようとするとIssueの数が多すぎて目の前の問題解決にフォーカスするパワーを失い、逆に目の前の問題解決にフォーカスすると全体を把握することができず優先順位順の高いものを判断できませんでした - チームのやる気を削ぐ問題
Issueの数が多すぎて一向に問題が減っている感じがしないこと、自分が把握できていないIssueが膨大にあると感じることなどから、無力感・徒労感を感じやすく、チームの自己肯定感が高まらない一因になっていました
転機
2021年頃から薄々この問題に気づいてはいたのですが、よい解決策が浮かばず今までのやり方を続けていました。
転機となったのは2つの事象からです。
1つはチームの認知負荷の問題について解決策を調べているときに次の記事を見たことでした:
この記事全体も参考になるのですが、特にホワイトボードに貼られた50枚以上の付箋チケットとともに書かれていた次の一文が非常に刺さりました。
これは1チームが抱えられる問題の量を超えているし，自分はこの後の議論をちゃんと進めることもできませんでした．
これはまさに当時の開発基盤グループの状況を言い表していました。2~3名体制のチームで300以上のチケットはチームが抱えられるキャパシティを超えていたんですね。
もう1つは、kubernetesなどのOSSリポジトリで自動的にIssueを閉じるbotをよく見かけるようになったことです。
私が初めてこのようなボットを見たときの印象としてはちょっと乱暴すぎるように思えました。せっかくIssueの形で提供された情報に対してX日間アップデートがないからと自動でCloseしてしまうのはどうか感じたためです。
しかし、切られるIssueチケットの数に対してOSS開発での開発リソースは遥かに少なく現実的にはすべてのIssueへきめ細やかな対応をすることは不可能です。Issue作成者に開発者から質問が投げかけられても返事が書かれないことも多くあります。
何より、こういったボットを動かしているOSSはそうでないOSSと比べて遥かによくIssue管理ができているように見えました。歴史が長く巨大で広く使われているOSSのリポジトリを見ると、物によっては1万に迫るIssueの数があったりするのですが、こういった自動Closeボットが入っているリポジトリはそれらよりIssueが1/10以下になり、かつOpen状態のIssueもきちんと議論や調査が進んでいる、Issueチケットの治安の良い状態が作れています。
上記の2つが決め手となり、開発基盤でも次のGitHub Actionsを導入することにしました。
actions/stale: Marks issues and pull requests that have not had recent interaction
2023年: staleアクション導入
前述のstaleアクションを使用して、90日間更新がないIssueチケットはcloseするように設定しました。 これにより徐々に非活性なIssueは減っていったのですが、その過程でいくつかの発見がありました。
bot(GitHub Actions)に任せることで罪悪感を回避できる
Issueが300個まで増えたことの一因として、他チームから報告してもらった問題を一方的にcloseすることの罪悪感がありました。解決していない問題から目を背けるようで、誠実さにかけるように感じたためです。
ただ、前述の通りIssueの増加で問題が発生しているためIssueの数を減らす必要があります。
このclose作業に人間の恣意や操作が入るとどうにも進めづらいのですが、 staleアクションは単純に進捗がないIssueを機械的にcloseしてくれるため、Issueを整理したい側としてとても助かるツールでした。
IssueをCloseしてもあとで掘り返せないわけではない
頑なにCloseしなかった理由として、テーブル上に出ている(Open)状態でないとあとでまたその問題について着手しようと思ったり、情報を追記しようとしたときに見つからないのではないか、見つけるのが難しいのではないか？と思っていたことがありました。
ただ、実際にはそんなことはなく、実行せずCloseしたチケットについても頭の隅にとどめておくことで「それやらずにCloseした問題と同じだね」などと紐づけ、場合によってはReopenすることができました。
Closeに対する考え方のアップデート(Reframing)が起きた
以前は
- Open状態のIssue: チームが解決するべき課題を可能な限り多くもれなく含んでおくべき
- Close状態のIssue: すでに解決した課題
という風に考えていました。
そのこともあり、解決せずにIssueをCloseするという行為に後ろめたさがあったわけですが、自動Closeボットを運用しつつチームが認知できるIssueの数には限界がある、といううことを認めることで、
- Open状態のIssue: チームが直近取り組んでいる/取り組むであろう問題
- Close状態のIssue: すでに解決した課題。もしくは当分着手しない課題
という風にアップデートすることができました。
2023年10月: Issue 45個
staleアクションを稼働させつつバックログ上のIssueが減ってくると1人の人間でも全体が見渡せるようになり、その結果重複や関係するIssueの存在に気づくようになりました。
それらを人間の手でさらに整理した結果、今では45個までIssueが減っています。
これにより最も改善されたのがチームの自己肯定感で、自分たちが取り組むべき問題の全体像について認知できていることは日々の実行や計画の中で自信になりました。
また、チームの舵取りを任されている身としても、直近僕たちが取り組んでいる課題はなんなのかが整理され、その事により中長期以上の数年単位でのやるべきこと・計画についても考える余力が出てきました。
まとめ
というわけで、今日は開発基盤のIssue管理のことを書きました。
このstaleアクションは本当に導入してよかったと思っていて、Issueのハンドリング・管理能力がチームに戻ってきた感じがします。
おそらく、同様にチケットが氾濫して管理しきれていないと感じているチームはたくさん存在すると思いますので、一つの事例として参考になれば幸いです。
おやくそく
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
こちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
