お元気ですか。watura です。 最近、キーボードを自作しました。その上キーの配列を QWERTY 以外のものにするという暴挙をしたため、驚くほどゆっくりこの文章を書いています。

ところで、GitHub の「ラベル」って使っていますか？

Zaim では、フルカスタマイズしてラベルを活用しています。この記事では、ラベルの実務的な運用をまとめていきます。ちなみに今回は iOS リポジトリのラベルを例としましたが、他もほとんど同じラベルを使っています。

ネーミングの基本

まず、ラベルの一覧です。

具体的には以下のように、

0. 優先度 (高)
0. 優先度 (中)
0. 優先度 (低)

1. 不具合
1. 機能追加
1. 機能変更
1. デザイン
1. 相談
1. リファクタリング
1. その他

2. Asana
2. Crashlytics
2. 要望

99. Asana行き
99. タスケテ
99. 再現しない

WIP
マイルストーン厳守
レビュー待ち
次マイルストーン

見積 1
見積 2
見積 3
見積 5
見積 8
見積 13

ざっと 26 個あり、プレフィックスを付与して0 系、1 系、2 系、99 系、その他、見積と分類しています。

Zaim では Issue にラベルを使い、Pull Request（PR）にはほとんどラベルをつけない、という運用です。基本的にすての PR は Issue に紐付くので、PR にラベルを付与すると重複が発生してしまうためです。

WIP が付いておらず、かつ Reviewer に自分が指名されている場合、基本的には皆さっさとレビューしているため、基本的には細かいラベルは不要とも言えます。

以下から、それぞれのラベルの内容を説明していきます。

0 系

Issue の優先度です。優先度の尺度としては、以下のようになっています。

0. 優先度（高）
放置するといろいろやばい

0. 優先度（中） 
「0. 優先度（高）」よりは優先度が低い

ラベルなし
 「 0. 優先度（中）」より優先度が低い

0. 優先度（低）
近いうちにやらなくてもいいくらい優先度が低い

「ラベルなし」があるように、全 Issue に優先度ラベルを付与しているわけではありません。すべての Issue にラベルが複数ついていると、可読性が低くなるためです。ラベルがない状態も優先度の尺度に含め、それがニュートラルであるという運用にしています。

また、優先されるべき度合いを示すためのラベルなので、優先度（高）であっても、必ずしも次のリリースに含めるわけではありません。どうしても次のリリースに含めたい場合は「マイルストーン厳守」などを付与するというルールがあります。

1 系

Issue の種別です。

不具合
アプリの不具合・バグ

機能追加
機能をつけることが確定している

機能変更
機能を変更する

デザイン
デザイン上の問題や改善

相談
チーム内で発生した機能についてや相談したいこと

リファクタリング
リファクタリングに関わる内容

その他
上記のどれにも含まれない

どういう Issue なのかを一目でわかるようにするためにつけています。

2 系

Issue の出所を示しています。最近はあまり使われていないので、廃止するかもしれません。

Zaim では開発そのもの以外のタスクは、タスク管理ツールの Asana で管理しています。

このため、Asana から指摘があって Issue 化したということ、逆に開発側だけでは決定できないので Asana で相談したいというラベルがあります。それが 2 系の「2. Asana」と 99 系の「99. Asana 行き」です。

2. Asana
Asana でのタスクがきっかけで作ったもの

2. Crashlytics
Crashlytics でのエラー発生がきっかけで作ったもの

2. 要望
ユーザーからの要望がきっかけで作ったもの

99 系

99. Asana 行き
Asana にタスクを作って開発以外のメンバーに確認

99. タスケテ
＼(^o^)／まじもう無理＼(^o^)／

99. 再現しない
指摘があったものの事象を再現できない

タスケテは、再現するものの何らかの理由で修正できない・実装方法がわからない場合に使います。また、再現しないはユーザーからのお問い合わせがあったものの、再現方法がわからない際に付与しています。

その他

WIP
Work in Progress

マイルストーン厳守
マイルストーン内で確実にこなさないといけない

レビュー待ち
Review Request 発行済

次マイルストーン
今回のマイルストーンには絶対入れない

この四つのうち、レビュー待ち以外は例外的に PR にも付与することがあるラベルです。絶対にマージしたいから今すぐ見るんだ！という場合や、さくっとやれるから PR は作ったけれど今はマージしたくない時に使います。

見積

1 見積を 0.5 日稼働として運用しています。見積 13 というラベルもあるにはあるのですが、それは複雑すぎる Issue なので、後で細かく分割しましょうというメッセージとして使っています。

おわりに

Zaim では半年ほど前からすべてのリポジトリでほぼ共通のラベルで運用するようになったので、さまざまなプロジェクトを横断する Issue に対応する場合も、視認性が非常に高まり、素早く業務に当たれるようになりました。

まだまだ改善の余地はあるかと思うので「こうやって運用している」「こうやると便利だ」というような事例があれば、ぜひオフィスに遊びに来がてら、教えてください。