はじめに
こちらの記事は カケハシ Advent Calendar 2023 の 2日目の記事になります。
https://adventar.org/calendars/8587
こんにちは。患者リストというサービスを開発している金です。
患者リストチームは1年以上Github Projectを使っていました。 メリットもありましたがチーム内ではデメリットの方を多く感じて、結局JIRAに移行することになりました。 JIRAに移行してからは弱3ヶ月ほど経ちました。
この記事では
スクラム開発をしている患者リストチームがGithub ProjectからJIRAに移行を決めた背景と、 その変更によってエンジニアメンバーが得たメリットについて話したいと思います。 もちろんJIRAの方に多くデメリットを感じて、Github Projectに移行したチームもあると思います。 ですので、この記事の内容はあるケースの一つであると思います。
スクラムチームがプロジェクト管理ツールに求めること
一言でいうと、スクラムの運用と管理がしやすいツールであること。 運用と管理がしやすいというのは以下に該当するものかと思います。 - スクラムで定義しているイベント(運用)を楽に進められる - ロードマップ、エピック、ストーリー、タスクなど、スクラムで定義しているアイテムの管理が楽
この点を考えるとGithub ProjectよりJIRAの方がスクラム開発に向いているツールかと思います。
Github Project どうだった？
1年半前患者リストチームはTrelloからGithub Projectへ移行をしました。 当時の理由は以下が主な理由でした。
- 「PRとタスク(issue)が紐づいてないため、Githubだけではなく必ずTrelloの確認も必要になる。 一つのところでまとめて確認したい」
- 「TrelloにはないGithub ProjectのInsightsの機能とWorkflow機能を使いたい」
Insightsの機能でスクラム関連指標を出したり活用をしていましたが、 移行の理由自体はあまりスクラムの運用にかかわるものではなかったと思います。
そのためか、移行してからエピックの管理、バックログの管理、ロードマップの管理、スプリントごとのタスク管理、タスクへのポイント記入はどうする？ などの問題に遭遇しました。 (今振り替えてみると、これらの問題の根本はGithub Projectは「スクラム専用ボードではない」、「タスクに上位・下位の概念がない」だったと思います) 結局これらの問題はCustom Labelをつけることで解決をしていました。
- SprintというLabelではスプリントを付与して、スプリントごとのタスクを管理する
- ボードでFilter機能を利用してスプリントで絞り、そのボードをスプリントのメインボードにする
- エピックに関してはエピックラベルを作ってそこに、エピックに紐づくタスクはエピックの番号を書いておく。
- ロードマップに関してはLayoutを利用する
ですが、このCustom Labelを活用する運用にも手間がかかっていました。 - スプリントが終わった後、消化できず次のスプリントになるタスクに一つ一つSprint Labelを変更しなきゃいけなかった点 - もしタスクからエピックLabelに紐付けを忘れると、後からタスクの探しが大変になる点
上の問題は、エンジニアのスクリプトの作成である程度楽にはなっていましたが、スクリプトを実行する手間がある、忘れるなどの不便さは残り続けていました。
それでJIRAは？
結論から申しますと、JIRAにはスクラム専用のボードが存在していて、Github Projectで感じでいた問題は解決されました。
JIRAのボードをスクラムボードで作成をすると以下のように分かれています。 - タイムライン - バックログ - アクティブなスプリント - レポート
タイムラインではエピックの期間設定でロードマップの管理を。 バックログではエピックに紐づくタスクの管理ができ、優先順位の並びや次のスプリントにどんなタスクをするかの整理を。 アクティブなスプリントではこのスプリントの専用ボードでこのスプリントのタスクの管理ができる。 スプリントの期間設定もできて、それが終わると残っているタスクを全体的に次のスプリントに移行できることもとても楽でした。
他にエンジニアとして嬉しかったのはJIRAの自動化機能とツールチェーン機能でした。豊富なIntegrationがあり、かなり活用しやすい機能でした。 上のイメージが実際に活用されているJIRAの自動化画面の一部です。
簡単な例としてはエンジニアが作業をするとき、タスクのステータスを変更することが地味に手間がかかったり忘れていました。 「TO DO」→「IN PROGRESS」→「IN REVIEW」→「DONE」このステータス変更を自動化して - PRが作成されたら自動的にステータスを「IN PROGRESS」にする、かつSTART TIMEを記載する - PRがマージされたら、ステータスを「DONE」にする、かつEND TIMEを記載する
意識せずに自動でステータスが変更されるようにしています。
JIRAはまた、分析にも強いと思います。 上記の例で出た、START TIMEとEND TIMEがまさに分析のために入れているLabelです。 同じEstimateのタスクでもかかる時間が多く異なる場合は、なぜを分析して改善に活用するために記載しています。 分析の場合、JIRAのレポートも活用されていますが、 患者リストチームではスクラムマスターがJIRAとスプレッドシートを連携してそこからlookerstudioでグラフを出し、改善のための分析を行なっています。
さいごに
患者リストチームの場合、スクラムチームですのでやはりスクラムボードを専用的に用意しているJIRAが楽でした。 加えて、Github Projectでは大変だった自動化やスクラム改善のための、分析も捗ることになり、非常に満足しております。 特にエンジニアとしては開発と直接関連はないですが、Github Projectで感じていた細かい使いずらさを感じる部分が減り、心理的にも行動的にもかなり楽になったと思います。 ちなみにですが、Github ProjectからJIRAに移行するときはGithub Projectのデータを全部CSVにExportしてそれをJIRAにImportする作業をスクラムマスターが短時間で終わらせていましたので、移行もかなり楽だったと思います。
以上になります！最近様々なツールが存在しており、自分たちのチームにはどんなツールが良いか悩まされるチームも多いかと思います。その中、この記事が少しでも役に立てたら嬉しいと思います。
