複数の github レポジトリの issue を一元管理できるいい感じのツールをいくつか試しながら検討した結果、ZenHub がダントツで良さげなので紹介します

会社の hp からしてイケてる感あります
Chrome extension を使って github レポジトリの 1 画面としてダッシュボードが追加されます
- これは普段 github を使っているエンジニアからすると、とても肌に合います
- 他の競合サービスと違って、github を拡張するという意味合いを強く意識したサービスのため、管理ツールとしてだけではなく、様々な拡張機能も魅力のひとつです
それに比べると、似たようなサービスである waffle.io は残念ながら使い続けたいと思えませんでした

インターフェース

比較: waffle.io

比較: pure github.com

このインターフェースの課題は 2 つあると思います
- 1 つ目はこれだけではステータス（= 進捗という意味でも、優先度という意味でも）が一目瞭然とはいえないこと
- 2 つ目は複数のレポジトリ（= 最近のサービスなら、service / service_infra, service_ios, service_android のようなレポジトリを複数抱えるチームは珍しくないように思います）があるとそれぞれを行ったり来たりしないといけないこと

導入実績

Facebook, MS, Sony などなど

日本でも最近聞かれるようになってきたように思います

ZenHub の機能

概要は、GitHub - ZenHubとは - Qiita によくまとまってます

特に、個人的に感動した点は

github issue に画像以外も添付できるようになる
- iOS, Android アプリのプロジェクトファイルや、Web サイトの HTML、excel ファイルなどを issue に紐づけて共有できるようになるので便利です
issue, PR にいいねができる
- 地味にこういう非同期コミュニケーションは現代的で良いと思います
キーボードショートカットなど chrome extension としてよく出来てる
- サービスとしての ZenHub を使わなくても、拡張ツールとして使い続けるのも良いと思います
- チームメンバーにこのことを指摘してもらってあらためてそう思います
github にインテグレートされた UI 上で、Kanban 方式のプロジェクト運用ができる
- この点が最も使えると思った部分なので詳細に書きます
- 以前、スクラム（or カンバン）導入検討時には、過去の経験からメリットよりもデメリット（今の状況においては、導入ハードルが高く運用コストも大きい）を主張したこともあったのですが、このツールはそのデメリットをかなり下げてくれると思います

ここから色々書きますが、ZenHub の良さは、個人的にはつまみ食いしてもそこそこ使えるところかなと思っていたりもするので、過去の苦い思い出からスクラム用語っぽいのに拒絶反応がある人はかいつまんで読んでもらえればと思います

実際、自分の所属するプロジェクトでもつまみ食いしている状態です
- 以下の文章は過去の自分の経験とも照らしあわせて、期待と予想を含めて書いてます

そもそも Kanban 方式とは

顧客へのデリバリーに必要なタスクの定義を行い、そのタスクをソフトウェア開発プロジェクトの関係者が理解するために、プロセスを視覚化する。そして、タスクの作業者は、作業をキューから引っ張って（プル）していく

スクラムと一緒に語られる機会も多い言葉ですが、別のものという認識です
以前お世話になっていたスクラムコーチによるプロジェクトでは、リリースまではスクラム、リリースして運用ではカンバンということでやっていました

この種のツールから見ていくと、github を拡張して管理するツールのすべてにおいて、だいたい次のようなキューを使っています

ICEBOX（とか TODO）
BACKLOG
IN PROGRESS
REVIEW
DONE
CLOSE

ZenHub Board の使い方

そもそも Kanban 方式を導入するメリットを説明する前に、使い方を書きます

ZenHub 社は HR も含め全社的に ZenHub をドッグフーディングしており、そのベストプラクティスが How the ZenHub team uses ZenHub Boards on GitHub にまとまってますので、これを意訳します

用語について

Pipeline は前述した キュー を横に連結したもので、プロジェクトのライフサイクルを示す
Milestone は github の機能のひとつ
- ここでは Sprint 期間中に達成した issue を保存する意味あいで使われる
- Sprint はスクラム用語で、ここでは特定の期間に割り当てられた Backlog にある issue がすべて DONE になるための期間を指しており、その期間はだいたい 2 週間が多いとききます
- 例えば、Sprint 期間を 2 週間とすると、5/11 に sprint planning meetings を開いて Backlog に issue を詰め込んで、5/25 の sprint planning meetings で Done にそれらの issue が入っているのを確認して、また Backlog に新しい issue を詰め込むというのを繰り返します
Sprint Goal はひとつの Sprint 期間中に達成する内容をまとめたもの
- 何を達成するとこの Sprint は完了といえるのかを事前に定義づけしておく契約書みたいなイメージです

Pipeline の全体像

New Issues

メンバーが自由に issue をつくったら、まずはこのパイプラインに放り込まれる
weekly triage meeting でこれらの issue をレビューして優先度をつける
- この meeting を通じてこのパイプラインは空にする

Icebox

優先度が低いバックログ issue をこのパイプラインに置く
重複 issue を作らないようにすることや心理的な負担を下げて、優先度の高い issue に集中するために置く
将来的に優先度を上げる判断が出来る程度の情報が issue にあればいい

Backlog

優先度が高いバックログ issue を置く
意訳すると、sprint planning meetings でそのスプリント期間中に終わらせる issue をこのパイプラインに置く
- このパイプラインは次の sprint planning meetings までに空になっていることが望ましい
- 補足：ここの空にするのは意味は、そのスプリントに紐付いた Backlog を空にするという意味で、全体での Backlog ではない（と思います、全体で空にできるにこしたことはないとは思います）

In-Progress

進行中の issue をこのパイプラインに置く
ここにある issue には必ずアサインされた担当者（この issue を完了にする責任を負う）が設定されていないといけない

Review/QA

他のメンバーによるレビューやテスト（ステージングテスト）期間にある issue をこのパイプラインに置く
開発はすでに完了している
例えば、レビュー依頼して忘れてしまう（または忘れられてしまう）ことを防げるようになると期待されます

Done

追加の作業はなく、クローズできる issue をこのパイプラインに置く
完了の定義が作業開始前から存在するとこのパイプラインは活きてくる
クローズする前に、確認が必要な指標や目的があれば、このパイプラインが使える
例えば、次の使い方が想定されます
- サービスのリリース後の本番確認中のものを Close にしないで Done にする
- AMI を作ったけど本番のインスタンスと入れ替えるまで Done にする
- iOS や Android アプリの開発は終わったけどリリースがまだなら Done にする

Milestones

Sprint の管理に milestones を使う

powerful snapshots of our product roadmap

Sprint のレコードには issue を使う

Sprint Goal という label をつけている

Kanban 方式を導入するメリット

進捗が可視化される

例えば

pure な github レポジトリだけで管理されている場合
- 途中から join したエンジニア（や忙しいマネージャーなど）が見ても進捗はたぶんわからなくて、qiita（日報）や slack （チャット）を相互参照しながら定例 mtg なども出てようやくなんとなくわかるようになる感じだと思います
Kanban 方式の場合
- キューの定義と分類が適切であれば、CLOSE DONE REVIEW を見れば何が終わっているかわかり、IN PROGRESS を見れば誰が何をしているかがわかり、BACKLOG を見れば今回の Sprint 期間中に何をするかがわかり、ICEBOX を見れば手が回っていないタスクがわかるので、実際最初からいるエンジニアも含めて全体の最新情報をすぐに把握できる
- そうなると、定例 mtg ではそれぞれの実施意図を伝えれば十分になる（むしろ、そういった話にすぐに入れる）

これの利点は、上記のような新しいエンジニアを含めエンジニアがすぐに全体を把握できるだけでなく、

issue のラベルもしっかりつけていれば（例えば、operation development support trouble とか）、エンジニア以外のメンバーも全体を理解することができるようになると期待されることにあると思います
- 例えばセールス的に欲しいと思っている新機能が何で出ないのだろうと思って今の Kanban を見れば、development タグ付きの issue が BACKLOG になく、ICEBOX にあるからだとわかる。そうなれば、何で BACKLOG に昇格されないのかをエンジニアなり誰かに訊くとかプロダクトマネージャーに交渉するとかもできる
また、プロダクトマネージャーは後述する Velocity も加味して、 development タグ付きの issue を四半期内に BACKLOG に昇格するために、どれくらいのエンジニア採用が必要なのかも数字的な根拠を持って判断できる

進捗が予想できるようになる

Milestone 機能を使うことで、2 週間（仮）で達成できる issue 数がだんだんと統計的に安定すると考えられている（= というかそうなっていない場合は mtg のやり方やタスクの切り方が悪いとされる）ため、Sprint をある程度こなしていくと、このチームでどれくらいの issue を今後消化できるかがわかってくると考えれます

このときの消化速度を Velocity と言うそうです
- この単位は、チームとかディヴィジョン単位やチーム内の機能開発メンバー単位、個人単位で算出できます
これが正確に機能するためには、issue の粒度を揃えて見積もる作業が必要になります
- これはかなり大変で、これがあるのでチーム全員（エンジニアだけではなく）で話し合うために週のうち半日は sprint planning mtg はかかったりします（補足：個人の経験にもとづいて書いてます）
- プランニング・ポーカーの出番です
- なので、この作業は省略されるケースも多いと思います（それが良いか悪いかはわかりません）

これは次のような利点があると思います

前述に絡みますが、チーム編成方針や採用目標を計画的に立てられる
issue の精査やロードマップの見直しを作業前にできる

振り返りができる

前 Sprint で何をするつもりで、それが何で消化しきれなかったのかを、定期的に（2 週間ごとなど）振り返る時間を設けるべきとされていて、それができる下地も整ってます

タスクのアサインが合理的にできる

少なくとも過剰なアサインはされなかったり、他の人が新しいタスクにチャレンジしやすくはなると思います

他の特徴全般にも言えると思いますが、基本的にやり終わってから失敗に気づくのではなく、やる前にリスクに気づけるのがこの方式の利点としてあると思います

また、やりたいことに対してそれをできる人が足りないこともわかるかもしれません

人事評価が合理的にできる（ようにみえる）

全社的にスクラム・カンバンを導入するきっかけのひとつに、シリコンバレーや日本にいる外国人エンジニアを採用するためという話は何度か聞いたことがあります

シリコンバレーにある会社は、スクラムやカンバン方式を採用していることが多いそうです

例えば、3 ヶ月ごとに評価する場合、3 ~ 5 月にその人が何を達成したかは、3/2 3/16 3/30 4/6 4/20 5/4 5/18 の Milestone を見ればわかります（少なくとも建前上）

これに親しんでいる人たちからすると、導入されていない会社はちゃんと働きを見てもらえているのか不安になるそうです

ここらへんは蛇足かもしれませんが、利点としてどうせならということであげました

まとめ

まずは、ZenHub を試してみると感じが伝わるかなと思います

zhb.io/chrome リンクから chrome extension をインストールできます
その後、自らのレポジトリを指定すればすぐに使えます

追記

3 年以上 ZenHub & Kanban を複数のプロジェクトで利用していてやっぱり有効に使える場面があるなと思い、それを別の視点からまとめたブログを書いたのでリンクします。

まあまあ複雑なシステムを少人数で開発するときにやったほうがいいと思うこと - yoheimuta’s blog

ZenHub を使って Kanban 方式をプロジェクトに取り入れる