こんにちは、開発部 MERY Server Team の中村(isetan)です。 今回は MERY Server Team が以前抱えていた Issue 管理の課題と、それを解決するために選んだ方法を紹介をしたいと思います。
MERY Server Team ではスクラムという開発手法をとっています。 スプリントと呼ばれる一定の期間ごとに、行うべき Issue を選んでいます。 Issue は GitHub の Issue を元に管理しています。 また各 Issue にはその Issue の複雑さや困難さを数値にしたストーリーポイントを割り振っています。
以前の Issue 管理方法とその課題点
Web サービスを開発していくと、ひとつのチームで複数のリポジトリを扱うことはよくあることかと思います。 MERY Server Team でも複数のリポジトリを扱っており、クローラーや編集チーム向けの社内アプリなどを含めると片手からはみ出るくらいの数のリポジトリを扱っています。
以前は GitHub の Issue と Trello を連携させて Issue を管理していました。 その時の連携方法は以下の様なものでした。
Trello に GitHub のリポジトリ名のリストを作り、そこへ Issue を Trello のリストに自動でカードとして追加していきます。 「MERY API」「MERY Web」といったリストが作成していました。 各リポジトリのリストの他に以下の様なリストを作成し運用していました。
- Sprint Backlog : スプリントでやるべき Issue をまとめたリスト
- Doing : 作業中の Issue を入れるリスト
- Pull Request : Pull Request を出した Issue を入れるリスト
- Complete : レビューが完了し、リリースできる状態になった Issue を入れるリスト
Issue の状態に合わせリストを移動していくといういわゆるカンバン方式です。
GitHub と Trello の連携も便利なのですが、いくつか課題点がありました。
例えば Issue が終わった時には Trello 上で Doing から Complete に移動し、さらに GitHub の Issue はまた別で close しなければならず、進捗のたびに２重の操作が必要でした。 片方の操作を忘れてしまうこともしばしば起こり、整合性がとれず進捗管理としてうまくいかないこともありました。
また従来 MERY のサーバサイドは１チームですべてのサーバサイドのリポジトリを扱っていました。 メンバーが増え、チームが増えてきたことで一つのボードを複数のチームで使いはじめたところ 「Server Team doing」「EC Team doing」などのリストが増えてきてしまい、一覧性と操作性が落ちてきました。
以上の課題点を解決するための要件は以下のようなものでした。
- Issue 管理ツールの状態や close が GitHub Issue の状態や close が同期すること
- リポジトリをまたいでスプリントごとなどの単位でひとつのカンバンで表示できること
- チームごとに表示するリポジトリを選択し、切り替えられること
候補に上がったサービスには Atlassian 社の JIRA と Backlog 、Codetree がありました。 JIRA は UI が肌に合わなかったこと、Backlog は上記で上がった課題点を解決できなさそうというところから候補から外れました。 Codetree は調査してみると上記の課題を解決してくれそうだったのでトライアル利用を開始することにしました。
Codetree とは
Codetree は Github をラップしてくれるサービスです。 最初に Issue と Pull Request をインポートして使い始めます。 Private Repository にも対応しています。 有料のサービスですが、2週間は無料で試用することができます。
Codetree の特徴
こちらが実際に使っている Codetree の スクリーンショットです。モザイクが多いですが雰囲気は感じ取ってもらえるかと思います。
Codetree に移行したのは以下のような特徴があったためです。
進捗管理がし易い
Codetree のカンバンの状態と GitHub の label が同期されます。 例えば Codetree 上で 「In Progress」に移動させると、GitHub の Issue に「in progress」とlabelが付きます。 また Codetree 上で Issue を close すると GitHub 上でもその Issue は close されます。 この機能のおかげで、Trello の時のようにタスク管理ツールと GitHub の両方を操作する必要がなくなり、負担がさがりました。
リポジトリをまたいで管理することができる
複数のリポジトリを GitHub のIssue に付与できる milestone でまとめて表示することができます。 スプリントをmilestoneとすることで複数のリポジトリを扱えるようになり、 MERY Server Team にはうってつけでした。
また Codetree は Project という単位で表示するリポジトリを選択できます。 そのためServer Team であれば EC Team のリポジトリを選択しないなど不要なリポジトリが表示されなくなり、Trello を使っていたときに起きていた一覧性と操作性の課題が解消しました。
Issue に関連する Pull Request とその状態をカンバンで表示することができる
これによりカンバン形式での進捗状況の把握がしやすくなりました。
上が Issue でその下が関連する Pull Request です。
各 Issue に重み付けすることができる
その重みをMERY Server Team ではストーリーポイントをつける機能として利用しています。 スプリント振り返りの時にdoneになったIssueでフィルタリングすることでベロシティを図ることができます
Codetree の改善して欲しい点
たくさん便利なことがあるのですが、使っていく中で改善して欲しい点もでてきました。
GitHub 上ではひとつの Issue に複数に人をアサインすることができますが、Codetree では一人しかアサインできません。 ひとつの Issue をフロントエンジニアとバックエンドエンジニアとが分担して担当することもあり、少し不便です。 今後のバージョンアップで改善されることを期待しています。
本利用までのスピード感
Codetree の採用が決定し、トライアル利用の終了と共に本利用に移行しました。 期間にすると調査開始から本利用まで2週間程度という素早い意思決定でした。 このように、素早い意思決定により環境をより良くしていけるのが peroli の魅力だと思います。
これからもスピード感を持ってより良い環境を提案し作っていけるよう頑張っていきます！