Content last updated 2026-03-04

シフトチェアの役割

シフトチェアの役割の責務と目標に関する情報

概要

EMEA Support Shift Chair の役割は、シフト時間中のサポートエンジニア間のチケット配分と調整を改善するための 3 段階の計画です。この役割は、エンジニアの自律性を維持し、自動的なチケットルーティングを避けつつ、リージョン間のハンドオーバー時の FRT 違反や長時間未割り当ての Rehomed チケットなどのキューの健全性に関する Issue に対処します。

現在のステータス: フェーズ 1 - 自発的参加
私たちは現在、実装のフェーズ 1 にあり、エンジニア主導のチケット選択と調整を伴う、自発的なシフトチェアのポジションに焦点を当てています。

このイニシアチブは Issue#6928: [EMEA RFC] EMEA Queue Health に端を発し、もともと Issue#6179: [EMEA] Define the Role and Responsibilities of Engineers in Ticket Routing, Ticket Management and First Response で提案された解決策を、シフトシステムの実践から得られた教訓と観察に基づく追加要素とともに実装しています。

課題の説明

シフトチェアの役割は、いくつかの主要な課題への対処を目的としています:

  • チケットの作業負荷分配における調整と透明性の欠如
  • 複雑なチケットが後のシフトやリージョンに何日も流れてしまう
  • 適切なチケットの優先順位付けを確保するためにマネージャーが介入しなければならない

役割の目的

シフトチェアは、キューの可視性をコラボレーションレベル（Slack）にもたらし、エンジニアがキャパシティと作業負荷について透明性を保ちながら、チケット選択を調整できるようにします。個人の判断を置き換えるのではなく、この役割は、顧客満足度を損なうことなく、エンジニアのチケット選択における選択肢を維持しつつ、キュー管理に対する透明で調整されたアプローチを作り出します。

主要な責務

1. キュレーション (キューの管理)

シフト開始時 に、シフトチェアスクリプトを実行し、以下の基準を使って優先順位付けされたチケットリストを特定、ソートして公開します:

Priority 1 (即時 FRT): NEW チケットで、シフト時間 +1 時間以内に FRT SLA が違反済みまたは違反しそうなもの*
Priority 2 (転送): すべての OPEN EMEA チケット、別名 「Rehomes」または「Handovers」
Priority 3 (営業時間): その他の EMEA 時間 +1 時間以内のすべての NEW または OPEN EMEA チケット* Priority 4 (SLA がない、または営業時間外): その他のすべての NEW EMEA チケット

*追加の 1 時間はシフトとリージョンのハンドオーバーをカバーします

期待される結果: 十分なエンジニアが利用可能でキャパシティがある限り、Priority 1、2、3 の各チケットは、シフトの終わりまでに担当者が割り当てられているべきです。

2. 調整 (チームファシリテーション)

シフト開始時 に、チケット割り当てのための調整をファシリテートします:

  • キュレーションされたチケットリストをすべてのシフト参加者と共有します
  • エンジニアが興味と専門性に基づいてチケットに志願できるようにします
  • 柔軟な調整フォーマットを可能にします - 自由に試してください！
  • 積極的なアウトリーチ: チケットに即座のボランティアがいない、または SLA/SLO が危険にさらされる場合、以下の組み合わせに基づいて特定の個人に ping します:

透明性の要件: シフトメンバーは、優先リストからどのチケットを取るかを示すべきです。チームメンバーがチケットを取れない、またはその日チケットの優先順位付けをスキップしたい場合は、調整スレッドで明示的に言及するべきです。

目標と成功指標

主要な目標

  • 95% FRT コンプライアンス: FRT SLO に違反する前に最初の応答を送る
  • 完全な割り当てカバレッジ: EMEA 時間 +1 以内に違反済みまたは違反しそうなすべてのオープンな EMEA チケットには担当者が割り当てられているべきで、理想的には NRT 違反前

追跡すべき主要な成功指標

  • リージョン間のハンドオーバー時の FRT 違反の削減
  • Rehomed チケットが新しい担当者を得るまでの時間の短縮
  • 作業負荷の可視性と調整の改善
  • キューの優先順位付けにおけるマネジメントの介入の削減
  • NRT SLO の全体的な改善

チケット選択ガイドライン

シフト時間中

  • 各エンジニアは、毎日 EMEA 優先リストから少なくとも 1 件のチケットを割り当てるよう努力するべきです。可能であれば、Rehomed 用に 2 件目のチケットを取ります
  • シフト時間内に違反する FRT および 転送されたチケット は、他のチケットよりも優先されるべきです
  • 透明性: 優先リストからどのチケットを取るかを伝えてください。チケットを取れない、または優先順位付けをスキップしたい場合は、簡潔な説明、または絵文字だけでもよいので、適切なレベルの詳細さで示してください。

シフト時間外

  • シフト時間のキャパシティを確保するため、チケットの割り当ては避けるべきです
  • シフト時間外にチケットを取る場合は、関連するシフトチャンネルに通知してください

日々のワークフロー

シフト開始のルーチン (最初の 30〜60 分)

  1. 優先リストの生成

    • チケット特定スクリプトを実行する（最初は手動、フル自動化は計画中）
    • 結果をレビューし、定義された優先順位と一致することを確認する
    • 各日には、少なくとも（利用可能なエンジニア数 - 2）件のチケットが必要ですが、シフトに参加しているエンジニアの数を超えるチケットは含めないでください。
      • 優先条件は常に緩和して、緊急度の低いチケットを含めることもできますが、特定のシフトに過剰な負荷をかけることも避けるべきです。

  2. 公開と調整

    • キュレーションされたリストをシフトチャンネルで共有する
    • 自発的な選択期間を設ける (30〜45 分)
    • チケットの複雑さや割り当てに関する議論をファシリテートする

  3. 更新

    • チケットが割り当てられるたびに、リスト内の対応するチケットの前に「(@SlackHandle)」を追加して、そのチケットを取ったエンジニアの名前でリストを更新する
    • 最初の 1 時間（シフトの半分）の後、シフトの主要な責務を達成するためのベストエフォートとして、Priority 1 から 3 のチケットに対して以下の「ルーティングサジェスチョン」ワークフローの利用を検討する。

  4. ルーティングサジェスチョン

    • 未請求の高優先度チケットがある場合:
      • チケットに対して ZenDuo の Product Category Prompt を実行する
      • Skills by Subject ページを使って、関連する Product Categories をエンジニアにマッチングしてみる
      • 関連する専門性を持つエンジニアを、残っている未割り当てチケットごとにルーティングサジェスチョンとしてタグ付けする

  5. 違反に近い FRT のモニタリング

    • New ステージでかつ FRT 違反まで 1 時間以内のチケットについて:
      • シフトの最高優先度としてフラグを立てる
      • 違反まで 45 分: シフトの全メンバーに支援を求めて ping
      • 違反まで 30 分: @support-manager-oncall に ping してエスカレーション

実践的な実装例

このシステムを実践した実例を以下に示します:

Shift Chair Trial

ツールとリソース

現在のツール

将来の自動化

キュレーションプロセス（優先チケットの特定とソート）は、調整とハンドオーバーの側面を維持しながら、手動の労力を削減するために自動化が計画されています。

ローテーションと参加

参加モデル

シフトチェアとしての参加は、すべてのチームメンバーに開かれています。チェアは負荷を分担し、改善アイデアの多様性に触れる機会を増やすために、ボランティアの間でローテーションされます。

一般的なシナリオと解決策

シナリオ: 優先チケットにボランティアがいない

  1. チケットに対して ZenDuo の Product Category Prompt を実行する
  2. Skills by Subject ページを使って、関連する Product Categories をエンジニアにマッチングしてみる
  3. 関連する専門性を持つエンジニアを、残っている未割り当てチケットごとにルーティングサジェスチョンとしてタグ付けする
  4. マッチがない、またはマッチしたエンジニアがチケットを取れない場合は、次のシフトに残す

シナリオ: 優先チケットを取れる L&R エンジニアがいない

L&R チームの Slack チャンネル #support_licensing-subscription に、利用可能なエンジニアが割り当てを取れるようにチケットへのリンクを ping します。

継続的改善

フィードバックの収集

  • 自発的なシフトチェアと広範なチームからのプロセスの有効性に関する定期的なインプット
  • マネジメントによる SLA/SLO のパフォーマンスとキャパシティパターンのレビュー
  • 成功した実践と課題のドキュメント化

プロセスの進化

このハンドブックは初期の実装を表しています。システムが成熟するにつれて:

  • チケットのキュレーションのための自動化が追加されます
  • 調整方法はチームのフィードバックに基づいて洗練されます
  • 成功指標はパフォーマンスデータに基づいて調整されます
  • 他のキュー管理ツールとの統合が開発される可能性があります
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License