Issue の作業

このページでは、Customer Support Systems チームで Issue を扱う際のワークフローを説明します。トリアージ、計画、開発、検証、実装を含め、Issue が作成されてから完了するまでに進むステージを取り上げます。

このワークフローを理解すると、各ステージで何が期待されるか、誰が責任を持つか、Issue を先へ進めるためにどのようなアクションが必要かを、チームメンバーが把握できます。

Issue フローチャート

Issue の標準的な進行は次のようになります。

graph TD;
  Start--> Triage;
  Triage--> Type;
  Type-->|Bug| Bug
  Type-->|Administrative| Administrative
  Type-->|Feature| Feature
  Administrative--> AdministrativeScheduling
  AdministrativeScheduling--> AdministrativeIsItTime
  AdministrativeIsItTime-->|No| AdministrativeQueued
  AdministrativeIsItTime-->|Yes| AdministrativeDevelopment
  AdministrativeQueued--> AdministrativeIsItTime
  AdministrativeDevelopment--> Implementation
  Bug--> BugDevelopment
  BugDevelopment--> BugValidation
  BugValidation--> BugValidated
  BugValidated-->|No| BugDevelopment
  BugValidated-->|Yes| Implementation
  Feature--> FeaturePlanning
  FeaturePlanning--> FeatureScheduling
  FeatureScheduling--> FeatureIsItTime
  FeatureIsItTime-->|No| FeatureQueued
  FeatureIsItTime-->|Yes| FeatureDevelopment
  FeatureDevelopment--> FeatureValidation
  FeatureQueued--> FeatureIsItTime
  FeatureValidation--> FeatureValidated
  FeatureValidated-->|No| FeatureDevelopment
  FeatureValidated-->|Yes| Implementation
  Implementation--> Completion
  Completion--> End
  Start(Issue created)
  Triage(Triage stage)
  Type{Request type?}
  AdministrativeScheduling(Scheduling stage)
  AdministrativeIsItTime{Is it being worked in the current iteration?}
  AdministrativeQueued(Queued stage)
  AdministrativeDevelopment(Development stage)
  BugDevelopment(Development stage)
  BugValidation(Validation stage)
  BugValidated{Was it validated?}
  FeaturePlanning(Planning stage)
  FeatureScheduling(Scheduling stage)
  FeatureIsItTime{Is it being worked in the current iteration?}
  FeatureQueued(Queued stage)
  FeatureDevelopment(Development stage)
  FeatureValidation(Validation stage)
  FeatureValidated{Was it validated?}
  Implementation(Implementation stage)
  Completion(Completion stage)
  End(Issue closed)

どの Issue を誰が起票できるか

• Feature Issue は、リクエスト元または対象となるチームによって異なります。
  • Global Support チームからのリクエストは、SIG チームのメンバーが起票する必要があります。
  • US Government Support チームからのリクエストは、US Government Support のマネージャーが Issue を起票する必要があります。
  • Knowledge Base に関するリクエスト（すべてのインスタンス対象）は、Support Senior Technical Program Manager が Issue を起票する必要があります。
  • その他のリクエストは、リクエストを行うチームのマネージャーが起票する必要があります。
• Bug Issue は誰でも起票できます。
• Administrative Issue は Customer Support Systems チームのみが起票します。
• Incident Issue は Customer Support Systems チームのみが起票します。

ステージ

Issue で行う作業は、Issue がどのステージにあるかに大きく依存します。Issue がステージ間を移動するにつれて、担当者は頻繁に変わることに注意してください。

使用するステージのクイックリファレンスは次のとおりです。

トリアージ

このステージで、DRI は次を行います。

• リクエストから必要な情報を収集します（必要な場合）。
• Issue を進められるかを判断します。
• Issue が有効かどうかを判断します（正しい人が提出したか、実現可能かなど）。

その後、DRI は次を行う必要があります。

• Issue に優先度ラベルが付いていることを確認します。
• Issue に顧客ラベルが付いていることを確認します。
• Issue がロードマップ項目に関連付けられている場合、ロードマップラベルが付いていることを確認します。

これらを整えた後、DRI はリクエストタイプに応じて Issue を次のステージへ移動します。

• Administrative Issue はスケジューリングステージへ移動します。
• Bug または機能 Issue は計画ステージへ移動します。

これは次のように quickactionsを使って、1 つのコメントで実行できます。

/label ~"Customer::Support"
/label ~"Priority::3"
/label ~"RequestType::Feature"
/label ~"roadmap_item"
/label ~"Stage::Planning"

また、次のグループコメントテンプレートを使用して、作業を支援する quickactions コメントを生成できます。

• Triage -> Planning
• Triage -> Scheduling
• Triage -> Development

誤った人物が起票したリクエストをクローズする

Issue の起票を許可されていない人物が Issue を起票した場合（どの Issue を誰が起票できるかを参照）、Issue をクローズし、リクエスト者に次へ進むために必要なアクションを案内する必要があります。

これを支援するため、該当する状況に適したグループコメントテンプレートを使用します。

• Not approved -> Talk to SIG team
• Not approved -> Talk to manager
• Not approved -> Talk to Senior Technical Program Manager

これらを使用すると、Issue の関係者に誰と話す必要があるかを案内でき、Issue も適切にクローズできます。

トリアージ中の Issue をクローズする

DRI が Issue を続行できないと判断した場合、DRI は次のアクションを行います。

• 続行しない理由をコメントします。
• Issue の status を Won't do に設定します。
• Issue をクローズします。

これは次のように quickactionsを使って、1 つのコメントで実行できます。

Greetings,

After review of this issue, we have determined we will not be able to proceed on this issue.

This is due to <insert reasons here>.

Due to this, we will be closing this out. Should the above mentioned reasons be resolved, please create a **new** issue.

/status "Won't do" 

計画

このステージで、DRI は次を行います。

• Issue のゲームプランを作成し、コメントとして Issue に投稿します。
• リクエストの技術的な実現可能性を判断します。
• 必要な作業タイムラインのおおよその見積もりを判断します（検証時間を除く）。
• RICE スコアを判断します。

その後、DRI は次を行う必要があります。

• Issue にウェイト値を追加します（RICE スコアを使用します）。
• Issue にイテレーションとマイルストーンを追加します（Bug Issue のみ）。

これらを整えた後、DRI はリクエストタイプに応じて Issue を次のステージへ移動します。

• Bug Issue は開発ステージへ移動します。
• 機能 Issue はスケジューリングステージへ移動します。

また、次のグループコメントテンプレートを使用して、作業を支援する quickactions コメントを生成できます。

• Planning -> Development
• Planning -> Scheduling

RICE スコア

Customer Support Systems は、機能 Issue に対して RICE Frameworkを修正したバージョンを使用しています。

修正したバージョンで使用できる値の内訳は次のとおりです。

上記の値からスコアを取り、次の式で RICE スコアを計算します。

(Reach × Impact × Confidence) / Effort

この計算ツール（GitLab Google アカウントへのアクセスが必要）を使用すると、RICE スコアをすばやく生成できます。

計画中の Issue をクローズする

DRI が Issue を続行できないと判断した場合、DRI は次のアクションを行います。

• 続行しない理由をコメントします。
• Issue の status を Won't do に設定します。
• Issue をクローズします。

これは次のように quickactionsを使って、1 つのコメントで実行できます。

Greetings,

After review of this issue, we have determined we will not be able to proceed on this issue.

This is due to <insert reasons here>.

Due to this, we will be closing this out. Should the above mentioned reasons be resolved, please create a **new** issue.

/status "Won't do" 

スケジューリング

ここで DRI は、変更の開発タイムラインについて話し合います。これは毎週のサイクルで行います。

決定したら、DRI は Issue で次を行います。

• Issue にイテレーションを設定します。
• Issue にマイルストーンを設定します。
• 今後 Issue を進める DRI を設定します。

その後、DRI は作業開始のタイムラインに応じて Issue を次のステージへ移動します。

• 作業開始のタイムラインが現在のイテレーションの場合、Issue は開発ステージへ移動します。
• 作業開始のタイムラインが将来のイテレーションの場合、Issue はQueued ステージへ移動します。

また、次のグループコメントテンプレートを使用して、作業を支援する quickactions コメントを生成できます。

• Scheduling -> Development
• Scheduling -> Queued

Queued

Issue はイテレーションが始まるまでここに置かれます。イテレーションが始まったら、DRI は Issue を開発ステージへ移動します。

また、次のグループコメントテンプレートを使用して、作業を支援する quickactions コメントを生成できます。

• Queued -> Development

開発

このステージで DRI は、テストと検証を可能にするために必要なセットアップを行います（通常はサンドボックス内）。DRI はセットアップの変更を行う際、何を実施したかを示すコメントを追加します。使用が必須の定型形式はありませんが、一般的な推奨例は次のとおりです。

## Development notes

- Zendesk Global Sandbox
  - Triggers
    - Modified [Example trigger](LINK_TO_TRIGGER)
  - Ticket forms
    - Renamed form [Example form](LINK_TO_FORM) to `Modified Example form`
  - Webhooks
    - Created [New webhook](LINK_TO_WEBHOOK)

必要なセットアップをすべて完了したら、実行する必要があるテストスイートを含むタスク項目を Issue 上に作成する必要があります。実施する必要があるテストごとに、子タスク項目を作成します。

各子タスク項目では、次のようにします。

• 件名／タイトルはテスト対象の名前にします（例として、SLA ポリシー Priority Support - FRT をテストする場合、件名／タイトルは Priority Support - FRT にします）。
• 本文／説明には次の 3 つのセクションを含めます。
  • Prerequisites: テストを実施するための前提条件。
  • Steps: テストを行う正確な手順。
  • Expected Result: テストで期待される結果の詳細。

## Prerequisites

- A test ticket must exist that is open
- A test ticket must use the `Support Ops` form

## Steps

1. Login to [Zendesk Global's Sandbox](https://gitlab1707170878.zendesk.com/) using the end-user `[email protected]` (login details can be found [here](https://docs.google.com/spreadsheets/d/1g6lJ3AUS4EYqoBYzAdExp4v1dkzOb3GWKaMIoZikjts/edit?usp=sharing))
2. Create a new ticket using the [Support Ops form](https://gitlab1707170878.zendesk.com/hc/en-us/requests/new?ticket_form_id=12510630404508) with the following information
   - Subject: `Test from issue xxx`
   - Description: `Testing`
   - What type of product are you using: `GitLab.com`
   - Email associated with your subscription: `[email protected]`
   - Subscription number: `A-S123456789`
3. Note the ticket ID to help locate it later
4. Logout of [Zendesk Global's Sandbox](https://gitlab1707170878.zendesk.com/)
5. Login to [Zendesk Global's Sandbox](https://gitlab1707170878.zendesk.com/) as an agent account. If you do not have your own agent account, you can use `[email protected]` (login details can be found [here](https://docs.google.com/spreadsheets/d/1g6lJ3AUS4EYqoBYzAdExp4v1dkzOb3GWKaMIoZikjts/edit?usp=sharing))
6. Locate the previously created ticket in Zendesk
7. Check the events of the ticket to confirm the SLA policy is set to `Support Readiness SLA`

## Expected Result

The ticket is using the SLA policy `Support Readiness SLA`

テストスイート用の子タスク項目をすべて生成したら、親 Issue にそれを要約するコメントを追加します。次のような内容にします。

## QA Test Plan

The following child test issues were created for this MR:

- LINK_TO_CHILD_TASK_ITEM
- LINK_TO_CHILD_TASK_ITEM
- LINK_TO_CHILD_TASK_ITEM
- LINK_TO_CHILD_TASK_ITEM
- LINK_TO_CHILD_TASK_ITEM

完全なテストスイートを生成した後は、テストを実施する必要があります（または SIG チームにテスト実施の支援を依頼します）。

テストの実施中は、テストの結果と状態で子タスク項目を更新します。テストが失敗した場合は、気付いた内容と必要な変更があるかを注記またはコメントとして追加します。テストが完了した後（成功でも失敗でも）、子タスク項目をクローズします。他の人がすばやく状態を読み取れるよう、子タスク項目の件名／タイトルを :white_check_mark: または :x: で編集し、最終ステータスを示すと役立ちます。

すべてのテストと開発が完了したら、Issue を次のステージに移動する必要があります。使用する正確なステージは、作業中の Issue のタイプによって異なります。

• Administrative Issue は実装ステージへ移動します。
  • 手動で行う場合は、新しいステージへ移動する際にラベル Validation::Skipped を必ず追加します。
• Bug および機能 Issue は検証ステージへ移動します。

また、次のグループコメントテンプレートを使用して、新しいステージへの移動を支援する quickactions コメントを生成できます。

• Development -> Validation
• Development -> Implementation

検証

ここで、DRI は Issue のリクエスト者に、セットアップされた内容が期待と一致することを検証するよう依頼します。

リクエスト者が変更を検証するために必要となるすべての情報を必ず含め、検証を依頼するコメントを作成してください。

Request validation グループコメントテンプレートを使用して、これを支援する quickactions コメントを生成できます。

この時点で、Issue は検証者からの検証ステータスを示すコメントを待ちます。返答に応じて、実施するアクションが変わります。

• リクエスト者が変更を検証した場合:
  • ラベル Validation::Received を追加します。
  • Issue を実装ステージへ移動します。
• リクエスト者が変更を却下した場合:
  • ラベル Validation::Rejected を追加します。
  • Issue を開発ステージへ移動します。

また、次のグループコメントテンプレートを使用して、新しいステージへの移動を支援する quickactions コメントを生成できます。

• Validation received
• Validation rejected

実装

ここでは技術設計図を作成し、変更を実装します（MR をマージするか、システムで直接変更を行います）。

技術設計図には、変更したすべての内容を詳細に記載します。設計図を見る人は、あなたが行ったことを完全に再現できる必要があります。これは、作成したすべての MR にリンクし、MR 外で行った変更を詳述することなどを意味します。

すべての実装タスクが完了したら（デプロイを使用する項目では、MR をマージすれば十分です）、Issue を完了ステージに変更します。

完了

DRI は、すべての作業が完了したこと（デプロイサイクルの一部である場合は、本番稼働する日付）を示すコメントを追加してから、Issue をクローズします。

Issue をクローズするときは、Issue の status を Complete に設定してください。

これは次のように quickactionsを使って、1 つのコメントで実行できます。

The work on this issue has been completed at this time.

As components of the changes are tied to scheduled deployments, it will be fully live 2026-02-01.

/label ~"Stage::Completed"
/status "Complete" 

また、次のグループコメントテンプレートを使用して、作業を支援する quickactions コメントを生成できます。

• Close out a completed issue

Blocked

これは、何らかの事情により Issue のすべての進行が妨げられたときに使用する特別なステージです。これは、承認の不足、ツールの調達待ちなどに関連している可能性があります。

DRI は、更新が必要か、または「ブロック解除」できるかを判断するため、これらの Issue を毎週（計画のサイクル中に）レビューします。

• ブロック解除のすべての基準を満たしている場合、DRI は Issue を元のステージに戻します。
• 前回の更新から 1 週間が経過しても Issue をまだブロック解除できない場合、DRI はエスカレーションプロトコルに従います。
  • ブロック解除されないまま 1 週間: ブロックしている当事者に更新を Ping します。
  • ブロック解除されないまま 2 週間: 前回更新を Ping した人物のリーダーシップに更新を Ping します。
  • ブロック解除されないまま 3 週間: 前回更新を Ping した人物のリーダーシップに更新を Ping します。
  • ブロック解除されないまま 4 週間:
    • 4 週間更新がなくブロックされていることを示すコメントを追加します。
    • Issue をクローズします。

エスカレーションプロトコルの例:

• 例 1: リクエスト者が Support Engineer の場合
  • 更新なしの第 1 週では、リクエスト者に Ping します。
  • 更新なしの第 2 週では、Support Manager に Ping します。
  • 更新なしの第 3 週では、Support Director に Ping します。
  • 更新なしの第 4 週では、Issue をクローズします。
• 例 2: リクエスト者が Support Manager の場合
  • 更新なしの第 1 週では、リクエスト者に Ping します。
  • 更新なしの第 2 週では、Support Director に Ping します。
  • 更新なしの第 3 週では、VP of Support に Ping します。
  • 更新なしの第 4 週では、Issue をクローズします。
• 例 3: リクエスト者が Support Director の場合
  • 更新なしの第 1 週では、リクエスト者に Ping します。
  • 更新なしの第 2 週では、VP of Support に Ping します。
  • 更新なしの第 3 週では、CTO に Ping します。
  • 更新なしの第 4 週では、Issue をクローズします。

注記: これらのエスカレーションパスは標準的な組織階層を前提としています。ブロックしている当事者の具体的なレポートラインに基づき、必要に応じて調整してください。

Issue を Blocked ステージへ移動する

Issue を Blocked ステージへ移動するには、次を行います。

• Issue を Blocked へ移動していることを示します。
• Issue が現在置かれているステージを記録します（元に戻せるようにするためです）。
• Issue のブロックを解除するために必要な基準を記録します。
• 基準を満たしたときに実行すべきアクションを示します。

また、次のグループコメントテンプレートを使用して、作業を支援する quickactions コメントを生成できます。

• Move issue to blocked stage

Backlogged

これは、Issue がバックログに置かれている場合に使用する特別なステージです。通常、作業する意向はあるものの、遠い将来（次の 10 イテレーションより先）または不明な将来の日付に対応することを意味します。

DRI は、スケジュールできるかを判断するため、これらの Issue を毎週（計画のサイクル中に）レビューします。

• スケジュールできる場合は、スケジューリングステージへ移動します。
• スケジュールできない場合は、Backlogged ステージに留まります。

トラブルシューティング

Issue が Issue ボードに表示されない

これは、Issue 自体にボードに必要なラベル（ステージラベル、顧客ラベルなど）がないことを示します。

Issue を適切にトリアージできるよう、ラベル Stage::Triage を追加して Dylan に割り当てます。

必要な情報がない

ワークフローの途中で必要な情報が不足していることに気付いた場合:

1. 情報を依頼するコメントを追加します。
2. 遅延が 1 週間を超える場合は、Blocked ステージへの移動を検討します。
3. リクエスト者と関連するステークホルダーにタグを付けます。

ページのソースコードを見る - ページの編集 - please contribute.