サポートステーブルカウンターパート

概要

顧客との直接的なやりとりの結果として、サポートチームは GitLab において独自のポジションを占めており、プロダクトマネージャーを顧客フィードバックにつなぎ、変更に影響を与える機会を持っています。この機会を活用するため、私たちは GitLab 内で「Stable Counterparts」として知られるモデルを採用しました。簡単に言えば、「Stable Counterpart」とは、会社内の別の機能の GitLab チームメンバーに割り当てられた永続的な連絡先です。詳細については、リーダーシップページの Stable counterparts 項目と、An ode to stable counterparts を参照してください。

期待される成果

• SSC は、より広いサポートチームと Product グループの間の橋渡しとして、双方向に情報を共有 します。
• SSC は製品フォーラムで顧客の声となり、製品の意思決定に影響を与えることができます。
• SSC は、特定の製品領域での垂直方向の主題専門知識を開発できるようになります。
• 製品チームは、さまざまな顧客のユースケースを理解・探求し、フィードバックを集める簡単な方法を持っています。

サポートチームメンバーをどのように Product と整合させるか？

• 製品の開発は セクション、ステージ、グループ に分割されており、そのページがこの役割を担う人物に関する単一の情報源です。
• すべての重要な製品グループをカバーすることを最適化したいと考えています。それに関係なく、特に複数のリージョンでカバレッジを持つために、グループに複数のカウンターパートが存在することは理にかなっている場合があります。

SSC ロールの要件

このロールで成功するには、SSC として実行する必要のある 必須タスク がいくつかあります:

1. 担当する製品グループ（複数の場合あり）の Support MBR スライド を毎月更新する
   • これは グループに関連する定期的なコミュニケーションでサポートを有効にする という目標のための強制機能を意図しています。これは毎月重要な更新がなければならないという意味ではありません — しかし、関連する更新が ある かを確認するために毎月いくらかの時間を割くことで、自動的に グループで起こっていることに警戒し関与する ことになります。
2. 対応する Issue テンプレート で CC を介してグループの新しい RFH Issue を購読する
   • サポート内の誰かがあなたのグループに助けを求めるたびに通知されます。あなたは追加のコンテキストを提供したり、自分の主題経験で同僚を自分で助けることができたり — または少なくとも自身の認識から利益を得ることができます。これにより グループで起こっていることに警戒し関与する ことができます。
3. 製品グループのチームシンクに月に少なくとも 1 回参加する
   • ミーティングに出るだけでは何もしていないように感じるかもしれませんが、一貫して見えるようにすることが 製品グループとの関係を確立し維持する 上で重要です。出席することで、つながる機会を作り、より簡単で効率的なコラボレーションの基盤を築きます。
   • 注: このアプローチはほとんどの人に推奨されますが、製品グループとタイムゾーンの個別の性質により、このタスクが妨げられる場合があります。代替案（例えばアジェンダドキュメントへの非同期キャッチアップや PM/EM との月次シンク）をマネージャーと話し合ってください。
4. 月に少なくとも 1 回、関連するチケットに関与する
   • 顧客が何を扱っているかをよく理解していないと グループに関連する定期的なコミュニケーションで Product を有効にする ことはできません。関連するチケットに関与する方法はたくさんあります。例えば、関連するサポート Pod のペアリングセッションに参加する、グループの RFH Issue に積極的に参加する、オフィスアワーをホストする、または単にチケットを自分に割り当てたり CC するなどです。

これらの各タスクは、以下にリストされている SSC ロールの目標に影響を与える力を与えるためのものです。これらの要件は SSC ロールでパフォーマンスを発揮するためのベースラインですが、超えようとする際の想像力を制限すべきではありません — うまくいく追加のことを行っているなら、それを続け、それが全員に対して形式化できるかとどう形式化できるかを考えてください。

SSC ロールの目標

製品グループとの関係を確立し維持する

私たちと同じように、製品チームは世界中に散らばっています。このため、必ずしもカウンターパートと同期できるとは限りません。

• 必須タスク: 製品グループのチームシンクに月に少なくとも 1 回参加する
• タイムゾーンが許可する場合、プロダクトマネージャーと自己紹介のコーヒーチャットを行う。
  • グループへの興味と、なぜ SSC になることを選んだかを話す。チームと製品チームの日常について尋ねる。
  • SSC への期待について製品チームに尋ねる。それらを管理し整合させる。
• 重ならないタイムゾーンにいる場合は、Slack で握手をする。
• 製品チームとのコミュニケーションのための定期的なケイデンスを確立する。
  • 特に定期的な非同期コミュニケーションモデルを維持する場合、生きている Google Docs を使うと役立ちます。それには このテンプレート を活用できます。
• 最初の自己紹介で、
  • 製品チームのチームシンクに自分を追加してもらう - シンクコールに参加できない場合はアジェンダドキュメントを読むことができます！
  • 製品チームの Slack チャンネルに参加する。
• 選んだグループにすでに SSC がいる場合は、既存のカウンターパートとコーヒーチャットをスケジュールしてもっと知ってください！

グループで起こっていることに警戒し関与する

• 必須タスク: 対応する Issue テンプレート で CC を介してグループの新しい RFH Issue を購読する
• 製品領域の主要な Issue（特に severity::1）と回避策を認識する。
• カテゴリに関連する顧客から提起されたチケットを認識し、それらを表面化して支持する。
• 今後のリリースでグループに関連する主要な変更を認識する。
• 次のメジャーリリースでの破壊的変更に関するグループの計画について、十分前（3 ヶ月／3 リリース前）に問い合わせる。顧客がどのように影響を受けるかを早期にしっかり理解するようにする。
• 製品グループの優先事項と課題を認識する。
• 製品チームがカバーする機能の使用における主題専門家になることを目指す。

グループに関連する定期的なコミュニケーションでサポートを有効にする

• 必須タスク: 担当する製品グループ（複数の場合あり）の Support MBR スライド を毎月更新する
• SWIR と関連するサポート Slack チャンネルを通じて発表を共有する。
  • SWIR と関連する Slack チャンネルの両方で、更新に [SSC Update: Group_Name: GitLab(Major).(Minor).(Patch)] のプレフィックスを使用する。この一貫性により SSC ロールの影響と重要性を強調するのに役立ちます。
• グループ関連の更新と発表は次のものになり得ます:
  • 今後のリリースに追加される新機能
  • 今後のリリースのバグ修正
  • チケットを生成する可能性が高い Issue
  • 良い貢献機会となる可能性のある Issue
  • 主要なドキュメント変更
  • 発見されたバグと適用可能な回避策
  • グループの機能に関連する可能性のある特別なプロセスまたはトラブルシューティングワークフロー
  • グループからの変更の結果としてサポートのワークフローに発生した変更
• 長期間更新がなかった場合は、「このリリースでは特に注意すべきものはありません、すべて順調です！」または「このトピックに関する素晴らしい新しいフィルタリングされていないビデオがあります」などのクイック更新を送ることを検討してください。
• 必要に応じてトレーニング資料とセッションを促進する。
• [オプション] 新しいチームメンバーとあなたのグループについてチャットし、SSC としての経験を共有するために四半期ごとのオフィスアワーを行うことを検討する。
• [オプション] あなたの製品グループの Support Preparedness Issue で DRI になるか、DRI を確実に見つけて、主要な変更が広く伝達されるようにする。

グループに関連する定期的なコミュニケーションで Product を有効にする

• 必須タスク: 月に少なくとも 1 回、関連するチケットに関与する
• チケットからの顧客フィードバックを Product チームと共有する。
  • 関連する Issue、チケット、Slack スレッドに製品チームをループする。
• 顧客の声となり、製品関連の決定と将来のロードマップに影響を与えるエージェントとなる。
• [オプション] Product チームの Slack チャンネルでの質問に手を貸す。

ロールでの作業

過去の SSC アクティビティの具体例

多くの異なるグループがあり、SSC になる単一のアプローチがすべてに完全にフィットすることはありません。グループとどう最適に作業するかを見つけるには時間がかかることがあり（あるシニアサポートエンジニアは、本当にコツをつかんだと感じるまでに 2 年以上かかったと言いました）、GitLab のすべてと同様に、それはイテレーティブで、願わくば透明なプロセスです。上記のセクションにリストされている期待事項は良い出発点ですが、強制でもなく完全でもありません。

追加のインスピレーションとして役立つ可能性のある、他の SSC が行っている事柄をいくつか紹介します:

• UX リサーチへの支援: サポートエンジニアとして、あなたは「実生活」のテストシナリオの定義とそれらの環境作成を支援するのに独自に適格です（Pipeline Authoring の例）
• Product デザインへの支援: 製品デザイナーが今後の機能を計画するとき、あなたは顧客が遭遇する可能性のある問題の種類とそれを回避する方法の観点からこれらの計画を見ることができます（Authentication and Authorization の例）
• ケイデンスで、自分が作業した、または見た関連するサポートチケットを特定し、タグ付けまたはリスト化する（Pipeline Authoring や Pipeline Execution の例）
• 適切な場合、Issue に「Support Priority」と「Support Efficiency」のタグを付ける。「Support Interest」を使って Issue を簡単に検索することもできます。
• 関連するチケットの数で 1 つ以上の高優先度 Issue を修正する影響を分析する（Authentication and Authorization と SaaS Account チケット の例）
• 製品グループに代わって顧客に連絡する: 通常 これは CMOC が行うことですが、緊急ではないケースでは、特定の顧客との特定の会話のためにドメイン固有の知識でより装備されているかもしれません（Pipeline Execution の例）
• 顧客有効化キャンペーンのレビューを提供する: Customer Success Programs Team は、顧客に GitLab の使用拡大を支援するための情報提供と教育のためのキャンペーンを作成します。SSC として、あなたは技術的正確性とチケットディフレクションに対する目で、顧客に送られるコミュニケーションをレビューする主題専門家として独自にポジションされています。詳細については SME Review Guidelines を参照してください。
• あなたの製品グループとトピック的に整合する Support Pod があるか確認し、参加を検討する — あなたは関連するチケットへの追加の露出から利益を得る理想的な候補です。

新しくオンボーディングされた SSC をサポートしメンタリングする

• SSC であることはグループに基づいて異なる経験です。しかし、新しくオンボーディングされた SSC を助ける、試行錯誤されたベストプラクティスを持っているはずです。それらをチーム内の他の SSC と共有することを検討してください。
  • @gitlab-com/support/support-stable-counterparts GitLab グループと #spt_stable-counterparts Slack チャンネルを使用して、他の SSC とベストプラクティスを共有し、プロセス変更、改善、その他のディスカッションに関する入力とフィードバックを集めます。
    • この Slack チャンネルには Slackbot のリマインダーアプリと Geekbot の両方が有効になっており、チャンネル参加者が定期的な更新を共有することを促しています。
• 実世界で何が機能して何が機能しないかに基づいてこのページとプロセスの他の側面をイテレートし、将来の SSC があなたの学びから利益を得られるようにしてください。

SSC として必要な時間を確保できない場合はマネージャーに懸念を上げる

• SSC ロールでの成功は、Product チームとの関係を構築し維持する能力に依存します。定期的にそれに時間を割く必要があります。
• 期待事項を十分に果たせないと感じる場合は、マネージャーとチャットして、時間管理と優先順位付けを手伝ってもらってください。
• 数週間離れて、再びバンド幅ができたときに戻ることは完全に問題ありません。

マネージャーからの期待事項

• SSC でもあるサポートエンジニアを管理している場合は、月に少なくとも 1 回はメンバーとの 1:1 で会話のトピックにすべきです。
  • このアクティビティの優先順位付けと時間の確保ができるようにする。
  • 懸念事項があれば解決に取り組む。
• 管理しているサポートエンジニアが SSC になることに興味がある場合は、How can I enroll and be a counterpart? のセクションを案内してください。
• SSC が長期間不在になる場合や、グループに関連する重要なイベント中の場合は、製品チームのバックフィルとして機能してください。

Product チームからの期待事項

• タイムゾーンの制約を認識し、SSC に合わせて柔軟に対応してください。
  • 新しい SSC をチームに紹介し、関連するチャンネル、ドキュメント、ミーティングに追加してください。
  • ドキュメント経由の非同期で関与するか、SSC とコミュニケーションの他のモードについて話し合ってください。
• すべての 関連する更新 を SSC と同期または非同期で共有してください。
• 各 SSC-PM の関係は異なります。あなたと製品チームに最適な方法を見つけることに取り組んでください！
• 何が機能して何が機能しないかに関するフィードバックをサポートと共有してください。
• これを最大限に活用するために期待事項を設定し管理してください！

グループに SSC が割り当てられておらず、リクエストしたい場合は、support-stable-counterpart プロジェクト で Issue を作成し、#support_team-chat と #spt_stable-counterparts で共有してください。

現在の SSC 空席

以下の表 は、現在 SSC が割り当てられていないすべてのグループとステージをリストしています。Product および／または Engineering Manager がサポートに連絡して SSC をリクエストしたグループのリストは、support-stable-counterpart プロジェクト で確認できます。

カウンターパートとして登録するには

グループのステーブルカウンターパートになることに興味がある場合、

• マネージャーと話し合います。
• サポートトレーニングプロジェクトで SSC Onboarding テンプレート を使用して Issue を開きます。
  • これは期待事項とベストプラクティスを案内する非常に短いモジュールで、半日もかからずに完了できます！
• 完了したら、ハンドブックのマージリクエストを作成します:
  • /data/stages.yml で関連するチームの ‘Support’ の下に自分の名前を追加します。正しくリンクされるようにするため、チームページエントリ用の YAML ファイル と全く同じ綴りで名前を記入してください。
  • MR をマネージャーにアサインします。

注: グループに 1 人以上の SSC がいることを推奨しているため、興味のあるグループにすでに SSC がいても、それで興味を失わないでください！

SSC Helper Agent

SSC ロールは初めてですか？まず SSC Onboarding テンプレート から始めてください。

SSC Helper Agent は、GitLab Support Stable Counterparts 向けの Glean エージェントです。最近の製品変更、次の GitLab メジャーリリースに向けた進捗、サポート準備作業、関連する Slack の議論を簡潔に把握できます。SSC が複数の情報源を手動で確認する必要はありません。

このエージェントは、SSC Helper Agent プロジェクトリクエストを受けて作成されました。このリクエストでは、GitLab の Issue、マージリクエスト、Slack の変更について、SSC が別の視点からも確認できるようにする必要性が明らかになりました。

アクセス

Glean で SSC Helper Agent を開きます。

想定ユーザー

主なユーザーは、担当する製品領域の変更を常に把握する必要がある GitLab Support Stable Counterparts です。

エージェントの機能

エージェントは実行ごとに、次の処理を行います。

• 選択したプロジェクトとラベルについて、最近の Issue とマージリクエストを確認します。
• 次の GitLab メジャーリリースに関連する進捗と未完了の作業を特定します。
• 関連する Slack チャンネルから、計画、ロールアウト、リスク、ブロッカー、インシデント、サポート準備に関する議論を検索します。
• スコープと影響に基づいて作業を分類します。
• Support のレビューが必要になる可能性のある項目を強調します。
• 関連する GitLab の Issue、マージリクエスト、Slack スレッドへのリンクを含む、簡潔で Slack 向けのステータス更新を作成します。
• Glean エージェントから Slack の DM として結果を送信します。
• SSC は、レポートを実行して Slack に送信するタイミングを選択できます。

入力

期待される出力

エージェントは、コンテンツが存在する場合に次のセクションで構成された、Slack 向けのステータス更新を作成します。

• 今週のハイライト — 注目すべき最近の変更
• 次のメジャーリリースに向けて — 今後のメジャーバージョンに関する未完了の作業と進捗
• Support の準備状況 — 顧客への回答やトラブルシューティングに影響する可能性がある項目
• Slack から — 設定されたチャンネルでの関連する議論

各セクションには、情報源となる GitLab の Issue、マージリクエスト、Slack スレッドへのリンクが含まれます。出力に基づいて行動する前に、リンク先の情報源を開いて確認してください。

制限事項

• Glean 検索、GitLab ドキュメント、ハンドブック、および該当する場合は Slack を使用して、GitLab のコンテキスト内で動作します。
• 名前、メールアドレス、本人確認情報を要求したり使用したりしません。
• Issue、MR、ユーザー名、ラベル、日付、チャンネル、URL を捏造してはいけません。不確かなフィールドは空白のままにします。
• 特定されたチャンネルが空の場合は Slack のアクティビティを報告できません。自動検出されたチャンネルは、明示的に文書化されているか、ユーザーが指定したものでなければなりません。
• 出力は Support が状況を把握するための概要であり、リンク先の情報源に代わるものではありません。
• Issue や MR を自動的に変更しません。

推奨される用途

SSC Helper Agent は次の用途に使用します。

• 製品領域に関する定期的な更新。
• SSC 同期や製品に関する議論の準備。
• Support の同僚に最新情報を伝える前に、最近の変更を確認する。
• 顧客への回答やトラブルシューティングへの影響を特定する。
• リリースのリスクと未解決の疑問を明らかにする。
• ドキュメント、ランブック、サポート準備のギャップを特定する。

エージェントを使用した新しい SSC のオンボーディング

1. 担当プロジェクトのパス（通常は gitlab-org/gitlab）、製品領域のラベル、正確に把握している Slack チャンネル名、確認対象期間（通常は 7 日）を収集します。不明な場合は、SSC、マネージャー、Product、Engineering の連絡先に確認してください。チャンネル名を推測してはいけません。
2. SSC Helper Agent を開きます。
3. フォームに用意された選択肢を使用して、プロジェクト、ラベル、確認対象期間、正確なチャンネル名をエージェントフォームに入力します。ローカルへのインストールやカスタムプロンプトは不要です。
4. 通常、ワークフローによって次のメジャーバージョンが自動的に導出されます。
5. 出力されたセクションを確認し、リンク先の情報源を開いて検証します。
6. 出力を Product、Engineering、Technical Writing とのフォローアップ、SSC 同期、Support の更新に使用します。
7. 出力が空の場合は、プロジェクトパスとラベルを検証し、days_back を増やし、正確なチャンネル名を指定して、情報源となる項目を直接調べます。

メンテナンス

SSC のワークフローまたはレポート、リリースプロセス、製品階層またはチャンネルマッピング、利用可能な検索動作、エージェントのフィールド、デフォルト、出力形式、分類ロジックのいずれかが変更された場合は、このドキュメントをレビューします。エージェントを更新するときは、変更内容を説明する短い注記とともに、このドキュメントも同じ変更で更新してください。

非グループ固有の SSC

いくつかのロールは製品グループ固有ではありませんが、すべて同じ期待事項と責務を伴います。 非グループ固有のカウンターパートは通常、関連グループに質問があり SSC が現在いない場合にも介入します。

Section	Group	Group Contact	Support Counterpart	Frequency
Finance	Accounts	TBD	TBD	N/A
Finance	Budget	Chase Wright	TBD	1x Qtr on budget + once per month
Legal	Legal	Robin Schulman	Lee Matos Val Parsons	N/A
PeopleOps	After-hire care	TBD	TBD	N/A
PeopleOps	Talent Acquisition	TBD	TBD	N/A
Performance	Performance	Stan Hu	Lee Matos	N/A
Production	.com Infrastructure	Dave Smith	TBD	N/A
Marketing	Developer Relations	John Coghlan	TBD	N/A
Marketing	Open Source Prog.	Bryan Behrenshausen	Andrew Conrad	weekly team meeting
Customer Success	Customer Success	Kristen Lawrence	TBD	weekly on Fri join EMEA scrum
Sales	Sales	TBD	Tine Sørensen	N/A
Security	Security Operations	TBD	TBD	N/A
UX	Tech Writing	TBD	Mike Lockhart	weekly team meeting
Quality	Reference Architecture	Grant Young	Simon Street	N/A

Product カウンターパート

Section	Support Counterpart
AI	TBD
Data Science	TBD
Fulfillment	John Lyttle
Sec	TBD

Group	Support Counterpart
Agent Foundations : Agent Developer
Agent Foundations : Agent Execution	Thomas Loughlin
Agent Foundations : AI Catalog
AI Clients : Developer Clients
AI Clients : Duo Chat	Duncan Harris
AI Clients : Duo Client SDK
AI Coding : Code Review
AI Coding : DAP Events
AI Coding : DAP Repository Flows
AI Platform : AI Core Infra
AI Platform : AI Model Services
Analytics : Analytics Instrumentation
Analytics : Global Search	Cleveland Bledsoe Jr Brenda Nyaringita Aysegul Acar
Analytics : Platform Insights
Application Security Testing : Dynamic Analysis	Thomas Loughlin
Create : Remote Development	Chris Stone
Create : Source Code
Database Excellence : Database Architecture	Mark Nagle Chris Nightingale Ryan Castro
Database Excellence : Database Automation	Mark Nagle Chris Nightingale Ryan Castro
Database Excellence : Database Health	Mark Nagle Chris Nightingale Ryan Castro
Foundations : Design System
Fulfillment : Cost Management	Shem Gyll
Fulfillment : Entitlements	Keven Hughes
Fulfillment : Seat Management	Alvin Gounder Chantal Lawrence
Fulfillment : Usage Visibility	Shem Gyll
GitLab Dedicated : Dedicated Migrations
GitLab Dedicated : Environment Automation	Adam Lauzon Daphne Kua Wade Jenkins Wei-Meng Lee
GitLab Dedicated : Geo	Bo Carbonell Daniel Diniz de Noronha Gabriel Yoachum
GitLab Dedicated : Import	Mike Lockhart
GitLab Dedicated : US PubSec	Wade Jenkins
GitLab Dedicated : Switchboard	Adam Lauzon
GitLab Delivery : GitLab Build
GitLab Delivery : Operate
GitLab Delivery : Release and Deploy	Amaury "Mau" Yacksmith
Growth : Acquisition
Growth : Activation
Growth : Engagement
Monetization : Platform and Infrastructure
Monetization : Subscription Lifecycle
Orbit : Context Systems	Kate Grechishkina
Package : Container Registry
Package : Package Registry
Plan : Planner Intelligence	Rocky Mongare
Plan : Planning Views
Plan : Portfolio Planning
Production Engineering : Fleet Management
Production Engineering : Networking and Incident Management
Production Engineering : Observability
Production Engineering : Runway
Security Factory : Agentic Security Flows
Security Factory : AI Security Research
Security Factory : Code Scanning	Christopher Chewa Mutua
Security Factory : Code Security
Security Factory : Composition Analysis	Ugur Dokmeci
Security Factory : Secret Detection	Christopher Chewa Mutua
Security Factory : Threat Research
Security Factory : Vulnerability Management	Gerardo Gutierrez
Security Governance : AI Control Plane
Security Governance : AI Governance
Security Governance : Compliance
Security Governance : Policy Engine
Security Governance : Policy Management	Danny Bailey
Security Governance : Security Controls	Gerardo Gutierrez
Security Platform : Abuse Engineering
Security Platform : Authentication	Jio Castillo Asmaa Hassan Ahmed Ali
Security Platform : Authorization
Security Platform : Build Security
Security Platform : Dependency Firewall
Security Platform : GATE Core
Security Platform : GATE Infra
Security Platform : Secrets Manager (Application)
Security Platform : Secrets Manager (OpenBAO)
Tenant Scale : Git	Gerardo Gutierrez Len MacRae
Tenant Scale : Gitaly	John Gaughan David Wainaina Gabriel Yoachum
Tenant Scale : Organizations	Asmaa Hassan Ahmed Ali Bruno Freitas
Verify : CI Functions Platform	Justin Farmiloe Michael Trainor
Verify : CI Platform	Mark Nagle
Verify : Pipeline Authoring	Segolene Bouly Luminus Alabi
Verify : Pipeline Execution	Paul Murray
Verify : Runner Core	Justin Farmiloe Michael Trainor

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