Switchboard チーム

概要

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

リソース

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

チームメンバー

チームメンバー情報は 原文 (英語) を参照してください。

プロダクトマネージャー: Loryn Bortins テクニカルライター: Lysanne Pinto プロダクトデザイナー: 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 / Beta / Production）
  • 必要な役割（以下の役割説明を参照）
  • アクセスの正当な理由
• アプリケーションのアクセス＆プロビジョニング詳細はテックスタックの「Switchboard - GitLab Dedicated」セクションに記載されています

作業の進め方

ミーティングと定例コール

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

チームには定期的な同期コールのセットがあります:

• Switchboard Sync — このコールでは、チームメンバーの日常業務に関する重要な情報を共有し、同期的なディスカッションが必要なプロジェクト項目を議論します
• 個々のコントリビューターとエンジニアリングマネージャーの 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 ヶ月の初日以前に作成すべきです

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

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

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

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

DRI（Directly Responsible Individuals）

すべてのプロジェクトは、DRI（Directly Responsible Individual）が担当し主導します。 Switchboard はクロスファンクショナルチームですが、DRI は UX デザイン、プロダクト上の決定、フロントエンドとバックエンドの実装、その他すべての成果物を含むプロジェクトのアウトプットをデリバリーする責任を負います。専門外であっても例外ではありません。 例えば DRI がバックエンドエンジニアの場合、すべての Issue を直接実装しないかもしれませんが、他のチームメンバーがプロジェクトを遂行するために必要な情報にアクセスできることを確認するために進捗を確認する責任があります。 DRI はプロジェクトのすべての部分を直接実装するわけではありませんが、デリバリーの責任を負います。これには、エンジニアリングチーム内で Issue が優先されるよう EM と協力すること、チーム内のさまざまな機能（UX、フロントエンド、バックエンド、プロダクトなど）がプロジェクトを遂行するために必要な情報にアクセスできるよう確認すること、考えられるリスクを強調してチーム全体での調整を確保することが含まれます。

私たちは Issue を使ってアイデアについて協力し問題を解決します。Issue に取り組むすべての人は、最新の決定でその説明（SSOT）を最新の状態に保ち、フォローアップの作業が追跡されていることを確認する責任があります。DRI はディスカッションスレッドが決定に至ることを確保する責任があります。 DRI はスレッドが適時な結論に至らない場合、非同期から同期ディスカッションへの切り替えも主導すべきです。 実装前に UX デザインが合意されている場合、DRI は MR のレビュープロセスを加速させ PM と UX デザイナーの作業負担を軽減するため、MR の成果物が Figma で提供されたデザインと一致していることを確認し、適切に承認することができます。

エピック開始時に 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 は複数のエンジニアが 1 つのエピックに貢献できるよう、可能な限り Issue を並行して進められるようにします
10. エピックにフロントエンドとバックエンドの両方の実装が含まれる場合、Issue に適切なラベルを付ける
11. チームメンバーが Issue を拾い作業を開始します
12. チームメンバーは個々の Issue で進捗を追跡するためにプログレスレッドを使用します
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 は複数のエンジニアが 1 つのエピックに貢献できるよう、可能な限り Issue を並行して進められるようにします
8. デフォルトは、1 つの機能のフロントエンドとバックエンドの実装を同じ Issue に保持して、ディスカッションが集中し、実装が並行して行われ、フロントエンドとバックエンドエンジニアが同期できるようにすることです
9. 実装が API エンドポイントの変更または作成を必要とする場合、エンドポイント、パラメーター構造、返却データ構造の計画について、フロントエンドとバックエンドの間でできるだけ早く合意する必要があります（手戻りを避けるため）。
10. フロントエンドとバックエンドの実装は別々の MR でデリバリーする必要があります
11. 実装が並行して行えない場合、またはバックエンドとフロントエンドの実装の間に大きな遅延が生じる可能性がある場合、またはバックエンドが独立して価値を提供できる場合、Issue を分割してリンクで関係を明確に特定する必要があります
12. SRE の依存関係はできるだけ早く明確にし、要件を Issue に明確に文書化する必要があります（SRE 依存関係 Issue の例）

Issue とエピックの追跡

1. エンジニアはプログレスレッドを使用して非同期で進捗を共有します
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. 関連する場合は Implementation Plan で Issue の説明を更新する
   4. Issue に Progress Thread を作成して毎日更新する

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

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

3. Issue ボードの Open カラム

   1. Open カラムの上部にある Issue を確認する
   2. 各 Issue について質問して、不足している情報を特定するためのディスカッションを進める
   3. 取り組む準備ができていれば ~“workflow-infra::Ready” としてマーク、自信がなければ EM を @メンションする

Switchboard デモ

デモにより、チームメンバーは Issue またはエピックの進捗や最終アウトプットを共有できます。目的は情報共有であり、アカデミー賞級のドキュメンタリー作成ではないため、チームとして退屈なソリューションを採用しています — スクリーン録画、録画された Zoom ミーティング、または Loom のいずれかを使用します。録画へのリンクはエピックの説明に追加されます。

エピック DRI は、エピックのキックオフ時にエピックとともにデリバリーされる少なくとも 1 つのデモを特定する責任があります。例: 機能 x がデリバリーされたとき（または Issue y が完了したとき）、機能 x をデモします。 チームメンバーは、すでに予約された時間中に同期的な Q&A が行えるよう、隔週の Switchboard チームシンクの直前にデモをデリバリーするようタイミングを合わせることが奨励されています。 チームメンバーは進捗やデリバリーマイルストーンを共有するために追加のデモを作成することを選択することもできます。

Issue テンプレート

Switchboard は以下の Issue テンプレートを管理しています:

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

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

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

Switchboard チームは現在小規模なため、「承認してマージ」アプローチを採用しています:

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

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

UI に変更が提案されている場合、上記に加えて以下の追加手順に従う必要があります:

GitLab 内部ユーザーに見える UI 変更:

1. MR 作成者は MR で PM と UX デザイナーに cc しますが、彼らはレビュアーでもマージのブロッカーでもありません
2. 提案がある場合は MR 上で対応するか、MR 作成者の判断で後続の MR で対応できます
3. 最終的に PM と UX デザイナーは内部向け UI 更新のレビュアーになりますが、プロセスはまだそこまで至っておらず、キャパシティもありません
4. 実装開始前に UX やコピーについてヘルプやガイダンスが必要な場合は、実装開始前に聞いてください

外部カスタマーに見える UI 変更:

1. MR 段階での曖昧さを避けるため、UX の変更、コピーの変更、プロダクト要件など Issue の未解決の質問をすべて把握することが非常に重要です。これは UI コードの変更を開始する前に、Issue でのデザインディスカッションを具体的な結論に至らせることを意味します。
2. MR 段階で UX/プロダクトの要素が欠けている場合、DRI と Issue のアサイニーが協力して、欠けている要素を MR で解決できるか、解決のために Issue に戻す必要があるかを判断します。これは DRI の定義に従ったものです。
3. PM とデザイナーはこれらのリクエストを最優先で処理します。
4. MR を PM をレビュアーとして追加し、最新情報を提供します。このレビューは MR の進行を妨げず、PM は高優先度として処理します。理想的には、プロダクト要件は Issue で確定しておくべきです。
5. 新しいコピーの変更がある場合、テクニカルライターをレビュアーとして追加して情報を共有します。これはノンブロッキングです（コピーは理想的に Issue で合意されているべきです）。また MR に Technical Writing タグを追加してください。
6. MR で UX デザイナーを cc し、彼らがコアレビュアーになる準備ができたらチームにその旨が伝えられます

注意: MR 開設後に UI 変更（内部向けまたは外部カスタマー向け）で大幅なディスカッションが必要になった場合、そのディスカッションを解決のために Issue に戻し、MR をブロックとしてマークしてください。これらのディスカッションは高優先度で解決され、MR の進行が再開できるまで Issue を PM とデザイナーにアサインしておく必要があります。 注意:

• 私たちは、これをサポートできるチームメンバーが揃い次第、2 つのレビューが必要な典型的な「レビュアーとメンテナー」アプローチに移行することを意図しています。
• マージリクエストは承認ガイドラインに基づいて承認される必要があります。
• GitLab レビューガイドラインによると、MR 作成者がマージリクエストをマージするのが適切なシナリオがあります: ブロッキングコメントがなく、マージリクエストに必要な承認がすべてある場合、作成者またはメンテナーはマージできます。
• Switchboard プロジェクトはマージされた結果のパイプラインを使用するよう設定されており、レビュアーはマージ前にパイプラインを実行して、更新が最新のメインブランチと互換性があることを保証する必要があります。
• マージリクエストをレビューする際、レビュアーは意図を伝えるために Conventional Comment ラベルを使用してください。
  • 明確化のため、Suggestion:、Issue:、Chore: のコメントは、(non-blocking) の記述がない限り、すべてブロッキングです。
• マージリクエストには、GitLab ドキュメントにある特化ラベルを使用してラベル付けします。MR には “frontend”、“backend”、または ~“documentation” のラベルを付ける必要があります

承認ガイドライン

レビュアールーレット

レビュアールーレットは GitLab.com プロジェクトで使用する内部ツールで、コードベースの各エリアのメンテナーをランダムに選択します。メンテナーを選択するには:

1. レビュアールーレットページに移動する。
2. Switchboard プロジェクトを選択する。
3. 希望する役割を選択する: ~maintainer::frontend、~maintainer::backend、~reviewer::backend、~reviewer::frontend。
4. Spin the wheel をクリックする。

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

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

レビュアーとメンテナー

Switchboard には レビュアーとメンテナーの 2 つのグループがあります:

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

フィーチャーフラグ

目的

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

完了の定義

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

• 機能が対象テナントの 100% にロールアウトされた
• 機能が事前に合意された期間（通常エピック計画レベルで決定、最低 1 週間）安定していた
• すべてのフィーチャーフラグの条件文がコードベースから削除された

フィーチャーフラグの操作

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

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

エピックテンプレート

### DRI :levitate:
- TBC

### Participants :busts_in_silhouette:

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

### Problem to solve :thinking:

### Video Walkthrough from Product :video_camera:

### Intended users :bust_in_silhouette:

| User | Visible | Description |
|----------|----------|-------------------|
| [Internal - Operator](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/#roles) |  |  |
| [Internal - Support](/handbook/engineering/infrastructure-platforms/gitlab-dedicated/switchboard/#roles) |  |  |
| [Internal - Provisioner](/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) |  |  |
| [Internal - Read Only](https://docs.gitlab.com/ee/administration/dedicated/configure_instance.html#add-users-to-an-instance) |  |  |

### User Permissions

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

### User experience goal :goal:


<!-- Overview of user experience goal -->

### UX Design Spec :paintbrush:
- Figma Link:
- Dev mode:
- Any other details

### Proposal :bulb:

### Open Questions :question:
| Question | Added by | Discussion thread | Resolved |
|----------|----------|-------------------| -------- |
|  |  |  |  |

### Feature flags

<!-- This table should document any feature flags that were added or removed by the epic -->

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

### Further details :mag:

### Dependencies :link:

### Permissions and Security :link:

### Documentation :book:

* Publicly Accessible Documentation:

### Epic Kick-Off :ballot_box_with_check:

* [ ] Video walkthrough from Product outlining expectations
* [ ] DRI identified
* [ ] Roll out plan agreed
* [ ] External customer communication plan defined
* [ ] Copy Requirements are highlighted to the Technical Writer
* [ ] UX Requirements are highlighted UX Designer
* [ ] Issue created to track Documentation requirements
* [ ] Outstanding Questions captured in threads for resolution
* [ ] Frontend, Backend and SRE dependencies highlighted and / or unknowns highlighted

### Roll out Plan :speaker:
<!--
If visible to external customers please provide the following information:
    - What communication is required ahead of release?
      - [ ] Internal communication to account teams
      - [ ] Customer communication in release post
      - [ ] Sign off from account teams before release - this should be reserved for features with the potential to be disruptive to users
    - Will this be rolled out to customers in pieces as implemented or available internally first?
-->


### Links / references :books:

*

## Demo Description :movie_camera: #

Demo Link - see 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.