Github Issues を利用したリリースマネージャのお仕事
最近、Quipper という会社で「リリースマネージャ」という名前のお仕事をしています。開発以外の仕事は久しぶりだったので大変でしたが、最終的にそれなり上手く行った方法を振り返りとしてブログに書いておくことにします。
経緯
自分のチームとは別のチームが開発しているサービスのリリースが迫っている中、それまで開発者の1人がリリース管理っぽいことをやっていたのですが、さすがに開発と管理の二足のわらじが辛くなってきたとのことで、急遽サポート的に自分が「リリースマネージャ」という役割りで参加することになりました。
コンセプト
コンセプトは「使用するツールを増やさない」です。 管理のために新しいツールを増やすと、その使い方を教えるなど新たなタスクが発生してしまいます。タスクを減らすためにタスクが増えるなんてナンセンスです。
ということでQuipper では普段の開発に Github を利用しているので、自然と Github Issues を利用することにしました。 （正確には既に Github Issues が使われていたので、それを整理する方向で調整しました）
Quipper の開発スタイルとか開発ワークフローについては、既に同僚の方は書いているので、そちらを参考にしてください。
ルーク、 MongoLab を使え！ - @kyanny's blog
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
Github Issues の使い方
ポイントはマイルストーンとラベルの使い方です。
マイルストーン
Issue は必ずマイルストーンに紐付けます。 マイルストーンに紐付けるという作業をすることで、Issue が放置されるのを防ぎます。 後でやるかもしれないがリリースには含めない、という Issue は「チェックはしたけど、意図的に先送りした」という印として、「nice to have」という名前のマイルストーンに紐付けておきます。
マイルストーンは絶対なので、原則リリース日はずらさず、消化しきれなかった Issue はマイルストーンを移動させます。
ラベル
ラベルは主に以下を利用します。
| from-customer | クライアントからの問い合わせをトリガーに作成された Issue。この時点ではバグかどうかはわからないが、取りこぼさないようにとりあえず Issue として作成する |
|---|---|
| bug | 社内で気が付いた Issue、もしくは from-customer の Issue がバグだった場合につける |
| critical | bugの中でも特に緊急性の高い Issue につける |
| confirm-spec | 仕様確認が必要な Issue につける |
| final-check | 修正が完了し、ビジネス側、クラアントに最終チェックして欲しい Issue につける |
実際はこれに加えてプロジェクト固有のラベル（例えば新機能開発なら、機能名とか）と併用して運用しました。
リリースマネージャのお仕事
ここまで準備が整えば、リリースマネージャのお仕事は次の手順を繰り返すだけの簡単なお仕事です。
やること
朝来て、帰るまでに以下の順番で作業をします。順序は日によって多少前後してもOKです。
- 朝会での進捗確認と問題点やリリーススケジュールの共有する
- マイルストーンに紐付けられていない Issue をマイルストーンに紐付ける
- 直近のマイルストーンを眺めて、担当者のいない Issue に担当者をアサインする
- critical ラベルの付いた Issue の進行状況を開発者に確認。必要に応じてタスクの前後関係をリソース調整する
- from-customer ラベルの付いた Issue の整理。とりあえず手元で再現するかどうかを確かめ、再現する場合は開発者に、しない場合はクライアントに確認する
- confirm-spec ラベルの付いた Issue の仕様をビジネス側の人と調整し、クライアントと開発者を含めて仕様を決定する
- final-check ラベルの付いた Issue の確認状況をビジネス側、クライアント側の人に確認する
- ドサ回り（チーム内をグルグルまわって、個別 Issue の相談をしたり、状況に応じてラベルの付け直しをしたりする）
- マイルストーンの Issue の数とスケジュールを見て、終わりそうにない Issue はマイルストーンを移動し、クライアント調整が必要なものは調整する
- 夕会での進捗確認と問題点やリリーススケジュールの共有する
- Issue は順次、増えていく可能性があるので、1日の最後に、もう一度 「マイルストーンに紐付けられていない Issue をマイルストーンに紐付ける」をして帰ります
リリースマネージャがやってはいけないこと
リリースマネージャはリリース対象サービスの開発をやってはいけません。 これは完全な失敗談ですが、すぐ直せそうだから自分でやろうとした結果、以下の問題が発生しました。
- 開発環境のセットアップに時間を取られた
- 開発フレームワークの勉強に時間を取られた
- どうしても目の前の問題に目が行って、リリース全体を考えられなくなった
- 結果、リリース管理作業がうまく回らなくなった
人間は基本シングルコア、シングルタスクです。開発したい欲求はグッとこらえましょう。 特に開発者がリリースマネージャの場合に陥りやすいので注意。
まとめ
Github があって本当に良かったです。
