複数の 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 のようなレポジトリを複数抱えるチームは珍しくないように思います）があるとそれぞれを行ったり来たりしないといけないこと
導入実績
日本でも最近聞かれるようになってきたように思います
- 突撃！隣の開発環境 パート1 【Wantedly編】 ｜ Developers.IO
- トレタの課題管理 〜巷で噂の ZenHub を試験的に導入してみた〜 : TORETA（トレタ） ブログ
- 個人ブログ
- GitHub issueに、かんばんボード機能を追加できるZenHubがマジ神 | IsaB
- Githubでカンバンが使えるようになるZenHubが素晴らしすぎる - 新・たけぞう瀕死の日記
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 方式の場合
- キューの定義と分類が適切であれば、
CLOSEDONEREVIEWを見れば何が終わっているかわかり、IN PROGRESSを見れば誰が何をしているかがわかり、BACKLOGを見れば今回の Sprint 期間中に何をするかがわかり、ICEBOXを見れば手が回っていないタスクがわかるので、実際最初からいるエンジニアも含めて全体の最新情報をすぐに把握できる - そうなると、定例 mtg ではそれぞれの実施意図を伝えれば十分になる（むしろ、そういった話にすぐに入れる）
これの利点は、上記のような新しいエンジニアを含めエンジニアがすぐに全体を把握できるだけでなく、
- issue のラベルもしっかりつけていれば（例えば、
operationdevelopmentsupporttroubleとか）、エンジニア以外のメンバーも全体を理解することができるようになると期待されることにあると思います - 例えばセールス的に欲しいと思っている新機能が何で出ないのだろうと思って今の 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 を複数のプロジェクトで利用していてやっぱり有効に使える場面があるなと思い、それを別の視点からまとめたブログを書いたのでリンクします。