Content last updated 2026-05-22

サポートチーム APAC

サポートチーム APAC のホームページ

サポートチーム APAC のハンドブックページへようこそ

このページでは、より広いサポートチームのハンドブックにまだ収まる場所が見つかっていない、 サポートチーム APAC 固有の項目を文書化しています。

その意図は、APAC サポートチームのメンバーが以下を優先することで、APAC 固有のイニシアチブ、 ポリシー、プロセス、ワークフローの結果に貢献できるようにすることです:

  1. 透明性。ハンドブックファースト を 実践し、APAC 固有の単一の信頼できる情報源を提供します。
  2. イテレーション。APAC サポートチームメンバーが、より広いサポートチームに混乱や不確実性を もたらすことなく、APAC 固有のポリシー、ワークフロー、プロセスを導入または更新できる 安全な場を提供します。

適切な場合は、このページから内容をより広いサポートチームのハンドブックの他のページに 移動することを常に検討すべきです。これがどう行われるかの例として、GitLab Support オンコールガイドのハンドブックページの APAC での考慮事項セクション を参照してください。

一般的なポリシー

サポートチーム APAC は一つのチームです

  • APAC サポートのレディネス部門のメンバーもサポートチーム APAC の一員です。
  • 個々のマネージャーの直属の部下グループを「自分のチーム」「あなたのチーム」と呼ばないようにしましょう。

サポートエンジニアリングのチームメンバーは、主に APAC サポートのビジネスアワー中に勤務すべきです

  • サポートエンジニアリングのチームメンバーは、APAC サポートのビジネスアワーの特定部分を カバーすることを目的に、特定の場所で採用されています。
  • 異なるタイムゾーンに所在している場合、チームメンバーは通常のタイムゾーンの勤務時間外で 働く柔軟性が認められますが、APAC サポートのビジネスアワー内で働き続ける必要があります。
  • 例外はケースバイケースで認められる可能性がありますが、必ずマネージャーと話し合い、 承認を得る必要があります。

サポートエンジニアは、すべての GitLab 製品プラットフォームを横断して作業できるべきです

  • サポートエンジニアは、GitLab がサポートするすべてのプラットフォーム (SaaS、Dedicated、 Self-Managed) の問題に取り組む意欲と能力を持つべきです。

サポートエンジニアは、L&R 業務以外にも時間を費やすべきです

  • サポートエンジニアは、開発、システム管理、サポートエンジニアリングなどさまざまなバック グラウンドを持って GitLab に入社します。私たちは、メンバーが持ち込んだ関連スキルを維持・ 向上できるようにすることで、チームメンバーの成長と発展を支援したいと考えています。
  • L&R の問題はしばしば挑戦的で複雑ですが、これらの実践的な技術スキルを維持するのには 適していません。L&R の問題解決に過剰に集中することは、これらのスキルの多くを衰えさせる 原因となります。
  • これを避けるため、APAC のサポートエンジニアは、業務時間の 30% を超えて L&R 業務に費やす べきではありません。

働き方の原則

働き方の原則とは、サポートエンジニアリングの業務を、お客様のニーズや事業のニーズと整合する 形で遂行できるようチームメンバーをエンパワーする行動指針です。GitLab のコアバリューと オペレーティング原則をサポート業務に適用するとどうなるかを示すのに役立ちます。

これらの働き方の原則は、GitLab のコアバリューおよびオペレーティング原則を補完するもので、 それらに従属すべきものです。両者の間に矛盾がある場合は、働き方の原則の変更や削除を提案 するためにマージリクエストを作成してください。

チケットをより速く解決する

チケットをより速く解決することは、より良い顧客成果につながり、サポートチームのメンバーが チームに必要なこと、またはメンバーがやりたいこと (新しいチケット、トレーニング、コード貢献 など) に費やす時間を解放します。このオペレーティング原則を適用する際には、以下の質問が 役立つかもしれません:

  • 自分が今やっていることは、このチケットをより速く解決するのに役立っているか？
  • プロセスを止めたり削除したりすれば、チケットをより速く解決するのに役立つか？
  • 自分のアイデアや努力は、チームとしてチケットをより速く解決することにつながるか？

このオペレーティング原則についてさらに学ぶ中で、思考やフィードバックを ディスカッション Issue に お寄せください。

簡単にする、障害を取り除く

私たちは、すべてのインタラクションを簡単にし、結果を得るために必要な労力を増やす障害を 取り除くことに努めています。これは、お客様、お互い、より広いチーム、その他生かせる場所 すべてに当てはまります。「どうすればこれをもっと簡単にできるか？取り除ける障害は何か？」 と自問できます。簡単にすることは、ロイヤルカスタマー を 作るのに役立ちます。

実例をいくつか紹介します:

  • ドキュメントページが曖昧であったり流れが悪かったりすることに気づき、適用しやすくする ためのマージリクエストを起こす。これは、お客様にもチームメンバーにも役立ち、さらなる チケットを未然に防ぐ可能性もあります。
  • 設定の問題に対処しているお客様に、現在の障害を解消した後に発生しそうな別の事項に 注意を促す。お客様が直面する前に警告すれば、別のサポートチケットを起票する必要が なくなります。
  • お客様の問題について理解した内容と、それを一緒にトラブルシューティングするための 進め方を、明確かつ簡潔にまとめてお客様に伝える。これにより、お客様は私たちが状況を 正確に把握しているかをすばやく確認でき、把握できていない場合は軌道修正してもらえます。 また、お客様にお願いするアクションがどこに向かうものかを理解してもらえるため、必要な 時間を費やす価値を理解しやすくなります。
  • 自分たちのポリシーが「いいえ」と言わせる原因になっていることに気づき、ポリシーの見直し が必要かを検討する。コンプライアンスのような場合のように、それが選択肢にならない場面も ありますが、可能な場合には何を変更できるか考える時間を取ることには価値があります。

運用メトリクスと測定

確実な低パフォーマンスの崖 (Cliff of definite underperformance)

サポートエンジニアは、過去 4 週間のうち 3 週間で取り扱ったチケット数が 8 件未満の場合、 確実に低パフォーマンスとみなされます。

サポートエンジニアがチケットに公開コメントまたは社内コメントのいずれかを残した場合、 そのチケットを取り扱ったとみなされます。

目的

サポートエンジニアのチケット生産性が、その役割の基本的な責務をもはや果たしていないと 言えるほど低い場合の明確な期待値を設定するためです。

頻度

サポートエンジニアの生産性は、週次のケイデンスでこの測定値と照合する必要があります。

測定値そのものは、四半期ケイデンスで、各会計四半期の開始時に更新されるべきです。

過去および現在のデータ

以下を示します:

  • 直前の 12 か月間 (記載された四半期の前) で観測された CoDU (確実な低パフォーマンスの崖) の数値。
  • その期間で数値がレビューされたときの通知 Issue へのリンク。
四半期崖の数値通知 Issue
FY27-Q1 (現行)7STM#7455
FY26-Q46STM#7281
FY26-Q39Q4 まで計算しないため未通知
FY26-Q29Q4 まで計算しないため未通知
FY26-Q18STM#6651
FY25-Q49STM#6468
FY25-Q39Q4 まで計算しないため未通知
FY25-Q28STM#6046
FY25-Q19STM#5821
FY24-Q48STM#5672
FY24-Q37STM#5494
FY24-Q27なし - FY24-Q3 で実施開始
FY24-Q16
FY23-Q45
FY23-Q35
FY23-Q25
FY23-Q15
設計上の考慮事項

この測定を設計する際には以下の点が考慮されました:

  • 直接的な貢献とチケットでの協働作業の両方を含めること。
  • 覚えやすく、追跡しやすいこと。
  • 通常の業務の流れの中で自然に達成され、特別な努力やフォーカスを必要としないこと。
測定値の取得

新しい会計四半期の開始時に、確実な低パフォーマンスの崖の数値を得るために 使用できる Zendesk Explore レポートをセットアップする手順は以下のとおりです。

Zendesk Explore レポートの作成

Support - Updates History データセットを使用して Zendesk Explore レポートを作成します。 以下の設定を使用します:

  1. メトリクス:
    • D_COUNT(Tickets updated)
    • D_COUNT(Tickets updated w/comment)
  2. 行:
    • Updater name
    • Updater region (オプション。APAC 以外のデータが含まれていないことを確認するために使用)
    • Update - Year
    • Update - Week of Year
  3. フィルター:
    • Ticket form - Excluded:
      • L&R (週次の L&R 生産性数値が非常に高くなる可能性があるため除外。この数値から派生する基準を設定するのは、L&R を定期的に行わないサポートエンジニアにとって不公平となる)
    • Updater tags - Selected:
      • jane_gianoutsos
      • ket_slaats
      • wei-meng_lee
    • Updater name - Excluded:
      • Anton Smith
      • Jane Gianoutsos
      • Ket Slaats
      • Wei-Meng Lee
    • Comment type - Selected:
      • Internal
      • Public
  4. 可視化タイプ: テーブル
  5. Result manipulation
    • Result path calculation - D_COUNT(Tickets updated)
      • Pattern: Percentile
      • Path: On rows

Zendesk Explore レポートからの測定値の取得

Zendesk Explore レポートで:

  1. 日付範囲フィルターを更新します:
    1. Update - Week of Year をクリック。
    2. 「Edit date ranges」をクリック。
    3. 「Date range」ペインで「Simple」タブをクリック。
    4. 「Custom」ラジオボタンを選択。
    5. 「Details level」セレクトドロップダウンで「month」を選択。
    6. 直近の FY 四半期で終わる前 12 か月の期間を選択。
    7. 「Apply」をクリック。
  2. Tickets updated カラムをソートします。
  3. 15% を超える最初のエントリを探します。
  4. その行の Ticket updated w/comment の値が崖の数値となります。
測定値のモニタリング

個々のサポートエンジニアの生産性が確実な低パフォーマンスの崖とどう 比較されているかをレポートするために、以下の Zendesk Explore レポートを使用します。

Zendesk Explore レポートの作成

Support - Updates History データセットを使用して Zendesk Explore レポートを作成します。 以下の設定を使用します:

  1. メトリクス:
    • D_COUNT(Tickets updated)
  2. カラム:
    • Update - Year
    • Update - Week of year
      • Filter > Edit date ranges > Advanced:
        • From the beginning of: 4 weeks in the past.
        • To the end of: 1 weeks in the past.
  3. 行:
    • Updater tags
      • Filter - Selected:
        • jane_gianoutsos
        • ket_slaats
        • wei-meng_lee
    • Updater name
  4. フィルター:
    • Comment type - Selected:
      • Internal
      • Public
  5. 可視化タイプ: テーブル
  6. Chart configuration > Display format:

    • D_COUNT(Tickets updated) > Advanced:

      IF (D_COUNT(Tickets updated) >= <cliff_number_here>) THEN
{
    "backgroundColor": "",
    "precision": 0,
    "scale": 1,
    "prefix": "",
    "decimalSeparator": ".",
    "italic": FALSE,
    "bold": FALSE,
    "suffix": "",
    "fontColor": "",
    "thousandsSeparator": " "
}
ELIF (D_COUNT(Tickets updated) = NULL) THEN
{
    "backgroundColor": ""
}
ELSE
{
    "backgroundColor": "#ffcccb"
}
ENDIF
測定の文書化

測定のレビューが実施されたら:

  • 以下のためのマージリクエストを作成します:

    • 数値が変わった場合は Cliff of Definite Underperformance セクション の最初の段落の数値を更新する。
    • Historical & Current Data 表の上部に現四半期の数値を新しい行として追加する。(Current) データへの参照もこの行に移動する。

  • Support Team Meta に、数値がレビューされたこと、変更があった場合はそれを記録するための通知 Issue を作成します。(以前の通知 Issue をテンプレートとしてコピーしてください)。

  • Historical and Current data 表の該当列に、通知 Issue へのリンクを追加します。

休日対応の計画

私たちは、チームの大部分に影響する 休日 に 配慮しています。以下は、グローバルな慣行とは別に対応を計画する、主に APAC チームメンバーの公式祝日です:

休日日付国備考
- オーストラリア デー
- インド共和国記念日		1 月 26 日オーストラリア、インドグループ 1 およびグループ 2 のオンコール対応の両方に影響するため、リージョン全体に影響します。
グッドフライデー (聖金曜日)移動祝日オーストラリア、NZ、フィリピン
イースターマンデー移動祝日オーストラリア、NZ、フィリピン
ANZAC デー4 月 25 日オーストラリア、NZ月曜のビジネスアワー最初の 2〜5 時間が無人になるため、前週金曜のうちに AMER に通知してください。
君主誕生日6 月の最初の月曜日NZ月曜のビジネスアワー最初の 2 時間が無人になるため、前週金曜のうちに AMER に通知してください。
君主誕生日6 月の 2 番目の月曜日オーストラリア (QLD を除く)
独立記念日6 月 12 日フィリピン6 月 12 日が月曜日の場合、オーストラリアの君主誕生日の祝日と重なる可能性があるため注意してください。

過去の計画 Issue を参照するには、[APAC] Holiday Coverage Planning Issues epic に リンクされた Issue を参照してください。

定期的な同期セッション

毎週隔週／2 週ごと毎月／不定期
  • APAC Crush
  • EMEA/APAC Crush
  • Support Team Call
  • L&R Meeting
  • Anton Sm's Office Hours
  • Julian's Kubernetes Help Sessions
  • APAC/AMER Crush
  • Release Review Party
  • APAC Office Hours
  • Social Call
  • ???

Zendesk における勤務時間の理解

以下の画像は、Zendesk における SLA タイマーや APAC リージョンのビジネスアワー との関係で、さまざまなチームメンバーの所在地における典型的な勤務時間を可視化したものです。 各セクションに表示される月にも注意してください。これは、一部の国がサマータイムを実施 していることによる違いです。

APAC 勤務時間

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License