こんにちは、ヌーラボの中村です。BacklogのGitチームで開発や運用などをやっています。

ヌーラボではプロジェクトの管理にBacklogを利用しています。Backlogでは課題種別やカスタム属性などをカスタマイズできますが、特にプロジェクト序盤の設定がプロジェクトの進行に大きな影響を与えます。

この記事では私が関わったプロジェクトで、実際どのようにBacklogの課題まわりの設定をカスタマイズしていたのかをお伝えします。

※本記事はヌーラボブログリレー2024 for Tech Advent Calendar 2024の20日目の記事です。

課題種別の再定義

プロジェクトの特性に合わせて課題種別を再定義します。

Backlogに初めから用意されている課題種別「タスク」「バグ」「要望」「その他」は汎用的でとっつきやすさはありますが、プロジェクトにぴったり合った管理をするためには過不足が出てきます。一旦すべて削除し、そのときのプロジェクトに合わせて必要なものだけに再定義しています。

作成の際はいくつか仮の課題を作成してみて、共通点を探します。作成した課題から「テンプレートに抽出できそうな箇所」と「ワークフロー（状態）の共通点」を探し、共通しているものに着目して一つの課題種別にまとめます。しっくりくる名前を考えて、それを新たな課題種別とします。

以下に私たちが実際に定義した課題種別を示します。

A. 請求管理のシステム化プロジェクト（外部チームとの仕様調整の多かったプロジェクト）

• PBI – プロダクトバックログアイテム
• Spec – 要求仕様・外部仕様をまとめる
• Discuss – チームをまたいだ検討や相談をする
• Data – 移行のためのデータを作成する

B. アプリケーションリプレースのプロジェクト

• Investigate – 現行システムの調査、新技術の調査など
• Develop – 開発全般
• Test – 性能テスト、システムテスト

C. インフラ構成のリプレースのプロジェクト

• PBI – プロダクトバックログアイテム（作業全般）
• Investigate – システム構成、インフラ上で動いているアプリケーションの挙動やリリース方法の調査

D. Backlog Gitの開発運用

• Bug – バグの記録とその対応
• Release – リリースの記録
• App Improve – アプリケーション改善
• Operation Improve – 運用改善
• [Ope] Kernel Update、[Ope] … – よくあるオペレーションを[Ope]始まりの課題種別として定義
• [Ope] General – その他の運用作業
• Product Backlog – プロダクトバックログ（1ヶ月以上かかるような課題）
• Product Backlog Item – プロダクトバックログアイテム（プロダクトバックログに紐づく課題）

課題の状態は侵入条件と合わせて検討

課題種別をまとめながら、種別ごとに課題の状態とその進入条件を定義します。

よく定義している課題種別は以下になります。

• 未対応
• Ready
• 処理中
• 処理済み
• WfR (Waiting for Release)
• 完了

進入条件は、過去の記事で紹介したものとほぼ同様のものを採用することが多いです。
→ Backlogを上手に使ってらくらくスプリント開発

定義した課題種別・状態・進入条件はいつもBacklogのWikiにまとめています。

マイルストーンの使い方

マイルストーンは3種類の使い方をしています。

• いくつかの課題を小プロジェクトとしてまとめる
• マイルストーンでプロダクトバックログを管理する
• プロジェクトのフェーズを期間で分ける（「◯◯プロジェクトPhase 1」や、単に「2025 Apr」とか）

オーソドックスな使い方かなと思います。

カテゴリーはなるべく使わない

基本的には使いません。絞り込みや集計の必要が発生したタイミングで、慎重に検討して付与します。

カテゴリーをむやみに作成してしまうと管理の手間が増えてしまいます。分類は課題種別で、絞り込みはタイトルなどを工夫して通常の検索で済ませられないかを考えます。それでも足りない場合にカテゴリーを追加します。

（「機能追加」「バグ修正」「コーディング」「デザイン」など、単に属性を表すだけのカテゴリーを作成するのは管理の手間だけが増えてしまう、アンチパターンだと思っています）

実際に作成したことがあるのは以下のカテゴリーです。

• ◯◯チームへ依頼 – 別チームの人に絞り込みをしてもらうために作成
• Onboarding – オンボーディング中のメンバーにおすすめしたい課題
• Change ABC System – 他プロダクトを変更する課題。会計の都合で集計する必要が出てきたため付与

これらは全て、課題を作成した後に付与しています。

「◯◯チームへ依頼」「Onboarding」は付けたり外したりできるものとして運用しています。

親子課題もなるべく使わない

親子課題も基本的に使いません。

課題同士の関連は多対多であることが多く、親子だけでは表現し切れないからです。代わりに課題詳細に関連課題を記載しています。

また、課題に紐づく詳細な作業（タスク）は、課題詳細の中にチェックリストとして書いたり、別途スプレッドシートに書き出したりして管理しています。

Backlogでは解決したい課題や発生している問題を管理し、作業などのTODOは他の方法で管理するようなイメージです。

親子課題の使いどころ

とはいえ、親子課題を使用したケースも1つだけあります。それは『A. 請求管理のシステム化プロジェクト』のプロジェクトです。

このプロジェクトはバックオフィスや総務・法務など各チームとの連携が重要なプロジェクトでした。開発チームだけでは仕様を決定できないものが多く、仕様の決定や開発に着手する前に関係部署との調整が必要なものが多くありました。

そのため、課題種別「Spec」（仕様の作成）と課題種別「PBI」（開発）の子課題に、課題種別「Discuss」（ミーティング）を割り当てる運用をしました。そして親課題のReadyの進入条件に「子課題にあるDiscussの課題が完了になっていること」を策定しました。

これによって、「関係各所との調整が完了するまでは開発への着手・仕様の確定はできない」というルールが表現されました。「親子」としてはなんだか順番が逆のように見えますが、親子課題の性質を利用して課題の依存関係を管理していました。

まとめ

私達が実際の開発プロジェクトでBacklogをどのようにカスタマイズしているのかを紹介しました。

Backlogも含め、ツールの使い方はチームで相談して決めることが一番重要です。ここで紹介した使い方は1つのケースとして参考にして、自分たちに一番合った使い方を追求してみてください。

みなさんも、いい使い方があればぜひ共有してくださいね。