Backlogのチケットの運用ルールを考えてみた
2024.09.14Backlogのチケットの整理ができない
こんにちは、のんピ(@non____97)です。
皆さんはBacklogのチケットの整理ができないと思ったことはありますか? 私はあります。
私はプロジェクトを管理する際にBacklogを用いることが多いです。
Backlogの課題(以降チケット)は以下のいくつかの設定項目があります。
これらの設定がある程度のルールに従って運用されていないと、プロジェクトで何が起きているのか把握しづらいです。場合によっては着手するべきタスクを見落としたり、優先順位を間違えたりするでしょう。
ということで、私が考えるBacklogチケットの運用ルールについて紹介します。具体的には以下について紹介します。
- チケットの種別の使い分け
- カテゴリとマイルストーンの使い分け
- チケットの単位
- チケットの親子関係
- チケットのフォーマット
- チケットに設定する期日
- チケットの優先度
- チケットの担当者変更のタイミング
- チケットに関連するチームの表現方法
- コメントをやり取りする際のルール
- チケットの状態の管理
- チケットのクロージングポリシー
チケットの種別の使い分け
まずはチケットの種別の使い分けです。
チケットの種別は「チケットの性質に関わる分類」として使用します。
例えば、以下のように使い分けます。
- タスク
- QA
- レビュー
- 課題
- リスク
- 会議
- 連絡
- 相談
それぞれの種別について以降説明します。
タスク
タスクはプロジェクトやスプリント開始時に想定していたやるべきこと や、何か作業を依頼する際に使用します。他の種別に該当しないようなものはタスクを設定するぐらいの使い方で良いと思います。
QA
QAは設計前の情報収集や、アウトプットに作成するにあたっての相談事をする際に使用します。
基本的にQAはタスクの子チケットとして起票します。
タスクのチケットの中でQAをしてしまって良い場面もありますが、1つのチケットでのやり取りが長くなってしまうようなコンテキストが深いものは別チケットに分けてしまった方が見通しが良いと感じています。
レビュー
レビューはレビュー依頼時に使用します。
レビューも基本的にタスクの子チケットとして起票します。
課題
課題はプロジェクト進行中に生じた問題や不具合が発生した際に使用します。
1つのチケットを解消するために対応すべきことが複数 かつ 内容がある程度分割できる場合は、子チケットとして同じく課題のチケットを用意します。
リスク
リスクはプロジェクト進行中に発生しうる問題を整理する際に起票します。
起票するタイミングとしては、リスクが顕在化してからではなく、「リスクとして考えられる」と感じ取った際に起票します。
「もしかすると考え過ぎかも」や「リスクと捉えるには少し大袈裟かもしれない」は考えなくとも良いです。プロジェクトとして対処のしようがない状況になってから発覚するよりかは圧倒的に楽です。仮に杞憂だったとしても、「このリスクは評価した結果、問題なかった」と「何をどこまで考えたのか」というリスクの評価範囲を整理することができるので、むしろ積極的に起票するべきです。
一方、リスクのチケットが起票され過ぎている場合はプロジェクト内に不安が蔓延していることとも言えるので、一度プロジェクトメンバーと抱えている不安について話し合うと良いでしょう。
リスクとして顕在化し、プロジェクトとして優先的に対応が必要になった場合は種別を課題に変更します。
また、1つのリスクで対応すべきことが複数ある場合は、子チケットとしてタスクを用意します。
会議
会議は議事録の共有をする際に使用します。
連絡
連絡は休暇予定などの連絡をする際に使用します。
相談
相談は今後のプロジェクトの進め方や定例会の日程調整などの相談をする際に使用します。
QAとの使い分けはQAはアウトプットについて、相談はプロジェクト運営について使い分けると良いと考えます。
カテゴリーとマイルストーンの使い方
簡単な使い分けは以下のとおりです。
- カテゴリー : 何に対して
- マイルストーン : いつやるのか
カテゴリーは関連する対象を示すものです。例は以下のとおりです。
- ネットワーク
- セキュリティ
- ファイルサーバー
- バッチ処理
- Active Directory
- 可用性
- 性能・拡張性
- 運用保守
- 移行
- システム環境
- プロジェクト計画書
- 打ち合わせ
- Backlog
- プロジェクト管理
カテゴリーは一つのチケットに複数設定可能です。チケットをグルーピングする際に便利なので積極的に使用していきます。
カテゴリーごとのチケットの進捗度合いを確認することも可能です。
抜粋 : プロジェクトのカテゴリーごとの課題数 – Backlog ヘルプセンター
マイルストーンは時期や工程です。例えば以下のように定義します。
- 要件定義
- 基本設計 (本番環境)
- 詳細設計 (本番環境)
- 運用設計 (本番環境)
- 移行設計
- 構築 (本番環境)
- 単体テスト (本番環境)
- 結合テスト (本番環境)
- システムテスト (本番環境)
- 移行リハーサル (初回)
- 移行リハーサル (2回目)
- 本番移行
マイルストーンは1つのチケットに1つしか設定できません。
Backlogでガントチャートを表示した際にマイルストーンの終了日には旗が立ちます。
抜粋 : マイルストーンで、プロジェクトの節目を明確にしよう – Backlog ヘルプセンター
チケットの単位
WBSのレベル分けも千差万別だとは思いますが、無理矢理WBSで例えるならWBSのレベル3や4相当のもの単位でチケットを切ると良いでしょう。以下WBSレベルごとのBacklogでの表現方法です。
| WBSレベル | レベルの説明 | 具体例 | Backlogでの表現方法 |
|---|---|---|---|
| レベル1 | 工程 | 要件定義 | マイルストーン |
| レベル2 | アウトプットのカテゴリ | 可用性 | カテゴリー |
| レベル3 | 具体的なアウトプット | AZレベル障害時の目標復旧水準 | 1チケット |
| レベル4 | アウトプットを作成するために必要な作業 | 対象範囲, RPO, RTO, RLO, リストア粒度 | 1チケット |
より細かいタスクについてはタスクの中にチェックリストを作成し、そこで管理する形でも良いでしょう。
チケットの親子関係
チケットの関連性が親子というより、派生したレベルであれば親子関係は設定しません。チケット間が主従レベルの関係性の場合、親子の設定をします。
ここでいう主従レベルは子チケットが全て完了しなければ親チケットが完了しないようなものです。
2024/9/14時点でBacklogのチケットは親子関係までしか設定できません。派生レベルで親子関係を組んでしまうと孫チケットも用意したくなってしまうというのも理由の一つだったりします。
チケットのフォーマット
チケットに記載する情報の粒度はある程度揃えたいところです。
以下のようなフォーマットに従い起票します。
## 目的
- このチケットの対応を行う目的、このチケットを通して実現したいこと
## 実施事項
- [ ] このチケットで取り扱う内容。 = 完了条件。全てにチェックが付いた場合はチケットをクローズする
## 詳細
このチケットの詳細
## アウトプット
- このチケットを通して作成する予定のアウトプット
## 参考情報
- このチケットの参考情報、前提となるインプット
「リージョン障害等大規模障害時の復旧目標」という少し具体的なチケット例を出すと以下のとおりです。
## 目的
- 大規模障害の発生した場合の復旧までの目標に関わる要件を整理する
## 実施事項
- [ ] DR時のRPOについて合意する
- [ ] DR時のRTOについて合意する
- [ ] DR時のRLOについて合意する
## 詳細
### DR時のRPO（目標復旧地点）
以前ご共有いただいた参考情報(1) A.1.1 には以下のように記載がございました。
- インシデント発生の1日以内のデータを用いて業務を復旧したい
#### ご回答依頼
以下についてご回答をお願いいたします。
- DR時のRPO
ご回答例)
- DR時のRPO :
- 目標は原則24時間以内
- ただし、バックアップジョブ開始から完了までの時間、およびバックアップデータのDRサイトへの転送時間を考慮して最大48時間まで許容する
いただいた情報をもとにバックアップの取得間隔を決定いたします。
#### 要件イメージ
ご回答依頼にてご回答いただいた内容を元に、要件として以下でまとめることを考えております。
- DR時のRPOは<ご回答いただいた内容を記載>
- DR時のRPOの補足条件として以下がある
- <ご回答いただいた内容を記載>
要件のイメージ、フォーマットについて改善したい点や不明点がございましたら、お教えください。
### DR時のRTO（目標復旧時間）
以前ご共有いただいた参考情報(1) A.1.2 には以下のように記載がございました。
- 該当システムの業務的な優先度は高い
- インシデント発生後2日以内に行いたい
- ただし、人命最優先
#### ご回答依頼
以下についてご回答をお願いいたします。
- DR時のRTO
ご回答例)
- DR時のRTO : 48時間
いただいた情報をもとにActive/StandbyなどDRサイトの実装方法やDRオペレーションのフローを検討いたします。
#### 要件イメージ
ご回答依頼にてご回答いただいた内容を元に、要件として以下でまとめることを考えております。
- DR時のRTOは<ご回答いただいた内容を記載>とする
- RTOの基準はインシデントが発生したタイミングとする
- 意思決定者および切り替え担当者を複数セット定義する
- 人命を最優先とし、天災を起因とする障害によってはインシデント発生時に、DR発動判断の判断者および、DR切り替え担当者への連絡が取れない可能性があることを考慮する
- DR発動時はDRサイトにフェイルオーバーし業務を継続する
- DRサイトは単なるデータ退避場所ではない
要件のイメージ、フォーマットについて改善したい点や不明点がございましたら、お教えください。
### DR時のRLO（目標復旧レベル）
以前ご共有いただいた参考情報(1)には関連する記載はございませんでした。
#### 要件イメージ
今までのお打ち合わせの内容を踏まえて、要件として以下でまとめることを考えております。
- DR時のRLOは以下とする
- DR対象としている全てのデータが復旧している
- プライマリサイトと同じSMBファイル共有がDRサイト上でも作成されている
- Active Directoryを用いた認証によるNASアクセスができる
- クライアントが接続先のドメイン名を変更しなくともNASアクセスができる
- DRサイトでは以下の処理を行わない
- アンチマルウェアソフト連携機能の利用
- アーカイブストレージへの自動連携
- 管理アクティビティ監査ログのログ集約
- DRサイト上で実行しない上述の処理はプライマリサイト復旧後に再開する
- (申し送り事項 : それぞれの具体的な実装方法は基本設計フェーズで検討する)
- DR時の前提として以下状態となっていることとする
- AD DCが本プロジェクトの範囲外でマルチリージョンで構築されている状態
- Direct Connect等でオンプレミスとAWSネットワークの疎通が取れている状態
- Transit GatewayによってVPC間、オンプレミスネットワーク間の疎通が取れている状態
要件のイメージ、フォーマットについて改善したい点や不明点がございましたら、お教えください。
## アウトプット
- 要件定義書
## 参考情報
(1) 非機能要求一覧.xlsx
Backlogでは種別ごとにテンプレートを指定することが可能です。フォーマットとして登録しておくと良いでしょう。
チケットに設定する期日
チケット起票時のルールとして、基本的に期日は設定します。
他社、他チームへ依頼するタイプのチケットについては、依頼者側に希望日やリミットがある場合はその日を設定します。希望日やリミットの設定背景があるのであれば、その理由を添えてあげると親切でしょう。
特に希望日がない場合はその旨を記載のうえ、起票日の一週間後を仮日として設定します。
期日はやり取りをする中で適宜修正をして問題ありません。
ただし、修正をする際はサイレントで修正するのではなく、何かしらコメントを添えて修正しましょう。
チケットの優先度
チケットの優先度に応じて以下から設定します
- 高
- 中
- 低
原則中で設定をします。
高にする場合は優先度が高い理由を添えます。「取り敢えず全て高で設定する」というのはもってのほかです。
また、中であっても、定期的に見直し、スケジュールに遅延が出ているものについては適宜変更を行います。
チケットの担当者変更タイミング
そのチケットのボールを持つ主体が変わったタイミングでチケットの担当者を変更します。
例)
- 設計について質問をする時
- 提案をして、答えを求めるとき
チケット起票時に設定されたメンバーが永遠に担当者として設定される訳ではありません。
チケットに関連するチームの表現方法
チケットには担当者を1名しか指定できません。
複数チームが関わっている場合は自身にどのチケットが関連しているのか分かりづらかったりします。
そのような場合は、チケットに関連するチーム名をカスタム属性で管理します。
カスタム属性を用いることでプロジェクトに合わせた任意の属性を定義することが可能です。
例) OSのカスタム属性
抜粋 : カスタム属性の概要 – Backlog ヘルプセンター
チケット起票時にこのチケットに関連するチームを複数選択します。
コメントのやり取りをする際のルール
チケット上でコメントのやり取りをする際は、お知らせ欄に相手担当者が所属するチームおよび、自身が所属するチームを指定し、一対一に閉じたコミュニケーションとならないようにします。
チケットの状態の管理
チケットの状態は以下があります。
| 状態 | 説明 |
|---|---|
| 未対応 | チケットの対応をまだ実施していない状態 |
| 処理中 | チケットの対応を着手している状態 |
| 保留 | 何かしらの理由でチケットを保留にしている状態 |
| 処理済み | アウトプットを各リーダーや意思決定者に確認してもらえる状態 |
| 完了 | チケットとしてクローズされた状態 |
保留の状態にする際は、必ず以下を記載します。
- 保留にした理由
- 保留状態から変更される条件
- 保留期間の目処
チケットのクロージングポリシー
チケットの起票、処理済み、完了について誰が対応するかを整理します。その他の状態は特にルールは設けません。
| チケット種別 | 起票者 | 起票時の担当者 | 処理済み | 完了 |
|---|---|---|---|---|
| 課題 | 誰でもOK | 適宜 | 起票者 | 各社PM |
| リスク | 誰でもOK | 各社PM | 起票者 | 各社PM |
| その他 | 誰でもOK | 適宜 | 起票者 | 起票者 |
チケットをクローズ = 状態を完了にする際はチケット内の実施事項に記載の内容を全て満たし、チェックが入っていることとします。
抜粋 : チェックリスト記法を活用しよう – Backlog ヘルプセンター
「後工程で検討」などの申し送り事項があれば、申し送り事項が埋もれてしまうことを回避するため、その申し送り事項についてのチケットを起票してから、クローズします。
まとめ
個人的なBacklogのチケットの運用ルールを考えてみました。
プロジェクトの種類や規模感によって設定するルールは異なります。プロジェクトに合わせたルールを作成しましょう。
また、ルールは作るだけで終わりではありません。継続して参照されて、ルールに則って運用される必要があります。
実際に運用する際はプロジェクトキックオフで説明をしたり、BacklogのWikiにまとめると良いでしょう。誰にも共有せずに一人でこのポリシーに基づいて運営しようとしているだけではプロジェクトは回りません。必ずプロジェクトメンバーと共有をします。
なお、一度設定したルールを変更してはならないというルールはありません。プロジェクトを進める中で体制やプロジェクトの性質とマッチしていないものについては適宜ルールを見直しましょう。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
