ワーキンググループ

GitLab の他のグループと同様に、ワーキンググループはさまざまな職能を持つメンバーで構成されます。詳細をご確認ください！

ワーキンググループとは？

GitLab の他のグループと同様に、ワーキンググループはさまざまな職能を持つメンバーで構成されます。ワーキンググループがユニークなのは、明確なロールと責任が定義されており、高いビジネスインパクトをもたらす目標を迅速に達成するという使命を担っている点です。ワーキンググループは目標が達成された時点（終了基準によって定義）で解散され、GitLab に不必要な官僚主義が蓄積されないようにします。

ワーキンググループは、非同期での作業が遅すぎる場合に、迅速に完了させる必要がある重要な業務に活用されます。

ロールと責任

必須ロール

ワーキンググループ DRI（直接責任者）

これはワーキンググループの成功に対して最終的な責任を負う人物であり、ファシリテーターの役割も担います。ファシリテーターはミーティングを運営し、ワーキンググループの運営効率と成功をサポートする責任を持ちます。

このロールの責任の詳細については、以下のプロセスをご参照ください。

エグゼクティブスポンサー

プロジェクトへの関与を維持し、必要に応じてワーキンググループ DRI をサポートし、エスカレーション（必要な場合）をサポートする責任を持つ E-Group メンバーです。結果に最も関心があるか、成果に責任を負う E-Group メンバーがこの役割を担います。通常、ワーキンググループ DRI が所属する職能を担当する E-Group メンバーが務めます。E-Group スポンサーは常に情報を把握しておく必要があります――特にタイムラインやスコープの変更、調整が必要な相互依存関係、または意見が求められる場合においてです。通常、ワーキンググループのミーティングに出席します。

E-Group スポンサーは、ワーキンググループの成功に必要な資金調達においてワーキンググループ DRI を支援する責任を持ちます。予算の権限は E-Group レベルにあるため、これは重要な役割です。

また、E-Group スポンサーは E-Group 全体へのブリッジとして重要な役割を果たします。関連するトピックや更新情報を E-Group に報告・共有すべき適切なタイミングを判断するサポートを担います。

ファンクショナルリード

ワーキンググループに対して自分の職能全体を代表する 1 名以上の人物で、ワーキンググループの Slack チャンネルを定期的に監視し、アクションアイテムの Issue を作成し、作成した Issue の DRI として機能し、ミーティングに積極的に参加し、ワーキンググループの目標達成に向けた機会に自ら志願し、ミーティングに同期または非同期で定期的に出席し、ワーキンググループから学んだ情報を職能チームと共有し、アクションアイテムに自発的に取り組み、職能チームからフィードバックを収集してワーキンググループに持ち帰ります。

オプションのロール

メンバー

特定分野の専門家で、定期的にミーティングに同期または非同期で出席し、ワーキンググループの Slack チャンネルを定期的に監視し、ワーキンググループから学んだ情報を同僚と共有し、同僚からフィードバックを収集してワーキンググループに持ち帰ります。メンバーは特定のワークストリームや活動の DRI を務めることもあります。

ガイドライン

ワーキンググループの増殖を防ぐために、エグゼクティブスポンサーが必要です。
1 人の人物が同時に複数のワーキンググループのファシリテーターを務めるべきではありません。
一部のワーキンググループへの参加は、多大な時間的コミットメントを必要とします。参加者は自分のロールと期待される成果を明確に把握し、時間と作業量を管理し、ロールを果たすことや成果物を提供することが困難に感じた場合は速やかにエスカレーションしてください。
ワーキンググループ内で OKR を持つ人はすべて、その取り組みに OKR を連携させることを強くお勧めします。

プロセス

ワーキンググループのマッピング

最初のステップは、ワーキンググループの成功に必要な活動の種類を丁寧にマッピングすることです。DRI は誰を巻き込むかについての推奨を得られますが、まずは実施すべき業務についての見解を持つべきです。

ワーキンググループの設立

DRI はワーキンググループのメンバーとなる主要な人物を特定してください。以下のいくつかの方法で行うことができます：

エグゼクティブスポンサーに連絡し、この取り組みのサポートを提供できる組織全体のリード/担当者を特定してもらう
この取り組みへのサポートが必要とされるステージのファンクショナルリードに連絡する
すでにこの取り組みで協力している人物を含め、継続したいかどうか、または引き継ぎを推薦する人物がいるかを確認する
- クロスファンクショナルなデータ収集・分析が必要な場合は、サポート可能なデータ DRI を特定してください。例として、ストレージ制限イニシアチブで実施したことをご参照ください
各ステージ/チームの Slack チャンネルで協力を募る。機能一覧（グループ別）ページが参考になる場合があります

例えば、このワーキンググループが最終的にカスタマーコミュニケーションを含む場合、カスタマーサクセス部門からの適切な代表者がチームに含まれており、その代表者が今後数週間および四半期において個人とチームへの要求を明確に把握していることを確認してください。

ワーキンググループのチーム規範の確立

DRI はワーキンググループの運営方法を確立してください。以下の内容が含まれます：

ミーティングの頻度
世界中のチームメンバーへのインクルーシビティ
ステータストラッカーに使用するステータス更新の頻度
全体的なプロジェクト管理（ミーティングのスケジューリングとプロジェクトステータスの追跡を含む）の DRI の指定
コラボレーション用の Slack チャンネルを作成する。Slack チャンネル名は #wg_ プレフィックスで始めること
目標達成を確認するためのメトリクスを収集する
インクリメンタルな進捗をもたらすべき活動を整理する
イテレーションをリリースし、メトリクスを追跡する
結果を伝達する

ワーキンググループは、GitLab のミーティング規範に従ってください。内容は以下のとおりです：

アジェンダを用意する
すべてを文書化する
ミーティングの終わりにアクションアイテムを確認する時間を設ける
アクションアイテムをマージリクエストまたは Issue に変換する

ワーキンググループは高パフォーマンスチームの構築に記載されているガイダンスに従ってください。

ワーキンググループのミーティング

DRI はワーキンググループに適切なケイデンスでミーティングを設定してください。緊急度・重要度および関連するタイムラインに応じて判断します。ミーティングのケイデンスは、進捗のスピードと、調整や意思決定に必要な同期タッチポイントの量に合わせてください。

例えば、意思決定が承認済みで変更が予想されない高優先度プロジェクトに携わっている場合があります。メンバーは自分のロールを理解し、Issue やエピックで追跡された活動を着実に進めています。この場合、2 週間に 1 回以上のミーティングは不要かもしれません。一方、毎日新しい成果物がレビューされ、迅速な意思決定が求められるプロジェクトに参加している場合もあります。この場合、週に 1 回以上のミーティングが適切です。

すべてのミーティングにはアジェンダが必要です。ライブドキュメントミーティングでは、Google ドキュメントがアジェンダでのミーティングノート取得の推奨ツールです。スタートとしてスタンドアップ / ワーキンググループテンプレートをご使用ください。次のセッションのアジェンダがない場合は、ミーティングをキャンセルしてください。

ハンドブックにページを作成する

ワーキンググループはハンドブックの現在の working-groups フォルダにページを作成し、以下のアクティブなワーキンググループのリストに追加してください。既存のワーキンググループを引き継いだ場合は、ページが最新の状態であることを確認してください。これにより、他のチームメンバーがあなたの取り組みについて知りたい場合の参照先が確保されます。GitLab では公開ハンドブックファーストを実践していますが、作業内容が非公開の場合は、コンテンツを SAFE に保つために内部ワーキンググループフォルダをご使用ください。

ハンドブックページに含めるべき項目：

イニシアチブ名
概要：これは何か、なぜ実施するのか？
終了基準を含む望ましいビジネス成果
リスクと相互依存関係を明確に示す。軽減策を示し、相互依存関係が認識され、計画の一部として対処されていることを確認する
主要なマイルストーンとその提供タイムライン
関与者。DRI とエグゼクティブスポンサー（いる場合）が誰であるかを含めること。すべての参加者の責任が明確に文書化され、理解されていることを確認すること

可能な限りハンドブックファーストで作業し、マージリクエストから始めてください。複数の人がリアルタイムでコラボレーションする必要がある提案の作成には Google ドキュメントを使用できます。また、資料が限定アクセスの場合にも検討できます。機密性の懸念が解消され、リアルタイム編集が重要でなくなったら、コンテンツをマージリクエストに移行し、Google ドキュメントをマージリクエストへのリンク付きで非推奨としてマークしてください。

Issue とエピックを作成する

Issue を使用して、ハンドブックページで定義された作業を含む、定義された作業を示してください。ラベルを使用して進捗を示し（ブロック済み、進行中、未着手）、作業のフェーズを強調してください。Issue は何をする必要があるか、影響を受けるチームの DRI は誰か、期待される成果を明確にする必要があります。これはすでに進行中の作業と新たにスコープされた作業の両方に適用されます。Issue を通じて変更を行ったり新しいやり方を実施することを決定した場合は、ハンドブックにその変更を文書化してください。

進捗の概要としてIssue ボードを使用することもできます。

作業が具体化されサブプロジェクトが特定されるにつれて、一部の Issue は同じサブプロジェクトの一部である他の Issue をグループ化するためにエピックに昇格させるべきです。ワーキンググループに関連する各サブプロジェクトに Issue またはサブエピックを用意することがベストプラクティスです。サブエピックを 1 つの親エピックの下にグループ化して、時間の経過とともに進捗を追跡してください。アイテムが完了したら、Issue やエピックを閉じ、ハンドブックに進捗を文書化してください。

ハンドブックと同様に、Issue やエピックはデフォルトで公開にしてください。Issue やエピックに内部に留めるべき資料が含まれている場合は、機密にするか、非公開のプロジェクトに置いてください。Issue やエピックを公開のまま維持できるが、内部専用のコメントを追加する必要がある場合は、内部メモを使用して Issue を公開に保ちながら機密のやり取りができます。

ワーキンググループは、最大の効率を実現するプロジェクト、グループ、サブグループの Issue やエピックを活用してください。GitLab 社関連プロジェクトのGitLab.com グループ内で運営されるワーキンググループには、以下のリソースが利用可能です：

ワーキンググループスコープのラベル（各ワーキンググループ専用）
- WorkingGroup::<NewWorkingGroupName>
Issue やエピックのステータス追跡のためのワーキンググループステータスラベル
- wg-status::Not Started
- wg-status::Ready
- wg-status::In Progress
- wg-status::Blocked
- wg-status::Complete
ワーキンググループの Issue、エピック、プロジェクトを整理するためのworking-groupsサブグループ

ステータス、更新、変更の伝達

マルチモーダルコミュニケーションを使用して成果を伝達してください。例えば、主要なエピックを使用して現在のステータスと更新情報を伝達できます。エピックの説明は最新のステータスで更新し続け、更新の記録をエピックへのコメントとして残してください。コメント内で該当する E-Group スポンサー（いる場合）および関連する DRI を @ メンションでタグ付けしてください。また、現在のステータスコメントへのリンクを、チーム規範の確立で作成した Slack チャンネルに @ メンションで関係者に投稿してください。

ワーキンググループの方向性や計画への重要な変更はハンドブックページに記載するべきですが、一般的なステータスや更新情報はエピックに保持することができます。

タイムラインやスケジュールの変更は、下流に波及する影響を持つ可能性があります。これらの変更をすべての関連ステークホルダーにできるだけ早く伝えることが重要です。日程の変更は、これらの変更を通じてユーザー・顧客をコミュニケーション・ガイドするタスクを担うチームメンバーに悪影響を与える可能性があります。

信頼関係の構築

ワーキンググループが結成されたら、チームメンバー間で信頼を築くことが重要です。これにより、ワーキンググループはより効果的に機能し、信頼性を構築し、必要に応じてチームメンバーが互いに脆弱性を見せられるようになります。作業自体を進めることが重要であるのと同様に、コーヒーチャット、活動、ゲームなど、ワーキンググループメンバーが個人的なつながりを築けるような時間を設けることも重要です。

ワーキンググループの解散

ワーキンググループが目的を果たしたら、解散の時期です。

祝いましょう。ワーキンググループを閉じられることは祝うべきことです！
このページの過去のワーキンググループセクションにワーキンググループを移動させる。
ワーキンググループのページを閉鎖日と関連する成果物で更新する。
Slack チャンネルをアーカイブする。
定期的なカレンダーミーティングを削除する。

限定アクセスコミュニケーションのためのプロセス修正

私たちは透明性が価値観の 1 つであるため、デフォルトで物事を公開にします。公開できないものもあり、社内に限定されるか、社内でも限定アクセスのものもあります。非公開リストにない場合は、外部に公開すべきです。ワーキンググループが非公開リストに記載されている内容に取り組んでいる場合、情報をより広く共有できると判断されるまで、ワーキンググループメンバーは情報へのアクセスを制限する注意が必要です。上記プロセスのいくつかの修正点を以下に示します：

準備
1. 限定アクセス命名規則を使用して適切なプロジェクト名を決定する。
2. 概要ページを作成し、アクティブなワーキンググループにリンクを追加する。限定的な情報を共有できますが、ファシリテーター、エグゼクティブステークホルダー、ファンクショナルリードを含む主要なチームメンバーを記録してください。
3. ハンドブックで作業する場合は、ページを機密にするか、限定アクセスの新しいプロジェクトに置くかを評価する。内部ハンドブックでの作業を検討する。公開前に情報を繰り返し更新する必要がある場合や、ステージング環境で MR ブランチを作成する必要がある場合にこれを使用します。E-Group 以外のメンバーには、プロジェクト固有の基準で一時的なアクセスが許可される場合があります。
4. ワーキンググループメンバーおよびプロジェクトに参加または情報提供されている他のメンバーのリストを維持する。このリストはすべての参加チームメンバーが利用できるようにしてください。何を伝達できるかを理解していることが確認されるまで、このリストにメンバーを追加しないでください。
5. 各ワーキンググループメンバーが外部および内部に伝達できる内容を理解していることを確認する。
6. プロジェクトに直接携わっているメンバーを含むプライベート Slack チャンネルを持つ。
7. アジェンダを特定のメンバーに限定する。
結果の伝達
- 関係者が重要な出来事についてのコンテキストを持ち、調整されているよう、直接のワーキンググループメンバーや他の主要なステークホルダーに結果と進捗を伝達する。プライベートチャンネル外で機密情報を共有しないこと。
プロジェクトが限定アクセスでなくなった場合は積極的に情報を共有する
1. 情報をより広く共有できるようになったら、進捗または終了成果を広く通知する。
2. どの成果物とコミュニケーション資料を内部または公開で利用可能にできるかを評価する。
  1. 内部ハンドブックで作業していた場合は、パブリックリポジトリに対してマージリクエストを作成する手順に従ってください。
  2. メンバーをパブリック Slack チャンネルに移行し、プライベートチャンネルをアーカイブする。
  3. プライベートアジェンダを非推奨にする。新しいアジェンダドキュメントにリンクする。
  4. GitLab のグループとプロジェクトを公開するか、より広い聴衆が利用できるようにすることを検討する。

ワーキンググループへの参加

アクティブなワーキンググループへの参加に興味がある場合は、まずあなたのマネージャーおよびワーキンググループのファシリテーターとリードにコミュニケーションを取ることを一般的に推奨します。その後、特定のワーキンググループのハンドブックページに対して MR を作成することで、ワーキンググループメンバーリストに自分を追加できます。

時差の関係で既存のワーキンググループミーティングに出席できない場合は、代替ミーティングの調整をファシリテーターに相談することができます。

アクティブなワーキンググループ（アルファベット順）

過去のワーキンググループ（アルファベット順）

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)

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