GitLab オフボーディング

オフボーディング概要

オフボーディングプロセスは People Operations チームが進行を担当し、プロセス全体を通じて Team Member Relations、IT Operations、Payroll などの他のさまざまなステークホルダーと協働します。

オフボーディングプロセスに関する質問がある場合は、必ずOffboarding FAQ ハンドブックページを確認してください。

注： 離職するチームメンバーは、雇用最終日の前に、福利厚生のカバレッジへの影響、最終支払、ラップトップのワイプ手配、株式管理に関する情報を含む包括的なメールを受け取ります。

オフボーディングサポート

オフボーディングに関連するシステムアクセスの質問やラップトップのワイプについては、[email protected] にメールを送ってください。

ペイロール関連の質問や未提出の経費精算については、[email protected] または [email protected] のいずれかに連絡してください。

その他のオフボーディング関連の質問について、アクティブなチームメンバーは HelpLab を介して People Operations に連絡するか、すでにアクセスが終了している場合は [email protected] にメールを送ってください。

注： 退職日が変更された場合は、HelpLab を通じて People Operations に連絡してください。チームが Workday を更新します。通知は変更の裏付け書類として使用され、チームメンバーの Workday レコードに保存されます。

自発的な退職

辞任前

1. チームメンバー： 引き継ぎプロセスや退職に関するコミュニケーション計画について話し合うため、辞任を提出する前に直属のマネージャーに連絡してください。
2. チームメンバー： 該当する場合はあなたのロケーションの通知期間を確認し、Workday で辞任を提出する際に通知期間を考慮してください。
3. チームメンバー： Workday にアップロードするための辞任届を作成してください。PEO や第三者雇用主を通じて雇用されている場合は、辞任届のコピーを PEO の担当者にも送付してください。

辞任

1. チームメンバー： 「辞任の提出方法」のジョブエイドのガイドラインに従って、Okta からアクセス可能な Workday で直接辞任を提出してください。
2. チームメンバー： Workday で辞任が提出された後、マネージャーは Workday であなたのオフボーディングを完了するリクエストを受け取ります。退職が完了すると、最終支払、継続的な福利厚生の提供、デバイスの返却などの追加のオフボーディング情報に関するオフボーディングパケットを受け取ることが期待できます。
3. チームメンバー： 質問がある場合はOffboarding FAQ ハンドブックページを確認してください。そのページにない質問がある場合は、HelpLab を使用して People Operations チームに連絡してください。注：あなたのオフボーディング Issue は退職前には表示されません。これはアクセスの deprovisioning に使用される Issue であり、勤務が終了した時点で作成されるためです。

辞任に関する国別の要件

ベルギー

辞任を Workday で直接提出（「辞任の提出方法」の e-Learning またはジョブエイドに従う）し、契約上の要件に準拠することに加えて、ベルギーで辞任するチームメンバーは、辞任届のコピーを [email protected] にもメールで送付する必要があります。

フランス

辞任を Workday で直接提出（「辞任の提出方法」の e-Learning またはジョブエイドに従う）し、契約上の要件に準拠することに加えて、フランスで辞任するチームメンバーは、辞任届のコピーを [email protected] にもメールで送付する必要があります。

ドイツ

辞任を Workday で直接提出（「辞任の提出方法」の e-Learning またはジョブエイドに従う）することに加えて、ドイツで辞任するチームメンバーはGmbH の住所に署名（ウェットインク）された辞任届を提供する必要があり、オフボーディング中に People Operations チームと連携して、適切に提供されることを確認してください。

日本

退職する日本在住のチームメンバーは、この辞任届を記入し、正確な税処理のために現地プロバイダー／パートナーで処理できるよう、月の 10 日までに HelpLab を介してペイロールに送付する必要があります。記入のためにドキュメントをダウンロードまたはコピーしてください。

シンガポール

シンガポール市民ではない辞任するシンガポール在住のチームメンバーは、Letter of Undertaking ドキュメントを記入し、現地プロバイダー／パートナーで処理できるよう、HelpLab を介してペイロールに送付する必要があります。記入のためにドキュメントをダウンロードまたはコピーしてください。

UAE

UAE の労働ビザで PEO/EOR に所属しているチームメンバーが辞任、契約完了、または転職した場合、UAE を離れるかどうかにかかわらず、ビザは会社によりキャンセルされる必要があります。扶養家族がいるチームメンバーは、まず扶養家族ビザをキャンセル（扶養家族が UAE を離れる場合）するか保留にする（扶養家族が残る場合）必要があります - これは扶養家族ビザのスポンサーであるチームメンバーが管理します。PEO/EOR 会社は MOHRE（労働カード用）と GDRFA（居住ビザ用）を通じた必須の労働ビザキャンセルプロセスを処理し、これには 1-3 営業日かかります。チームメンバーはキャンセル後 30 日以内に UAE を離れるか、新しいビザを取得する必要があります。適切にキャンセルしない場合、再入国禁止、超過滞在罰金、最終的なペイロールおよび健康保険処理に関する問題が発生する可能性があります。

退職

1. マネージャー： チームメンバーが Workday で辞任を完了すると、Workday のインボックスにチームメンバーを退職処理するためのプロンプトが届きます。次のジョブエイドに記載された手順に従ってください。辞任が提出されていない場合は、退職するチームメンバーの Workday プロファイルにアクセスし、Actions を選択し、続けて Job Change、最後に Terminate Employee を選択して退職を開始する必要があります。
   • 注：Workday で退職を提出してもすぐにアクセスが終了するわけではありません。チームメンバーの最終勤務日に開かれるオフボーディング Issue が、退職するチームメンバーの deprovisioning プロセスを開始します。
2. マネージャー： 退職が regrettable か non-regrettable かを示すプロンプトが表示されます：
   • Regrettable：チームメンバーの退職が会社、顧客、プロジェクト、またはチームに悪影響を及ぼす。チームメンバーは結果と振る舞いの両面で、特に GitLab の価値観を守る一貫した実績がありました。
   • Non-Regrettable：チームメンバーはパフォーマンス、行動、文化、または価値観の不一致により期待を満たしておらず、コーチングが開始されています。コーチング期間（インフォーマルまたはフォーマル）の開始は、マネージャーが Team Member Relations および／または整合する People Business Partner に連絡することで示されます。
3. マネージャー： チームメンバーの退職に関する詳細が確定したら、departure announcementを計画するためにチームメンバーと時間をスケジュールしてください。追加のガイダンスが必要な場合は PBP に連絡してください。
4. People Business Partner： マネージャーが提出した退職の詳細をレビューし、Workday でポジションをクローズするためのプロンプトを Workday のインボックスで受け取ります。雇用の最終日を含む詳細に同意する場合は Approve をクリックしてください。さらに議論が必要だと感じる場合は、マネージャーおよび／またはチームメンバーとの sync を手配し、さらなるレビューのために退職を差し戻すこともできます。
5. People Ops： トランザクションが完全に承認されると、Workday のインボックス内で退職の通知を受け取ります。

オフボーディング

1. People Ops： Workday の退職レポートに示された最終勤務日の事前に決定された時間に、オフボーディングの親ケースと子ケースが HelpLab で作成されます。すべてのシステムオーナーには、子ケース作成の通知メールが届き、チームメンバーのアクセスを取り消せるようになります。
2. Deprovisioner（システム）： HelpLab で子ケースが届き、チームメンバーのアクセスがオフボードされたことが示され、あなたのアプリケーションから削除する必要があります。
   • SOX システムへのアクセスは緊急に対応する必要があります
   • すべてのタスクは 5 日間の SLA 内に完了する必要があります
   • 子ケース内のタスクに対応し、完了したらケースをクローズしてアクセス削除の完了を示します。
   • 子ケースは 5 日後に自動的にクローズされます。

非自発的な退職

注： 非自発的な退職は、Workday でプロセスを開始する Team Member Relations（TMR）のみが進めます。 チームメンバーの非自発的なオフボーディングは決して簡単ではありません。私たちはこのプロセスを可能な限り人間味のあるものにするために、ガイドラインと情報を作成しました。以下に概説するポイントに加え、underperformanceに関するガイドラインも必ず参照してください。

非自発的プロセス

マネージャーとチームメンバーは、この時点に達する前にunderperformanceに関するガイドラインを進めているはずです。

1. マネージャー: 支援のため TMR スペシャリストに連絡してください。
   • TMR はパフォーマンスの問題が何だったか、どのように対処を試みたか、そしてマネージャー／チームメンバーのドキュメントすべてをレビューします。
   • レビューが完了し、チームメンバーをオフボードする決定が下された後、マネージャーは非自発的オフボーディングコールおよび退職日の最適なタイミングをレビューする必要があります。下記の Last working day のガイダンスに従い、機密性の高い顧客ミーティングが予定されているとき、またはチームメンバーがオンコール中のときに非自発的オフボーディングコールをスケジュールすることは避けることをお勧めします。
   • TMR は Workday でオフボーディングを入力して承認します。入力されると、関連するオフボーディングのステークホルダーは Workday レポートまたは Workday 通知でアラートを受け取ります。
   • TMR は別の Slack チャネルで IT と協働します。
2. TMR: TMR は PBP、マネージャー、組織のリーダーを含むプライベートな Slack チャネルを作成し、オフボーディングと合意されたオフボーディング日をレビューします。
3. TMR: 該当する場合、TMR は TMR スペシャリスト、マネージャー、チームメンバー間のコールの準備として退職金の合意書を準備します。この合意書の準備に関する追加のガイドラインは、以下の Separation and Release of Claims Agreements セクションにあります。退職金合意書が適用されるかどうかを判断するには、PBP および Team Member Relations Specialist がアクセスできる Severance Eligibility ガイドラインを参照してください。
4. マネージャー: 日時が確認されたら、マネージャーはチームメンバーと時間をスケジュールし、TMR スペシャリストにオフボーディングのニュースを共有するためのチームメンバーとのミーティングの Zoom 詳細を含む プライベートで個別のカレンダー招待 を送ります。
5. Payroll: チームメンバーが法定休暇要件のある PEO/エンティティに雇用されている場合、Workday の Time Off セクションを見て、最終支払いで支払われる必要のある休暇があるかをレビューします。
6. Payroll: チームメンバーが co-employer との契約を持っている場合、ペイロールリードは退職するチームメンバーの法定休暇などに関する情報を、co-employer の連絡先にメールで転送します。
7. TMR/マネージャー: 悪いニュースをチームメンバーに伝える最良の方法を議論します。この議論はプライベートなチャットチャネルで行うことができますが、ビデオで行うのが最適です。
8. TMR/マネージャー: 会話のどの部分を誰が担当するかを決定し、必要なら練習します。
   • 必要に応じて TMR はマネージャーにオフボーディングミーティングのスクリプトを提供します。
9. TMR/マネージャー: 退職するチームメンバーがピープルマネージャーの場合、オフボーディングが進行する前にチームに対する退職のコミュニケーション計画が整っている必要があります。コミュニケーション計画には、暫定リーダーの特定、（理想的には）暫定リーダーと direct reports のスケジュールされたミーティング、現マネージャーの退職と暫定リーダーシップを発表するためのスケジュールされたチームコール、最後により広いチームと共有するための適切なチームチャネルでの発表が含まれます。
   • 重要：
     • チームへの通知と質問への回答が最優先です。
     • 退職の発表は #team-member-updates Slack チャネルで行うべきではありません。あなたのチームまたは部門に固有のチャネルを選択してください。
     • ほとんどの場合、オフボーディング当日にチームコールが行えます。
10. TMR/マネージャー: コール 前 に行うオフボーディングアクション（例：admin 権限の取り消し）、コール 中 に行うアクション（例：Slack と Gmail のアクセスを取り消す）、後でもよいアクションを決定します。すべてのアクションのリストはオフボーディング Issue テンプレートを参照できます。この会話は PBP、マネージャー、リーダーとのプライベートな Slack チャネルで行う必要があります。
11. TMR: チームメンバーがプロダクション環境にとってリスクである場合、TMR は Infrastructure Managers にプライベートに連絡してオフボーディングを支援できる人を決定する必要があります。インフラチームメンバーが特定されたら、その人をチームメンバーのオフボーディングのために People Operations、Security、Payroll に送られるプライベートなカレンダー招待に追加する必要があります。オフボーディングの会話が始まると、TMR はチームメンバーの名前を Slack でプライベートにインフラ担当者に送り、オフボーディングプロセスを開始します。

コールの進行

1. マネージャー: 悪いニュースを率直に伝え、遠回しに言って関係者全員にとって不可避な苦痛を長引かせないでください。マネージャーは決定が最終的であることを明確にしますが、この決定に至った経緯を説明し、この決定に至るために従ったプロセスを示します。サンプルの導入文は “コールにご参加いただきありがとうございます、[チームメンバーの名前]。残念ながら、お話ししたかった理由は、xyz のために、あなたを解雇し、GitLab との雇用／契約を終了することを決定したからです。” です。
2. マネージャー: TMR にコールを引き渡して続行します。
3. TMR: TMR も決定が最終的であることを明確にしますが、チームメンバーの側の話を真摯に聞きます。彼らの言うことには、たとえば採用や審査の慣行に関して、チームの他のメンバーにとって有用な教訓があるかもしれないからです。
4. TMR: 以下に概説するオフボーディングメモから実用的なポイントを必ず伝えてください。
5. TMR: 会話が完了したら、TMR は非自発的オフボーディングメールドキュメントと退職金書類を DocuSign でレビューと署名のためにステージングします。

オフボーディングコール中の重要なポイント

全チームメンバー

1. 最終支払： “あなたの最終チェック（または請求期間）は X の支払期間で、X 日分の支払いを含みます”。
2. 会社の所有物： “ハンドブックに説明されているとおりにすべての所有物を返却してください。また、携帯電話から GitLab のメール接続を削除してください”。
3. 業務経費： “最終的な経費レポートを Navan Expense に作成（従業員向け）、または、契約者の場合は最終的な請求書とともに未処理の経費を申請して、これらを適時に払い戻せるようにしてください”。
4. 機密保持と非開示： “あなたはプロフェッショナルだとわかっています。雇用時に署名した合意書を覚えておいてください”。
5. 個人情報： GitLab があなたの個人メールを会社の他のメンバーと共有することを希望する場合は、People Ops にメールを送るか、あなたの代わりに転送できるさようならのメッセージを送ってください。

米国チームメンバー

1. COBRA： “あなたの福利厚生は、Consolidated Omnibus Budget Reconciliation Act（“COBRA”）の対象となる月の最終日に終了します。キャリア（Lumity）には通知済みで、キャリアはファイル上の自宅住所に書類を送付します”。
2. PPACA： “Patient Protection and Affordable Care Act（“PPACA”）に基づき、マーケットプレイス経由の補助金付きヘルスケアオプションの対象にもなる可能性があります。 ご興味があれば、翌月のカバレッジを得るために、月の 15 日よりかなり前にマーケットプレイスにサインアップすることが重要です”。
3. HIPAA： “1996 年の Health Insurance Portability and Accountability Act（HIPAA）に基づき、credible coverage の証明書が必要な場合は、現在のキャリアのオンラインポータルからダウンロードするか、People Ops にリクエストしてください”。
4. 失業保険： “失業保険の資格があるかどうかは、あなたの州の労働機関（CA では EDD）が決定します”。
5. GitLab に情報を提供してください： “あなたが引っ越した場合、年末にあなたの W-2 が確実に届くようにしたいと思います。 他のご質問について、GitLab の X（電話番号とメールアドレスを提供）にも連絡できます”（いつでも、どんな理由でも連絡するよう招待することを検討してください）。

Workday での非自発的退職の開始

1. TMR: 次のジョブエイドに記載された手順に従って、システムでチームメンバーを退職処理します（Workday プロファイルで Actions、続いて Job Change、最後に Terminate Employee を選択）。

2. TMR: 退職が regrettable か non-regrettable か、そしてチームメンバーが将来再雇用に適格かどうか（レビュー付きで、ただし特に行動や職務放棄に関連する場合は適格ではない）を示すプロンプトが表示されます。

3. TMR: 退職の詳細を提出した後、マネージャーまたは PBP がビジネスに退職を伝えたこと、IT でアクセスが切られたことを確認するアンケートを完了するよう求められます。

4. People Business Partner: 退職トランザクションをレビューし、承認し、オフボーディングプロセスを開始する準備ができたことを確認するためのコメントを入力するために受け取ります。PBP がオフボーディングプロセスを開始したくない場合、準備ができるまで退職を承認すべきではありません。

5. People Ops: すべてのコメントとアンケートをレビューして、オフボーディングプロセスを開始する準備ができていることを確認します。必要に応じて、People Operations チームメンバーは PBP に連絡してプロセスを開始できることを確認する必要があります。これにより、非自発的退職のプロセスが完了します。

最終勤務日

非自発的なオフボーディングコールが行われ、最終勤務日が決定された後、チームメンバーは GitLab システムへのアクセスがなく、GitLab のためにいかなる仕事も行う必要がないかもしれません。

“Garden Leave” 中であれば、退職日までペイロール上ではアクティブのままです。非自発的オフボーディングコールと退職日のタイミングを決定する際は、これがチームメンバーの進行中のタスクや責任に与える影響を考慮することが重要です。マネージャーの承認またはローカル法に従い、GitLab の業務遂行に必要でない限り、garden leave 中に経費を発生させてはいけません。

マネージャーとして、Team Member Relations Specialist（TMR）および／または People Business Partner（PBP）と協力して、機密性の高い顧客ミーティングが予定されているとき、またはオンコール中に非自発的オフボーディングコールをスケジュールすることは避けることをお勧めします。これが避けられない場合、マネージャーは引き継ぎ／是正計画を確保する責任があります。

People Engineering の自動化は、Team Member Relations Specialist（TMR）と People Business Partner（PBP）からの通知に従い、チームメンバーの最終勤務日の終わりにオフボーディング Issue を生成します。Last Working Day または Garden leave が期限切れになると、チームメンバーは公式に GitLab からオフボードされます。オフボーディング Issue の前およびこの用語の全体的なプロセスについては以下を参照してください。

米国チームメンバーの最終勤務日

1. TMR: TMR は計画されたオフボーディングについて法務／CPO のレビューを受けます。
2. TMR: TMR は、チームメンバーのアクセスが停止される日と公式のオフボーディング日について、オフボーディング Issue が開かれる前に、ペイロール、報酬・福利厚生、セキュリティ、株式管理に通知します。
3. TMR: TMR は、People Operations チームと協力してオフボーディング Issue に正しい日付があり、ペイロール、報酬・福利厚生（Total Rewards）、セキュリティ、株式管理のすべてのステークホルダーに連絡され、オフボーディングの詳細を理解していることを確認します。

サンプルオフボーディングメモ

適切な場合（マネージャー、Group Executive、People Ops との会話で決定）、次のオフボーディングメモ（オープンに閲覧可能な Google Doc として提供）を使用してください。もちろん、各個人の状況に合わせてパーソナライズし、調整する必要があります。 書かれている通り、米国を拠点とする従業員にのみ適用可能です。

Separation and Release of Claims Agreements

Separation and Release of Claims Agreements はすべてのオフボーディングに適用されるわけではありません。適用される／適用されないケースをレビューするには、Team Member Relations チームと PBP がアクセスできる Severance Eligibility ドキュメントを参照してください。退職金合意書が適用される場合、以下の手順に従う必要があります：

米国チームメンバーの退職金プロセス

1. TMR: 当該のオフボーディングケースに割り当てられた TMR Partner/Specialist は、適切な退職金テンプレートを選択する必要があります。オプション：Non-California over 40、California over 40、Non-California under 40、California under 40。
2. TMR: TMR Partner/Specialist はテンプレートのコピーを作成し、Copies of Individual Severance Agreements フォルダに保存します。
3. TMR: TMR Partner/Specialist はドキュメントを記入します。
4. TMR: TMR Partner/Specialist はドキュメントの株式オプションセクションで株式チームに ping します。
5. TMR: TMR Partner/Specialist は最終レビュー／承認のために PBP と法務と共有します。
6. TMR: TMR Partner/Specialist は署名のために DocuSign でドキュメントをステージングします。使用するテンプレートによっては、チームメンバーが Separation and Release of Claims Agreement に署名するための時間が限られていることに注意してください。
   • 署名のためにドキュメントをステージングする際は、次の点に注意してください：
     • ドキュメントをチームメンバーの 個人 メールアドレスに送ることを忘れないでください
     • DocuSign で assign signature order オプションを選択して、チームメンバーが最初にドキュメントに署名するようにします
     • すべての US (Inc.) 退職金合意書は VP, People Operations & Technology の Karen Iacobucci が署名する必要があります。Karen が不在の場合は、CPO の Robert Allen が署名を担当します。
     • US (Federal LLC.) 退職金合意書は、連邦エンティティ内の適切なチームメンバーが署名する必要があります。
7. TMR: 署名されたドキュメントを受け取ったら、TMR はチームメンバーの Workday プロファイルの documents タブにアップロードする必要があります。
8. TMR: 最終ステップとして、TMR スペシャリストは適切な uspayroll@gitlab または nonuspayroll@gitlab と total rewards にメールで、最終的な退職金合意書がチームメンバーの Workday プロファイルの documents タブにアップロードされたことを通知します。

重要な注意：

• 退職金は元チームメンバーがドキュメントに署名し、撤回期間が経過するまで支払われません。
• 法的に要求されない限り、退職金を決定する際に在籍期間を考慮しないため、チームメンバーを平等に扱います。他の会社は時々長い在籍期間に対してより高い退職金を与えることがあります。短い在籍期間は次の雇用主に説明しにくく、また短い在籍期間ではストックオプションのアップサイドが少なく、ベスティング・クリフにすら到達していないかもしれません。
• 40 歳以上のルールを必ず理解してください。
• 退職時のミーティングでは、元チームメンバーに合意書への署名を強制するような言葉は決して使わないでください。“署名することを選択された場合”; “署名前にこの文書を法的アドバイザーにレビューしてもらう権利があります” などの言い回しを使ってください。

調査中のチームメンバーの休暇

調査中に休暇に入るチームメンバーについては、以下のプロセスに従ってください：

1. TMR: 調査中にチームメンバーを休暇に入れ、アカウントを無効にする決定について、Legal、整合する PBP とコミュニケーションを取ります。
2. TMR: TMR はチームメンバーのアカウントを無効にするための IT サポートをリクエストします。
3. TMR: TMR はチームメンバーとマネージャーとのコールをスケジュールし、調査が行われる間チームメンバーを休暇に入れる決定を通知します。
4. TMR: TMR は会話が完了し、アカウントが無効になったときにマネージャーと PBP に通知します。この期間中、マネージャーはチームメンバーのアカウントにアクセスできません。
5. TMR: TMR は IT に対し、アカウントに不在メッセージを設定する必要があることを通知し、チームメンバーが OOO であり、彼らのマネージャーに連絡してくださいというメッセージを含めます。
6. TMR: TMR はチームメンバーの個人メールに「Team member Suspension letter」を DocuSign 経由で送信します。TMR はこのドキュメントをチームメンバーの Workday プロファイルの documents タブにアップロードします。
7. TMR: TMR は調査が完了したら、整合する PBP とマネージャーに最終決定を通知します。チームメンバーが仕事に戻る場合、TMR は連絡してチームメンバーと会う時間をスケジュールします。
8. TMR: チームメンバーが仕事に戻る場合、TMR は IT に対し、チームメンバーが休暇から戻ることと、アカウントを有効にする日付を通知します。

オフボーディングコンプライアンス

関連ローテーションの People Operations メンバーは、その特定の週内に開かれたすべてのオフボーディング Issue について毎週監査を行い、すべての People Operations タスクが完了し、peopleops::done ラベルが追加されていることを確認します。

すべての部門によるすべてのオフボーディングタスクは、オフボーディング日から 5 日以内に完了する必要があります。1Password、Slack など、より重要で時間に敏感なシステムについては、関連する部門により最初の 24 時間以内に完了されます。アプリケーションとシステムの deprovisioner に関する情報は、Tech Stack Applications ハンドブックページにあります。

オフボーディング Issue を正常に完了させるためには、システム／ツールがオフボーディングするチームメンバーに該当するかどうかにかかわらず、すべてのタスクにチェックを入れることが重要です。ボックスをチェックすることは、次のいずれかを示します：

• この特定のシステム／ツールへのチームメンバーアクセスを取り消しました
• 確認した結果、このチームメンバーにはこの特定のシステム／ツールへのアクセスは付与されていませんでした。

GitLab Alumni プログラム

すべての自発的な退職者は、特に明記されない限り、Slack チャネル #gitlab-alumni への追加対象です。非自発的な退職者は、Team Member Relations が別途明記しない限り、alumni チャネルの対象にはなりません。 Workday での退職トランザクションで提供されるオフボーディング詳細により適格性が判断され、後に IT と共有されます。

このチャネルの目的は、チームメンバーとネットワークを作り、社交することです。

チャネルへの参加は任意で、GitLab の行動規範に従います。

GitLab（会社）はチャネルを監視し、独自の裁量で人を削除できます。 GitLab のCode of Business Conduct and Ethicsはチャネルで適用されます。

退職の伝達

オフボーディングを伝達する目標は透明性であり、チームメンバーがさようならを言う機会を提供することです。個人によって快適に感じるコミュニケーションのレベルが異なり、各オフボーディング状況にも異なる状況とニュアンスがあることを理解しています。この理由から、また個人への敬意から、オフボーディングを伝達するためのいくつかの主要な指針があります：

自発的な退職

1. すべての自発的なオフボーディングは、ステークホルダーの透明性と認知のために、適切なチームチャネルでアナウンスすることをお願いします。
2. チームメンバーとマネージャーは、チームメンバーのオフボーディングのニュースを誰が共有するか（すなわち、チームメンバーかマネージャーか）を決定する裁量を持ちます。誰が共有するにせよ、共有前にチームメンバーがマネージャーとオフボーディングメッセージをレビューすることが必要です。

チームメンバーのロールによって、コミュニケーションのタイミングは異なる場合があり（例：直属チーム、主要ステークホルダーなど）、マネージャーは最も早く知らされるべき人を決定する裁量を持ちます。退職を伝達するために通常従う順序は：

1. 直属チームに通知

「直属チーム」は通常、チームメンバーの直属チーム内の同僚（同じマネージャーへのレポーティングおよび／または同じ機能グループにいる人など）で、通常は比較的小規模なグループです。

ほとんどの場合、チームメンバーが直属チームに退職を伝達しますが、一貫性のためにメッセージはマネージャーとクロスチェックする必要があります。

2. 主要ステークホルダーに通知

主要ステークホルダーへのコミュニケーションは、1:1 の通知、および／または一般的な認知のためにチーム固有のチャネルにアップデートを投稿することで行えます。主要ステークホルダーは、退職するチームメンバーが非常に密接に働いている個人（通常は日々の仕事で）で、彼らの仕事においてチームメンバーの退職の影響を感じることになります。主要ステークホルダーのマネージャーも認知を確保するためにコミュニケーションループに含める必要があります。

主要ステークホルダーをオフボーディングのループに含めることが不可欠です：

1. 今後の計画を伝達する
2. ビジネスの継続性と透明性を確保する

退職はステークホルダーにできるだけ早く伝達される必要があり、チームメンバーの退職後 2 営業日以内が最大の時間枠です。

可能で適切な場合は、マネージャーが退職するチームメンバーと協力して、退職する前に退職するチームメンバーの仕事の多くを移行する計画を整えることもお勧めします。

ほとんどの場合、マネージャーが主要ステークホルダーにチームメンバーの退職を伝達します。

3. 適切なチームチャネルでアナウンス

オフボーディング Issue で簡潔に説明されているように、GitLab は人が退職する理由について、その時に常に完全なコンテキストを提供できるわけではありません。

ただし、手順で言及されているように、自発的オフボーディングについては、チームメンバーは自分の退職に関するメッセージをチームや他の主要なステークホルダーと共有するために、マネージャーと協力してメッセージングできます。

チームメンバーのチームと他のステークホルダーにニュースが共有され、退職するチームメンバーとそのマネージャー間でメッセージングが合意されたら、それは関連するチームチャネルに投稿されます。

マネージャーとチームメンバーは、今後のチームメンバーの退職を伝達する方法のガイドとして、このテンプレートを任意で活用できます：

I want to share that [team member's name] ([group] [role]) will be leaving GitLab, and [his/her/their] last day is (date of their last day). (Context to add about the team member's time at GitLab - examples: their favorite contribution to the handbook or they can use the update to express gratitude towards teams and individuals that have made their experience at GitLab positive.) I would like to take this opportunity to thank (team member's name) for their contributions and wish them all the best for the future. If you have questions about tasks or projects that need to be picked up, please let me know. If you have concerns, please bring them up with your manager. To keep in touch with (team member's name) he/she/they can be reached at (contact info - e.g. LinkedIn, email, etc.)

チームメンバーがオフボーディングメッセージを共有することを好む状況と、マネージャーがそうすることを好む状況があります。チームメンバーとマネージャーが投稿前に一緒にメッセージングをレビューしていれば、どちらでも構いません。

非自発的な退職

透明性は私たちの価値観の 1 つです。オフボーディングの場合、必要に応じて同僚と direct reports にのみ退職を共有することを選択します。
非自発的に解雇された場合、これは個人のプライバシーに影響し、職務パフォーマンスは意図的に個人とそのマネージャーの間で保持されるため、通常共有できません。

他の従業員のオフボーディングについて懸念があれば、マネージャーまたは People Business Partner と相談してください。

1. 部門／ステークホルダーに通知

マネージャーは、退職するチームメンバーをより広い部門に通知する方法として、自分の部門のチャネルにメッセージを投稿することを検討すべきです。

何を共有するか

I want to share that [team member's name] ([group] [role]) will be leaving GitLab, and [his/her/their] last day is (date of their last day). I would like to take this opportunity to thank (team member's name) for their contributions and wish them all the best for the future. If you have questions about tasks or projects that need to be picked up, please let me know. If you have questions or concerns, please bring them up with your manager. 

場合によっては、チームメンバーが退職した理由についてさらに明確化されないことがあります。懸念がある場合は、マネージャーに対処してもらえます。 すべての退職に対する敬意ある扱いを維持することに基づき、異なるレベルの透明性が存在します。チームメンバーが去ることは、ある人にとっては学習の機会かもしれませんが、誰にとってもゴシップのポイントになるべきではありません。マネージャーは、学習の機会とプライバシーの期待のバランスをとり、質問がある場合は People Business Partner に相談する必要があります。

離職率データ

GitLab の離職率データは社内でのみ閲覧可能です。

オフボーディングタスクの管理

オフボーディング Issue

すべてのツールの deprovisioning を追跡するために、オフボーディング標準に従ってオフボーディング Issue を開いてください。

GitLab への所有物の返却

オフボーディングの一環として、1,000 USD を超える価値の GitLab の所有物はすべて GitLab に返却する必要があります。

ラップトップについては、ラップトップ買い戻しポリシーを確認・参照してください。これは、チームメンバーが GitLab の裁量により、リフレッシュで新しいものに切り替わるとき、またはチームメンバーがオフボーディングするときに、既存のラップトップを保持するか買い戻すかのオプションを持つ可能性があることを述べています。ただし、チームメンバーが調査、不正行為、GitLab の Code of Business Conduct & Ethics のいずれかの違反による解雇、その他の法的または安全関連の調査に関与する場合、無料でラップトップを購入または保持するオプションは無効になる可能性があります。

ラップトップを GitLab に返却するには、オフボーディング後すぐに [email protected] に連絡してください。

Navan Expense

このセクションは Accounting 部門のものです。

Navan Expense から誰かを削除するには、Navan Expense にログインし、左のサイドバーの “Settings” に移動します。 チームメンバーを雇用するエンティティに基づいて適切なポリシーを選択します。左メニューの “People” を選択します。 個人の名前を選択し、“Remove” をクリックします。 その人にコーポレートクレジットカードが割り当てられている場合は、解除する前に Accounts Payable に通知してください。

マネージャーのレトロスペクティブ

非自発的なオフボーディングについては、退職するチームメンバーの採用、オンボーディング、コーチング／コミュニケーションについてレトロスペクティブを行うことは任意です。マネージャーとして、レトロスペクティブのためにこのテンプレートを使用できます。記入したテンプレートをマネージャーおよびあなたのグループの People Business Partner と共有してください。

エンジニアリング部門内では、これは必須プロセスです。なぜなら、これにより採用マネージャーは、チームメンバーと別れることになった最終的な決定の経緯と、それが将来の採用プロセス中にどのように防げるかについて熟考することになるからです。

評価フレームワーク

1. この結果はどうすれば回避できたか？
2. 見逃した初期の兆候はあったか？
3. 振り返って、パフォーマンスの問題に対する認識と当事者意識をもたらすためにどんな質問をすべきだったか、例：「同僚と比較して自分自身をどう評価しますか」？ - 人々は驚くほど正直に答えます。

失業保険申請

米国における失業保険申請

米国では、失業保険は自身に過失なく職を失った GitLab のチームメンバーに給付を提供します。目的は、特定の要件を満たす従業員に一時的な経済的援助を提供することです。

失業保険は州レベルで管理され、連邦法に準拠します。各州は、割り当てられた額、期間、失業保険の資格に関して、独自の資格基準と規制を確立しています。

資格基準には、基準期間中の収入と勤務時間の両方の点で、州が指定する要件を満たすことが含まれます。場合によっては、州が追加のサポート情報、特に申請に関するより詳細な賃金関連の詳細を要求することがあります。

失業保険は雇用主の拠出を通じて資金を調達されており、ほとんどの州が適用される State Unemployment Taxes を持ちますが、多くの雇用主は通常 State Unemployment Taxes も支払います。

虚偽の失業申請の報告

あなたがフルタイムのチームメンバーで、州の Unemployment Commission から失業給付のリクエストについて話し合うために連絡された場合、Unemployment Claim Fraud の被害者である可能性があります。

発信者に情報を提供する前に、機関の従業員と話しているか確認してください。州の Unemployment Commission に虚偽の申請があることを確認した場合は、HelpLab を通じて People Operations チームに報告してください。

さらに、こちらは失業保険詐欺を報告するための U.S Department of Labor 連絡先 へのリンクです。

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