この記事はPHC BXC Advent Calendar 2022 11日目の記事です
はじめに
私はこれまで複数のタスク管理ツール（Jira/Backlog/Redmine等）を利用してきましたが、Jiraが一番手に馴染んでいます。一方で、Jiraはその多機能性がゆえに、最初かなりとっつきにくいです。
本記事では、Jiraを使って課題管理し始める際に、初期で躓きがちな設定についての考え方を記載していきます。
前提
以下の方々を想定して記載しています。
- チームのリーダー等で、タスクの管理を行う必要がある
- 組織にJiraは導入されているものの、なんとなく使っており、あまり使いこなしていない
- 開発チームに所属している（ただし基本的には非エンジニアの方でも参考になるように記載しています）
本記事のスコープ外
本記事では以下の内容は取り扱いません。機会があれば別記事にしようと思います。
- 日々のタスク・プロジェクト管理の方法論
- スクラムでの運用方法、レポート等
- 各種自動化、連携方法等
- Jiraの導入方法
プロジェクト作成
Jiraではプロジェクトという単位で課題群を管理しています。プロジェクト単位で課題タイプ/権限/通知等を設定するため、後述しますが基本的にはチーム単位で作成することをお勧めします。
作成方法（公式ドキュメント）
プロジェクトテンプレート
プロジェクト作成時にテンプレートを選択する必要があります。Jiraには色々テンプレートがあります。大量に選択肢がありすぎて迷いますが、本記事の読者は「ソフトウェア開発」を選択してください。他のテンプレートもいくつか試行したことがありますが、どれもピンときませんでした。
「ソフトウェア開発」の場合、さらにかんばん/スクラム/バグ追跡の３つから選択する必要があります。迷った場合は、スクラムを選んでおけばよいと思います。
参考記事
プロジェクト テンプレートとは?
なお、このプロジェクトテンプレートの変更は基本的に不可で、新しいプロジェクトを作成してそこに移行する必要があります。
プロジェクトタイプ
Jiraにはチーム管理対象プロジェクトと企業管理対象プロジェクトという2つのプロジェクトタイプがあります。基本的な違いは、管理方法とチームレベルまたは企業/Jira 管理者レベルのどちらで管理されるかということです
多くの場合このプロジェクトタイプは適当に選択されており、あまり気にする必要はないと思います。組織としてのJira運用ルールが固まってなければチーム管理対象プロジェクトを、そうでなければチーム管理対象プロジェクトをお勧めします。
プロジェクトを分けるか否か
新しいプロジェクトが始まる際、「新たにプロジェクトを作った方がいいですか？」と聞かれることがあります。私の回答は「チームが同じなら１プロジェクトでOK。ただし、実質的にタスクを管理するリーダーが複数いるなら、リーダー毎にプロジェクトを分けましょう」です。
公式のBest Practices: Strategies for Defining your JIRA Projectsではベストプラクティス（しかし絶対的な正解ではない）として、リリース可能なプロダクト/チーム/ビジネスユニットでプロジェクトを分ける方法を記載していますので、参考にしてください。
プロジェクト内の各設定について
原則
まず、Jiraプロジェクト内の「課題タイプ」、「ワークフロー」、「画面」、「フィールド」に関しては、権限の考え方が割と複雑です。この辺りを理解せずにがっつりカスタマイズすると後々保守が大変になるので、「できる限りデフォルトで運用し、困った場合のみカスタマイズする」ことをお勧めしています。
どんな感じの構成になっているのかについては下記の記事に詳細がありますが、この図がすっと頭に入る方はなかなかいないかと思います。
課題タイプ
チケットの種類を表すものに、課題タイプがあります。詳細は公式ドキュメント 課題タイプとはをご参照ください。
ソフトウェア プロジェクトのデフォルト課題タイプはエピック・ストーリー・タスク・サブタスク・バグの4つです。特段の理由がない限り、この標準の課題タイプで事足りると思います。課題の種類ごとに分類したい場合は、ラベル機能を利用するとよいです。
Jiraに不慣れな方からは「どういうときにストーリーを選べばよいのか？」と質問されることがあります。ステータスやラベルについては、直感的に理解できますが、ストーリー・エピックあたりは概念的に馴染みがないからでしょう。チーム内で課題タイプの定義を共有しておくことをお勧めします。
参考記事
課題タイプについては以下の記事が分かりやすいです。
ワークフロー
ソフトウェア プロジェクトのデフォルトワークフローはTODO->進行中 ->DONEの3種類ですが、比較的大きめのチームになるとこの3分類では物足りなくなると思います。このワークフローに関してだけは、以下の理由によりカスタマイズを推奨しています。
- 現状タスクがどの状態にあるのかを可視化するため
- タスクの状態が変わったこと（担当者やフェーズ）を通知するため
ワークフローはチームの運用の実情に沿った形で設計する必要があります。必要以上に細かく分類してしまうと、ステータスの変更自体が負荷になってしまうため、私は以下のような観点でワークフローを分けています。
- 担当者が変わるとき
- 今のチームでは実装者とテスト実施者は基本分けることになっています。よって、「テスト待ち」というステータスを作り、テスト準備が整った段階でステータスを変えることで「テストが可能になった」という事実を見える化するようにしています
- 次のアクションまでに時間が空くとき
- 今のチームだと、1つのリリース日に対して、複数の機能をまとめる傾向があります。これにより、早めにリリース準備が整った機能も、他の案件の準備を待つことになります。このような事情により、「リリース待ち」というステータスを用意しています。
参考記事
公式ドキュメント
カスタムフィールド
以下の記事にもありますが、基本的にはJiraが元々持っているシステムフィールドを利用して運用することをお勧めします。特に単純なテキストについては「説明」（本文）欄に書いてしまえばよいと思います。
カスタムフィールドを利用する場面としては、その項目自体で集計ないしはフィルタリングしたい、といったニーズが挙げられると思います。例えばバグの発生原因として「仕様検討漏れ/設計漏れ/テストケース不足」等の分類をしておき、それらを入力してもらって後ほど傾向分析がしたい、等の場合です。
最後に
Jiraに関しては個々のhow toの情報は多く存在するものの、考え方についての情報があまりネット上に存在していません。私自身、初心者の時に色々試行錯誤して時間を費やしてしまったので、今後Jiraに触れる方が同じ轍を踏まないように記事を書いてみました。
Jira公式からも Jira Software のガイドとチュートリアルというドキュメントが公開されており、こちらからマニュアル・ベストプラクティスも参照できます。興味を持った方はご覧ください。Jiraを使うだけでは良いシステムができるわけではありませんが、うまく利用することでチームの生産性を上げる事は可能です。ぜひ色々試してみてください。