Issue の作業

このページでは、カスタマーサポートオペレーションチームでの 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 は、リクエストの発信元/関係するチームによって異なります。
  • グローバルサポートチームから来るものについては、SIG team のメンバーである必要があります
  • 米国政府サポートチームから来るものについては、米国政府サポートのマネージャーが Issue を作成する必要があります。
  • ナレッジベース (任意のインスタンス) に関するものについては、サポートのシニアテクニカルプログラムマネージャーが Issue を作成する必要があります
  • その他のものについては、依頼するチームのマネージャーが作成する必要があります
• Bug Issue は誰でも作成できます
• Administrative Issue は、カスタマーサポートオペレーションチームのみが作成すべきです
• Incident Issue は、カスタマーサポートオペレーションチームのみが作成すべきです

ステージ

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

使用するステージのクイックリファレンス:

トリアージ

ここで DRI は次のことを行います。

• リクエストから必要な情報を収集する (必要な場合)
• Issue を進められるかを判断する
• Issue が有効か (正しい人物によって提出されたか、実現可能かなど) を判断する

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

• Issue に 優先度ラベル があることを確認する
• Issue に 顧客ラベル があることを確認する
• Issue に ロードマップラベル があることを確認する (Issue がロードマップ項目に紐づいている場合)

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

• 管理 Issue の場合は、スケジューリングステージ に移動します
• バグまたは機能 Issue の場合は、計画ステージ に移動します

これは クイックアクション を使用して 1 つのコメントで実行できます。次のように記述します。

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

また、次の グループコメントテンプレート を使用して、補助となるクイックアクションコメントを生成することもできます。

• 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 をクローズする

これは クイックアクション を使用して 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 にイテレーションとマイルストーンを追加する (バグ Issue のみ)

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

• バグ Issue の場合は、開発ステージ に移動します
• 機能 Issue の場合は、スケジューリングステージ に移動します

また、次の グループコメントテンプレート を使用して、補助となるクイックアクションコメントを生成することもできます。

• Planning -> Development
• Planning -> Scheduling

RICE スコア

カスタマーサポートオペレーションは、機能 Issue に対して RICE フレームワーク を独自に修正したバージョンを使用しています。

私たちが修正したバージョンの可能な値の内訳:

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

(Reach × Impact × Confidence) / Effort

このカリキュレーター (GitLab Google アカウントアクセスが必要) を使用して、素早く RICE スコアを生成できます。

計画 Issue をクローズする

DRI が Issue を進められないと判断した場合、DRI は次のアクションを取る必要があります。

• 進めない理由を説明するコメントをする
• Issue の status を Won't do に設定する
• Issue をクローズする

これは クイックアクション を使用して 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 は キュー済みステージ に移動します

また、次の グループコメントテンプレート を使用して、補助となるクイックアクションコメントを生成することもできます。

• Scheduling -> Development
• Scheduling -> Queued

キュー済み

Issue はイテレーションが開始されるまでここに留まります。イテレーションが開始されたら、DRI は Issue を 開発ステージ に移動する必要があります。

また、次の グループコメントテンプレート を使用して、補助となるクイックアクションコメントを生成することもできます。

• 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 タイプによって異なります。

• 管理 Issue の場合は、実装ステージ に移動します
  • これを手動で行う場合、新しいステージに移動する際に必ずラベル Validation::Skipped を追加してください
• バグおよび機能 Issue の場合は、検証ステージ に移動します

また、次の グループコメントテンプレート を使用して、新しいステージへの移動を補助するクイックアクションコメントを生成することもできます。

• Development -> Validation
• Development -> Implementation

検証

ここで DRI は、Issue のリクエスト元に対し、セットアップした内容が期待に合致するか検証するよう依頼します。

これは、リクエスト元に検証を依頼するコメントを行うことで実施します。リクエスト元が変更を検証するために必要なすべての情報を含めるようにしてください。

Request validation グループコメントテンプレート を使用して、これを補助するクイックアクションコメントを生成できます。

この時点で、Issue は検証者による検証ステータスを示すコメントを待ちます。あなたのアクションは、検証者から返ってきた内容によって異なります。

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

また、次の グループコメントテンプレート を使用して、新しいステージへの移動を補助するクイックアクションコメントを生成することもできます。

• Validation received
• Validation rejected

実装

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

技術設計図には、変更されたすべての内容を詳細に記述するべきです。設計図を見れば、誰でもあなたが行ったことを完全に再現できるようにしておきます。これは、作成したすべての MR へのリンク、MR 以外で行った変更の詳細などを意味します。

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

完了

DRI は、すべての作業が完了したことを示すコメント (デプロイメントサイクルの一部であれば、いつ稼働するかの日付も) を追加し、Issue をクローズします。

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

これは クイックアクション を使用して 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" 

また、次の グループコメントテンプレート を使用して、補助となるクイックアクションコメントを生成することもできます。

• Close out a completed issue

ブロック済み

これは、何かが Issue 上のすべての動きをブロックした場合に使用される特殊なステージです。これは、不足している承認、ツールの調達待ちなどに関連する可能性があります。

DRI は (計画ケイデンス中に) これらの Issue を毎週レビューして、更新が必要か、「ブロック解除」できるかを判断します。

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

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

• 例 1: リクエスト元がサポートエンジニアの場合
  • 更新なしの 1 週目、リクエスト元に依頼します
  • 更新なしの 2 週目、サポートマネージャーに依頼します
  • 更新なしの 3 週目、サポートディレクターに依頼します
  • 更新なしの 4 週目、Issue はクローズされます
• 例 2: リクエスト元がサポートマネージャーの場合
  • 更新なしの 1 週目、リクエスト元に依頼します
  • 更新なしの 2 週目、サポートディレクターに依頼します
  • 更新なしの 3 週目、サポートの VP に依頼します
  • 更新なしの 4 週目、Issue はクローズされます
• 例 3: リクエスト元がサポートディレクターの場合
  • 更新なしの 1 週目、リクエスト元に依頼します
  • 更新なしの 2 週目、サポートの VP に依頼します
  • 更新なしの 3 週目、CTO に依頼します
  • 更新なしの 4 週目、Issue はクローズされます

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

Issue をブロック済みステージに移動する

Issue をブロック済みステージに移動するには、次のことを行います。

• Issue がブロック済みに移動されることを示す
• Issue が現在いるステージを記録する (戻せるように)
• Issue のブロックを解除するために必要な基準を記録する
• 基準が満たされたときに取るべきアクションを示す

また、次の グループコメントテンプレート を使用して、補助となるクイックアクションコメントを生成することもできます。

• Move issue to blocked stage

バックログ

これは、Issue がバックログ化された場合に使用される特殊なステージです。これは通常、作業する意図はあるが、遠い将来 (次の 10 イテレーションを超えて) または不明な将来の日付に対応されることを意味します。

DRI は (計画ケイデンス中に) これらの Issue を毎週レビューして、スケジュールできるかを判断します。

• スケジュールできる場合は、スケジューリングステージ に移動されます
• スケジュールできない場合は、バックログステージに留まります

トラブルシューティング

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

これは Issue 自体にボード用の必要なラベル (ステージラベル、顧客ラベルなど) が欠けていることを示しています。

ラベル Stage::Triage を追加し、Issue が適切にトリアージされるよう Dylan に割り当ててください。

必要な情報が欠けている

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

1. 情報を依頼するコメントを追加する
2. 遅延が 1 週間を超える場合はブロック済みステージへの移動を検討する
3. リクエスト元と関係する利害関係者にタグを付ける

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