サポートポッド

サポートポッドは、任意のチームメンバーグループが、取り組みたい任意の課題セットに対して、関心ベースの自己組織化グループを立ち上げるために利用できる柔軟なフレームワークです。

GitLab の製品機能セットや顧客のユースケースは、ある程度の専門化を取り入れる意義があるほど大きく複雑になっていますが、専門化を軸に業務やチームを再編するほどの規模にはまだ達していません。

サポートポッドは、ある種の専門化を今すぐ導入すると同時に、GitLab のますます複雑化するビジネスや顧客のニーズに合わせてサポートチームがスケールする中で直面する現在の運用上の課題に柔軟に適応できます。

サポートポッドをワークフローに組み込む方法については、サポートポッドと働くワークフローページ を参照してください。

ネーミング

Support Pods がこの取り組みの正式名称であり、フォーマルな書面または口頭でのコミュニケーションでは必ずこの名称で呼んでください。GitLab の文脈では「pod」という言葉がさまざまな意味で使われるため、混同や曖昧さを避けるためです。

ディレクトリ

サポートポッドを始める

開始前に

• サポートポッドが扱う活動内容を決める。
• 少なくとも 3 名のチームメンバーがサポートポッドの活動への参加をコミットしている。
• サポートポッドのリード を決定する。

立ち上げ

1. Example Pod テンプレートページを複製する。
2. 新しく作成したページをサポートポッドの名前にリネームする。
3. サポートポッドのページを、ポッドに関連する内容に修正する。
4. CODEOWNERS ファイルの ^[support-pods] セクションに自分（と他のリード）を追加する。

開始後

1. Running a Support Pod セクションに目を通し、サポートポッドの運営に関するガイドラインや推奨事項を確認する。
2. Support Week In Review でサポートポッドの新規作成を告知する。

サポートポッドの運営

サポートポッドリードの責務

各サポートポッドには少なくとも 1 名のリードを置き、ポッドの目的を定義し、その目的の達成に向けて進捗をドライブする責任を担います。

サポートポッドのリードは サポート安定カウンターパート（SSC）とは異なります。SSC はエンジニアリングの製品グループとの協働に注力し、サポートポッドのリードはサポートチーム内での協働に注力します。対応するポッドが存在する場合、SSC が同時にそのポッドのリードを務めることが理にかなっていることもあります。

サポートポッドのリードは、次の責務を担います。

• サポートポッドの活動を支援する意思のあるチームメンバーをリクルートする。
• サポートポッド内、および GitLab 組織のより広いチームメンバーとの協働を組織化する。
• サポートポッドの活動に必要なリソースやツールを入手する。
• ポッドの目的が達成された、または不要になった場合にサポートポッドを解散する。

各サポートポッドは自己組織化されているため、リードは各サポートポッドがどのように意思決定を行うかを自由に決められます。その際、GitLab Values と次の原則を念頭に置いてください。

• GitLab Handbook: Directly Responsible Individuals。
• Working on tickets サポートワークフロー: Key Principles および Priorities & Impact。

協働の手段

ここでは、サポートポッドのメンバーと協働するために使えるさまざまな手段の一覧を示します。

Zendesk

個人ビューを作成し、その設定をサポートポッドのメンバーと共有することで、メンバー全員が同じチケットビューを参照できるようにすることもできます。残念ながら現時点では、これを行う最も実用的な方法は、スクリーンショットを取得して共有するなどの手作業です。

Zendesk の共有ビューを使うアプローチは Support Team Meta Issue #6187 で検討されています。

GitLab.com の Issue

ラベルと Issue ボードを作成し、gitlab-org および gitlab-com グループ内でサポートポッドに関連するすべての GitLab.com の Issue をフィルタして表示することもできます。

Support Pods プロジェクト

Support Pods プロジェクト 内のサポートポッド用ディレクトリに、関連ファイルやドキュメントを保管することもできます。

Google Doc

GitLab.com の Issue や Zendesk チケットなど、より恒久的な手段に最終的に移行する前に、Google Doc を作成して文章での協働や保管に使うこともできます。GitLab の全員が閲覧または編集できるよう権限を設定してください。

Slack

Slack を使って協働する場合は、既存のチャンネルを活用することを検討してください。

• 顧客を対象とする場合は、顧客アカウントの内部チャンネル（#a_XYZ-internal）が適切な場合があります。
• GitLab 製品を対象とする場合は、ステージ（#s_）、グループ（#g_）、機能（#f_）チャンネルが適切な場合があります。

専用チャンネルを作成する場合は、チャンネル名のプレフィックスを #spt-pod_ としてください。

ポッド固有のペアリングセッションをチャンネル内で実施する場合は、#pairify-app でリクエストすることで、新しいチャンネルに Pairify のサポートを追加できます。

ギャップの特定とアクションによるサポートポッドの改善

課題に対応するには、サポートポッド内、または専門知識の分布における懸念領域を特定する必要があります。

ギャップや課題を特定する方法は数多くありますが、最も重要なのは、それらに対してどうアクションを取るかを決めることです。

これは網羅的なリストではありませんが、リードが成功裏に実施した方法の例です。

1. SWOT 分析
   • アクション: 「Threats」と「Weaknesses」に対して Issue を作成し、解決の DRI を割り当てる。
2. 専門知識の分析。Auth の例。
   • アクション: ベース人数のサポートポッド参加を呼びかける、対象人数の絞り込んだ未受講モジュールを設定するなど、状況に応じて変わります。
3. アンケートなどの方法でサポートチームメンバーから痛みポイントのリストを集める。
   • アクション: 実行可能な点があるかリストを分析する。それぞれに対して Issue を作成し、解決の DRI を割り当てる。

歴史的経緯

イテレーション 1

Iteration 1 は、2021 年 8 月に APAC、2021 年 9 月に グローバル でロールアウトされました。これは学習と協働を促進することに重点を置いており、Working on Tickets ワークフロー を補完するように設計されたため、サポートポッドのビューは他のすべての Zendesk ビューの後に手を付けることになっていました。

イテレーション 1 の初期フェーズの参加者からは、他のビューでの作業負荷が大きく、サポートポッドのビューに手を付ける時間が足りないという声が寄せられました。この問題を緩和するため、2022 年 2 月に サポートポッドビューを他の Zendesk ビューよりも優先する という試行を行いました。

振り返り

うまくいったこと:

• サポートポッドのビューは 1 つのトピック領域にフォーカスしているため、チケット業務の生産性が向上し、トレーニング時のハンズオン学習を促進できる。
• 全アサイン担当者と全リージョンのチケットが見えるため、助けを必要としそうなチケットを見つけやすく、協働しやすい。

うまくいかなかったこと:

• サポートポッドをチケットワークフローに組み込もうとした結果、ガイダンスがグローバルおよび地域の業務優先順位と衝突し、チケット対応の優先順位に混乱が生じた。
• ガイダンスの衝突によって、グローバルなワークフローから外れる行動を取ることに対し、パイロット参加者の一部が後ろめたさを感じた。

改善できる点:

• サポートポッドのメンバーが互いにどう協働できるかを明らかにする — 協働のほとんどは、サポートポッド内ではなく、そのチケットに取り組んでいる人との間で発生していた。
• サポートポッドのコンテンツをより焦点の絞られたものにする — たとえば Instance Management のように、フォーカスを促すには問題の種類が広すぎるビューがあった。

イテレーション 2

Iteration 2 は、チケット業務を組織する主要な仕組みとして Support Global Groups (SGGs) がロールアウトされた背景の中で、2022 年 3 月にロールアウトされました。サポートポッドは、任意のチームメンバーグループが、グループが取り組みを選んだ任意の課題セットに対して、関心ベースの自己組織化グループを立ち上げるために利用できる柔軟なフレームワークへと進化しました。これにより、SGG と共存し、補完できるようになりました。

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