今年に入って開発のプロジェクト管理をGitHub ProjectからJiraに移行しました。
どのような意図で今回Jiraに移行したのかを紹介させてもらえばと思います。
GitHub Projectsを利用していたときの課題
GitHub Projectsを使い始めた時はホワイトボードの物理的なカンバンの代わりとしてだったと思います。その時のエンジニア数はまだ3名で、 GitHub Projectsの機能でも特に問題は感じていませんでした。
元の運用は、
- issueのマイルストーンにバックログを作る。マイルストーン内ではissueが優先度順に並べられる。ストーリーポイントは数字のラベルをissueにつける。
- マイルストーンから次のスプリントでやる分だけをスプリントマイルストーンに移動、GitHub Projectsに紐づけてカンバンに表示させる。
- スプリント開始!プルリクエストにissueを紐付けておくとプルリクエストがmergeされたときにissueもdoneになって便利。
というシンプルな形でした。
しかし、メンバーが増え、リポジトリが増え、管理するタスクが増えるとこの運用がつらくなってきました。
つらかった点
GitHub Projectsでの運用で辛かった点には以下の様なものがありました。
- マイルストーンがGitHub Repositoryに紐付いているissueをまとめる機能なので、複数のRepositoryをまたいで一つのマイルストーンにissueを集めることが出来ない。
- issueが入れ子関係を持てないのでlabelで管理することになり、labelが増殖する
- 消化したストーリーポイントを数えるのがめんどくさい
- asigneeをつけ忘れると誰がやってるか分からない
- バックログの整理が大変(GitHubのマイルストーンは複数のissueをドラッグアンドドロップで動かせない😢)
- 何がいつリリース予定なのか整理するのが大変
たまたま、エンジニア以外からもタスク管理ツールを選定して導入して欲しいという話があったので、このタイミングでJiraを全社導入し、開発チームもJiraに移行することに決めました。
Jiraの導入
今回Jiraに乗り換えたことで上記の問題が全て解決されました!
- Jiraのバックログはリポジトリに関係無いので、複数リポジトリにまたがるストーリーも管理できる
- epicを親のissue、storyを子のissueとすることによって、issueを入れ子で管理
- スプリントのベロシティを自動で計測してくれるし、epicに属するissueのポイントの合計もすぐ表示される
- カンバン上の移動にルールを追加することが出来るので入力漏れがない
- バックログのissueは複数選択出来、簡単に動かせる。
- いつ何がリリースされるのか一目瞭然
いくつかピックアップして説明していきます!
スプリントのベロシティを自動で計測してくれるし、epicに属するissueのポイントの合計もすぐ表示される
スプリントの機能を使って、スプリントの開始、終了を実行すると毎回の消化ポイントを自動で集計してレポートに出してくれます。 以前はissueについてるlabelのストーリーポイントを数えていましたが、そんなことをする必要はありません!
また、epicに属するissueの合計の見積もり、完了、残りのストーリーもすぐ表示されるので、大きな機能がどれくらいでリリースされそうかわかります。
カンバン上の移動にルールを追加することが出来るので入力漏れがない
カンバン上でTO DOからWIPにカードを移動させようとすると、移動するためのルールを満たしているかどうかのチェックが走ります。 今は、担当者とリリース予定の日付を入力しないとWIPに移動出来ないようにしています。
バックログのissueは複数選択出来、簡単に動かせる。
Jiraのバックログではスプリントとバックログが同じページに表示されており、簡単に移動させることが出来ます。
いつ何がリリースされるのか一目瞭然
Jiraのリリース機能によって、リリース予定日ごとに何をリリースするかをまとめるようになりました。 GitHubのPRと連動しているので、もうマージされたのか、まだレビュー中なのかというところまで細かく分かるようになっています。
移行手段
すでにGitHubに大量のissueが積まれており(500個以上!)、それらを整理してJiraに移行する作業はどう考えても苦行に思えました。GitHubAPIでissueをダウンロードしてcsvに整形してJiraにアップロードするというのが正攻法のようでしたが、そもそも全部移行する必要は無いのではと考えたため移行したいものだけ移行できるZapをZapierで作りました。
GitHub issueのコメントにjira移行と書くとJiraのストーリーを作ってくれた上で元のGitHub issueのURLを説明文に入れてくれるというすぐれものです。
移行してみて
Jiraに移行したことにより、これから更にチームメンバーが増えたり、Repositoryの数が増えたりしても大丈夫な体制を構築できたと自負しています。 また、想定していたわけではないのですが、開発のビジネス要件が全てJiraにまとまるようになり、PMとのコミュニケーションが円滑になりました。 元々はGitHub Issue上でやっていたことですが、GitHub上で管理すると、どうしてもコードについてのアレコレを書いてしまいがちになったり、どこのRepositoryに起票したらいいんだ、となったりしていました。 これがJiraとGitHubで使い分けられたことにより、PMはJiraのみ見れば良い状態になりました。
まだ導入して1ヶ月ほどですが、開発チームの状態に合わせてこれからカスタマイズを続けていきます!