賞味期限切れのissueを無慈悲に閉じよう

こんにちは！STORES ブランドアプリのバックエンドエンジニアをしているotariidaeです。春風の季節ですね。たまに風で舞い上がった砂塵が目に入ってつらいです。

issue管理の課題

さて、私が所属する開発チームではGitHub Projectsを用いてバックログを管理しています。バックログアイテムはissueとして作成される形となり、GitHubとネイティブに統合された円滑な開発体験が構築できてすごく便利です。

しかし、issueはともすると完了される速度よりも新しく起票される速度の方が大きくなります。そうすると管理コストが増大するという問題が生じます。内容を最新の状態に保ったり、優先順を判断して並び替えたりといったメンテナンスが難しくなります。n件のissueの並び順はn!通りですから、もし100件のissueがあれば並び順は10¹⁵⁷オーダーです。人間の認知能力をはるかに超越しています。

かつての私たちのチームでも数百件単位でissueが溜まっていました。その中には、例えば次のようなものが含まれていました。

1年前に起票されてそのままの機能開発のissue
4ヶ月前に起票され「いつかやろう」という思いだけが残っているリファクタリングのissue
いにしえの単語が入り混じり、今となっては有用性の判断もつかないissue

これらのいわば「賞味期限切れ」のissueが価値に変わる未来はきっと来ないでしょう。今までずっと着手されなかったissueは、これからもずっと着手されないだろうことは想像に難くありません。

ならば、閉じてしまいましょう。

GitHub Actionsによるissue整理の自動化

最終更新から2ヶ月半が経過したissueを自動的に閉じる仕組みを導入しました。具体的にはactions/staleアクションを次のような設定で運用しています。

2ヶ月更新のないissueに「Stale」ラベルを付与
14日後に「Stale」ラベルが付いたままのissueを自動的に閉じる

この「2ヶ月」という期間はチームで検討してざっくりと設定した値です。私たちの開発チームは2週間スプリントを採用しており、4スプリント（約2ヶ月）前のissueであれば、もはや賞味期限切れとみなせるだろうという想定です。

また、ラベル付与後の14日間は、重要度が高いissueを意図せず閉じてしまわないための猶予期間としています。この期間中にStaleラベルを手動で外すことで、クローズを回避できます。

   - uses: actions/stale@v9
      with:
        days-before-issue-stale: 60
        days-before-issue-close: 14
        operations-per-run: 3000 # デフォルトの30だと足りないので100倍

💡Tips: 大量のissueを抱えるリポジトリだと、operations-per-runはデフォルトの30だと足りないため、大きめの値を設定すると良いです。

結果

私たちのチームで実際に運用してみたところ、導入直後で224件のissueが閉じられました。

一斉に閉じられるissueがSlackに通知される様子と通知量に押し流されるnfujiuさん

これにより、オープンなissueの数は以前よりも大幅にスリムになり、現在は100件台に収まっています。それでも少し多い感じはありますが、数百件もあった時期と比較すると大きな差です。

issueが閉じられることによる悪影響は、いまのところ感じていません。4スプリント以上も前のissueは日々の活動において滅多に参照されることはありませんでした。もし、閉じられてしまったissueを再び直近で着手したいと思い直したときも、単にreopenすれば良いだけなので、さほど手間はかかりません。