@koic です。
GitHub などでイシュー管理しているプロジェクトは多いと思います。プロジェクトで開いているイシューの数はいくつありますか？
私はいくつかのプロジェクトで 100 以上のイシューが開いているのを確認しています。Rust では 8,000 以上のイシューが開いているので全然大したことないかもしれませんが、いつまでも放置していても見通しが悪いままなので整理するのは悪くないアクションです。
これは人それぞれの好みもありますが、オープンソースのような自由時間で行っている活動で、地球の裏側から開かれた (良かれとオープンされた) イシューをクローズするのは精神力を使うので、Stale bot のようなものでクローズするのは「問題 vs 私たち」の構図にするひとつの選択です。一方で業務の方ではもう少しきめ細かくクローズできると良さそうという考えを持っていて、本稿ではそんなお仕事でのイシュークローズに対するパターンを取り上げます。
- 再発しないエラー
- 閉じずの作業ログ
- Pull Request で解決済み
- 動きがない
- すでに問題ではない
- 誰もボールを持っていない
- 小さなリファクタリング
- 大きなリファクタリング
- データのトリミング
- クローズには理由を添えて
再発しないエラー
まず運用で起きたエラーは何らかの形でイシュートラッキングされますが、偶発的に起きたエラーについてずっと問題が起きていなければクローズできるものかもしれません。 偶発的に起きたエラーでも起きたら致命的なものであれば、本質的な問題を追求する必要がありますが、何年も再発せず困難かつ起きても軽微なものであればクローズします。
またエラーのリスク度合いの判断が難しいような場合は、『システム運用アンチパターン』の『運用の可視化』で言及されているリスク優先度番号 (RPN = Risk Priority Number) のような判断軸を使ってみるのもよいでしょう。
閉じずの作業ログ
システムへの新しいミドルウェアの導入や、問題の解析、手運用手順など、作業で行ったことのログとしてイシューが使われていることがあります。既にログとしての役目を終えているようであれば、クローズに進めることができるでしょう。
作業手順自体が次にその作業を行う際に有用なものであれば、Wiki などでドキュメント化しておくことを検討しておくとなお良しです。
Pull Request で解決済み
Pull Request で解決済みであるにもかかわらず、イシューだけが残っているケースがあります。対応するイシューがある場合に Pull Request を開く場合は Fixes #42, Closes #42, Resolves #42 などといった closing keyword でリンク付けておくとマージと同時にイシューがクローズされて便利です。closing keyword について、詳しくは GitHub のドキュメントを参照してください。
動きがない
チーム開発で自分ではイシューの状態が判断できない場合は、イシューの起案者や問題を知っていそうなメンバーに ping をしましょう。例えば業務で3ヶ月以上イシューの動きがなければ、既に重要でない問題なのか、何かブロッカーがあるのか改めて聞いてみても、そんなに急かしている感じにはならないでしょう。
また、アクションとしての動きを強めたいような時は、担当と期限を作った具体的なアクションにするのも一法です。これは KPT で Try からアクションを出すときと同じ具体化です。内容によってチームのふりかえりに持っていって議論してみても良いでしょう。
すでに問題ではない
刻一刻と要件に応じて姿を変えるのが Web アプリケーション開発の特性のひとつです。過去の時点で問題だったことが、要件や実装の進んだ現在では問題となっていないことがあります。そういったイシューは見つけたらクローズしましょう。
誰もボールを持っていない
そのイシューについて担当している人がいないことを「ボールを持っていない」というメタファーで表現されることがあります。何ヶ月も放置されている重要でないイシューである場合、クローズされて困る人はいないでしょう。
小さなリファクタリング
Pull Request を作っているときが一番知識と熱量のあるタイミングです。小さなPull Request で「あとでリファクタリング」とされた状態で master / main ブランチにマージされた後に、数ヶ月経っても動きがないイシューはリファクタリングされる望みが薄いでしょう。リファクタリングでも受け入れ試験が不要そうな、小さなリファクタリングであればサッと隙間に実現してしまうのも手です。その時は closing keyword を添えておきましょう。
大きなリファクタリング
例えばクラスやテーブル構成を変えるような大掛かりなリファクタリングは、それなりの工数を使う上、リリースでの注意点が増えることもあるでしょう。イシューを閉じる技術をテーマにしている本稿ですが、こういった実現したいけれどいまがその時ではないものは、ラベル付けでフィルタリングできるようにして留めておくのはひとつのアプローチです。ラベルを見るだけでクローズ対象でないと分かるだけでもイシューの整理作業は効率化します。
データのトリミング
バリデーションの漏れなどで、実害がないものの余分なゴミがついたデータが存在する場合があります。これらを運用でトリムする作業がイシューとして残っているとき、未実施の場合は改めて議題に挙げると良いでしょう。一方で順次データが洗い替えされているケースであれば、洗い替えが終わっているような時期であれば用済みとしてクローズできます。
クローズには理由を添えて
すべてのイシュークローズに共通することとして「なぜクローズされたのか」をまわりや将来の自分が把握するため、クローズ理由をコメントに添えておくことを強くおすすめします。こういったひと手間の積み重ねで情報トラフィックの交通整理が向上してきます。
「イシューを閉じる技術」をぱっと浮かぶ範囲で紹介しました。この他にも閉じることができるイシューを見つけるタイミングはあると思いますので、続きはそれぞれの現場にて。本稿がそれぞれの現場のイシューを整理するきっかけになれば幸いです。
また永和システムマネジメント アジャイル事業部では、世の中に無限に存在するイシューを一緒に解決するメンバーを募集しています。
