この記事ははてなエンジニアアドベントカレンダー 2023の5日目の記事です。
maku693です。
私が現在所属しているチームではJiraを使ってチームのタスクを管理しています。
はてなではスクラムやそれをベースにした手法を使ってプロジェクトを管理していることが多いですが、以前所属していたチームでは別のウェブサービスを使っており、ベロシティ計測や中長期の計画に手間がかかると感じていました。
私は今のチームに異動して初めてJiraに触れたのですが、うまくJiraの機能に乗ることでそういった仕事を省力化できることがわかりました。
この記事では私のチームでJiraをどのように活用しているか紹介します。
Jiraの良いところ
Jiraの良いところはスクラムのコンセプトをもとにした機能が豊富な点です。私のチームもスクラムをベースにプロジェクトを管理しているので、他のツールに比べてよりチームに適していると感じました。
Jiraを使っていて特に良いと感じるのは次の3点です。
- 「バックログ」ボードでの計画がしやすい
- 「課題タイプ」と「バージョン」でタスクが分類できる
- 「レポート」機能を使ってプロジェクトの進捗が把握できる
それぞれ詳しく説明します。
「バックログ」ボードでの計画がしやすい
Jiraの「ボード」とはJiraの課題の表示方法の一種です。私のチームでは「バックログ」ボードを使って直近数スプリントの計画を実施しています。
Jiraのバックログボードには「スプリント」と「バックログ」の概念があります。これらはそれぞれスクラムのスプリントバックログとプロダクトバックログに相当するもので、バックログには将来とりかかる予定のタスクを、スプリントにはそのスプリントに手がける予定のタスクを並べられます。
スプリントは好きなだけ用意しておくことができるので、先のスプリントの計画をするだけでなく、まだリファインメントされていない課題を表現するなど、とりあえずタスクを分類する場所として使うこともできます。
ボード上のスプリントには見積もりの合計が表示されます。後ほど説明するスプリントレポートを見ればチームのキャパシティがわかるので、スプリントプランニング時にスプリントバックログの過不足を防げるのが便利です。
「課題タイプ」と「バージョン」によるタスクが分類できる
課題タイプ
Jiraでは課題タイプを任意に追加できますが、私のチームではデフォルトで存在する「エピック」と「ストーリー」をよく利用しています。
「エピック」は「〇〇機能」のような、開発に1ヶ月程度かかるような粒度でバックログを管理するのに利用しています。
「ストーリー」ではエピックを構成するユーザーストーリーを管理しています。ストーリーについては必ずしも「△△できる」のようなユーザーストーリーっぽい書き方のタイトルにしているわけではなく、作業量が多いときは「××のUI」「××バックエンドAPI」などのようにコンポーネントレベルで分割することもあります。タスクの見積もり（ストーリーポイント）はストーリーに記録しています。
また、ストーリー中の細かいタスクは「サブタスク」で管理しています。サブタスクに関してはストーリーを実現するコードを書く際に、Pull Request単位くらいの粒度で分割して利用しています。これに関しては見積もりはしていません。
私のチームでは1チームでいくつかのプロダクトの面倒を見ている都合で、複数のエピックを並行して何スプリントにもまたがって進行させることがあるのですが、単に課題の種別があるだけでなく、エピック - ストーリー - サブタスク という親子関係がスプリントとは別に存在することで、素直にそういった状況を表現できるのが便利なポイントです。
バージョン
「バージョン」は課題タイプやスプリントとはまた別の軸で、これを使うと複数の課題をあるバージョンにまとめられます。
私のチームでは何ヶ月かかけていくつかの機能を開発し、全てが完成してからそれらをまとめてリリースしています。
このようなマイルストーンを管理する際に、一つの大きなエピックを作るのではなく、エピックは機能単位で表現し、バージョンを使ってそれらをまとめられるというのがわかりやすくて気に入っているポイントです。
なおバージョンはストーリーに設定しています。こうすることで同じバージョンに紐づくストーリーの見積りの合計がレポートで把握できます。
「レポート」機能を使ってプロジェクトの進捗が把握できる
Jiraが特に秀でていると感じるのはこのレポート機能です。
私のチームではつぎのレポートをよく利用しています。
- ベロシティグラフ
- バージョンレポート
- エピックレポート
私のチームではスプリントプランニングの際に 「ベロシティグラフ」で過去のスプリントのベロシティの実績を確認し、次のスプリントのキャパシティの参考にしたり、「バージョンレポート」「エピックレポート」でバージョン・エピックの開発が締切に間に合うか確認したりといった形で利用しています。
なお、バージョンレポートとエピックレポートは集計対象が異なるだけで見た目はほぼ同じです。
この2つのレポートはいわゆるバーンアップ形式の表現ですが、どちらもバーンダウン形式のものも存在するので、必要に応じてどちらも見れるのが便利です。
内部的にどのような計算式が使われているのか把握していないのですが、バージョンやエピックの完了予定日も表示されるので、これも計画の参考にしています。
また、このレポートは半期や1年などの中長期計画を立てるときにも利用できます。たとえば企画の立ち上げ段階で、開発を実施するかどうかが確定していないタイミングでは、バックログがまだ詳細化できないことが多いと思います。そのような状況でも、レポートを使えば過去のエピックの見積もりや開発期間が簡単にわかるので、同等の規模の機能の見積もりと、直近のチームのベロシティをもとに開発期間の予測を立てられます。
ただし、レポートを正常に運用するには、バックログアイテムの見積もりがある程度正確に行われていたり、スプリントの期間を一定にしていたりと、スクラムのお約束が守られていることが前提になります。そういったスクラムのコンセプトをチームに浸透させておくことも重要かと思います。
おわりに
Jira以外のツールだとタスクを分類する軸が足りなかったり逆に自由度が高すぎて使いづらかったりと不満を感じることが多いのですが、Jiraにはスクラムの概念をもとにモデリングされた機能がビルトインされているので、そういった面での辛さがないのが嬉しいポイントです。
スクラムチームのプロジェクト管理に悩んでいるけど、今までJiraを使ったことがないという方は一度試してみてはいかがでしょうか。
この記事ははてなエンジニアアドベントカレンダー 2023の5日目の記事でした。
明日の担当は 
id:tomato3713 さんです！
（おまけ）クラウド版Jiraで今回説明したようなプロジェクトをセットアップする方法
この記事を書くにあたって初めて知ったのですが、クラウド版Jiraのプロジェクトには、「チーム管理対象プロジェクト」と「企業管理対象プロジェクト」の2種類があります。今回説明した機能のうち特にレポート周りは「企業管理対象プロジェクト」でしか利用できないものが多いです。
「チーム管理対象プロジェクト」だとエピックやバージョンのレポートが見れない上に、あとからプロジェクトタイプの変換はできないようなので、そのようなレポートが必要な場合は最初から「企業管理対象プロジェクト」として作成するのがおすすめです。
詳しくは次のJiraのヘルプを参考にすると良いでしょう。
チーム管理対象プロジェクトと企業管理対象プロジェクト間の移行 | Jira Software Cloud | Atlassian サポート
少し調べてみたところ、どうやらPremiumやEnterpriseプランではAdvanced Roadmapsという機能が利用でき、これが代替になるようにも見えるのですが、無料プランのアカウントしか持っていないので試せていません。この辺りも機会があれば触ってみたいと思います。
