Content last updated 2026-10-16

昇進と異動

GitLab の昇進と異動に関する情報とプロトコル。

このページは現在レビューおよび作成中です

最新情報については、こちらの Loop ページを参照してください。

VP+ 役割の採用

社内昇進と新しいリーダーシップ役割の両方に一貫したレベルのレビューを確保するため、すべての新規 VP 以上の「採用予定」役割は e-group によってレビューおよび承認されます。シニアリーダーは、提案された役割の正当化ドキュメントを作成するために、People Business Partner とパートナーシップを組む必要があります。正当化ドキュメントにより、e-group は役割のビジネスニーズと、組織内でどのように整合するかをよりよく理解できます。

このレビューは、e-group オフサイト中に行われる組織設計議論の一部です。

提案された役割は、組織がビジネスニーズへの可視性を持ち次第すぐにレビューできます。ただし、新しい VP+ 役割のニーズがこれらの組織設計議論外で発生した場合、採用慣行のアジャイル性と競争力を引き続き確保するために、週次の e-group ミーティング中にレビューできます。

正当化ドキュメントは次の場合に使用される必要があります:

  1. 既存の役割をより高いレベル (VP+) でバックフィルすることを決定した場合
  2. VP+ 役割の新規ヘッドカウントを開く場合 (現在の会計年度のヘッドカウント計画に組み込まれていなかった)

マネージャーのプロセス: 昇進のリクエスト

  1. 昇進の変更を年 2 回の昇進サイクルで処理するか、Greenhouse で処理するかを判断します
  2. 年 2 回の昇進サイクルで進める場合は、People Business Partner およびリーダーシップと協力して、計画プロセスに先立って昇進を推薦し、チームメンバーが計画とキャリブレーションに含まれるようにします。この時点で、昇進または報酬変更ドキュメントが作成されていることを確認します。
    • 昇進を推奨しているチームメンバーが director またはそれ以上の場合は、Director 以上への昇進を参照してください。
  3. 昇進/報酬変更が Greenhouse を通じて処理されるべき場合は、Greenhouse 昇進/異動プロセスセクションで概説されているステップに従ってください。
  4. 昇進が例外と見なされる場合は、例外の処理方法: Workday でのサイクル外昇進リクエストの提出で概説されているステップに従ってください。

プロセスを開始する前に考慮すべきこと:

  • チームメンバーが昇進を通じて次のレベルに移動する準備ができていても、ビジネスの性質上、その特定の役割または次のレベルが利用できない場合があります。たとえば、チームメンバーは Manager または Director の役割の準備ができていますが、ビジネスにはその時点で追加のマネージャー/ディレクターのニーズ、予算、範囲がありません。そのポジションは将来利用可能になる場合とならない場合があります。
  • 空席がジョブページを通じて広告されている場合、個人は役割の応募を提出する必要があります。同様に、空席投稿がない場合は、誰もが応募し検討される機会を持てるよう、空席投稿を作成し #new-vacancies Slack チャンネルに共有する必要があります。

報酬の増加の推奨

GitLab では、昇進が報酬の観点でインパクトがあり、同じ役割のピアと公平であることを確保しています。マネージャーは、直接の部下のキャッシュ報酬の増加の推奨を提案します。質問がある場合は、People Business Partner または Total Rewards チームに気軽に連絡してください。

昇進報酬ガイドライン

  • チームメンバーが同じ職務ファミリー内のあるレベルから次のレベルに昇進する場合、報酬範囲の最小値と中央値の間に持っていくのが一般的です。
  • Total Rewards チームは通常、昇進の一部としてキャッシュ報酬への 5 〜 10% の増加を推奨します。追加のエクイティは、昇進のエクイティに基づいて固定されます。
  • 以下の条件を持つ昇進は、Total Rewards チームとエグゼクティブ承認者への追加の正当化が必要です。昇進ワークシートのコメントとしてビジネス上の正当化を追加してください。
    1. 10% を超える増加

異動報酬ガイドライン

Greenhouse で異動の報酬をレビューする際、Total Rewards チームは、以下の一般的なガイドラインを使用してオファー詳細を承認する前に、同じような役割間で内部公平性を確保します:

  1. ラテラル異動 (異なるまたは同じ職務ファミリー、同じグレード): 通常、チームメンバーがラテラル異動で増加を受けることは期待しません。これには、グレードまたは職務レベルの変更なしにテリトリー、セグメント、専門分野の変更を受けるチームメンバーが含まれます。
  2. 昇進異動 (異なるまたは同じ職務ファミリー、より高いグレード): 通常、チームメンバーが 5 〜 10% の増加を受けることを期待します (昇進の期待される増加に整合)。
  3. その他の異動タイプ: ケースバイケースでレビューできる他の異動があります。たとえば、誰かが異なるまたは同じ職務ファミリーのより低いグレードに異動する場合、役割の市場レートとの整合性を確保するために報酬が下方調整される場合があります。レビューを行うために Greenhouse で Total Rewards チームをタグ付けしてください。

Workday サイクル外昇進承認プロセス

このセクションでは、People Business Partner が Workday で昇進リクエストを送信した後の承認チェーンについて説明します。

  1. 変更は、マネージャー、次のレベルマネージャー、e-Group リーダーに承認のためにルーティングされます。
  2. リクエストが承認された場合、People Operations チームは DocuSign で職務変更レターをステージングします。
  3. DocuSign はマネージャーにチームメンバーと昇進について議論するよう促します。マネージャーは、1-1 meeting by sharing the job change letter on the call のとおり、1 対 1 のミーティング中に職務変更レターを共有して、変更をチームメンバーに伝えます。マネージャーとチームメンバーはレターを処理/署名します。署名後、マネージャーは Slack の #team-member-updates チャンネルで昇進をアナウンスします。アナウンスでは、マネージャーは個人が昇進基準をどのように満たしたかを記述し、お祝いを述べます。
  4. 部門とマネージャーの変更については、People Operations チームメンバーは組織変更チェックリスト Issue を作成します。

People Operations チーム向け: 昇進、内部異動、報酬変更の処理

  1. リクエストが Workday を通じて承認された場合、People Operations チームは職務変更レターを作成しますが、リクエストが Greenhouse を通じての場合は、CES チームが職務変更レターを作成し署名が完了したことについて、People Operations Team will be notified via the People Operations team email のとおり People Operations チームのメール受信箱に通知が届きます。

職務変更レター

  1. 国別の署名要件をレビューし、それに従って職務変更レターを処理します。すべての法人と国の場所で職務変更レターが必要なわけではないことに注意してください (たとえば、米国のチームメンバーは職務変更レターを受け取りません)。
  2. 該当する職務変更レターテンプレートのコピーを作成し、Workday リクエストに基づいてすべての適用可能な情報を入力し、該当する署名者または会社署名スタンプを追加します。発効日は次のとおりです:
    • 変動報酬の変更があるセールス担当者の場合、発効日は法人に関係なく常に月の 1 日です。
    • チームメンバーが報酬の変更なしのラテラル移動を行う場合、開始日は任意の月曜日にできます。
    • 米国のチームメンバーの場合、発効日は 1 日または 16 日のいずれかである必要があります。ペイロール締切日が現在のペイ期間で経過した場合、発効日は次のペイ期間の開始にする必要があります。発効日を決定する際は、GitLab Inc および Federal Payroll カレンダーを参照する必要があります。
    • たとえば、変更が 6 月 22 日に処理される場合、この日付は 6 月 23 日のペイロール締切日より前なので、発効日は 6 月 16 日にする必要があります。
    • 変更が代わりに 6 月 25 日に処理される場合、これはペイロール締切日後なので、発効日は 7 月 1 日にする必要があります。
    • カナダのチームメンバーの場合、発効日は、変更が処理されるタイミングに応じて、ペイロール締切日に最も近く、それ以降ではないペイ期間の開始にする必要があります。発効日を決定する際は、GitLab Canada Corp Payroll カレンダーを参照する必要があります。
    • たとえば、変更が 6 月 15 日に処理される場合、6 月 6 日のペイロール締切日は経過しているので、これは 6 月 20 日の締切日を持つ次のペイ期間に行きます。6 月 20 日の締切日に対応するペイ期間の開始は 6 月 21 日であるため、6 月 21 日が発効日になります。
    • その他のすべての変更については、月の 8 日以前に処理される場合は当月の 1 日、月の 8 日を過ぎてから処理される場合は翌月の 1 日が発効日です。
    • たとえば、GitLab Ltd チームメンバーが 6 月 7 日に処理される変更を持つ場合、これは 6 月 1 日に発効します。
    • 変更が代わりに 6 月 15 日に処理される場合、これは 7 月 1 日に発効します。
  3. エクイティ報酬は、米国外の誰かの職務変更レターには含まれてはなりません。RSU 情報を含む別のレターが職務変更レターに含まれていることを確認してください。
  4. チームメンバーがフランスに雇用されている場合、レターでの分類を確認できるよう、Legal Employment チームと職務変更レターを共有してください。
  5. 会社のスタンプのみが必要な場合、レターは変更をコミュニケートするためにチームメンバーのマネージャーにメールで送られる必要があります
  6. 電子署名が必要な場合、DocuSign でレターをステージングし、GitLab メールアドレス経由で署名する以下のチームメンバーを追加します:
    • マネージャー用にラジオボタン (追加のものは削除) を追加して、マネージャーが 1:1 Zoom コール中に職務変更レターを共有することにより、チームメンバーに変更をコミュニケートし、そして再度ラジオボタンを 1 つ追加 (追加のものは削除) して、#team-member-updates Slack チャンネルでアナウンスします。
    • チームメンバー用の署名フィールドを追加します
    • チームメンバー用の署名日フィールドを追加します
    • 注: a) ドキュメントを準備する際に「Set signing order」オプションが選択されていること、b) ラジオボタンのみが 必須フィールドのオプションの選択を可能にするため、チェックボックスではなくラジオボタンを選択することを確認してください。これにより、マネージャーがレターのタスクをチェックせずにレターを処理することを禁止します。
  7. 署名済みのレターを、Workday プロフィール内のそれぞれのチームメンバーのドキュメントタブに保存します。
  8. 組織変更チェックリストのここで述べた基準を満たしている場合、People Operations Specialists は Workday からアラートを受け取り、異動するチームメンバーのために Issue が開かれることを確実にします。

暫定および代理役割

暫定 (Interim)

エンジニアリング部署内のキャリア開発構造の一環として、暫定 (interim) および代理 (acting) 役割の機会が時折発生します。暫定および代理役割がエンジニアリングキャリア開発にどのように適合するかについての詳細は、エンジニアリングキャリア開発ハンドブックページを参照してください。暫定および代理プロセスに関する情報については、以下を続けて読んでください。

暫定期間の開始

定義セクションで強調されているように、すべての暫定役割は (応募者の数に関係なく)、Greenhouse 応募および面接プロセスを経る必要があります。面接プロセスのステップは、採用マネージャーと次のレベルリーダーによって決定されます。これには、標準の GitLab 採用プロセスのいくつかのステップが含まれます。暫定役割への応募に興味のあるチームメンバーのプロセスは次のとおりです:

  1. チームメンバー: Greenhouse で暫定ポジションに応募します。

チームメンバーが面接プロセスを成功裏に完了し、暫定期間に選ばれたら、チームメンバーが暫定役割で成功するための準備が整うように、以下のステップを取る必要があります。

  1. CES: 暫定期間の開始を最終化するための職務変更レターを発行します。レターには、暫定職務タイトル、開始日、終了日 (既知の場合) を含める必要があります。職務変更レターは重要です。これは、Total Rewards が Greenhouse からの変更を通知される方法です。
  2. People Operations: Workday でチームメンバーの職務およびビジネスタイトルを更新して、暫定役割を開始したことを反映します (例: Senior Manager, Engineering (Interim))。この更新は、暫定の開始日と終了日を追跡するための SSOT として機能し、現在暫定役割で執行している人物に関する透明性を提供します。暫定期間は報酬への影響がないため、職務コードと職務レベルは同じままです。つまり、Change Job プロセスを開始する際に他のフィールドを更新しないでください。
  3. 現在のマネージャー: 暫定マネージャーに移動する必要のある直属の部下がいる場合、この変更は現在のマネージャーまたは必要に応じてそれぞれのグループの People Business Partner が Change Manager プロセスに従って Workday で開始する必要があります。ここでの哲学は、チームメンバーが面接プロセスを成功裏に経て、マネージャー役割の暫定期間に対応できる準備ができていることを示したのであれば、Workday で直属の部下を持つために必要なレベルの EQ と裁量を持っているということです。もちろん、暫定期間が昇進で終わらない場合、チームメンバーは引き続き機密情報を機密として扱うことが期待されます。

暫定期間の終了

暫定期間が終了する際、次の 2 つの結果のいずれかが発生する可能性があります:

  • チームメンバーが成功基準に整合して暫定期間を成功裏に完了し、永続的に暫定役割に移動します。
    • 一般的なガイドラインとして、暫定期間は 30 日未満にならず、4 か月を超えないようにする必要があります。
    • People Business Partner は、変更を公式にするために、昇進ドキュメントを含む Change Job 操作ガイド を使用して Workday で昇進リクエストを送信する必要があります。Workday では、変更の理由を Promotion - Promotion にする必要があります。暫定までの達成と暫定中の達成を昇進ドキュメントに使用できます。マネージャーは、昇進ドキュメントを作成し、報酬の増加を推奨する責任があります。注: チームメンバーの移動が昇進につながる場合にのみ、昇進ドキュメントが必要です。ラテラル移動の場合、昇進ドキュメントは必要ありません。
  • チームメンバーが暫定期間を成功裏に完了しないか、マネージャートラックを追求したいものではないと決定し、暫定期間前の役割に戻ります。
    • 暫定期間が成功しなかった理由がチームメンバーに明確になるよう、チームメンバーと採用マネージャー間でフィードバックセッションが行われるべきです。
    • People Business Partner は、マネージャーのリクエストに応じて、暫定期間が終了したらチームメンバーの職務タイトルを元に戻すために、Workday Change Job プロセスおよび承認フローを Workday で送信する必要があります。
    • 暫定期間を成功裏に完了しないことは、チームメンバーが将来同様の役割に移動できないことを意味するわけではありません

結果に関係なく、暫定期間が終了する際、マネージャーは適格基準に従って暫定ボーナスをレビューし、チームメンバーのために暫定ボーナスリクエストを送信する必要があります。完全なボーナス計算がボーナス提出のコメントに記載されていることを確認してください。

Workday での暫定の移動の更新

暫定役割への職務変更レターを受け取ったら、以下のように変更を処理します:

  1. レターを Workday の Documents > Contracts & Changes Document Category に保存します
  2. 報酬変更をレビューします
  3. アクセスレベル
    • 暫定役割 - アクセス変更 (必要な場合)
  4. 職務タイトルを更新します (必要な場合)
  5. マネージャーを更新します (必要な場合)

注: 代理役割の場合、Workday で変更は行われません。代理ポジションを追跡するために、マネージャーはこのフォームを完成させる必要があります。

代理 (Acting)

「代理」で役割にいる人は、一時的に役割を占有し、元の役割に戻る人です。役割で「代理」を務めることは、その役割が個人のキャリア開発パスの目標に合うかを判断するために役割を実験するためかもしれませんし、永続的に役割を埋めるために誰かを雇う間、空いた役割を埋めるためかもしれません。暫定はエンジニアリング部署にのみ適用されますが、代理は GitLab 全体で使用されます。

代理役割は通常昇進で終わらないため面接は必要ありません。また、通常、Workday で直属の部下が代理マネージャーに移動することもありません。 代理ポジションのために誰かを選択するプロセスは次のとおりです:

  • 今後の代理役割はスタッフミーティング中に議論されます。
  • リーダーシップは、今後の代理役割のためにチームメンバーから関心を集めることができます。
  • 採用マネージャーは、代理役割に最も適したチームメンバーを決定します。
  • 先に進む前に、部門長が代理期間と選択された候補者を認識しサポートしていることを確認してください。

代理期間が終了する際、マネージャーは適格基準に従って暫定ボーナスをレビューし、チームメンバーのために暫定ボーナスリクエストを送信する必要があります。

代理役割と内部モビリティ

チームメンバーが代理の役割で働いていて、その役割が公式に募集中のポジションになる場合、非公式の代理の役割にいるチームメンバーは、他の候補者と一緒にオープン役割の検討対象となる可能性があります。チームメンバーが代理ポジションを永続的にすることに興味を示す場合、以下のプロセスに従う必要があります:

  1. チームメンバーがマネージャーに、ポジションを永続的に追求することへの興味を表明します。
  2. チームメンバーが、代理の役割でのこれまでのパフォーマンスについてフィードバックを受けるために、採用マネージャーに連絡します。
  3. チームメンバーは、標準的な採用慣行に整合して、Greenhouse でポジションに応募することを歓迎されます。 注: 採用マネージャーと代理チームメンバーが相互に同意して役割の検討を進める場合、ポジションが現在の役割と同じまたはより低い職務レベルで、同じ部署内にあり、ピープルマネジメントポジションでない場合、正式な面接プロセスは必要ない場合があります。採用マネージャーが面接プロセスを含めないことを好む場合、整合する People Business Partner (PBP) と接続して、彼らがサポートしていることを確認する必要があります。代理ポジションにいるチームメンバーが時間をかけてポジションで成功する能力を実証する独自の経験のため、この面接例外の可能性が存在します。
  4. チームメンバーが正式にオープン役割に移動した後、バックフィルポジションが作成されます。

降格

降格は常に後退とは見なされません。チームメンバーが新しいスキルを習得する機会、または彼らの興味のある領域により密接に整合する役割に移動する機会である可能性があります。あなたの直属の部下の 1 人を降格するには、マネージャーは以下のステップに従う必要があります:

  • 降格がパフォーマンスによる場合、マネージャーは Team Member Relations とパフォーマンスの問題や可能な降格について議論する必要があります。
  • 降格には Google ドキュメントでの報酬とエクイティのレビューも含める必要があります。マネージャーはこれらのトピックについて Total Rewards チームに相談する必要があります。
  • チームでの降格と変更 (もしあれば) について合意に達したら、関連する Google ドキュメントが完了した後、降格を Compensation Group がレビューおよび承認するためのエスカレーションポイントとして機能します。
  • 承認されたら、マネージャーは個人に通知し、Compass 経由でリクエストを提出して必要な変更をリクエストする必要があります。その後職務変更レターが作成されます。
  • その後、People Operations チームは People Operations チーム向け: 昇進と報酬変更の処理の下にリストされているプロセスに従う必要があります。
  • コミュニケーションは個人への敬意のために必要な人に限定し、公開してはなりません。
  • マネージャーは必要なアクセスリクエストまたはアクセス変更リクエストを開始します。

職務タイトル専門分野の変更

職務タイトルの専門分野は、ステージ、グループ、および/または責任範囲内のチームメンバーの特定の焦点領域を示すために使用されます。これらの専門分野は職務タイトルの一部ではありませんが、ステージ、グループ、および/または焦点領域への投資に関するレポートに反映されるために使用されます。また、People Group とリーダーが組織健全性指標と比率をレビューするために活用するリソースでもあります。

チームメンバーの職務タイトル専門分野に変更が必要な場合、マネージャーは新しい職務タイトル専門分野情報と変更の発効日 （Data Correction を選択） を含む People Operations チーム向けの Compass ケースを作成する必要があります。既に存在しない新しい職務タイトル専門分野を作成する必要がある場合は、Workday: Job Title Specialty Request テンプレートを使用して Workday で作成してもらうために Issueを開いてください。Workday でこのフィールドが正確であり続けることを確実にすることは、マネージャーの重要な責任です。

マネージャー向けの職務タイトル専門分野ガイダンス

GitLab のさまざまな部署は、職務タイトル専門分野をさまざまな方法で管理しています。以下に、一貫したアプローチを確保するために職務タイトル専門分野をどのように考えているかを文書化するために、特定の部署向けのガイダンスを概説しました。

チームの現在の職務タイトル専門分野のレポートに簡単にアクセスするには、以下のステップに従うことができます:

  • Workday にログインします
  • 検索バーに “My Team Job Title Specialties” と入力します
  • あなたの組織のために “OK” をクリックします

Development および Infrastructure 部門の場合

  • 誰が専門分野を持つべきか:
    • IC: ステージおよび/またはプライマリーグループ (該当する場合) を持つべきです
    • ピープルマネージャー: IC を管理する Manager、Senior Engineering Manager、Group Product Manager は、ステージおよび/またはプライマリーグループ (該当する場合) を持つべきです
  • 職務タイトル専門分野の更新をリクエストする際は、以下のフォーマットに従ってください:
    • Product/Categories をレビューし、使用するグループ名がこれらに一致することを確認します。一致しない場合は、Product Manager に接続して確認し、必要に応じて更新するために協働してください。
    • 職務タイトル専門分野フィールドにステージとグループの両方を追加します
      • 例: “Authentication” の代わりに “Govern: Authentication” を追加
      • 重要: ステージとグループの間のコロン (:) の後にスペースを残してください。。たとえば、Create: Source Code は正しいフォーマットで、Create:Source Code は正しくないフォーマットです。これは、レポートを取得する際に投資の整合性に対する正確なカウントを確保するのに役立ちます。
    • 各人をレビューし、1 つのグループのみがリストされていることを確認します。
      • 注: 2 つのグループがある状況では、プライマリーグループを選択します。
    • すべての専門分野情報が Job Title Specialty (Multi-Select) フィールドではなく Job Title Specialty フィールドにあることを確認します。

Customer Support 部門の場合

  • 誰が専門分野を持つべきか:
    • IC: 役割の焦点が Global、Federal、Readiness (該当する場合) であることを示します
    • ピープルマネージャー: Manager と Senior Manager が役割のプライマリーフォーカスを示します (該当する場合)。

注: サポートの場合、ステージやグループではなく、職務タイトルに捉えられていない役割の焦点に紐付いています。

  • 職務タイトル専門分野の更新をリクエストする際は、People Operations に連絡する際に必ず以下のフォーカスエリアのいずれかを使用してください:
    • Global
    • Federal
    • Readiness

Workday でのマネージャーセルフサービス: 職務情報変更

職務情報の変更は、報酬関連ではない Workday のチームメンバーのプロフィール上の任意の情報を更新するために使用されます。現在のマネージャーがすべての職務情報変更リクエスト (チームメンバーのマネージャーを変更するリクエストを含む) を送信します。これらの変更は、コンプライアンス上の理由から承認証跡を持つために Workday を通じて必要です。

現在のマネージャー向け: マネージャー変更の処理

このジョブエイドは、Workday 内でチームメンバーを別のマネージャーに移動する方法に関する指示をピープルマネージャーに提供するのに役立ちます。直属の部下を移動する必要のあるマネージャーが利用できない場合は、おそらく「supervisory organization」が作成されていないことを意味します。管理レベルが「Manager」と表示されていても、Workday でチームメンバーが直属の部下を持つには監督組織が必要です。監督組織は、彼らが管理しているチームに固有の名前を持つべきです (例: Commercial Sales - EMEA、Content Marketing (John Smith)、Backend Engineering - Ruby)。監督組織のセットアップが必要なチームメンバーの名前、固有の名前、監督組織の発効日を Compass 経由で People Operations チームに連絡してください。Workday でセットアップをお手伝いします。

セールスマネージャーへの注: チームメンバーが Workday で正しいセールスマネージャーの下に移動されない場合、セールスコミッションのクレジットが正しいマネージャーにロールアップされません。コミッション対象役割の追加の昇進と異動の考慮事項はこちらを参照してください。

People Operations 向け: マネージャー変更の処理

  1. People Operations Specialist は Okta 経由で Workday にログインして、Workday で異動を承認します > 右上隅の Inbox をクリック
  2. ‘Transfer’ というタイトルのビジネスプロセスと ‘Manager to Another Manager’ という理由をレビューします > クリック: approve

EBA がシニアリーダーシップを更新するプロセス:

  1. People Operations チームに変更を Workday で行うようリクエストし、発効日を提供するために、Compassでケースを作成します。
  2. People Operations チームが Workday で変更を処理します。
  3. 完了したら、チームは EBA にフォローアップして、すべての変更が行われたことを知らせます。
  4. その後、EBA はチームページで変更を行う必要があります。

People Operations 向け: 職務情報変更リクエストの処理

  1. すべての職務変更リクエストを監査し、変更が Payroll トラッカーで捕捉されていることを確認します。
  2. Job Title Specialty 変更リクエストの場合、マネージャーは Workday でチームメンバーの Speciality を更新してもらうために People Operations チーム Compassに連絡します。
    • People Operations チームメンバーは、タイトルが既に Workday に存在するかどうかを確認する必要があります。存在しない場合は、Job Speciality がそれぞれの部門ハンドブックページに追加されているかどうかをチェックします (例: https://handbook.gitlab.com/handbook/engineering/ai/search/、または People Operations チームメンバーがそれを追加するためにそれぞれの Issue にタグ付けされているかどうか。不明な場合は、それぞれの People Business Partnerに連絡してください)。

部門異動

募集中の役割に応募することに興味がある場合は、Greenhouseまたは #new-vacancies Slack チャンネルで見つけられる社内求人掲示板リンクを通じてそうしてください。

応募を進められるようにするには、以下の適格性ガイドラインを満たす必要があることを理解してください:

  • パフォーマンス適格性のガイドライン:
    • タレントアセスメント中に Performing または Exceeding Performance レベルと評価されたチームメンバーは、別の役割の検討対象となる資格があります
    • パフォーマンスが Developing と評価されたチームメンバー、または書面によるパフォーマンスマネジメントを積極的に受けているチームメンバーは、対象とならない場合があります。これらの状況では、進めるためにマネージャーおよび/または PBP の承認が必要です。
    • タレントアセスメントを受けていないチームメンバーは、進めるためにマネージャーおよび/または PBP の承認が必要です
    • 役割での期間の適格性は、現在の役割で 6 か月になります。これらの例外:
    • ビジネスインパクト (収益依存、暫定役割から永続役割への移行)
    • ビジネス主導の異動 (再編成の例)
    • SDR/BDR 12 か月の役割期間

社内応募者は応募提出前に現在のマネージャーまたは People Business Partner と話す必要があることに注意してください。公式の応募は、チームメンバーが募集中の役割に応募するか、Talent Acquisition チームに連絡することによってシグナルされます。役割に関する非公式の会話では、チームメンバーがマネージャーに通知する必要はありません。内部役割への関心をマネージャーにコミュニケートすることに懸念がある場合は、People Business Partner に連絡してください。

詳細については、私たちの内部採用プロセスハンドブックページを参照してください。

社内応募者向け

異なる職務ファミリー

  • 異動に興味がある場合は、新しいポジションに応募するだけです。新しい役割が良いフィットかどうか確信が持てない場合は、採用マネージャーと時間を取って役割と必要なスキルについてさらに学んでください。その会話の後、社内の機会を追求することに興味がある場合は、役割に応募する意図を現在のマネージャーに伝えることをお勧めします。応募に許可は必要ありませんが、彼らに対して透明であることをお勧めします。ほとんどの人は、リファレンスチェックとして連絡してきた誰かからあなたの移動を知るより一般的に良いため、その透明性を評価するでしょう。これを、現在のマネージャーおよび/または過去のマネージャーからのあなたのパフォーマンスに関する潜在的な新しいマネージャーに与えられるフィードバックについて議論する機会としても使用できます。
  • 異動は、新しいポジションに応募する応募プロセスを経る必要があります (ジョブページで応募)。チームメンバーは、空席記述で概説されているフルインタビュープロセス全体を経る場合があります。標準面接プロセスへの一般的な例外は、行動または「価値観の整合性」段階です。リクルーターは、標準面接プランへの変更の背後にある理由をチームメンバーの Greenhouse プロフィールに文書化します。役割またはプロセスに関する質問がある場合は、部門または部署の People Business Partnerに連絡するか、私たちの内部採用プロセスハンドブックページを訪問してください。いずれの場合も、異動が確認される前に、該当する People Business Partner にメールで通知する必要があります。
  • 異動の場合、異動先のマネージャーが GitLab の社内リファレンス (以前と現在のマネージャーに限定) で確認することが期待され、要求されます。ピアまたは直属の部下と社内リファレンスチェックを行わないでください。質問または例外については、リクルーターと People Business Partner に関与させてください。
  • 応募者、現在のマネージャー、または異動先のマネージャーが、異動を調整するためにプライベート Slack チャンネルを作成することが推奨されます (必須ではありません)。関連するマネージャー、ディレクター、People Business Partner、Finance Business Partner、リクルーターなど、関与する人を全員招待します。
  • 現在のマネージャーがエンジニアリングで役割をバックフィルする必要がある場合、彼らはこのプロセスに従う必要があります。他の部署の場合、彼らは部門長、リクルーター、Finance Business Partner と協働してバックフィルが利用可能であることを確認する必要があります。異動が確認されたら、現在のマネージャーはリクルーターと Finance Partner と協働してバックフィルのための GHP IDを取得し、Greenhouse で役割を開きます。
  • オファーが行われる前に、リクルーターは、チームメンバーと異動先のマネージャーが現在のマネージャーに実際に連絡を取ったことを確認します。彼らは新しい機会と、チームメンバーにオファーが行われることを議論します。
  • Talent Acquisition チームは、該当する場合、オファーが行われる前にポジションが少なくとも 3 営業日掲載されていることを確認します。
  • 報酬とエクイティは、新しいレベルとポジションを反映するために採用プロセス中にレビューされる場合があります。
  • 面接後、マネージャーと GitLab チームメンバーが異動を進めたい場合、社内リファレンスをチェックする必要があります。マネージャーは異動をブロックできませんが、決定に情報を与えるのに役立つ良いフィードバックがあることがよくあります。GitLab チームメンバーは、新しいチームへの好みを説明し、新しいマネージャーに与えられるフィードバックを理解するために、マネージャーと話すことが推奨されます。また、パフォーマンス要件は役割間で常に等しいわけではないため、GitLab チームメンバーがある役割で苦労する場合、それらの弱点は新しい役割ではそれほど顕著ではないかもしれません、その逆もあります。
  • リクルーターと採用マネージャーは、社内候補者とオファー詳細をレビューし、採用プロセスに従って Total Rewards チームから職務変更レターが送付されます
  • チームメンバーが異動した場合、新しいマネージャーは #team-member-updates Slack チャンネルでアナウンスし、必要な追加のオンボーディングまたはオフボーディングを開始します。新しいマネージャーが異動アナウンスを行う前に、チームメンバーの現在のマネージャーと、現在のチームがチームメンバーの新しいポジションと異動について通知されていることを確認する必要があります。
  • 機能的役割を変更するチームメンバーは、新しい機能のオンボーディングを完了する必要があります。たとえば、Frontend の仕事に移行または取り組む Backend Engineer は、Frontend Engineer のオンボーディングを行う必要があります。

同じ職務ファミリー、異なる部門または専門分野

チームメンバーが現在の職務ファミリーに残るが、専門分野または部門を変更する場合 (例: Plan から Secure への移動、または Development から Infrastructure への移動)、上記のステップに従います。役割の要件が同じであれば、採用手順が短縮される場合があります。最低限、採用マネージャーがチームメンバーと面接することをお願いします。

役割に選ばれた場合、People Operations チームから部門と専門分野への変更を概説する職務変更レターが送付され、People Operations チームが Workday で処理します。現在のマネージャーが役割をバックフィルする必要がある場合、Finance Partner に連絡する必要があります。

社内部門異動

部門内の別のポジションに興味があり、そのマネージャーがあなたのマネージャーでもある場合、以下を行う必要があります:

  • Google ドキュメントでマネージャーに提案を提示します。
  • 空席がジョブページで広告されている場合、検討されるには応募を提出する必要があります。空席投稿がない場合は、誰もが応募し検討される機会を持てるよう、空席投稿を作成し #new-vacancies チャンネルに共有する必要があります。
  • マネージャーは機能要件を評価します。各レベルは空席記述で定義されている必要があります。
  • 承認された場合、マネージャーは関連する指揮系統を通じてマネージャーの承認を取得する必要があります。
  • 報酬とエクイティが再評価されます。この部分が含まれるまで提案を送信しないでください。
  • チームメンバーが異動した場合、マネージャーは #team-member-updates Slack チャンネルでアナウンスし、必要な追加のオンボーディングまたはオフボーディングを開始します。

内部異動の開始日

GitLab チームメンバーが新しい役割に選ばれた場合、マネージャーは合理的で迅速な異動計画について合意する必要があります。通常、最大 4 週間が合理的な期間ですが、会社、影響を受ける人々、プロジェクトの最善の利益となる方法で異動を完了する判断を行うべきです。

合意された異動日は、現在のマネージャー、新しいマネージャー、異動するチームメンバー間で異動日が整合するように、Greenhouse のオファーレターに反映されるべきです。これは、両方のチームが計画を立て成功への準備を整えるために不可欠です。バックフィルが採用される間、退職するチームメンバーの作業負荷をカバーするために、チームメンバーの以前のチームがシャッフルすることが通常であることに注意することが重要です。これは、スムーズで迅速な異動と前向きなチームメンバー体験を確保するためです。開始日について整合する際、開始日を選択する際にペイロール整合性も考慮してください。

異動を遅らせることは、異動する個人にとって良いチームメンバー体験を確保するために避けるべきですが、不可抗力により異動日を延期する必要がある場合、両方のマネージャーがチームメンバーに伝える新しい異動日について合意する必要があります。

部門異動 マネージャー主導

すべての異動は最終的にチームメンバーが開始する必要があります。

  • 応募プロセス中、採用マネージャーがチームメンバーの現在のマネージャーと透明であることを強く推奨します。そうすることで、現在のマネージャーが異動の計画を立てるための最大限の時間が確保され、全体のプロセスがスピードアップされます。
  • 採用マネージャーは、潜在的に興味のあるすべての候補者を引き付けるために、#new-vacancies Slack チャンネルにオープン役割を投稿する必要があります。
  • 最初にマネージャーと話さずに潜在的な候補者に直接連絡することは強く非推奨です。採用マネージャーは、透明性と認識を確保するために、現在のマネージャーのチームメンバーに連絡する意図を共有する必要があります。

昇進が考慮されるとき - 同じ職務ファミリー内

チームメンバーが、自身の職務ファミリー内の 1 つ上のレベルの空席が投稿されているのを見た場合 (たとえば、Intermediate Frontend Engineer が Senior Frontend Engineer の空席を見た場合)、チームメンバーはマネージャーとその機会を探ることについての会話を持つべきです。

マネージャーは、昇進準備状況に関連するチームメンバーのパフォーマンスについて正直であることが責任です。マネージャーがチームメンバーが準備ができていると同意する場合、彼らは周期的な昇進キャリブレーションプロセスに従います。彼らがチームメンバーが昇進の準備ができていないと考える場合、彼らはキャリア開発ドキュメントを見直し、チームメンバーと昇進プランに取り組む必要があります。マネージャーは、チームメンバーがこの時点で昇進の準備ができていないこと、および何に取り組む必要があるかを明確にする必要があります。マネージャーとの会話の後、チームメンバーがまだ役割への応募を提出したい場合、彼らは応募し、外部候補者と同じ面接プロセスを経ることができます。リクルーターは、社内面接プロセスが開始される前に、昇進準備状況の会話が行われたことをマネージャーと確認します。

社内応募者向け - 異なる職務ファミリー

役割が完全に異なる職務ファミリー内 (自身の部署内、または完全に異なる部署内、たとえば、Product Designer が Product Manager の役割に興味がある場合)、チームメンバーは Greenhouse の GitLab 社内求人掲示板に投稿されたものを通じて応募を提出する必要があります。

チームメンバーが応募した後、リクルーターはチームメンバーに連絡して、役割の報酬について連絡を取ります。場合によっては、報酬が現在のものより低いかもしれません。チームメンバーが新しい役割の報酬を理解し同意したら、プロセスを続けることができます。 社内と外部の候補者は、フルスクリーニングコール (上記のように、報酬について議論する短い会話になる) を除き、同じプロセスに従います。ただし、社内応募者が同じ部署にとどまっていて、エグゼクティブレベルの面接がプロセスの一部である場合、エグゼクティブは面接をスキップすることを選択できます。すべての面接フィードバックとノートは、チームメンバーから自動的に隠される社内チームメンバーの Greenhouse プロフィールに捕捉されます。面接が完了した後、社内「リファレンスチェック」が応募者の現在のマネージャーと新しい採用マネージャーによって行われます。 チームメンバーが社内で異動する希望とキャリアの志向についてマネージャーに通知することが推奨されます。マネージャーは、新しい採用マネージャーからではなく、新しい採用マネージャーが現在のマネージャーにリファレンスを確認する前に、チームメンバーから新しい機会について聞くべきです。

役割について確信が持てない場合は、採用マネージャーとコーヒーチャットをセットアップして自己紹介してください。役割への興味と、空席要件と必要なスキルについてもっと学びたいという願望を表明します。その会話の後に、自分が資格を持っているか、移動を快適に行えると感じない場合、採用マネージャーに、次の機会のために準備ができるよう自分自身を開発するために何ができるかについてのガイダンスを提供するよう依頼してください。採用マネージャーと学習のためのインターンシップをセットアップすることも可能かもしれません。

社内昇進/異動のアナウンス

組織変更チェックリストが役割を変更するロジスティクスをキックオフすることを目指す一方で、以下のガイドラインは、関与するすべての当事者からの一貫性と整合性を確保するために、社内昇進と移行のコミュニケーションを導くことを意図しています。

  1. 会社全体のアナウンスの前に、チームメンバーは直近のチームメンバーとニュースを共有する機会を与えられる必要があります。
  2. 昇進には通常エクイティ付与も含まれます。エクイティ付与金額が職務変更レターに記載されていない場合、マネージャーは以下のステップに従って Workday にナビゲートしてチームメンバーにコミュニケートする金額を見つけることができます:
    • Workday にナビゲート
    • 昇進したチームメンバーのプロフィールに行きます
    • 左パネルの Job をクリックします
    • 上部のタブから Worker History をクリックします
    • タイトルに Stock Grant を含み、昇進の発効日のビジネスプロセスをクリックします。
    • これにより、イベントを表示する新しいページが開きます。Stock Grant Details テーブルまでスクロールダウンして、提案された金額を確認します。

注意してください: エクイティ付与には取締役会の承認が必要です。コミュニケーションを取る際、マネージャーはこのエクイティ金額が提案された金額であるが、公式に承認されるのは次の取締役会ミーティングであることを強調するべきです。

  1. new manager は #team-member-updates Slack チャンネルにアナウンスを投稿する必要があります。これは理想的には (タイムゾーンが許す場合) 候補者が署名した同日に、職務変更レターへの署名に合わせて行うべきです。
  2. 職務変更レターが署名された同日にアナウンスすることが不可能な場合、アナウンスは候補者が署名してから 24 時間以内である必要があります。
  3. この初期アナウンスに続いて、current managerは、他の関連するチーム固有のチャンネルでこのアナウンスを行うことができます。

すべての場合のアナウンスは、昇進の背後にある「なぜ」を説明する必要があります。チームメンバーの貢献または実際の昇進ドキュメントをいくつかのポイントで共有することは、透明性を促進し、パフォーマンス期待に関する明確さを提供し、他の人が昇進への道を理解するのを助けます。

注: Total Rewards と People Operations チームは、その役割の一部として情報を更新する管理により昇進または異動を可視化できる場合がありますが、アナウンスが行われるまで昇進/異動についてチームメンバーとコミュニケーションを取ってはなりません。_

People Success と Talent Acquisition チーム向け

空席は、Greenhouse 社内求人掲示板を使用して少なくとも 3 営業日内部に投稿されます。役割が内部に投稿されない場合、新しい役割を受けたチームメンバーの Workday ドキュメントに文書化されたビジネスケースが必要です。詳細については部門異動を参照してください。

詳細は職務変更レターセクションで見つけることができます。

組織変更チェックリスト

以前は Career Mobility Issue として知られていた組織変更チェックリストは、チームメンバーが以下の基準のいずれかを満たすときに、彼らのアクセスがレビューされることを確実にするために開かれます:

  • マネージャーから個人コントリビューターへの移行 (Workday 内で Mgr+ から IC への管理レベルの減少として定義)
  • チームの移行 (組織変更チェックリストの目的のために、チーム変更はマネージャーとコストセンターの両方の変更として定義)

管理レベルに移動する個人コントリビューターは、彼らのアクセスがレビューされる必要がある場合とそうでない場合があります。このステップを確認するために、現在のマネージャーと新しいマネージャーに確認してください。アクセスを更新する必要がある場合は、こちらに文書化された AR プロセスに従ってください。

または、チームメンバーが必要なシステムとツールへのアクセスを既に持っている場合、マネージャーは GitLab のトレーニングプロジェクト内にハウスされている ‘Becoming a GitLab Manager’ と ‘Interview Training’ Issue を開くことができます。

  • ‘Becoming a GitLab Manager’ と ‘Interview Training’ Issue を開くには、GitLab のトレーニングプロジェクトを訪問 -> Issue -> 新規 Issue。
  • ‘Description’ で指定されたプロジェクトテンプレートを選択し、下部の Create Issue を選択します。

組織変更チェックリストが必要ない場合 (リクエストは可能):

  • チーム/専門分野の変更だが、アクセスリクエストは不要

マネージャーがチームメンバーの役割に組織変更チェックリストが必要だと感じる他の役割変更については、Compass 経由で People Operations チームに連絡してください。

組織変更チェックリスト作成プロセス

それぞれのローテーションの People Operations Specialistは、(基準に基づく適格なチームメンバーのために) Workday からアラートを受け取ると組織変更チェックリストを開き、サポートのために移行に割り当てられます。

People Operations Lead は、適格なチームメンバーが組織変更チェックリストを開いたかどうかを確認するために、月次レポートを引きます。

組織変更チェックリストは、割り当てられた People Operations チームメンバーによって、自動化された Slack コマンドを使用して、発効日に、またはマネージャーがチームメンバーの移行の準備を開始できるよう発効日後 3 日以内に作成されます。

確実にする重要な事項:

  1. 移行発効日から 2 週間の期日を追加します。
  2. 以前のマネージャーと新しいマネージャーが Issue で正しくリストされていることを確認します。
  3. People Operations リストの下にあるすべての該当タスクを完了します。

組織変更チェックリストが最終化された後の重要なタスク

チームメンバーが成功するためのセットアップには、現在のマネージャーと新しいマネージャーの両方によるアクションが必要です:

  • 必要なシステムと、もはや必要のないシステムのために正しいアクセスリクエストを作成します。
  • 必要なトレーニング Issue を作成します。
  • チームメンバーにチームページ、GitLab プロフィール、Zoom、Slack、LinkedIn などのプロフェッショナルネットワークでタイトルを更新するように思い出させます。関連する場合は、新しい名刺を注文することも思い出させます。
  • 年次報酬レビューの途中の場合、現在のマネージャーと新しいマネージャーが、同期または非同期でフィードバックの引き継ぎを成功裏に手配することが推奨されます。
  • 該当するチームメンバーによるすべての移行タスクは、移行開始日から 2 週間以内に完了する必要があります。

コミッション対象役割の従業員の昇進と異動

このセクションでは、セールスコミッションプランを持つ従業員を昇進または異動するために必要なステップを説明します。昇進または異動が発生するとき、セールスマネージャーは、移行中のスムーズな従業員体験を確保するために特定のステップに従うことが重要です。Sales Operations、Sales Finance、Commissions チームは、必要なシステムを更新し、チームメンバーが新しい報酬プランを受け取ることができるよう通知される必要があります。

注 これらのステップは、People チームとパートナーシップを組んで昇進と異動に必要な他のすべてのステップに加えてのものです。

現在のセールスマネージャー向け

  1. 昇進および/または異動の正しい道を決定します。私たちの昇進プロセスはハンドブックにあります。異動の場合、セールス採用チームにオープン役割があるかどうかを確認してください。昇進および/または異動を処理する前に、必要なステークホルダーとプロセスに従っていることを確認します。
  2. Sales Operations に変更を通知し、Salesforce とテリトリーマッピング SSOT を更新できるよう、テリトリー変更リクエスト Issueを開きます。

Sales Recruiting 向け

  1. Sales Finance に昇進/異動を通知し、Adaptive を更新できるよう、バックフィルヘッドカウント活用 Issueを開きます。
  2. Issue テンプレートの ‘Approval’ セクションに示されているように、Sales Finance とセールス Commissions チームの適切なメンバーにタグ付けします。

Sales Finance 向け

  1. 昇進/異動を考慮してチームメンバーの Adaptive のプロフィールを更新します。
  2. チームメンバーが昇進/異動した空の役割をバックフィルする要請を開く必要があるかどうかについて、リーダーシップと People チームとパートナーシップを組みます。

Sales Commissions 向け

  1. 毎月、Workday で新規採用、昇進、異動を特定します。
  2. ヘッドカウントの変更について Sales Strategy and Analytics チームに通知するための月次 Issue を作成します。Sales Strategy and Analytics チームは、従業員の採用/昇進/異動日から 4 週間以内に、セールス従業員にクォータ1を割り当てます。
  3. クォータは Commissions チームに提出され、すべてのコミッションが管理および監視される Xactly システムに追加されます。
  4. 新しいセールスマネージャーに承認とチームメンバーへのリリースのために新しい報酬プランを発行します。

チームメンバー向け: 新しいマネージャーへの移行

GitLab には、昇進、ラテラル異動、会社の再編、マネージャーの辞職など、チームメンバーがマネージャーを変更する原因となるいくつかの状況があります。新しいマネージャーとの新しい関係を構築するプロセスは時に不確実になる可能性がありますが、この移行プロセスをスムーズに進めるためのリソースがあります:

  • 1-1 の移行は、マネージャー移行の非常に重要な部分です。これにより、新しいマネージャーが重要な議論、成果物などについて最新の状態になり、この情報が移行で失われないことを確実にします。
  • 組織変更チェックリスト引き継ぎテンプレートは、達成、強み、育成領域などが、今後すべて証拠とともに捕捉されることを確実にするのに役立ちます。これにより、キャリア開発の進捗が継続し、マネージャー変更で失われないようにします。
  • 最新の 360 フィードバックレビューと最新のパフォーマンスレビューを新しいマネージャーと共有することは、強みと改善領域について整合し、両方を発展させるためにパートナーシップを組む方法を議論する素晴らしい方法でもあります。

マネージャー向け: チームメンバーをあなたのチームに移動

新しいチームメンバーがあなたのチームに移動するとき、上記の「新しいマネージャーへの移行」の項目に加えて、新しいマネージャーが考慮すべきいくつかの追加事項があります。

  • 以前のマネージャーと新しいマネージャーの間で機密トピックの初期 confidential handover を行います (以前のマネージャー、新しいマネージャー、チームマネージャーとの 1-1-1 とは別)。
  • この confidential handover を定期的に (おそらく移行後 2 週、4 週、6 週) 行います。これにより、初期の質問と考慮事項だけでなく、新しいものが発生したときにも出てくることができます。
  • この引き継ぎには、機密で 1-1-1 では議論されなかったタレントアセスメント計画のために必要な情報を含めます。
  • 新しい直属の部下が次の 6 か月で昇進する可能性がある場合、以前のマネージャーからサポートする情報の引き継ぎを必ず行い、1-1-1 で議論された情報と confidential handover で議論された機密情報の両方を含めて、これを推進する DRI になります。

チームメンバー向け: 役割変更後のタイトルの更新

新しいタイトル変更を反映するために、いくつかの場所でプロフィールを更新する必要があります。以下に限定されません:

フィールドチーム向け:

  • 必要に応じて、名刺。
  • GitLab コミュニティプラットフォーム: Forum、Discord
  • 講演活動のための略歴/履歴書 (Sessionize など)
  • ソーシャルメディアプラットフォーム (LinkedIn、X、Fediverse、Reddit など)

脚注

  1. 会計年度計画中、Sales Strategy and Analytics は Sales Management と緊密に協働して、さまざまなセールステリトリーすべてに値 (フルクォータ) を割り当てます。新しいセールス従業員が参加するとき、ASM は彼らにテリトリーを割り当て (この時点で、事前に決定された値があります)、Sales Commissions は従業員の開始日と役割に基づいてランプスケジュールを適用して、彼らが運ぶクォータに到達します。 ↩︎

最終更新 October 28, 2026: Merge pull request #591 from kyama0/translation/batch-2026-10-28-1 (5d840611)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License