組織構造

はじめに

このページでは、GitLab という会社を構成する組織構造、レイヤー、ジョブフレームワークについて説明します。私たちは個人貢献者向けとピープルマネージャー向けの 2 つのジョブフレームワークで運用しています。これらのフレームワークの使い方や、その他のプロジェクト、そして GitLab の組織構造に関するさらなる考慮事項について解説します。

組織図

誰が誰に報告しているかを示す最新の組織図は、Workday にログインし、Profile セクションを選び、左サイドバーから Team を選択して Org Chart を表示することで確認できます。私たちの HRIS はチームメンバーおよび組織情報のシングルソースオブトゥルース（SSOT）です。

レイヤー

GitLab には会社構造として最大 8 つのレイヤーがあります（Associate/Intermediate/Senior、Manager、Senior Manager、Director、Senior Director および/または VP、Executives、CEO）。レイヤーをスキップすることはできますが、通常、同じレイヤーに報告する人を置くことはありません（例: VP が VP に報告する）。

GitLab のデュアルキャリアパス

デュアルキャリアパスとは、チームメンバーがピープルマネージャーのポジションに就く必要なく、上位への移動を可能にするキャリアパスです。この構造は、深いスペシャリスト/技術スキルを持つチームメンバーで、(1) ピープルマネージャーのポジションを追求することに関心や意向がなく、むしろ個人貢献者（IC）として働きたい場合、または (2) 現時点でチームにさらにピープルマネジメントのレイヤーを追加する十分なビジネス上の必要性がない場合に、彼らを昇進させる方法として機能します。 現時点でデュアルキャリアパスが最も整備されているのは Engineering ディビジョンですが、構造やビジネスニーズが許す範囲で、他のディビジョンでも整備が始まっています。スペシャリスト/技術職トラックとピープルマネージャートラックの分岐は、通常 Senior レベルより上です。Senior レベルの役職に到達した人が昇進を望むときに、純粋にスペシャリスト/技術職にとどまるか、ピープルマネージャーの役割を追求するかを決める必要があります。マネージャーは、希望すれば両方のトラックの業務を試す機会を提供できます。ほとんどの場合、IC トラックとピープルマネジメントパスの給与帯は一致します。チームメンバーは 報酬ページ で報酬の詳細を確認できます。

ジョブフレームワーク

GitLab の各職位レベルに対する期待を明確かつ一貫して示すために、ジョブフレームワークを開発しました。2 つのジョブフレームワーク、個人貢献者用とピープルマネージャー用（GitLab 内部のチームメンバーのみ閲覧可能）があり、ジョブレベル で示されるレベルに対応しています。フレームワークに更新があった場合、必ず広く伝達します。チームメンバーとして変更を提案したい場合は、People Business Partner プロジェクト で confidential issue を開くことをおすすめします。

ジョブフレームワークの目的

ジョブフレームワークは、チームメンバーが現在貢献しているキャリアレベルを理解し、組織内の上位レベルに必要なスキルを理解するのに役立ちます。チームメンバーは、ビジネスニーズが追加スコープを支持する場合に、次のレベルへ進むために自分に何が求められているかをより簡単に把握できます。

このガイダンスは、マネージャーがパフォーマンスへの期待やキャリアの進捗についてより生産的な会話を行えるようにし、チームメンバーが個人的な成長目標を設定し共通の期待を作るのを支援できるようにし、組織全体の異なるレベルへの期待の一貫性を確保します。

マネージャーとチームメンバーが共有するジョブフレームワークを持つことは、透明性、一貫性、実行可能性、公正性を高めます。部門長は People Business Partner と協力し、ここで提供される一般的なフレームワークを超えて、機能ごとの具体的なフレームワークを職種固有のコンピテンシーとともに構築できます。

ジョブフレームワークの使い方

ジョブフレームワークは以下のプログラムで使用しています。

• 昇進プロセス
  • ここでは、ジョブフレームワークのレビューが、四半期ごとの部門昇進キャリブレーションに先立って必須となります。
  • ジョブフレームワークは、昇進ドキュメントに焦点を提供し、次のレベルでのパフォーマンスのコア領域が、会社全体で一貫して捕捉されるのに役立ちます。
• キャリア開発会話
  • マネージャーとチームメンバーの両方が会話の中でフレームワークを活用できます。
  • フレームワークは、GitLab の異なるレベルでのコンピテンシーと職務基準の透明性を高めます。チームメンバーのキャリア開発目標と整合させると、チームメンバーとマネージャーは Learning & Development Programs を活用してこれらのコンピテンシーを発達させるために協力できます。
• 組織設計とヘッドカウント計画
  • フレームワークは、リーダーシップと採用チームが、オープンにする予定の役職に適切なレベルを特定するのを支援します。
  • 既存のジョブレベルの拡張や新たな導入については、フレームワークを活用して必要となる際立ったコンピテンシーをレビューします。
• タレントアセスメント:
  • ジョブフレームワークは、自己評価とマネージャー評価の両方において、グレードレベルのコンピテンシーに対してチームメンバーを評価するために、タレントアセスメントプログラムで活用すべきです。レベルごとのコンピテンシーのレビューにおいて、強みと開発機会が浮かび上がる可能性があり、これがレビューの内容として役立ち、チームメンバーとマネージャーの今後の発達やキャリア機会についての議論につながります。
• サクセッションプランニング:
  • 各役職レベルの要件を評価する際にサクセッションプランニングでジョブフレームワークを活用します。

職位ごとのコンピテンシー

各ジョブフレームワークでは、各レベルで期待されるコンピテンシーを表すカテゴリを特定しています。以下に各カテゴリの定義を記載します。

• Scope & Influence: 各職位の責任の範囲と、プロダクト、チームメンバー、または会社戦略に対する影響の与え方。 これは自分自身の業務へのフォーカスから、プロダクト、チームメンバー、顧客、または会社戦略の観点での全社・社外への影響にまで及びます。
• Complexity & Problem solving: 日々の責任とプロジェクトにおける複雑さと問題解決スキルのレベル。 低/中レベルの複雑さと問題解決から、GitLab の長期目標達成に影響を与える非常に複雑な問題まで及びます。
• Leadership & People Management/Communication: 表すリーダーシップのレベルと、組織内でのコミュニケーションの取り方。個人貢献者もその役割においてリーダーシップを発揮することを期待しています。 これはチーム内からエグゼクティブや取締役会のメンバーまでに及びます。
• High Performing Teams: ハイパフォーマンスの各特性は、成功を認識し測定できるように 3 つの指標に分けられています。
• バリューコンピテンシー: CREDIT バリュー と整合するコンピテンシー。
• リモートワーキングコンピテンシー: リモートワーキングコンピテンシーと整合するコンピテンシー。
• 機能別コンピテンシー: 機能ごとに固有のコンピテンシー。これらは各機能が自ら構築します。

上記のコンピテンシーカテゴリのほかに、ジョブフレームワークに 2 つのカテゴリを追加しています。

• 典型的なレポートライン構造: その職位レベルの典型的なレポートライン構造を示します。
• 次のレベルとの違い: あるレベルと次のレベルの違いを示す簡潔なステートメント。

個人貢献者ジョブフレームワーク

個人貢献者は Managers of One です。IC は GitLab チームメンバーの大多数を構成します。IC 用ジョブフレームワーク は、IC の各レベルで期待される最低限のコンピテンシーを示すハイレベルなガイドです。レベルごとの厳密な要件と責任については、チームメンバーは各職務の Job Family ページを参照してください。

ピープルマネージャージョブフレームワーク

ピープルマネージャー用ジョブフレームワークはこのタブで確認できます。以下に各レベルとそのレポートライン構造を説明します。

すべてのピープルマネージャーへの一般的な期待

すべてのピープルマネージャーには、以下に示す行動面での一般的な期待があります。これらはジョブフレームワークには含まれていませんが、私たちがピープルマネージャーに期待する行動やチーム/同僚との関わり方のガイドとして使えます。ジョブフレームワークとの違いは、ハイレベルなコンピテンシーを記述するものではなく、非常に具体的な期待値と GitLab の基本を設定するものである点です。

マネージャー

マネージャーは マネジメントグループ に属します。コンピテンシーカテゴリごとの期待値はジョブフレームワークで確認できます。通常、マネージャーは Senior Manager または Director に報告します。

シニアマネージャー

シニアマネージャーは マネジメントグループ に属します。さらにコンピテンシーカテゴリごとの期待値はジョブフレームワークで確認できます。通常、シニアマネージャーは Director 以上に報告します。

ディレクター

ディレクターは通常、マネージャーのマネージャーです。彼らは ディレクターグループ を構成します。一部のコストセンターでは、ディレクターは部門にマッピングされます。たとえば G&A ディビジョンの下、Business Operations はディレクターが率いる部門です。ただし、これは厳格な規則ではありません。たとえば G&A の下では、People はすべて 1 つの部門にまとまっています。 ディレクターグループのメンバーは、すべてのマネジメントグループメンバーが行うリーダーシップに加えて、ジョブフレームワークに記載される追加のコンピテンシーを示すことが期待されます。通常、ディレクターは Senior Director 以上に報告します。

ディレクターグループ

ディレクターグループのメンバーは、すべての マネジメントグループ のメンバーが行うリーダーシップに加えて、以下を示すことが期待されます。

1. 日々の実行を会社のトップ目標に整合させる能力を持ち、トップ目標がチームメンバーに対して適切に伝達されることに責任を持つ。
2. ピアツーピアで働き、問題を素早く解決するためにチーム内の健全なコンフリクトをスポンサーし、すべての選択肢が尽くされた場合にのみエスカレーションする。
3. ビジネスから今後 3〜4 年で必要となる役割を野心的に定義し、チームを成長させ採用する。
4. チームを コミュニケーションガイドライン に従って働くようにコーチし、自ら手本を示してリードする。

Slack チャンネル: #directors-and-above（プライベート）

シニアディレクターと VP

シニアリーダーは、シニアディレクターまたは VP として定義されます。

シニアディレクターは通常、マネージャーや/またはディレクターのマネージャーです。一部のディビジョンでは、シニアリーダーがコストセンター構造の部門にマッピングされます。通常、シニアディレクターは VP 以上に報告します。

VP は通常、シニアディレクターや/またはディレクターのマネージャーです。シニアディレクターと同様に、彼らは部門にマッピングされます。通常、VP はエグゼクティブに報告します。

シニアリーダーは、すべてのディレクターグループメンバーが行うリーダーシップに加えて、ジョブフレームワークに記載される追加のコンピテンシーを示すことが期待されます。

1. 重要な戦略的および機能的責任を持つ。
2. 重要な運営予算の責任を持つ（報酬計画、予算配分、交渉、投資のトレードオフ判断など）。
3. 大規模なチーム（直接報告と間接的報告の両方）のパフォーマンスと成功に対するレバレッジと影響力を持ち、その成功は多数の人々全体での成功の拡大につながる。
4. 意思決定の影響は広範かつ重大である。
5. 一部は、会社を代表し、会社が責任を負う意思決定や発言を行うために、重要な対外的責任を持つ。

VP-Directs

VP-Directs は、E-Group メンバーに直接報告する GitLab VP のサブセットです。彼らは VP-Directs グループのメンバーです。

エグゼクティブ

エグゼクティブレイヤーは以下のように構成されます。R&D 系のエグゼクティブには、Chief Product Officer (CPO)、Chief Information Security Officer (CISO)、Chief Technology Officer (CTO) が含まれます。 Go-to-market 系のエグゼクティブには、Chief Revenue Officer (CRO) と Chief Marketing Officer (CMO) が含まれます。 3 つの enabling 機能、すなわち legal、finance、people には、それぞれ C レベルのエグゼクティブとして Chief Legal Officer (CLO)、Chief Financial Officer (CFO)、Chief People Officer (CPO) がいます。

これらのエグゼクティブで E-group を構成します。 彼らは毎週ミーティングを行い、四半期ごとの取締役会に出席し、ほとんどの議論トピックに public Slack channel #e-group を持ち、まれな機密事項のためにプライベートチャンネルも持っています。

Sales と Marketing を除き、通常、1 つの コストセンター には複数のエグゼクティブが属します。たとえば、CLO、CFO、CEO、CPO はすべて G&A（General & Administrative Expenses）コストセンターの下にあります。

E-group

E-group のメンバーは、シニアディレクターと VP のすべてのメンバーが行うリーダーシップに加えて、以下を示すことが期待されます。

1. 関連性が高く、野心的で、定量化可能な OKR を提案し、その 70% を達成する。
2. 信頼でき、チームが合意したことを確実に完遂するようにする。
3. 他の部門が気付く前に、自身の機能内の問題を検出し伝達することについてプロアクティブである。
4. 各自の機能領域でより高いパフォーマンスを発揮するリーダーを採用し、維持する。
5. 3〜4 年先に必要な役割と要件を作成し、そのプロファイルに合った人材を採用する。
6. 素早くイテレーションし、部門にイテレーションをトレーニングすることで、膨大な量のことを完了させる。
7. ビジネスにおいて過度に戦術的になるのではなく、ビジネス戦略とビジョンを定義し伝達する。
8. 他の機能領域に関する洞察を共有し、他の人をその仕事においてより優れたものにする。
9. クロスファンクショナルなプロセスに対して改善を提案し実装する。
10. 自身の機能の外で結果を出すことを頻繁に支援する。
11. 他のエグゼクティブを、その専門領域においてより優れたものにする。

Slack チャンネル: #e-group（パブリック）と機密事項用のプライベートチャンネル

マネジメントグループ

マネジメントグループのメンバーは、すべての GitLab チームメンバーが 行うリーダーシップに加えて、以下を示すことが期待されます。

1. チームメンバーが包摂されていると感じ、価値を認められていると感じるようにすることは、マネージャーの最も重要なタスクの 1 つです。チームメンバーと心理的安全性をプロアクティブに作り出し、多様な視点が聞かれ、誰もが本物の創造的なコミュニケーションと貢献ができるようにします。
2. チームメンバーが自分の役割で何を期待されているかを理解するようにすることは、マネージャーが会社の成功を確実にするために果たす重要な役割です。マネージャーは、Job Family に具体的な パフォーマンス指標 を含み、それが各チームメンバーに明確に伝達されるようにすべきです。
3. パフォーマンス不足の管理 もマネージャーの重要なタスクです。
4. 時が良いときは、節度の声であれ。時が悪いときは、希望の声であれ。希望の声を効果的に務めるには、マネージャーが会社のミッション、目標、リーダーシップの意思決定を理解しているようにしてください。マネージャーがリーダーシップの意思決定に懸念を持つ場合、コンテキストを理解するためにリーダーにそれを声に出し、健全な意思決定ができるようチームメンバーからの重要な洞察を共有し、その後チームメンバーにコンテキストを説明できるようにすべきです。
5. 効果的な組織を維持するために、マネージャーのスパンオブコントロールは約 7 人（4 人から 10 人の範囲）であるべきです。この範囲を下回ると、組織レイヤーを追加することの非効率性が、特化したグループを持つことの利益を上回ります。この範囲を上回ると、マネージャーは適切な 1:1 をする時間がなくなります。
6. スパンオブコントロールは組織のすべてのレベルで同じです。これにより、組織がコストを増やし意思決定速度を下げる追加レイヤーを持つことを防ぎます。扱える報告者数を増やすには、マネージャーになりうる directly responsible individual への委譲を増やします。レポート数は、今から 6 か月後に組織がどこにあると予想するかに基づいてサイズ感を決めます。
7. 誰かを褒めるときは、公開の場で、聴衆の前で 行うようにしてください。改善を提案するときは、プライベートに 1 on 1 で行ってください。Harvard の研究 によると、ハイパフォーマンスチームに対するポジティブ・ネガティブフィードバックの理想比率はほぼ 6:1 です。ポジティブフィードバックは惜しまず与えてください。
8. チームミーティング、グループ会話、その他のコミュニケーションで、あなたの意見に建設的に挑戦し、難しい質問をしてくれる人に感謝を表してください。これは心理的安全性を作り出し、私たちのバリューを促進し、5 つの機能不全 を防ぐのに役立ちます。
9. 同じゴールにたどり着く方法は複数あることを理解してください。異なる視点があり、議論が必要です。
10. 誰かが辞めることを検討していると言ったら、すべてを置いて彼らの話を聞いてください。彼らの懸念を見つけ出すために質問してください。遅らせると、その人は価値を認められていると感じず、決定は不可逆になります。
11. 新しいチームメンバーの参加を発表するのに加えて、退職も #team-member-updates チャットチャンネルでアナウンスされます（ただし Google/Slack アカウントが取り消された後にのみ。詳細は オフボーディングページ と オフボーディングチェックリスト を参照）。当該個人のプライバシーを尊重しなければなりません。誰かが辞めた、もしくは辞めようとしている理由を尋ねられた場合、共有可能・不可能な内容を記述したハンドブックの 一般的なガイドライン セクションを参照するように案内してください。
12. 昇給や肩書は、本人が頼んだからや辞めると脅したから与えるべきではありません。私たちは、頼まれなくともプロアクティブに昇給と昇進を行うべきです。頼まれたときにそれを行うと、頼まない人に対して不公平となり、結果として頼んでくる人がはるかに増えることになります。
13. GitLab を 家族のように 言及しないでください。私たちのチームが緊密なグループのように感じるのは素晴らしいことであり、それはより強いチームを築くので奨励すべきです。しかし、家族 と チーム は異なります。家族 は関係のために集まり、それを維持するために重要なことを行います。チーム は task のために集まり、完了に必要なことを行います。task より関係を優先しないでください。さらに、家族には オフボーディングプロセス はありません。家族には無条件の愛があるべきですが、チームには条件付きの愛があります。最高の会社は家族の支援者です。。チームが家族だという考えは、不当なプレッシャーにつながりかねません: “このオフィスは家族のようで、休日に来るべきだという漠然とした圧力がある”。あなたは自分のキャリアの CEO であり、GitLab を顧客として扱ってください。
14. 報告者の仕事を会社の他の人に対して褒めてクレジットを与え、決して自分のものとして提示しないでください。これと多くの素晴らしい教訓は、読む価値のある Ask MetaFilter スレッド で見つけられます。
15. 自身の 認知バイアス を意識するようにしてください。
16. 一貫性と俊敏性 を組み合わせてください。
17. チームに対する期待や働き方を文書化した README ファイルを維持することを検討してください。MR を奨励してください。
18. 私たちのタイムスケールは短いものの、PIP の考え方 について素晴らしい記事があります。
19. 人々のブロックを解消するためにあらゆることをしてください。生産性を妨げている質問がある場合、自分でその質問に答えるか、答えられる人を見つけてください。
20. あたかも言葉が広く共有されるかのように（たとえば新聞に掲載されるかのように）、プロフェッショナルな方法で コミュニケーションしてください。
21. 重要な決定を放送するために マルチモーダルコミュニケーション を採用してください。
22. ソーシャルメディアで 返信することが期待されます。質問があれば、#social_media チャットチャンネルで相談してください。
23. 報告者が自分の仕事において 進捗の感覚 を持てるようにしてください。
24. Sam Altman のツイート と Paul Graham の返信 の組み合わせがそれを最もよく表現しています: “People either get shit done or they don’t. And it’s easy to be tricked because they can be smart but never actually do anything.” 質問への明確な答えではなく、結果を見てください。さもないと、パフォーマンス不足者を特定するのに時間をかけすぎることになります。
25. GitLab Contribute（以前の GitLab summits）は、会社全体での インフォーマルコミュニケーション と 絆作り のためのものです。GitLab Contribute 中のビジネス活動の時間は限られているため、すべての定期ミーティングはそれ以外で行うべきです。インフォーマルでクロスチーム、オープンエンドで、個人貢献者を含むミーティングを望みます。たとえば、GitLab に現在欠けている機能を全員に提案してもらうなどです。
26. GitLab Contribute まで意思決定を遅らせないでください。代わりに、それ以前に物事を完了させるためのデッドラインとして使ってください。
27. GitLab には明示的な 20% タイムはありません。活動ではなくインパクト を測定します。割り当てられた仕事で良い結果を出している人は、自由に会社の他の部分に貢献したり、ペットプロジェクトに取り組んだりできます。「あなたのペットプロジェクトはあなたのパフォーマンスを損なっています」と言わないでください。代わりに、「X を完了することに合意したが、遅れている。何が起きたのか、どう手伝えるか？」と言ってください。
28. 何か新しいものを公開する前に指標を選んでください。新規公開の 10 件のうち 9 件は失敗します。プロジェクトがうまくいっていない場合、完全に打ち切ってください。チームをヘッドカウントで飢えさせ、ゆっくり死ぬのに任せることは、節約でもモチベーションにもなりません。ブレークイーブンに何年もかかる勝者に資金を投入してください。
29. 昇給を事前に話し合わないでください。サラリーカリキュレーターは、昇給額が決まる前に変更される可能性があるためです。
30. 昇進、昇給、ボーナスについて、変更が承認プロセス全体を通過するまで話し合わないでください。People Ops は、マネージャーがチームメンバーに昇進と昇給を伝えてよいタイミングを知らせます。
31. 報告者に方向性を指示するのではなく、納得のいく方向性に到達するまで ソクラテス式問答法 に従って質問をするのがベストです。報告者はより狭い領域でより深い知識を持つので、彼らは異なるデータに基づいているため、異なる結論を引き出すのが容易です。だからこそ質問が非常に重要です。
32. Berkshire の共通の指針 に従ってください: “Always tell us the bad news promptly. It is only the good news that can wait.” 悪い知らせはできるだけ早くマネージャーに知らせてください。悪い知らせを迅速に報告することは、それから回復するために必要な信頼を保つために不可欠です。
33. 軍事的なアナロジーやイメージを避けるようにしてください。私たちは軍隊ではなく、戦争中ではなく、戦闘はなく、誰も殺していなく、武器を持っていません。軍事用語は 包摂的でなく、ゼロサム思考につながる可能性があります。私たちは競争と勝利を非常に真剣に受け止めますが、物理的暴力の語彙で物事を記述する必要はありません。同様に、“rock star” や “badass” のような協調的でない攻撃的な用語は、人々の間に壁を作ります。業界で標準的な用語（たとえば Unix プロセスを kill する）であれば、より効率的なので使用しても問題ありません。レプリケーションメカニズムには「master-slave」ではなく「primary-secondary」を使ってください。
34. 上には不満を、下には説明を。聞いた懸念をマネージャーに伝えてください。同僚や報告者が不満を言う場合、なぜ意思決定が行われたかを説明してください。理由がわからない場合は、マネージャーに尋ねてください。
35. チームに悪影響を与える他のリーダーからの意思決定について、その背後にある理由を説明することで共感を作り出してください。チームと他のリーダーとの録画された AMA セッションを開催し、未回答の質問をするようチーム（および自分自身）を促してください。議論が 組織全体にとってベスト なものを明らかにすることで手本を示してください。自分を組織の他の部分からチームを保護する者として決して提示しないでください。これは シージメンタリティ を作り出し、コラボレーション を妨げます。
36. 非同期コミュニケーション を奨励し、handbook-first であることを奨励し、貧弱なオーディオや ビデオ品質 を伝え、開かれたマイクを指摘することによって、チームメンバーが良い リモートワーキングプラクティス を確立できるようコーチしてください。
37. GitLab のポリシーが守られるようにすることは、マネージャーの責任の重要な部分です。マネージャーは、チームメンバーとビジネスの最善の利益の両方に配慮する義務があります。マネージャーが、チームメンバーが GitLab ポリシー（GitLab Code of Business Conduct and Ethics や Relocation policy などを含むが、これらに限定されない）に違反していることを知った場合、これを 対応する People Business Partner または Legal チームにすぐに伝えるのは彼らの責任です。

Slack チャンネル: #managers、#people-managers-and-above（プライベート）

取締役会メンバー

取締役会メンバー は GitLab の取締役会に従事し、取締役会会議や取締役会委員会、その他の責任に参加します。

CEO Skips

E-Group が「CEO Skips」コールやミーティングを開催するという話を時折耳にすることがあります。 CEO Skips グループは、E-group に直接報告する人々で構成されています。People Business Partner、Chief of Staff、internal communications も含まれます。 一部の IC、一部のマネージャー、一部のディレクター、一部のシニアリーダーで構成されます。

Functional Leaders

Functional Leaders には、すべての CEO Skips と、E-Group メンバーから招待されたごく少数の他のチームメンバーが含まれます。

このグループは、適切な場合にインプットとメッセージングのコミュニケーションを支援するために呼び出されます。

例として、Functional Leaders は E-group のオフサイトごとに会議を開催します。

Slack チャンネル: #functional-leaders（プライベート）

Directs-Group

Directs-Group は、各機能のシニアリーダーから成るグループです。これらのリーダーは E-Group の延長として運営し、6〜9 か月のローテーションで重要なイニシアチブを支援します。Office of the CEO は、コホートの E-Group スポンサーと協力して、このグループの組織化とオリエンテーションに責任を持ちます。

Directs-Group プログラムの目的

1. E-Group と E-Group の意思決定により多くの露出を与え、C レベルの可能性を持つリーダーを育成する。
2. 重要なイニシアチブを推進し、情報を提供するために、より大きなグループの人々を招集する。
3. チームと機能内での E-Group からの情報のカスケードを支援する。これには、機能リーダーシップチームの同僚へのカスケードも含まれる。

Directs-Group の責任

1. E-Group との指定されたミーティングや E-Group オフサイト の一部に出席し、貢献する。
2. オンボーディング、オフボーディング、定期的にスケジュールされる Directs-Group シンク、専門開発プログラム、次のコホートのランピングに参加する。
3. Directs-Group での関与から生じるコミュニケーションカスケードとイニシアチブのサポート。
4. 既存の責任を管理しながらこの役割に従事する。
5. コホートプロジェクトに貢献する。

Directs-Group の選考プロセス

1. Office of the CEO は、毎回のコホート終了日の 3 か月前に選考プロセスをキックオフし、最初の E-Group オフサイトの前に Directs-Group の特定とオンボーディングに十分な時間を確保し、Directs グループ間の適切な移行を行います。
2. 各 E-Group メンバーが第 1 希望と第 2 希望の候補者を特定します。E-Group は、第 1 希望の候補者選定の中で TMRG 基準が満たされない場合に議論します。
3. 候補者は、その役割を担う新コホートが始まる少なくとも 45 日前に特定され、通知されます。
4. 候補者が指名を辞退する場合、機能リーダーは検討のため新しい候補者を指名できます。

Directs-Group の選考基準

各 Directs-Group コホートは以下の基準を満たす必要があります。

1. 良好な状態にある成長性と高パフォーマンスのチームメンバー。
2. E-Group メンバーへの直接の報告者である Director 以上。
3. CREDIT バリュー を一貫して示す人々。
4. 各コホートの 1/3 以上が、未代表のグループ のメンバーで構成される必要がある。
5. 米国外を拠点とする人を 1 名含む。

Directs-Group リーダーシップ

Directs-Group の指名プロセスの間、E-Group はコホートをリードする人を指名します。理想的には、この人は前のコホート出身で経験を持っているのが望ましいです。この人の責任は以下の通りです。

1. 主要な成果物について E-Group と Directs-Group の合意を取り付ける。
2. グループが適切に機能するようにする。
3. 新たに到着するコホートの公式メンバーであること。
4. 新たに到着するコホートのランプアップを助ける。
5. 新たに到着するチームの活動と成果物を調整する。
6. E-Group に対するコホートの代表者として務める。
7. E-Group スポンサーとの協力により、グループが少なくとも 1 つのコホートプロジェクトで成功を達成することを保証する。

この人は以下を基準に選ばれます。

1. クロスファンクショナルなリーダーシップチームをリードする実証された能力。
2. この追加の時間コミットメントを行える能力。

Directs-Group のタイミング

コホートは GitLab の会計年度の 2〜3 四半期に合致する 6〜9 か月にわたって進みます。具体的な開始日は E-Group オフサイトに合わせて定められます。

Directs-Group のための E-Group スポンサー

各コホートには、コホートの期間中の E-Group スポンサーがいます。この人は Directs-Group ミーティングに出席し、より広い E-Group との公式リンクとして務めます。この人は Directs-Group リーダーに対する安定したカウンターパートになります。E-Group スポンサーと Directs-Group リーダーは異なる機能から来ます。スポンサーはまた、Directs-Group がコホートとして貢献できる少なくとも 1 つの領域を特定するのを支援します。Directs-Group ミーティングの間、スポンサーはイニシアチブのステータスをチェックし、フィードバックを提供します。

Directs-Group の参加者

過去、現在、未来の Directs-Group 参加者はここに列挙されます。

コホートプロジェクト

各 Directs-Group には少なくとも 1 つのコホートプロジェクトがあります。コホートプロジェクトは、GitLab を何らかの形で改善するために設計されたクロスファンクショナルなイニシアチブであるべきです。コホートの最初の月内に少なくとも 1 つのコホートプロジェクトを特定すべきです。選定には Directs-Group と E-Group スポンサーが関与すべきです。コホートは、新たに到着するコホート向けにプロジェクトのアイデアを推奨できます。

コホートプロジェクト:

1. 2022-01 から 2022-10: Stop イニシアチブ、Internal Handbook 更新
2. 2022-11 から 2023-08: 戦略計画のリフレッシュ

VP-Directs グループ

VP-Directs グループは、主に VP-Directs（E-Group メンバーに直接報告する VP）で構成されます。これは、重要なコミュニケーションのカスケード、変革管理の支援、ミッション＆ビジョンが組織のすべてのレベルで徹底的に理解され続けるようにすること、最優先のクロスファンクショナル活動の支援、会社のセンチメントとエンゲージメントのゲージとして機能できるシニアリーダーのグループです。ある機能に VP-Directs が 0〜2 人しかいない場合、E-Group メンバーは機能を代表するために機能内から追加の 1 名または 2 名を指名できます。

VP-Directs グループの目的

毎月のミーティングと Slack チャンネルを通じて、このグループは以下に従事します。

1. 情報のカスケード: E-Group が組織に吸収・理解してほしい具体的なメッセージがあり、シニアリーダーがそのメッセージを伝えるのに役立てます。これは、特定の課題や挑戦に対して重い変革管理が必要となるときや、E-Group が広範なリーダーシップサポートを必要とするときに特に重要です。このグループにそれを吸収し、組織を通じて変革を推進してもらいます。
2. 情報とパースペクティブの提供: このグループは、意思決定や行動が取られている際にシニアな意見の交わる場として機能できます。たとえば、E-Group が戦略的な組織のピボットの必要性を特定し、より広範なシニアレベルのインプットが必要な場合、このグループに従事させることができます。
3. クロスファンクショナルなイニシアチブのリーダーシップを提供: E-Group はこのグループに特定のクロスファンクショナルなイニシアチブを引き受けるよう依頼することがあります。たとえば、このグループは Employee Engagement Survey からのフィードバックへの対応（すべての機能リーダーと並んで）や戦略計画活動をサポートする役割を果たすことができます。
4. 顧客から学ぶ: 顧客をこのグループに招待して話してもらうことで、リーダーシップグループとして GitLab と私たちの課題と機会に対する顧客の視点を理解し、組織全体に顧客中心性を推進し続けます。

VP-Directs グループのコミットメント

1. 月次ミーティングに参加（可能な場合は同期的に。適切な場合は録画ミーティング）
2. Slack チャンネルをモニター
3. プロポーザルと計画に対するインプットを共有
4. 議論すべき内容やグループの効果性を改善する方法のアイデアがあれば、プログラムマネージャーに連絡

VP-Directs グループの管理

初期管理には以下が含まれます。

1. ローテーションの E-Group スポンサー: 公式の E-Group 代表者
2. CEO の Chief of Staff: E-Group インターロックを所有、スポンサーとパートナーする
3. VP of Talent and Engagement: チームエンゲージメントを所有し、内部コミュニケーションの VP of Global communications とパートナーする。VP of Global communications は、必要に応じて広範なコミュニケーションを所有する。 この初期管理チームは、グループを軌道に乗せ、規律とルーティンを確立し始めることに責任を持ちます。これをよりよく理解するにつれて、このモデルからイテレーションできます。 管理チームは以下を行います。
4. EBA チームと調整して、招待シリーズが送られ、確立されるようにする。
5. 適切なアクションが記録され、フォローアップされ、必要に応じて説明責任を持つようにする。
6. ミーティングが明確な目的を持ち、情報が効果的に共有され、グループの目標が満たされるよう、E-Group と VP Group の交差点として務める。

組織構造

• ディビジョン: 1 人のエグゼクティブの下の領域。例: Engineering ディビジョン。
• 部門: Director または VP によってリードされ、複数のチームまたはサブ部門で構成される。例: Engineering ディビジョン内の Infrastructure 部門
• サブ部門: Director または Senior Manager によってリードされ、複数のチームで構成される。例: Development 部門内の Enablement サブ部門
• コンパートメント: Senior Manager によってリードされ、サブ部門構造がすでに使われている場合の複数のチームで構成される。例: Dev サブ部門内の Manage コンパートメント
• チーム: 部門を構成し、ラインマネージャーとその直接の報告者で構成される。例: Security 部門内の Security operations チーム

注 - Engineering と Product ディビジョン内では、組織構造内で安定したカウンターパートを維持するため、組織構造と プロダクト階層 との密接な関係を維持するよう努めています。

Finance も財務計画目的のために「部門」という概念を持っています。しかし、これらは私たちの組織部門と整合しません。たとえば、Finance 部門の「product development」は PM と Engineering の両方の機能をまとめます。しかし、Engineering 機能の一部ではあるが別の予算である Support 部門は除外されます。この名前の衝突は、おそらく将来解決すべきです。さらなる参照については、会計目的の 部門集計構造 を参照してください。

ハンドブックとドキュメントを最新に保つよう最善を尽くしていますが、過去に使われた特定の用語は時を経て更新されてきました。Functional Group という用語はもう使われておらず、現在は Departments という用語に包含されています。Functional Group leader という用語はもう使われておらず、現在は E-group リーダーという用語に包含されています。

Output（成果）による組織化

多くの点で、私たちは Output によって組織化されています。 これにより、責任が重複しないことを保証できます。 また、すべてのディビジョンが明確な優先事項を持つことを保証します。

Product Groups

私たちのエンジニアリング組織は、プロダクトカテゴリ階層 で定義されているグループに直接整合しています。 私たちのグループは、複数の機能からの 安定したカウンターパート の原則で運営されます。

たとえば、Product Manager、Product Marketing Manager、Engineering Manager、Content Marketer、Backend Developer、Frontend Developer、Product Designer が、「Package」と呼ばれるグループに専属しています。これらの個人はまとめて「Package グループ」を構成します。「Package」という言葉は、彼らの肩書の中で専門分野として現れ、場合によってはチーム名にも入っています。

私たちは、Product Groups の安定したカウンターパートをいくつかのタイプに区別します。

• Primary Stable Counterparts - Product、Development、Product Design からプロダクト階層（通常はグループ）に割り当てられたチームメンバー。
• Complete Stable Counterparts - Primary 機能以外の機能からプロダクト階層に割り当てられた、私たちの プロダクトカテゴリページ で定義されているすべてのチームメンバー。たとえば、Support、Product Marketing、Customer Success から安定したカウンターパートを割り当て、彼らはすべて complete stable counterparts の一部とみなされます。

グループにはレポートラインがありません。それは マトリックス組織を望まないからです。 代わりに、グループが適切に機能するために安定したカウンターパートに頼ります。 デザイン、テクニカルライティング、品質のような共有機能では、安定したカウンターパートとなるよう個人は 1 つ以上のステージとペアになります。

すべての人が貢献できるとはいえ、グループのスコープは重複せず、他のグループがユーザーに価値を届けるために必要な依存関係にならないべきです。 これは 結果、イテレーション、効率性 を促進します。

内部プラットフォームグループ（プロダクトのユーザー向けでない部分、たとえば内部 API セットに焦点を当てるもの）は、プラットフォームの改善に依存する他のグループに対して 重い調整コストを生み出す傾向 があります。効率性を保つために、各グループがノンブロッキングで、直接ユーザーに価値を届けられるようにすることが重要です。これが、私たちが内部プラットフォームグループを避ける理由です。

また、グループが複数のグループにまたがって共有されるスコープ定義を持たないようにすることも重要です。2 つの例を挙げます。

1. 国際化グループはありません。 その責任は多くのグループに分散されています。 代わりに、国際化ツールグループを持つかもしれません。
2. パフォーマンスグループはありません。 GitLab がパフォーマントであることを保証するのは、すべてのグループの責任です。 代わりに、パフォーマンスツールグループを持つかもしれません。

Application Performance グループ と Database グループ がありますが、これらの憲章は他のチームのコンサルティングとフレームワークの提供を含み、ノンブロッキングとみなされます。

Application Performance グループ は、システム的なパフォーマンスボトルネックの特定、ドキュメント作成、他のグループが機能のパフォーマンスを理解し改善するのを支援するツールに焦点を当てています。

Database グループ は、データベース管理/スケーリングの細部に焦点を当て、データベース開発ガイダンスを必要とする開発チームのためのコンサルティングを提供することに焦点を当てています。データベース関連のマージリクエストは引き続きデータベースメンテナの承認を必要としますが、私たちの database review プロセスは、データベースチームのメンバーだけを超えて必然的にスケールしています。

Product Group ヘルスアセスメント

プロダクトロードマップを実行する能力は、Product Group の健全性に依存します。直感、強引な個性、その他のアドホックな方法に頼るのではなく、ハイパフォーマンスチームを開発するためのフレームワーク（Drexler-Sibbet モデル など）が存在します。さらに、チームの健全性は測定でき、改善は体系的に行えます。たとえば、Spotify Health Check モデル は、チーム内で改善できることを可視化する軽量な方法です。

Product Group ヘルスアセスメントの目標は、グループが改善領域を特定できるようにすることです。それらをグループの相対的な「成熟度」を評価するために使用すると、グループが結果をできるだけ良く見せるよう積み上げるという倒錯したインセンティブが生まれます。その結果、ヘルスアセスメントはマネジメントが Product Group 間で比較対照するために使用されるべきではありません。代わりに、Product Group のリーダーが、アセスメントを管理し、時間とともに改善をイテレーションする DRI となります。

開始するには、自由に Team Health Survey テンプレート のコピーを作成し、開発グループのニーズに合わせて編集してください。

Building High Performing Product Groups Learning Session

Learning & Development チームは、高パフォーマンスを可能にする ために Product Group と一緒にライブ学習セッションをファシリテートできます。Drexler-Sibbet モデル は、チームを段階を経て高パフォーマンスへと導くためのフレームワークです。ライブ学習セッション中、L&D ファシリテーターは Product Group と協力し、高パフォーマンスを達成するために何が起こる必要があるかについてチームメンバーを整合させる活動を定義します。セッションのスケジューリングに興味があれば、#learninganddevelopment に連絡して詳細を確認してください。

チームメンバー向け Product Group の設定

従業員データのシングルソースオブトゥルース（SSOT）であるため、Workday は Product Group 割り当ての SSOT として機能します。R&D 機能（Product/Engineering）の各チームメンバーには、team.yml エントリで specialty フィールドが割り当てられます。このエントリは www-gitlab-com プロジェクト で編集可能ですが、調整は Workday からの 日次同期によって上書きされます。チームメンバーの specialty を調整するには、彼らのマネージャーが Job Information Change を開始する必要があります。

チームメンバーの specialty を指定する際には、私たちのプロダクト 階層 の最小単位と、それらの指定された 名前 を使用します。たとえば:

• Create ステージの Code Review グループに安定したカウンターパートのチームメンバーは、Create: Code Review という specialty 指定になります。
• Verify ステージ全体に安定したカウンターパートのチームメンバーは、Verify という specialty 指定になります。
• Manage ステージの Access と Import グループ、および Create ステージの Gitaly グループに安定したカウンターパートのチームメンバーは、Manage: Access、Manage: Import、Create: Gitaly という specialty 指定になります。

Single-Engineer Groups

Single-Engineer Group（SEG）の目標は、GitLab プロジェクト内の planned または minimal カテゴリで GitLab をイニシエートすることです。Single-Engineer Group は、既存の viable または complete カテゴリに投資するためのものではありません。SEG が取り組む候補となるプロダクトのアイデアのリストは こちら です。

GitLab では、1 人のエンジニアが素晴らしい偉業を達成する力を信じています。多くのオープンソースプロジェクトは、1 人のエンジニアが個人的に経験した問題の周りに構築する決定を下したことから始まりました。たとえば、DZ による Continuous Integration や、Kamil による GitLab Runner です。このエネルギーのための場所を作りたいのです。

私たちは、より大きな組織と既存のコードベースの中でアイデアをインキュベートすることで、より大きな組織から生まれる摩擦のマイナス面を制限しながら、より高い成功率を保証できると信じています。SEG のいくつかの利点は次のとおりです:

1. 行うべき決定がたくさんあり、1 つの脳でより効果的に行われる。
2. 複数の人がマージコンフリクトに陥らずに作業するには十分なコードがない。
3. 作業を早めに開始することで、他の人が貢献するためのより多くの時間が生まれる。商業化より数年先んじてスタートする必要がある。

プロセスの問題として、Single-Engineer Group は私たちの Software Demo Process に参加し、ステークホルダーと非同期にコラボレーションし、イテレイティブなフィードバックを取得し、自律性を保ちながら GitLab の他の部分との最低限の整合性を維持する方法とすることを要求します。

グループが大きな成功を見つけ、採用によって測定され、プロダクトのその領域をさらに進化させる必要がある場合、次のステップはマルチパーソンのグループを形成することを検討することです。時にはカテゴリが完成し、グループは成功裏に解散できます。カテゴリが採用を生まない場合もあります。学んだ教訓を集め、その学びに基づいてグループを解散させるか、さらに投資するかを検討します。

私たちには目の前に大きな機会があり、野心的でありたいと思っています。したがって、時間をかけて私たちの R&D の 10% をこれらを追求し続けるために投資したいと考えています。しかし、イテレーションの精神に基づき、ほんの一握りの Single-Engineer Group から始めます。より多くを学び、投資するドルが増えるにつれて、徐々に SEG を追加していきます。

成功基準

エンジニアの成功は、プロダクト・マーケット・フィットの問いに対する迅速で高品質な答えを得ることに関連します。その答えは絶対に「いいえ」となる場合があり、パフォーマンスはグループがより大きな複数人グループに昇格するかどうかに依存しません。これの測定は GMAU です。

スポンサーシップ

GitLab の誰でも、Single-Engineer Group の作成を提案できます。

Single-Engineer Group は、他の新規投資と同様に優先順位付けされ、以下からの承認を得る必要があります。

• Chief Product Officer
• CTO
• CEO

選定

SEG が Development 部門にある場合、VP of Development は、Single-Engineer Group である間のエンジニアのレポート構造を決定する責任を負います。

エンジニアの基準:

• エンジニアはシニアエンジニア（またはそれ以上）でなければならない。
• 主題に対して情熱的でなければならない。
• 独立して働ける能力に意欲を持っているか、類似のモデルで以前に成功している必要がある。
• 過去の会社の技術的共同創業者であること
• 成功したオープンソースプロジェクトの早期の貢献者であること
• 過去の Single-Engineer Group で成功裏に働いたこと

Stable counterparts なし

Single-Engineer Group には stable counterparts はありません。これを考える最良の方法は、コミュニティ貢献です。選定基準は、安定したカウンターパートなしで独立して働けるエンジニアを選ぶために設定されています。このセットアップは、以下の望ましくない副作用を避けるためです。

• ホームグループでフルタイムの責任を持つ他のチームメンバーに不注意に貢献を依頼することは、燃え尽きや、Single-Engineer Group がモデルにしている投資量を超える投資につながる可能性があります。
• 他の安定したカウンターパートが、問題検証や/またはソリューション検証に関するより多くの厳密さを要求する可能性があるため、エンジニアが自由を失う。

Single-Engineer Group の作成例

MR には、Single-Engineer Group の作成方法の例が記述されています。

Working Groups

Working Group は、ビジネス目標を達成するために一定期間集まる特定のタイプのグループです。Working Group には定義された責任があり、定期的に会議を行います。理想的には、Working Group は目標が完了したときに解散でき、蓄積した官僚主義を避けられます。

ミドルマネジメント

ミドルマネージャーは、CEO に報告せず、ピープルマネージャーが報告してくるチームメンバーです。 これは誰かのタイトルや組織図での位置によって定義されるのではなく、この 2 つの基準によって定義されます。

役割

人はある 1 つのことについてスペシャリストであり、複数のことについてエキスパートであることができます。これらは チームページ にリストされています。

スペシャリスト

スペシャリストは、特定のトピックに対する責任を担います。 彼らはこのトピックの Issue を追跡し、かつ/またはそこで時間の大部分を費やします。 時にはこのトピックにリードがいて、彼らに報告します。 スペシャリストになれるのは 1 つのトピックだけです。 スペシャリストの記述は、特定のタイトルの職務記述内の段落です。 スペシャリストはタイトルの後にリストされます。たとえば: Developer, database specialist（Developer, database に短縮しないでください）。 複数を持てる場合や、時間の大部分をそこで費やさない場合、それはおそらく 専門性（エキスパート） です。 スペシャリストは、同じタイトルを持つ他の人と同じ職務記述を持つため、同じキャリアパスと報酬を持ちます。

エキスパート

エキスパートとは、ある特定のトピックについて平均以上の経験を持つことを意味します。 一般的に、GitLab で一定期間働いた後、複数のトピックのエキスパートになります。 これにより、会社の人々が、より詳しい人を素早く見つけられるようになります。 これらのラベルを自分自身に追加し、マージリクエストをマネージャーに割り当ててください。 専門性は、スペシャリスト と異なり、職務記述にはリストされません。

Production Engineer の場合、「Expert」としてのリストは、その個人が現在別のチームに組み込まれていることも意味する可能性があります。 組み込まれている期間の後、彼らは上記で説明した通常の意味でのエキスパートになります。

Reliability と Production Readiness に焦点を当てた Developer は、Reliability Expert と命名されます。

メンター

エキスパートは個々の Issue または問題に対する支援を提供する可能性がある一方、メンターシップは誰かのキャリア、機能スキル、かつ/またはソフトスキルを成長させる手助けに関するものです。それは他人の成長への投資です。

エキスパートをハードスキル（Ruby、国際雇用法など）であり、ソフトスキル（コンフリクトを通じてのマネジメント、セールス組織でのキャリア開発のナビゲートなど）ではないと考える人もいます。

特定の領域でメンターになりたい場合、その情報をチームページに追加してください。GitLab 内部でメンターになりたいか、外部でなりたいか、両方か、必ず明記することが重要です。チームページの専門性セクションで指定する方法の例: Mentor - Marketing, Internal to GitLab または Mentor - Development (Ruby), External and Internal to GitLab。

その他の考慮事項

タイトル中の「Manager」という単語は、ピープルマネジメントや構造を意味しない

一部の個人貢献者（直接の報告者がいない）は、タイトルにカンマなしで manager が含まれます。これらのタイトルは、私たちの会社構造でもサラリーカリキュレーターでもピープルマネージャーとみなされません。例として、product manager、accounting manager、account manager、channel sales manager、technical account manager、field marketing manager、online marketing manager、product marketing manager があります。manager の後にカンマがある人は、私たちの会社構造でピープルマネージャーです。

「Team」、「team member」、「community」の用語

「team」という用語は最小グループに使用されます。team は、マネージャーとその報告者として定義されます。「team」は group や department を指しません。

私たちは、会社で働くすべての人を「team members」と呼びます。「team」が小さいグループを指すことを考えるとこれは少し混乱しますが、私たちが検討した代替案すべてに対して「team member」が好ましいと考えています:

1. GitLab Inc. のために働く多くの契約者がいるため、「employees」という用語は使いません。
2. 「Staff」は GitLab Inc. で働く場合のユーザープロファイル上に表示されます が、これは エンジニアリングレベル でもあるので混乱します。
3. 「Gitlabbers」はもう使われません。より広いコミュニティを包含しないためです。
4. チームメンバーを「Tanuki」（私たちのロゴを指す）と呼ぶことを検討しましたが、動物の種で人間を指すのは混乱します。

GitLab は GitLab という会社よりも大きいプロジェクトです。GitLab を取り巻くコミュニティを、会社の人々を含むものとして見ることが本当に重要です。したがって、「community」という用語を使うとき、それはすべての GitLab ユーザーと貢献者を指すべきです - チームメンバーを含む。

チームメンバーでないユーザーと貢献者を指すには、「wider community」を使います。

詳細については、GitLab ライティングガイドライン をご覧ください。

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