Switchboard チーム

概要

Switchboard は Dedicated Group内のチームです。私たちのミッションは、外部の GitLab Dedicated 顧客が自分のテナント環境を管理できるようにし、GitLab Dedicated オファリングをスケールアップできるように Environment Automation チームの運用負荷を削減することです。このページに明示的に記載されている違いを除き、私たちは Dedicated Groupと同じプロセスに従います。

リソース

• Switchboard ハンドブックページ
• Switchboard デモライブラリ

チームメンバー

Product Manager: Loryn Bortins Technical Writer: Lysanne Pinto Product Designer: Jesse Hoek

私たちとの連携方法

Switchboard チームと関わるには：

• GitLab Dedicated チーム Issue トラッカーで Issue を作成する

• Issue に以下のラベルを付ける：

  • component::Switchboard
  • workflow-infra::Triage
  • group::switchboard

• Issue を作成する際は、誰かに @ でメンションする必要はありません

• 注意を引きたい場合は、Dedicated グループ階層で定義されている特定のチームハンドル @gitlab-dedicated/switchboard を使用してください

• クロスファンクショナルチームとして、Switchboard は内部で @gitlab-dedicated/switchboard/frontend-engineers と @gitlab-dedicated/switchboard/backend-engineers を使用し、特定の専門知識を持つエンジニアからのインプットを求めます

• Switchboard Issue ボードはチームの現在のすべての作業を追跡しています

• Slack チャンネル

  • Switchboard 固有の質問は #g_dedicated-switchboard-teamで見つけられます
  • 私たちの Slack グループハンドルは @dedicated-switchboard-team です
  • 広い Dedicated グループに関連する Issue は #g_dedicated-teamで提起できます
  • Dedicated グループ内の他のチームには、チーム作業のディスカッション用の独自の作業チャンネルがあります：
    • #g_dedicated-environment-automation-team
    • #g_dedicated-us-pubsec

Switchboard アプリケーションへのアクセスのリクエスト

アクセスのプロビジョニングは環境によって異なります：

Test 環境

Test 環境へのアクセスは Lumos を通じてプロビジョニングされます。Test アクセスに以前使用されていた Okta グループはもう存在しません。

1. Switchboard Test の Lumos アクセスリクエストを開きます。
2. 必要なロール を指定します（下記の ロールの説明を参照）。
3. Permissions では、Other を選択します（Dedicated Team Users が特に必要な場合を除く）。
4. アクセスの正当性を記載します。

Beta および Production 環境

Beta および Production 環境へのアクセスでは、引き続き既存の Google/Okta グループプロセスを使用します：

• 以下を指定して Access Requestを作成
  • 特定の環境 (Beta / Production)
  • 必要なロール (下記の ロールの説明を参照)
  • アクセスの正当性
• アプリケーションのアクセス＆プロビジョニングの詳細は Tech Stackの Switchboard - GitLab Dedicated セクションにあります

私たちの働き方

ミーティングとスケジュールされた通話

私たちは、プロジェクト管理セクションで説明されているように、プロジェクトの Issue トラッカー内で非同期に作業することを優先します。

チームには、いくつかの定期的な同期通話があります：

• Switchboard Sync - この通話中、私たちはチームメンバーの日々の作業に関する重要な情報や、同期ディスカッションが必要なプロジェクト項目を共有します
• 個人コントリビューターと Engineering Manager との 1 対 1

個人間の Switchboard 作業を議論するための即興 Zoom ミーティングが必要に応じて作成されます。 これらのミーティングはプライベートでストリーミングされるか、録画され (1*)、GitLab Unfiltered プレイリストにアップロードされることが期待されます。 通話の結果は永続的な場所で共有されます (Slack は永続的ではありません)。これは、チームが成長するにつれて、初期段階で行われた決定がチームが大きくなった後の段階で疑問視されるため、特に重要です。

1* 録画ルールの例外は： 1 対 1 通話、プロジェクト以外の作業に関するディスカッション、当事者が録画に快適でない場合や議論されているコンテンツの性質から録画できない場合。ただし、例外があっても、プロジェクト関連のディスカッションの結果は、メインの Issue トラッカーなどの永続的な場所に記録される必要があります。

プロジェクトの追跡、計画、デリバリー

リソース

• Switchboard チームロードマップ
• Switchboard チームトップレベルエピック
• Switchboard チーム Issue ボード
• Switchboard テクニカルライティングボード
• Dedicated Issue トラッカー

四半期計画

四半期計画は、Switchboard EM と PM によって所有および推進されます。

1. EM または PM は、Dedicated の quarterly_planning Issue テンプレートを使って四半期計画 Issue を作成します。

   • Issue のタイトルを Switchboard - FYXXQY planning に設定する (XX は年、Y は四半期)
   • 理想的には、計画は少なくとも 1 四半期前に開始する必要があります。次の四半期の計画 Issue は、現在の四半期の第 2 月の 1 日目までに作成されるべきです

2. EM と PM が Issue 上で非同期にブレインストーミングします

3. 現在の四半期の第 3 月に、EM または PM は

   • チームにインプットを求める
   • すべての依存関係が関連チームに伝達されていることを確保する
   • 目標に優先順位を付ける
   • 関連エピックを文書化する

4. EM は、Grand Review で使用される四半期のデリバリーエピックを作成し、この変更を反映するように epic-summaries ボットを更新します

直接責任のある個人 (DRI)

各プロジェクトは、Directly Responsible Individual または DRIによって所有および推進されます。 Switchboard はクロスファンクショナルチームですが、DRI は、自分の専門知識に関係なく、UX デザイン、製品の決定、フロントエンドおよびバックエンドの実装と、その他のすべてのデリバラブルを含むプロジェクトの出力を提供する責任を負います。 例えば、DRI がバックエンドエンジニアの場合、すべての Issue を直接実装するわけではないかもしれませんが、他のチームメンバーがプロジェクトを達成するために必要な情報にアクセスできるように、進捗を確認する責任があります。 DRI はプロジェクトのすべての部分を直接実装するわけではないが、提供される責任を負います。これには、エンジニアリングチーム内で Issue が優先順位付けされることを確保するための EM とのコラボレーション、チーム内のさまざまな機能 (UX、フロントエンド、バックエンド、製品など) と協力してプロジェクトを達成するのに必要な情報にアクセスできるようにする、可能性のあるリスクを強調する、チーム全体での足並みを揃えるなどが含まれます。

私たちは、アイデアについてコラボレーションし、問題を解決するために Issue を使用します。Issue で作業しているすべての人は、最新の決定で説明 (SSoT) を最新の状態に保ち、結果として生じるフォローアップ作業が追跡されていることを確保する責任があります。DRI は、ディスカッションスレッドが決定に達することを確保する責任があります。DRI はまた、スレッドがタイムリーな結論を得ていない場合、同期ディスカッションへの転換を推進すべきです。UX デザインが実装前に合意されている場合、DRI は、MR デリバラブルが Figma で提供されたデザインと一致し、それに応じて承認することを確認することにより、MR レビュープロセスを加速し、PM と UX Designer の作業量を削減できます。

プロジェクトの開始時に DRI が従うエピックのリファインメントプロセスは、以下の エピックのリファインメントセクションで説明されています。DRI は、週次ステータス更新 (詳細)と、エピックにデモリンクが添付されることを確保する責任もあります (Switchboard デモを参照)。最終のステータス更新を提供し、エピックを閉じる手順は ここにあります。

エピックのリファインメント

Switchboard チームがエピックをリファインメントするプロセス：

1. エピックの DRIを特定
   • チームメンバーが志願するか、EM が特定のチームメンバーに DRI として活動するよう求めることができます
2. 不足している要件を特定
   • すべてのチームメンバーは、エッジケースを引き出すためにこの Issue のコメントで質問します
3. DRI がエピックに ~“workflow-infra::Ready” のラベルを付ける
4. DRI はエピックキックオフが完了していることを確認 - エピックテンプレートを参照
5. 期限と開始日を割り当てる
   • DRI、EM、PM が協力して、チームのキャパシティ、外部の期限、関与する作業量に基づいて期限を割り当てる
6. DRI はエピックで提供される少なくとも 1 つのデモを特定し、エピックの説明に簡単な概要を追加する (Switchboard デモを参照)。
7. 大幅なコード修正やアーキテクチャの追加の場合、DRI は開発作業が始まる前に、可能であればチームと早期に技術文書ドラフトを作成して共有します。
   1. 文書ドラフトには、新しいシステムの高レベルの技術的説明と、それがどのように機能するように意図されているかを含めるべきです
   2. シーケンス図のようなイラストの図が推奨されます
   3. 技術文書は、現在 ./docs ディレクトリの下にある switchboard プロジェクトに追加できます
8. EM または DRI が個々の Issue に ~“workflow-infra::Triage” のラベルを付ける
9. DRI は、可能な限り Issue が並行して取り組まれるようにし、複数のエンジニアが単一のエピックに貢献できるようにする
10. エピックがフロントエンドとバックエンドの両方の実装を含む場合、Issue はそれに応じてラベル付けされるべきです
11. チームメンバーは Issue を取り上げ、それらに取り組み始める
12. チームメンバーは個々の Issue で進捗を追跡するために Progress Threads を使用する
13. チームは Switchboard Sync 中に進捗を確認する
    • 提起する Issue のないエピックは読み取り専用にできる
    • 最も近い期限に基づいて、エピックのディスカッションに優先順位を付ける
14. 期限が現実的でない場合、チームメンバーは、チームが一緒にこれに対処できるように、できるだけ早く Issue にコメントする

注： 1、2、4 は並行して実行できます

Issue のリファインメント

Switchboard チームが Issue をリファインメントするプロセス：

1. Issue が作成され、リファインメントの準備ができたら、~“workflow-infra::Triage” ラベルを付ける
2. PM と EM は、Open と ~“workflow-infra::Ready” のカラムが優先されることを確認する
3. チームメンバーは Issue ボードの Open カラムの Issue を見て、明確性を高めるために Issue で質問する
4. Issue に未解決の質問がない場合、~“workflow-infra::Ready” のラベルを付けることができ、自動的に Ready カラムに移動します
5. Issue が何らかの方法でユーザーにテキストを公開する場合、technical writing ラベルを追加する必要があります。例えば、Issue が UI テキストを変更する、エラーメッセージを表示する、フィールドを追加するなどの場合です
6. Issue がフロントエンド実装を必要とする場合、frontend ラベルを使用するべきです
7. DRI は、可能な限り Issue が並行して取り組まれるようにし、複数のエンジニアが単一のエピックに貢献できるようにする
8. デフォルトは、ディスカッションが中央集中化され、実装が並行して実行され、フロントエンドとバックエンドのエンジニアが同期されるように、単一の機能のフロントエンドとバックエンドの実装の両方を同じ Issue に保持することです
9. 実装が API エンドポイントの修正または作成を必要とする場合、再作業を避けるために、エンドポイント、params 構造、戻りデータ構造の計画は、フロントエンドとバックエンドの間でできるだけ早く合意されるべきです。
10. フロントエンドとバックエンドの実装は、別々の MR で提供されるべきです
11. 実装が並行して行えない場合、またはバックエンドとフロントエンドの実装の間に有意な遅延がある可能性がある場合、またはバックエンドが独立して価値を提供できる場合、Issue を分割し、関係を関連する Issue をリンクすることで明確に特定する必要があります
12. SRE 依存関係は、Issue に明確に文書化された要件で、できるだけ早く呼び出されるべきです (SRE 依存関係 Issue の例)

Issue とエピックの追跡

1. エンジニアは、非同期方式で進捗を共有するために Progress Threads を使用する
2. Switchboard Sync の開始時に、チームは ~“workflow-infra::In Progress” または ~“workflow-infra::Triage” のラベルが付いたエピックを確認して、期限が適切であることを確認し、ブロッカーを強調する
3. エピックの DRI は、Grand Reviewの準備のために毎週水曜日にエピック説明のステータスを更新する
4. エピックの DRI は毎週期限をレビューする。エピックのステータス更新には、期限における DRI の信頼レベルと、デリバリーへのリスクが含まれるべきです

作業の選択／次に何をするか

1. Issue ボードの ~“workflow-infra::Ready” カラム

   1. Issue ボードの ~“workflow-infra::Ready” カラムから Issue を選択する
   2. Issue を自分に割り当て、~“workflow-infra::In Progress” に設定する
   3. 該当する場合、Issue の説明に Implementation Plan を更新する
   4. Issue に Progress Thread を作成し、毎日更新する

2. Switchboard チームトップレベルエピック

   1. Switchboard のトップレベルエピックを見て、最も近い期限の Issue に取り組むことを申し出る
   2. ガイダンスとして Switchboard チームロードマップを使用する

3. Issue ボードの Open カラム

   1. Open カラムの一番上にある Issue を見る
   2. 各 Issue について、不足している情報を特定するために質問しディスカッションを推進する
   3. 取り組む準備ができている場合は Issue を ~“workflow-infra::Ready” としてマークするか、それを行う自信がない場合は EM に @mention する

Switchboard デモ

デモにより、チームメンバーは Issue またはエピックの進捗または最終的な出力を共有できます。フォーカスは情報の共有であり、オスカー受賞ドキュメンタリーを作成することではないので、チームとして私たちは画面録画、録画された Zoom ミーティング、Loom のいずれかの 退屈なソリューションを使用します。録画へのリンクはエピック説明に追加されます。

エピックの DRIは、エピックがキックオフされるときにエピックで提供される少なくとも 1 つのデモを特定する責任を負います。例えば 機能 x が提供されたとき (または Issue y が Done になったとき)、機能 x をデモする。 チームメンバーは、すでに予約されている時間中に同期 Q&A が行える可能性があるように、隔週の Switchboard チーム同期の直前にデモを提供するタイミングを取ることが推奨されます。 チームメンバーは、進捗またはデリバリーマイルストンを共有するための追加のデモを作成することを選択できます。

Issue テンプレート

Switchboard は以下の Issue テンプレートを保守します：

マージリクエストレビューガイドライン

私たちは特に GitLab コードレビューガイドラインに従い、マージリクエストレビューをリクエストする際は Dedicated グループ原則に従います。

マージリクエストレビュープロセス

Switchboard チームは現在小規模なので、‘Approve and Merge’ アプローチを使用します：

1. マージリクエストのレビューの準備ができたら、1 つ以上の Switchboard のレビュアーを選択します。
   • 誰を選択するかが確実でない場合、reviewer rouletteを使ってランダムにレビューアを選択できます。
   • Issue に technical writing のラベルが付いている場合、Switchboard Technical Writer をレビューアとして追加します
2. レビューアは マージリクエストレビューのガイドラインに基づいてレビューを実行します。
3. 満足していれば、レビューアは他のレビューアが対処されていない質問や提案を持っていない限り、承認してマージします。
4. マージリクエストが必要な承認を持っている場合、レビューアはパイプラインをトリガーし、自動マージを設定します。
   • レビューアにマージ権限がない場合、マージするためにメンテナを探すべきです。

追加の UI レビュープロセス

上記に加えて、UI への変更が提案される際は、以下の追加手順に従う必要があります：

社内 GitLab ユーザーに見える UI 変更：

1. MR 作成者は PM と UX Designer を MR で cc しますが、PM と UX Designer はレビューアまたはマージのブロッカーではありません
2. 提案がある場合、MR で対処するか、MR 作成者の裁量で後の MR で対処できます
3. 最終的に PM と UX Designer は社内可視 UI 更新のレビューアになりますが、私たちのプロセスはまだそこに達しておらず、PM と UX Designer のキャパシティもありません
4. UX またはコピーに関するヘルプやガイダンスが必要な場合、Issue の実装が始まる 前に 質問してください

外部の顧客に見える UI 変更：

1. デザイン変更、コピー変更、製品要件など、Issue 上の未解決の質問を特定することは非常に重要で、MR 段階での曖昧さを避けます。これは、UI コード変更が開始される前に、Issue 内でのデザインディスカッションを通じて具体的な結論を出す必要があります。
2. MR 段階で UX/製品の部分が欠けている場合、DRI と Issue の担当者は、欠けている部分が MR で解決できるか、解決のために Issue に戻す必要があるかを決定するためにコラボレーションします。これは DRI の定義に従ったものです。
3. PM とデザイナーは、これらのリクエストを最優先で処理します。
4. PM をレビューアとして MR に追加し、最新情報を伝えます。このレビューは MR の進捗を妨げず、PM はそれを高い優先度で処理します。理想的には、製品要件は Issue で確定すべきです。
5. 新しいコピーの変更がある場合は、Technical Writer をレビューアとして追加して情報を提供し、これはブロックしません (コピーは Issue で合意するべきです)。さらに、Technical Writing タグを MR に追加します。
6. UX Designer を MR で cc し、UX Designer がコアレビューアになる準備ができたら、そのことがチームに伝えられます

注： UI 変更 (社内または顧客向け) で MR がオープンされた後にかなりのディスカッションが必要になった場合、そのディスカッションは解決のために Issue に戻され、MR はブロックされたとマークされるべきです。これらのディスカッションは解決の優先度が高く、MR で進捗を再開できるまで Issue は PM とデザイナーに割り当てるべきです。 注：

• 私たちは、これをサポートするチームメンバーがあり次第、2 つのレビューを必要とする典型的な ‘reviewers and maintainers’ アプローチに移行することを意図しています。
• マージリクエストは 承認ガイドラインに基づいて承認されるべきです。
• GitLab レビューガイドラインに従って、作成者がマージリクエストをマージするのが適切なシナリオがあります： ブロッキングコメントがなく、マージリクエストが必要なすべての承認を持っている場合、作成者またはメンテナがマージできます。
• Switchboard プロジェクトは マージ結果パイプラインを使用するように設定されており、つまり、レビューアは更新が最新の main ブランチと互換性があることを保証するために、マージ前にパイプラインを実行する必要があります。
• マージリクエストをレビューするとき、レビューアは意図を伝えるために Conventional Comments のラベルを使用すべきです。
  • 疑念を避けるために、Suggestion:、Issue:、Chore: のコメントはすべてブロッキングです。(non-blocking) ステートメントで装飾されている場合を除きます。
• マージリクエストは、GitLab ドキュメントにある 専門分野ラベルを使ってラベル付けします。MR は “frontend”、“backend”、または ~“documentation” のラベルが付くべきです

承認ガイドライン

Reviewer roulette

Reviewer roulette は、GitLab.com プロジェクトで使用される内部ツールで、コードベースの各領域に対してメンテナをランダムに選択します。メンテナを選択するには：

1. reviewer rouletteページに移動します。
2. Switchboard プロジェクトを選択します。
3. 目的のロールを選択します： ~maintainer::frontend、~maintainer::backend、~reviewer::backend、~reviewer::frontend。
4. Spin the wheel をクリックします。

GitLab コードレビューガイドライン

• マージリクエストのレビューを依頼する
• マージリクエストをレビューする
• 適切なバランス
• 品質
• パフォーマンス、信頼性、可用性
• マージリクエストのパフォーマンスガイドライン

レビュアーとメンテナー

Switchboard には、Reviewer と Maintainerの 2 つのグループがあります：

• すべての Switchboard チームメンバーは Reviewer グループに含まれます。
• チームメンバーが完全にオンボードされ、コードベースに関する知識に自信を持つようになったら、Maintainer グループに招待されます。

フィーチャーフラグ

目的

Switchboard のフィーチャーフラグは、新機能の安全で段階的なロールアウトを可能にし、問題が発生したときの迅速なロールバックのためのキルスイッチを提供します。

完了の定義

フィーチャーフラグコードは、ロールアウト成功後に削除する必要があります。 機能は、以下を満たすまで完了とは見なされません：

• 機能が該当するテナントの 100% にロールアウトされた
• 機能が事前に合意された時間 (通常はエピック計画レベルで決定され、最低 1 週間) にわたり安定している
• すべてのフィーチャーフラグ条件付きがコードベースから削除された

フィーチャーフラグを扱う

• オーナーを割り当てる - すべてのフィーチャーフラグには、その削除を担当する指定されたオーナーが必要です。オーナーは削除 Issue の担当者として設定されます。
• クリーンアップ Issue を事前に作成する - フィーチャーフラグを導入する際は、すぐに削除のためのフォローアップ Issue を作成し、実装 Issue にリンクする
• エピックで削除計画を文書化する - フィーチャーフラグを導入するエピックは、フィーチャーフラグセクションに予想される削除タイムラインとクリーンアップ基準を含める必要があります
• 短命をデフォルトとする - フラグは通常 100% ロールアウト後 1-2 週間以内に削除されるべきです

陳腐化したフィーチャーフラグは、技術的負債を生み出し、システムの意図された動作を不明瞭にします。タイムリーなクリーンアップは、コード品質の維持に不可欠です。

エピックテンプレート

### :levitate: DRI
- TBD

### :busts_in_silhouette: Participants 

- Frontend Engineer:
- Backend Engineer:
- SRE:
- Product Designer:
- PM:
- Technical Writer:
- EM:


### :thinking: Problem to solve
<!-- Describe the problem or opportunity this feature addresses. What is broken, missing, or inefficient? Focus on the "why" — what user or business need is driving this work? -->



### :bust_in_silhouette: Target users
<!-- Who will benefit from this change? Describe the Switchboard user groups affected (e.g., customer tenant admins, internal operators, internal support users, etc). Include any relevant context about their workflows.-->



### :bulb: Proposal
<!--Describe the proposed solution at a high level.-->



### :crystal_ball: Design spec

* Spec issue:
* Walkthrough video:
* Prototype:
* Figma:

### :link: Dependencies

### :book: Documentation

* Public docs:
* Internal docs:

### :key: User permissions

| User role | Visible | Notes |
|-----------|---------|-------|
| [Internal - Operator / Migration Operator](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/#roles) |  |  |
| [Internal - Hosted Runner Operator](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/#roles) |  |  |
| [Internal - Provisioner](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/#roles) |  |  |
| [Internal - Support](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/#roles) |  |  |
| [Internal - Read Only](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/#roles) |  |  |
| [External - Tenant Admin](https://docs.gitlab.com/ee/administration/dedicated/configure_instance.html#add-users-to-an-instance) |  |  |
| [External - Read Only](https://docs.gitlab.com/ee/administration/dedicated/configure_instance.html#add-users-to-an-instance) |  |  |

| Functionality | Roles with Access | Fleet-Level (Y/N) | Permission Name (set by Engineering) |
|---------------|-------------------|-------------------|--------------------------------------|
| e.g. View runner |  |  |  |
| e.g. Create runner |  |  |  |

### :flag_white: Feature flags
<!--This table should document any feature flags that were added or removed by the epic.-->

| Feature flag | Details | Removal Issue |
|--------------|---------|---------------|
|  |  |  |

### :arrow_right: Rollout and customer communications (optional)

_Use this section if the epic needs a rollout or customer communications after the build is complete. The DRI and the PM do this work together. Remove this section if it is not necessary._

- [ ] Make the rollout plan with the PM, for example internal users first and then all tenants.
- [ ] Tell the account teams before the release.
- [ ] Write the customer communications with the PM. Post them in #dedicated-customer-hub.
- [ ] If the change can disrupt customers, get approval from the account teams before the release.

### :books: Resources

### :arrow_forward: Demo

https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/#switchboard-demos

---

<!-- STATUS NOTE START -->

<!-- STATUS NOTE END -->

/label ~"group::switchboard" ~"workflow-infra::Triage"
/confidential

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