はじめに
with で Android エンジニアをしている 石田 です。with の Android チーム(以下 with-android)では GitHub の Issue の管理について約半年間見直してきました。というのも従来の Issue 管理には課題がある状況でした。それは例えば以下のようなものです。
- Issue の数がなんとなく多い気がする
- 数年前に作成された Issue が未だに存在している
- 作業の手が空いた時にどの Issue の対応を行うべきなのかパっと分からない
- Issue 対応へのモチベーションが湧かない
これらの課題に対応するため少しずつ Issue 管理を改善し、最近になってそこそこ洗練されてきたなと思えるようになりました。本記事では半年間で培った Issue 管理術を紹介します。
Issue のライフサイクル
Issue 管理の見直しによって最も大きな変化があった Issue のライフサイクル について説明します。
従来の Issue のライフサイクル
従来の with-android での Issue のライフサイクルは下図のようなものでした。
驚くほどシンプルですが、Issue が作成されたら朝会でカテゴリ分け(重要度と緊急度)を決定します。これで終わりです。「重要かつ緊急」にカテゴライズされたものは確実に実装がなされていましたが、それ以外にカテゴライズされたものは実装されることなく 放置される可能性が非常に高い状態 でした。
現在の Issue のライフサイクル
現在の Issue のライフサイクルは下図のようになっています。ライフサイクルを 3つの期 に分けて説明します。
誕生期
Issue が作成されたら朝会の中でメンバーで議論し、その内容が有用であると判断された場合は、アサインとマイルストーンを決定します。当たり前のようですがこれがすごく重要で、「だれ」が「いつ」やるかを明確にする ことで Issue の放置を防いでいます。一方、有用でないと判断された場合は、「低優先度」ラベルを付与します。アサインとマイルストーンは設定しません。
再生期
誕生期で「低優先度」ラベルが付与された Issue はどうなるかというと、期初のタイミングで 年2回 行っている棚卸し会で再度議論されます。やっぱりこの Issue は有用であると判断された場合は、アサインとマイルストーンを決定します。
一方、再び有用でないと判断された場合は思い切ってクローズします。また、Issue としての内容はよくても対応したいエンジニアがいなければ結局放置されるという結果が目に見えるので、そのような場合もクローズします。それでも判断に迷う場合はそっとしておきます。
お別れ期
誕生期でも再生期でも処理されず、放置され続けた Issue についに寿命が訪れます。365日以上 アクティビティのない Issue をクローズするように設定した Stale が自動的に Issue をクローズします。これにより数年に渡って Issue が放置されるという可能性はなくなります。
Cycle の導入
Cycle の導入 も Issue 管理が上手くいった理由の一つです。
Issue のライフサイクルの説明の中で、対応することが決まった Issue にはマイルストーンを設定すると述べましたが、with-android ではマイルストーンをアプリのバージョンと関連付けています。そのため どのバージョンで入るか明確に決められない Issue はどうするのかという問題が発生します。
そのような場合にはマイルストーンの代わりに GitHub Projects(Beta) の Iteration を設定することで「いつやるか」の計画を立てています。with-android では Iteration を Cycle と呼び、1か月を単位として運用しています。月初にはその月の Cycle で取り組む Issue をリストアップし、メンバー間で合意を取ることで計画性を担保しています。
Iteration についてはこちらのドキュメントを参照してください。
ラベルの細分化
従来のラベルは以下のものを使用していました。
リファクタリングタスクバグ修正
現在はこれらのラベルを細分化し、以下のものを使用しています。
リファクタリング: Compose化リファクタリング: モジュール分割リファクタリング: モダナイズリファクタリング: 負債返却タスクタスク: 定期バグ修正バグ修正: クラッシュ
このようにラベルを細分化した理由は、単純にもう少しラベルに具体性を持たせたかったというのもありますが、それ以上にメンバーがどんな Issue の対応に多く貢献したかをひと目でわかるようにするためです。リファクタリングのような地味とも言える作業は評価に繋がりにくいということがしばしばありますが、このようにしておけば定量的な評価材料になるので、Issue 対応のモチベーション向上になるのではないかと考えています。
まとめ
本記事で紹介した Issue 管理を行うことで、with-android では Issue が放置される隙が全くなくなりました。よくわからないけど未対応の Issue がたくさんあるな...という状態を脱却し、Issue を完全にコントロールしている状態に変わりました。 例え Issue の数が同じでもそれらがコントロールされているのか、それともされていないのかでは大きな違いです。
Issue 管理について課題感を感じているチームはぜひ本記事を参考にしてみてください :)