Content last updated 2026-07-28

Candidate Experience Specialistの責務

このページでは、Candidate Experience チームが担当するプロセスとシステムの概要を説明します。

CESチームは、GitLab Service Desk と ModernLoop を活用して、CESチームへのすべての受信リクエストを追跡します。GitLab チームメンバーで Candidate Experience チームへのリクエストや質問がある場合は、[email protected] にメールを送ると、CES Service Desk 内に自動的に Issue が作成されます。どの CES チームメンバーがあなたのリクエストを担当するかについては、アライメントページをご覧ください。私たちのチームはインタビューのスケジューリングに ModernLoop を活用しており、既存のカレンダーや ATS とシームレスに連携しています。

CESチームによる Service Desk の運営方法

この CES Service Desk プロジェクトで適切な通知を設定します。
- 右上の「Star」と「Clone」の隣にあるベルアイコンをクリックします
- 「Custom Settings」に移動します
- 「Issue is Created」にチェックを入れます
- ウィンドウを閉じます
左側のメニューバーで「Issues」をクリックします
- ここがすべての受信 CES メールが Issue を作成する場所です。誰かが CES メールエイリアスにメールを送ると通知が届きます。対応が必要な「メール」はすべて、このプロジェクト内にオープン Issue としてリストアップされます。
各 CES は、Service Desk と個人のボード内の Issue にトリアージを行うことから作業日を開始し、Issue に適切なラベルを追加します。
1. 新しい Issue をクリックします
2. 未割り当ての場合は、自分自身または担当 CES に右側のツールバーから割り当てます
3. Issue メッセージを読みます
4. ラベリング - 各 Issue には少なくとも1つの適切なラベルを付ける必要があります。
5. Issue にコメントを追加して「メール」に返信する場合は、候補者へのメールと同様にコメントを入力してください。常に候補者がどのメールにも含まれている可能性を念頭に置いてください。
6. アクションが不要で Issue が解決済みの場合は、クローズできます。解決しようとしている問題が解決されるまで Issue をクローズしないでください。
ボードの作成 - 割り当てられた Issue を一か所で表示・管理するため
1. 左のメニューの「Plan」の下にある「Issue Boards」をクリックします
2. 現在のボードビューであるチームメンバーの名前をクリックします（例：「Alice」）
3. 「Create new Board」をクリックします
4. 新しいチームメンバーの名前または適切なボードラベルとして新しいボードにタイトルを付けます
5. 「show closed list」のチェックを外します
6. 「Scope」の隣にある「Expand」をクリックします
7. 「Assignee」セクションの下で「Edit」をクリックし、適切な担当者を選択します
8. 「Create Board」をクリックしてボードを作成します
9. 列/特定ラベルリストを追加するには、オープン Issue の列の隣の「+ New List」をクリックします
10. 「Scope」の下で「Label」が選択されていることを確認します
11. 「Value」の下で目的のリストの適切なラベルを選択します
12. ボード上のリストの順序を変更するには、リストをクリックしてドラッグします

チームインタビュー

候補者がチームインタビューの準備ができると、採用担当者は ModernLoop で候補者の都合のいい時間を確認するリクエストを送ります。可用性リクエストが送られると、CES のスケジューリングタスクが作成されます。
- 採用チームが定めたロールの短いタイムラインがある場合は、インタビューをスケジュールする必要がある期限について CES に事前に知らせる必要があります。インタビュアーの準備時間を確保するため、インタビューは最低48時間後にスケジュールすることをデフォルトとします。
- 注意点: Greenhouse で @ces をタグ付けする際は、同じ ping でチーム以外の人をタグ付けしないでください。そのユーザーが Service Desk プロジェクトに追加されてしまいます。
24時間以内に返答がない場合、CES はフォローアップで候補者の都合確認リクエストを再送し、次のメール送信から24時間後に Issue の期限を設定して再度可用性を確認します。
- 候補者に2回目のメールを送っても返答がない場合、CES は採用担当者に無返答を通知し、それ以上可用性の取得を試みません。
可用性が確認できたら、CES は Greenhouse/ModernLoop のインタビュープランに基づいてインタビューをスケジュールします。
- CES はインタビューに ModernLoop の Zoom 統合を使用します
- 候補者が可用性を提供した後、オプションのステップとして、スケジューリングに課題がある場合は CES チームメンバーが Greenhouse から「Candidate First Touch Email」を送ることができます。
このメールは、候補者のインタビュースケジューリングが進行中であることを伝え、候補者とのエンゲージメントを高めるために送信されます。
CES が応募者プロフィールのマージアラートを確認した際に、プロフィールが一致している場合（候補者のメールアドレス、電話番号、または履歴書が一致している場合）、応募者プロフィールをマージします。手順についてはホームページの候補者衛生セクションをご覧ください。
CES は ModernLoop 経由でインタビュー確認を送信します
CES はスコアカードに基づいて自動的に次のインタビューをスケジュールしません
- 採用担当者またはハイリングマネージャーは、次のインタビューラウンドのスケジューリング支援を ModernLoop で要求するため、上記と同じスケジューリング手続きに従う必要があります。
- 「no」または「definitely not」のスコアカードを受け取った候補者は、不合格にする前に採用担当者とハイリングマネージャーと話し合う必要があります。

テクニカルインタビューのスケジューリング

特定のポジションでは、候補者が自身の知識とスキルを実演するテクニカルインタビュー（例: Ruby on Rails、Golang、フロントエンドなど）が必要です。テクニカルインタビューリクエストは、採用担当者が「Technical interview, level & coding language pool - 90 mins」というフォーマットを使用するため、ModernLoop のスコアカードタイトル内で識別できます。

重要事項：

これらのインタビューは90分間です
候補者はインタビューをスケジュールできる前に GitLab ユーザー名を提出する必要があります
インタビュアーと候補者はインタビュー前に準備する時間が必要なため、インタビュアーがインタビューの3営業日（または72時間）前にマージリクエストを送るため、インタビューは3.5〜4営業日後にスケジュールされます。
インタビュアーは候補者と同じジョブレベル以上でなければなりません。インタビュアーは自分より上位のジョブレベルの候補者をインタビューすることはできません。

テクニカルインタビューをスケジュールするには、CES は以下のプロセスに従ってください：

候補者がチームインタビュー段階に正常に到達すると、採用担当者は候補者に可用性リクエストメールを送ります。このアクションにより、ModernLoop で CES のスケジューリングタスクが開始されます。
- 候補者が応募または選考段階で GitLab ユーザー名を提出しなかった場合、採用担当者は GitLab ユーザー名フォーム（チームインタビュー段階またはエバーグリーン段階にあります）も送ります。これにより、候補者に GitLab ユーザー名をフォームに入力するよう求めるメールが生成されます。
CES は CES サービスデスクに別のチケットを受け取ります：
- 入力済みの GitLab ユーザー名フォーム。これは候補者がメールに返信した後にのみサービスデスクに届き、ユーザー名は自動的に候補者プロフィールの「Details」タブの「Details > Other」の下に追加されます。CES は GL ユーザー名が有効であることを確認し、GL ユーザー名が URL 形式であることを確認してください。
- CES は ModernLoop のテクニカルスケジューリングタスクに「GL Username received」タグを追加します。
候補者の GL ユーザー名が有効であることを CES が確認したら、CES チームメンバーは ModernLoop でインタビューのスケジューリングに進むことができます。
- 注意: インタビュアーにインタビュー招待を送る際は、「Technical Interview with MR」テンプレートを選択してください。
CES は ModernLoop を通じて候補者に確認を送ります。
- 候補者にインタビュー確認をメールで送る際、CES は適切な（Ruby、Golang）ModernLoop メールテンプレートを選択します。これにより、テクニカルインタビューで何を期待できるかについての追加情報が候補者に提供されます。

インタビュー24時間前にMRへの提出がない場合

インタビューの予定24時間前までに候補者が MR にいかなる作業も提出していない場合、インタビュアーが CES チームに通知します。
CES チームメンバーはインタビューをキャンセルし、Greenhouse の「Email to candidate - MR Not submitted」テンプレートを使用して候補者にメールを送ります。CES は採用担当者に通知するために候補者の Greenhouse プロフィールにも備考を残します。
CES は採用担当者から指示を受けるまでインタビューを再スケジュールしません。

エグゼクティブインタビューのスケジューリング

以下のプロセスは、Executive Business Administrator（EBA）チームとエグゼクティブ採用担当者とパートナーシップを組みながら、CES チームがエグゼクティブインタビューをスケジュールする際に従う手順を概説しています。Candidate Experience チームと EBA チームは、インタビューのスケジューリングに 24 時間の SLA 応答時間を遵守します。エグゼクティブ採用担当者からのインタビューリクエストは、エグゼクティブカレンダーのみにスケジュールされます。

採用担当者は ModernLoop でスケジューリングタスクを作成し、CES の ModernLoop 内「My Tasks」リストに表示されます

CES は EBA チートシートドキュメントでエグゼクティブインタビュアーの設定を参照し、#EBA-team-interview-requests チャンネルでインタビュー詳細を各 EBA に連絡します。
このチャンネルでインタビューをリクエストするには、「Workflow」をクリックして各フィールドに適切な情報を入力します。

CES は、返答を待つ間、EBA スケジューリングタスクへの Slack リンクとともに ModernLoop のインタビュータスクに「Pending EBA」ラベルを追加します。

注: フォローアップの SLA は、スケジューリングを遅らせる時間の競合を確認するために 24 時間です。時間が合わない場合は、CES が候補者にさらに多くの可用性をリクエストするか、インタビュアーに合う時間を提案することができます。

EBA がインタビューに最適な日時を確認したら、CES は ModernLoop を通じて候補者にインタビュー確認メールを送ります。
CES は ModernLoop を通じてインタビューをスケジュールし、インタビュアーにカレンダー招待を送ります。招待は必ずプライベートに設定してください。
CES は元の Slack メッセージで緑のチェックマーク絵文字を使用してインタビューのスケジュールを EBA に通知し、チケットをクローズします。

このプロセスは、エグゼクティブ採用だけでなく、EBA がサポートするエグゼクティブチームメンバーが含まれるあらゆる採用やインタビューにも適用されます。すべてのエグゼクティブチームメンバーが EBA サポートを持っているわけではないため、通常の CES スケジューリングプロセスに従って ModernLoop で直接スケジュールされる場合があります。

注意：

候補者がリスケジュールを必要とする場合は、Slack チャンネルで適切な EBA に通知し、候補者の更新された可用性と Greenhouse プロフィールを共有してください。
EBA と CES チームは、Slack チャンネルでインタビューの変更や懸念事項を伝えます。オファーのフラグ立て、インタビュースコアカードの記入、またはエグゼクティブのスケジュールに関するリクエストなど、その他のリクエストもこのチャンネルで伝えることができます。

候補者のアクセシビリティと配慮リクエストプロセス

GitLab では、すべての人が貢献できる機会を持てるインクルーシブな環境の育成に取り組んでいます。以下の手順は、候補者が提出したアクセシビリティと配慮リクエストをチームが処理するためのワークフローを概説しています。

Googleフォームの提出

候補者は以下のいずれかの配慮リクエストフォームを提出します：
- 候補者ポータル - 配慮リクエストフォームへのアクセスは電話スクリーニング段階でポータルを通じて提供され、インタビュープロセス全体を通じて利用可能です。
- 最初のインタビュー可用性メール。

CESへの通知と初期レビュー

候補者が配慮フォームを提出すると、すぐに CES に通知が届きます。初期レビューでは、CES は以下のマトリックスを使用して配慮がレベル 1 かレベル 2 かを判断します。

カテゴリ	レベル 1 - 標準（CES が直接対応 - 24時間以内に確認）	レベル 2 - 複雑（TMR + 法務 - 24時間以内に確認 - 24〜48時間以内にフォローアップと判断）
テクノロジー配慮	✓ クローズドキャプション	✓ カスタムソフトウェアニーズ
インタビュー配慮	✓ 複数日インタビュー ✓ インタビューの延長時間	✓ 標準提供を超えるリソース配分
その他	該当なし	✓ 固有または複雑な配慮ニーズ ✓ ポリシー解釈が必要なリクエスト ✓ 標準提供を超えるリソース配分

候補者への確認メール送信

24時間以内にレベルに関わらず、CES は候補者に「Accommodation Request Acknowledgment Email」を送ります（リクエストのレベルに基づいて GH からテンプレートを選択してください）。

Greenhouse コーディネーション移管

候補者の GH プロフィールで、「Application Coordinator」を指定された配慮担当 CES に設定します。これにより、Modernloop はすべての将来のスケジューリングタスクを自動的にルーティングし、一貫したサポートと配慮漏れゼロを維持します。

タグ付けとドキュメント管理

CES は Greenhouse に配慮タグを追加し、追跡のために ModernLoop（ML）に内部メモを追加します。候補者のプライバシーを維持するために、メモは汎用的に保ちます。

標準配慮の実施

レベル 1 の配慮については、スケジューリング時に CES はインタビュアーの招待に「accommodation requested:」の隣に TE スニペットを使用して配慮を含めます。クローズドキャプションには「zoomclose」、延長時間には「adtime」を使用します。
候補者が複数日のインタビューをリクエストした場合、CES はそれに応じてインタビューをスケジュールします。
配慮全体の実施における SLA は 24 時間です。

非標準リクエストのエスカレーション

レベル 2 のリクエストについては、CES は専用のプライベート Slack チャンネルにリクエストをエスカレーションします。
チームは実装戦略を作成し、ポリシー例外の承認を確保し、決定の根拠を文書化し、最終計画を電子メールで候補者に通知します。
配慮が対応可能な場合、CES は ML インタビュアーの招待も更新して配慮リクエストとその実施方法を反映させます。
配慮全体の実施における SLA は 48 時間で、TMR/法務との協議と候補者への通知を含みます。

インタビュアーへの連絡と確認

スケジューリング後、CES はインタビュアーに配慮について DM し（レベル 1 と 2 の両方、対応可能な場合）、成功したインタビューを実施するために必要なサポートがあることを確認します。

注意: CES は説明責任とフォローアップのために、すべてのインタビュアーとのコミュニケーションと確認の内部追跡を維持します。追跡シートは CES チームリポジトリに参照用リンクが掲載されています。

ModernLoop

ModernLoop は、Candidate Experience チームがインタビューを予約するために使用するスケジューリングツールです。

ModernLoop へのログイン

Okta の ModernLoop タイルを選択し、SSO を使用してログインしてください。

Chrome ブラウザに ModernLoop Chrome 拡張機能がインストールされていることを確認してください。

ModernLoop を使用したインタビューのスケジューリング方法

左のタスクバーを使用して「My Tasks」に移動します
「Action required」バケットで、「ready to Schedule」ラベルの候補者をクリックします
サイドウィンドウが開くので、スクロールして「Schedule now」ボタンをクリックします。ページが候補者の可用性に開きます。右側で「Next: Setup Interviews」ボタンを押します。
スケジュールする必要があるインタビューの情報（時間、インタビュアー、スコアカードなど）を確認し、「Next: Find Schedules」をクリックします
ModernLoop はインタビューオプションのリストを作成します。インタビュアーのカレンダーを確認するには、インタビュアーのカードの右上にある「view」オプションをクリックします。
スケジュールオプションを選択するには、オプションカードの右上の「use schedule」をクリックします。
場所は自動的に Zoom として選択され、Zoom ルームが選択されます。どの Zoom ルームを使用するかについては CES チームに確認してください。オーバーブッキングを避けるため、各 CES メンバーはスケジューリング時に使用する特定の Zoom ルームが割り当てられています。
ModernLoop でスケジューリングする際のカレンダーセクションは、インタビューがスケジュールされると表示される内部カレンダーを指します。候補者イベント用の「Candidate Interview Calendar」と内部イベント用の「Interview calendar」があります。これらのカレンダーはこのセクションに自動入力されます。
ドロップダウンリストから候補者へのメールテンプレートを選択します。
インタビューにブリーフが必要な場合は、「Add attachment」を選択して含めることができます。
インタビュアーへの招待については、ドロップダウンリストから正しいテンプレートを選択します
すべての詳細を確認し、「Confirm and send」を押します
候補者への招待を送る前にインタビュアーへの招待だけを送りたい場合は、「Send internal only」を選択します。これにより、インタビュアーへの招待が送られ、候補者は「My tasks」の「Pending」セクションに移動します。候補者への招待を送りたい場合は、候補者プロフィールに移動して「finish and Send」をクリックします。

内部インタビューのスケジューリング方法

内部候補者のスケジューリングタスクを採用担当者から ModernLoop で受け取ったら、タスクに「internal candidate」タグが適用されていることを確認します。
見当たらない場合は、追跡のために「internal candidate」タグを ModernLoop タスクに自分で追加します。
外部候補者とは異なり、採用担当者は内部候補者にメールで可用性をリクエストしません。代わりに、候補者が提出した可用性を待たずに直接インタビューを手配するために CES のスケジューリングタスクを作成します。
採用担当者は、CES がインタビューをスケジュールするために候補者の GitLab カレンダーを利用することを候補者に伝えます。
CES は候補者の可用性提出を待たずに直接通話のスケジューリングに進んでください。
Google カレンダーにアクセスして、インタビュアーと内部チームメンバーのカレンダーを並行して表示します。
適切な時間帯が確認できたら、インタビューをスケジュールし、ModernLoop で内部候補者に確認を送ります。

スケジュール済みインタビューのインタビュアーの追加または変更方法

スケジュール済みインタビューにインタビュアーを追加または変更したい場合は、「My tasks」で「scheduled」に移動し、スケジュール済みインタビューをクリックします。
インタビューの詳細を含むサイドページが開いたら、インタビュータイルの 3 つのドットをクリックし、「Edit Interview」を選択します。
インタビュアーを追加するには「add interviewer」を選択し、新しいインタビュアーの名前を入力します。
インタビュアーを削除するには、名前の隣の 3 つのドットを選択し、「remove interviewer」を選択します。

インタビュアーモジュールの設定方法（インタビュアープールとトレーニングプラン）

ModernLoop のモジュールはインタビュアープールであり、研修生がシャドウ/リバースシャドウを経て進めるようにもなっています。

モジュールを設定するには、以下の手順を実行します：

左のタスクバーの「Modules」に移動します
「New Module」をクリックします
モジュールに名前を付け、トレーニングプラン（通常は2回のシャドウと1回のリバースシャドウ）を選択し、「role-by-role」を選択して作成します
「add interviewers」をクリックし、モジュールのトレーニング済みインタビュアーの名前を入力します。次に「fully trained」を選択すると、インタビュアーがモジュールに追加されます。
研修生を追加するには、右上隅の「Add interviewers」をクリックします。研修生インタビュアーの名前を入力し、「Trainee」を選択します。

モジュールを削除するには、モジュールをクリックし、「settings」に移動して「delete module」をクリックします。

インタビュープランにモジュールを割り当てるには：

「Jobs」に移動し、インタビュアーモジュールを使用するジョブを選択します。
「stage」タブを選択し、必要なインタビュー段階を選択します。
インタビュープランには、Greenhouse のこの段階のインタビューが表示されます。「Add Interviewer」をクリックし、使用するモジュールの名前を入力します。

テクニカルインタビューのスケジューリング方法

テクニカルインタビューにインタビュアーモジュールが必要な場合は、ジョブインタビュープランで正しいインタビュアーモジュールが選択されているか確認します。
1:1 インタビューと同じ手順でインタビューのスケジューリングを続けます。
候補者メールには「Technical Interview - Candidate confirmation」テンプレートを選択し、正しいテキスト展開スニペットを使用してテクニカル指示を追加します。
MR があるインタビューには、インタビュアーへの内部招待に「Technical Interview with MR」を選択します。
モジュールからシャドウインタビュアーがいる場合、ModernLoop は誰がリードで誰がシャドウかをインタビュアーに伝える段落を自動的に追加します。
「Select finish and send」を選択します。

組織全体の設定の更新方法

注意: 組織設定を変更できるのは管理者のみです。組織設定はホームページの左側のメニューにあります。

候補者が採用プロセスから辞退した場合

候補者がインタビュープロセスから辞退したいと CES Service Desk にメールを送った場合、CES は候補者のメール（Service Desk チケットではなく）に返信し、採用担当者を CC に入れます（採用担当者がすでにメールに含まれていない場合）。CES の返信は、採用担当者が候補者を引き止める機会がある可能性があるため、確定的なことは言わないようにしてください。基本的な返答は以下の通りです：

Candidate Name 様、メールありがとうございます。こちらのメールに採用担当者を CC として追加しました。追加のご質問がございましたら、担当者よりご連絡いたします。

CES は辞退した候補者の Greenhouse プロフィールで採用担当者をタグ付けする必要もあります。

唯一の例外はエグゼクティブの役職です。辞退メールをエグゼクティブ採用担当者に転送するだけで、フォローアップは採用担当者が対応します。

秘密保持契約（NDA）

候補者に秘密保持契約（NDA）を送るには、採用担当者は Greenhouse で @ces にメンションしてください。 CES は DocuSign にログインし、「start」と「use a template」を選択して、共有テンプレートにアクセスします。 NDA が返送されたら、Greenhouse の「details」セクションにドキュメントをアップロードします。DocuSign から別ファイルとしてこのドキュメントをダウンロードし、NDA 本体のみを使用してください（サマリーは不要です）。

バックグラウンドスクリーニング

GitLab はリファレンスを取得し、雇用確認とともに犯罪記録チェックを実施します。

候補者がベルギーにいて、そのポジションがグレード 9 以上でない場合、CES または採用担当者（リファレンスチェックプロセスを開始する方）は、リファレンス/バックグラウンドスクリーニング段階に #legal Slack チャンネルを通じて法務チームに求人票を送り、そのポジションが信頼職かどうかを判断する必要があります。
採用担当者は「Email the team」を選択し、口頭オファーがなされた後に CES に「CES Start Contract Request」メールを送ってオファーレターとバックグラウンドスクリーニングプロセスを開始する必要があります。
Candidate Experience Specialist はバックグラウンドスクリーニングを開始し、候補者のコントラクトプロセスを開始します。
バックグラウンドスクリーニングの結果は Senior Background Check Specialist が受け取り、必要に応じてチームメンバー関係部門と法務にエスカレーションされます。

バックグラウンドスクリーニングのレビューに関する詳細はこのページをご覧ください。

Greenhouse を通じたバックグラウンドスクリーニングの開始

Greenhouse にログインし、候補者のプロフィールに移動します。
「Application」タブをクリックします。
「Export to Sterling」をクリックします。
「Complete Report」をクリックすると、Sterling の Web サイトにリダイレクトされます。
「Invite」をクリックし、2番目のステップから始まる以下の手順に従います。
候補者がニューヨーク市にいて、すでにステップ 1 を開始している場合は、従来の米国チェックではなく NYC ステップ 2 を注文してください。

Sterling Talent Solutions を通じたバックグラウンドスクリーニングの開始

Sterling にログインし、候補者のメールアドレスを入力して E-invite を送ります。
「Applicant Information」に候補者の姓と名、および確認のためのメールアドレスを入力します。
候補者の場所を選択します。米国の候補者は市と州を含める必要があります。
次に、「Job Position」ドロップダウンメニューから「GitLab」を選択します。
次に、候補者がいる国の名前を選択します。国が記載されていない場合は、「Global Screening」を選択します。
最後に、ページの下部にスクロールして「Send」をクリックします。
Greenhouse プロフィールにバックグラウンドスクリーニングが開始されたことをメモします。

リファレンスチェックフォーム

オファーを提示する前に、採用担当者はリファレンスチェック段階でフォームを送ってリファレンスやその他のオファー関連情報をリクエストする必要があります。候補者がいる国に基づいて、すべてのジョブで利用可能なフォームのバージョンがいくつかあります。CES が Service Desk でフォームを受け取ったとき、確認する必要がある 3〜4 つのフィールドがあります：NYC のステータス、PIAA（従業員発明譲渡契約）、外部業務の開示、TMRG リクエストです。

NYC（ニューヨーク市）の場所

米国リファレンスチェックフォームのみ：米国リファレンスチェックフォームは候補者に送られ、口頭オファーを提示する前にステップ 1 が完了されている必要があります。候補者が NYC またはその 5 つの区（ブルックリン、ブロンクス、ニューヨーク（マンハッタン）、クイーンズ、またはスタテンアイランドと記載される）に所在する場合に「Yes」を選択した場合、2 段階のバックグラウンドスクリーニングプロセスを完了する必要があります。

ロングアイランドは NYC の一部ではなく、このプロセスはそこの住民には適用されません。

CES サービスデスクは、候補者が「Reference Check Process Information - USA」フォームを提出したことを示すチケットを受け取ります。CES は候補者が NYC の場所の質問に「Yes」を選択したことを確認します。
CES はプロセスを案内するためにチケットにテキスト展開スニペット refchecktodo を追加します。CES は「NYC BGC」ラベルを追加します。
CES は https://sterlingcheck.app/dashboard/#/dashboard/ にアクセスします。チェックと共に配信されるメールテンプレートを編集できるため、このバージョンの Sterling を使用することが重要です。
- NYC Step 1 スクリーニングパッケージを選択します。「Employment Location」フィールドにサンフランシスコ、「Projected Salary」フィールドに候補者の給与（この範囲は候補者の GH プロフィールの「Approvals」タブにあります）を入力する必要があります。「next」をクリックします。
- 次のページの「Email Content」で、ドロップダウンから「NYC Step 1」テンプレートを選択します。
- ページ下部にスクロールして候補者のフルネームとメールアドレスを入力します。「Send Invite」を送信します。
CES はチケットに「Pending」ラベルと期限を追加します。ETA があるかどうかを確認するため、Greenhouse で 1 営業日後のフォローアップリマインダーを作成します。
- Sterling で ETA が設定されたら、その ETA 日付で Greenhouse に別のフォローアップリマインダーを作成します。結果は ETA より早く届く場合があります。
- BGC エスカレーション（例：「Status: Unperformable」または「Status: Consider」）については、Senior Background Check Specialist に連絡してください。
このプロセスは、雇用確認と犯罪チェックを分離する NYC 法のために追加されました。Sterling での Step 1 スクリーニング結果のステータスに注目してください。ステップ 1 がクリアされるのを待っている間、採用担当者は候補者に口頭オファーを提示し、Greenhouse でのオファー作成と承認段階を進めることができます。採用担当者は準備ができたら CES にコントラクトリクエストチケットを送ることができますが、CES はステップ 1 がクリアされるまで書面によるコントラクトを候補者に送ることができません。 ヒント: CES サービスデスクがコントラクトチケットを受け取ったら、この候補者が NYC 2 段階バックグラウンドスクリーニングプロセスを受けていることをチームメンバーに思い出させるために、NYC BGC ラベルをすぐに追加してください。
- 他のチームメンバーが開始した Sterling の BGC を確認する際は、Sterling ダッシュボードの左上の「Entire Organization」を必ず選択してください。
採用担当者が CES にコントラクトチケットを送ったら、CES は Greenhouse 統合を通じてバックグラウンドスクリーニングの NYC Step 2 を完了します。Sterling で NYC Step 2 スクリーニングパッケージを選択して送信します。 トラブルシューティングのヒント: Greenhouse Sterling 統合を通じてステップ 2 を開始する際に「expired」エラーが表示された場合は、Sterling Direct ダッシュボードに移動します。右側の「E-Invite Applicant to Background Check」で候補者のメールアドレスを入力し、「Invite」を選択します。
- 申請者の情報を入力します
- 「Order Information」で、ジョブポジションとして GitLab を選択し、「Screening Package」で NYC Step 2 を選択します。
- 次にページの右下にスクロールして「Send」を選択します。

外部業務と PIAA プロセス

フォームでは、候補者が外部業務、副業、発明などを開示することが求められます。「none」または「n/a」と記載されている場合は、このステップをスキップできます。候補者が外部業務セクションまたは PIAA セクションのいずれかに情報を開示した場合、CES は以下の手順を実行します：

CES は TA Candidate PIAA and Outside Work Disclosure Group にアクセスします
CES はページ右上の「New Project」をクリックします
「Create from template」を選択します
「Group (1)」タブを選択し、青いボタン「Use Template」をクリックします
「Project Name」に候補者の名前をタイトルとして作成します
他のフィールドはそのままにして「Create Project」をクリックします
- 注意: プロジェクトが作成されると、そのプロジェクト内に Issue を作成できるページに移動します。ここで開示に関するすべての情報を提供し、HM、TMR、採用担当者、ディレクターを参加させます。
ページ左側の「Issues」をクリックし、「New Issue」を選択します。
「Issue Name」に候補者のフルネームと受け取った開示の種類を使ってタイトルを作成します。
「Description」ドロップダウンで「piaa_outside work_discussion template」を選択します
すべての関連情報を入力します。
- 候補者の名前と Greenhouse リンク
- CES チェックボックスの下に候補者が行った開示をコピー＆ペーストします
Issue を自分に割り当て、下部の「Create Issue」をクリックします
Issue が作成されたら、左のツールバーの「Manage」をクリックし、「Members」を選択します。
「Invite Members」をクリック - HM の名前、ディレクターの名前、採用担当者の名前を入力し、「Guest」のままにして「Invite」をクリックします（これらは「Issue」レベルでのみ招待されるため、タグ付けされた Issue のみを確認できます。他のプロジェクトへのアクセス権はありません）
- 重要な注意: すべての開示において、ディレクターレベルの承認が常に必要です。
Issue に戻り、「Edit」をクリックして情報ボックスで採用担当者、HM、ディレクターをタグ付けし、「save」をクリックします
- これらのチームメンバーはタグ付けされたときにメールで通知されます。
Issue のコメントセクションで、TE スニペット「discreview」を使用して参加者に開示のレビューを求めます
コメントで承認確認が受け取れたら、CES は適切なラベルを削除します。
法務レビューと承認が必要な場合、TMR が適切な法務メンバーを Issue に招待して審査を依頼します
完全に承認されたら、「Fully Approved」ラベルを追加して Issue をクローズします。
候補者の GH プロフィールに移動し、「Email (Candidate’s Name)」を選択します。「Disclosure Confirmation」テンプレートを選択し、候補者が行った開示を空白部分にコピー＆ペーストして送信します。このメールはあなたと採用担当者を CC に含めます。
受信トレイからメールを PDF としてダウンロードし、候補者の Workday プロフィールの「Pre Hire Documents & Changes」フォルダにアップロードします。

TMRG との会話

私たちの採用プロセスには、候補者が TMRG チームメンバーとの面談をリクエストできる任意のステップが含まれています。これはオファーが提示される前にインタビュープロセスを完了した候補者に提供されます。候補者がこの機会を利用するかどうかは、全体的な採用決定には影響しません。

現在のすべての TMRG がこのプロセスに参加することに同意しています。グループリストはこちらから確認できます。

候補者がリファレンスチェックフォームを通じて TMRG チームメンバーとの面談をリクエストした場合、Candidate Experience Specialist は以下を行います：

専用の #candidate_tmrg-call Slack チャンネルでこの通話の TMRG ボランティアに連絡します。
- ショートカットボタンをクリックします（稲妻マークのついたプラスマーク）
- 適切な詳細を入力します
  - 候補者はどの TMRG と話したいですか？
  - 候補者はどこにいますか？
  - 候補者はどのポジションにインタビューしていますか？
  - 「Submit」をクリックします
送信後、リクエストはボランティアに自分の Calendly リンクと LinkedIn プロフィール（オプション）で返答するよう求めます。
ボランティアが見つかったら、Candidate Experience Specialist は Greenhouse で「TMRG - Reviewed」メールテンプレートを候補者にメールで送ります。CES はチームメンバーの名前、Calendly リンク、LinkedIn プロフィール（提供された場合）でテンプレートを更新して候補者に送ります。
24時間以内にボランティアが見つからない場合、CES チームメンバーは専用の TMRG Slack チャンネルで TMRG に連絡します。
2回目のリクエストから24時間以内にもボランティアが見つからない場合、CES は TMRG リードに連絡してスケジューリングの支援を求めます。リクエストから3営業日以内にボランティアが見つからない場合、CES は TMRG リードに会話への参加を求めます。

これらの通話に参加する GitLab チームメンバーへのアドバイスとして、あなたと GitLab でのあなたの役割についての短い自己紹介から始めることをお勧めします。その後は、目標があなたの質問に答え、私たちがどのように働くかについての洞察を提供することなので、候補者が会話をリードするように任せることをお勧めします。

これらの通話では Greenhouse にスコアカードを提出する必要はありません。候補者が何か問題と思えるもの（例：私たちの価値観に反する過去の行動を概説する場合）を言及したり、彼らを成功に導くために役立つ情報を共有した場合、その詳細をインタビューしている役割の採用マネージャーに共有することをお勧めします。これをレビューし、候補者の採用またはオファープロセスを変更する必要があるかどうかを決定するのはハイリングマネージャーの責任です。

コントラクトの送付

ハンドブックの Candidate Experience Specialist コントラクトプロセスセクションを参照してください

Candidate Experience Specialists がコントラクトを準備します。Candidate Experience Specialist は他のタスクよりもコントラクトを優先しますが、期待されるターンアラウンドは 1 営業日です。コントラクトが時間的に重要な場合は、急ぐ理由を説明してください。Candidate Experience Specialist が 1 営業日を満たせない場合は、Greenhouse で採用担当者と CES マネージャーに通知し、理由を説明します。

採用担当者は CES コントラクトプロセスページとコントラクト、試用期間、PIAAページ、および内部ハンドブックの雇用契約ページにあるコントラクトプロセスの基本知識を熟知しておく必要があります。

オファーのすべての側面を確認します：

新しいチームメンバーの法的名前がプロフィールに記載されていますか？
- 候補者のリファレンスチェックフォームを確認して、法的名前が GH に正しく反映されているかを確認します
- チームメンバーのフルネーム（法的 ID を目視確認する前の時点でわかる限り）を入力することが非常に重要です。フルネームはバックグラウンドスクリーニングプロセスのために提供される必要があります。人の法的名前全体と名前に使用されるアクセントを含め、できるだけ正確にすることが重要です。
新しいチームメンバーの住所は詳細ページに記載されていますか？
場所とオファーの詳細に基づいて必要なコントラクトの種類とエンティティは何ですか？
すべての必要な情報（開始日、給与、場所など）は最新の状態ですか？
開始日は「no start date」ではなく、People Connect と IT が十分な通知を受けるための十分な時間を提供していますか？理想的には 10 日間の通知を提供しますが、チームはそれよりも短くても対応できます。
署名者は Candidate Experience Specialist によって決定され、更新されていますか？
新入社員の場所に基づいてエンティティが選択されていますか？ジョブタイトルに Federal または PubSec が含まれている場合は、採用担当者に Federal LLC ではなく Inc としてコントラクトが設定されているかどうかを確認してください。

オファーパッケージに記載されている詳細に基づいてテンプレートを使用して Greenhouse 内でコントラクトを生成し、OTE、ドロー、ボーナスがオファーの詳細に含まれているかどうかに注意してください。
欠落している情報を収集するために採用担当者または新しいチームメンバーに連絡します（注意: 候補者の住所はリファレンスチェックフォームに記載されています）。
コントラクトが Greenhouse 外で作成された場合は、コントラクトが法務チームのメンバーによってレビューおよび承認されていることを確認してください。
Greenhouse 内から DocuSign でコントラクトをステージし、正しい署名者にメールを送ります。「To」フィールドに名前を入力し、事前に決定された署名者を選択します。「CC」フィールドに採用担当者とハイリングマネージャーを CC で追加します。
候補者を採用済みにする前に Candidate Experience Specialist は、候補者が見込みになっている役割を含む他のすべてのアクティブな役割から候補者を不合格にします（不合格メールを送らずに）。注意: このステップをスキップすると、候補者が採用済みになったときにプロフィールが Workday にエクスポートされません。
すべての候補者について候補者を採用済みにする前に CES はプロフィルがマージされていることを確認します（内部候補者の場合、候補者が元の Hired の非アクティブな役割を表示していれば示されます）。ハンドブックの候補者衛生セクションで候補者マージの手順を確認してください。注意: このステップをスキップすると、プライバシーの問題が発生し、新入社員が自分の Greenhouse プロフィールを見る可能性が高まります。
候補者を採用済みにする前に CES は採用担当者に通知し、他のすべてのアクティブな候補者に連絡または不合格にするための 24 時間を与えます。これが完了したら、CES は GH での採用手続きを進めることができます（候補者がまだ採用要件にいる場合は、候補者を採用済みにする際に「keep open」オプションを選択してください。これにより、採用要件に候補者が残るように新しいオープニングが作成されます）
候補者を採用済みにする前に CES は候補者プロフィールの Details > Source & Responsibility セクションに記載されている採用担当者とコーディネーターが正確であることを確認してレポートの精度を確保します。
CES は Greenhouse で候補者を「Hired」にします：プロンプトが表示されたら、採用要件をクローズするオプションを選択してください。 新入社員の Workday プロフィールが自動的に生成されます。
Candidate Experience Specialist は Greenhouse から IT Ops、ハイリングマネージャー、採用担当者を CC にして新しいチームメンバーにウェルカムメールを送ります。候補者の場所とラップトップを自分で調達する必要があるかどうかに基づいて適切なウェルカムメールを送ります。
- このメールにはラップトップ注文プロセスに関する手順が含まれています。
ウェルカムメールを送った後に開始日が変更された場合は、こちらの必要な手順を参照してください。
開始日とオンボーディング日の整合の例外: 新しいチームメンバーが法的な理由（雇用の断絶を防ぐため）で特定の開始日を必要とするが、その特定の日（公共の祝日、Family & Friends Day などのため）にオンボーディングが制限されている場合、Candidate Experience Specialist はプライベート Slack チャンネル people-connect_ces で People Connect チームに通知できます。コントラクト、Greenhouse、Workday は実際のオンボーディング日に関わらず、同じ開始日を反映する必要があります。

Candidate Experience Specialist の候補者との最後の責任は、システムに候補者を採用し、People Connect に引き渡すことです。採用プロセスにはより多くの複雑さがあるため、CES は開始日の例外と新入社員の守秘義務を明確にするための以下のガイドラインを作成しました。

Greenhouse リマインダーの設定 - CES は GitLab Issue の期限機能を活用して開始日を追跡し、採用担当者との一貫したコミュニケーションを維持して採用要件の候補者が完全にクリアされることを確認します。CES は「Need to hire into Workday」ラベルを使用し、GitLab Issue に期限を設定して追跡することもできます。

People Connect チームは、エンティティ/PEO ベースのチームメンバーをオンボードするための SLA 期間として 10 営業日を持っています。例外の場合、People Connect チームに必要な最低通知期間は 5 営業日です。

プロアクティブなコミュニケーション - コントラクト生成と採用済みのマーキングに遅延または問題が発生した場合は、CES が #peopleconnect-ces Slack チャンネルですぐに通知することが不可欠です。開始日まで 10 日未満の緊急採用の場合は、people-connect_ces チャンネルで TE スニペット「Itlaprequest」を使用して、開始日に間に合うようにラップトップが配送できるかを確認してください。この確認を受け取った後にのみ、採用担当者に開始日を確定できます。

新入社員の例外 - 公的な発表を必要とする機密採用については、Alissa Meeks または Melody Patel に具体的なシナリオを知らせてください。また、関連するすべてのコミュニケーションに参加させて最新情報を共有してください。これも例外として扱われます。

グローバル祝日の確認 - CES は提案された開始日が新入社員の場所での祝日と重なるかどうかを確認する必要があります。新しいチームメンバーがオンボーディング初日にサポート/オンボーディングバディがいることを確認するために採用マネージャーと確認することは採用担当者の責任です。

緊急採用の開始日例外メール - このメールは、提案された開始日変更に関する必要な説明とビジネス上の正当な理由を求めます。People Connect チームはこれをケースバイケースでレビューします。緊急採用とは、HM が以前に合意した開始日より早い開始日を要求し、新しい開始日が候補者オンボーディングの標準 10 営業日の SLA 期間を遵守していない状況を指します。重要： People Connect チームへの最低 5 営業日の通知なしには例外は認められません。

緊急採用の主な理由は、重要なスキルギャップ/新しいビジネスチャンス、エクイティベスティンググラントオプション、予期しない退職やバックフィルです。CES はこのメールを候補者の Greenhouse プロフィールの「Email the team」オプションからアクセスできます。

CES コントラクトプロセス

採用プロセスがスムーズに進んだと仮定して、今度は適用されるコントラクトを準備する時です。口頭オファーがなされたら、Greenhouse の「email team」オプションを通じて Issue が作成されます。CES は Greenhouse 内の DocuSign を使用して申請者にコントラクトを送ります。まれに、CES は Google ドキュメントを使用して Greenhouse 外でコントラクトを作成する必要がある場合があります。その場合、CES は署名のために送る前にマネージャーにコントラクトの正確性をレビューしてもらう必要があります。

まず、以下を検証してください：

コントラクトを送る前に候補者が「offer」段階に移動されています。CES はこれを調整できますが、これは採用担当者が口頭オファーをする準備ができたときに行うステップであるため、採用担当者に通知することが重要です。
開始日は「no-start day」ではなく、送付日から 10 日以上先です。People Connect は新入社員の処理に最低 5 日必要ですが、可能であれば 10 日をリクエストします。採用担当者は両当事者がコントラクトに署名するのにかかる時間と、残りのすべての候補者を不合格にする準備が必要です。
候補者は私たちが採用できる国に住んでいます。すべての国の採用に関する SSOT はこちらです。
Greenhouse のオファーパッケージに記載されている通貨は、Total Rewards によって承認されない限り、通常は新しいチームメンバーの現地通貨である必要があります。これはオファーを提示する前に確認および承認される必要があります。通貨の変更は、同じ金額でも別の通貨の場合でも、Greenhouse での完全な再承認が必要になります。
チームメンバーがどのエンティティで雇用または契約されるかを確認します。ポジションのタイトルに「Public Sector」が含まれ、米国に所在する場合は、Federal コントラクトが必要な場合があります。採用担当者は PBP に確認してください。
候補者がベルギーに所在する場合、CES または採用担当者は 2 つの追加事項に注意する必要があります。i. ベルギーには厳格な言語/翻訳要件があるため、CES または採用担当者は候補者がベルギーのどの地域に所在するかを確認し、法務に知らせて正しい言語での正しいコントラクトを確保し、必要に応じて翻訳を手配できるようにする必要があります。ii. そのポジションがグレード 9 以上でない場合、CES または採用担当者は、候補者がオファー段階にある際（何かを送信する前に！）に #legal Slack チャンネルを通じてロールのリンクと求人票を法務チームに送り、そのポジションが信頼職かどうかを判断する必要があります。
採用担当者は「Email the team」を選択し、口頭オファーがなされた後に CES に「CES Start Contract Request」メールを送ってオファーレターとバックグラウンドチェックプロセスを開始する必要があります。

エンティティコントラクトの署名者

このチャートは GitLab の各エンティティで利用可能な署名者を示しています。優先する署名者の順に記載されています。このチャートは GitLab にエンティティがある新入社員のコントラクトにのみ使用してください。コントラクトの更新、ジョブ変更レター、異動などの内部異動には使用しません。

エンティティ	署名者
GitLab Inc	すべての採用リード（Jake Foster、Marissa Farris）、Jess Dallmar、Rob Allen、適切なグレードで文書に署名できる Inc に雇用されている他の People Group チームメンバー。JCL には Morgan Wilkins が署名できます
GitLab Federal LLC	Bob Stevens
GitLab BV Belgium, Dutch & English	Marissa Farris、Jake Foster
GitLab BV, Netherlands	Marissa Farris、Jake Foster
GitLab Canada Corp	Simon Mundy、Rich Song
GitLab France S.A.S.	Jake Foster、Rob Allen
GitLab GK, Japan	Jess Dallmar、Rob Allen & Jack Connors バックアップ: Simon Mundy
GitLab GmbH	Marissa Farris、Rob Allen
GitLab Iberia S.L (Spain)	Jake Foster、Rob Allen。バックアップ: Jim Gladen & Simon Mundy
GitLab Ireland LTD	Marissa Farris、Rob Allen、Jake Foster、Jack Connors
GitLab Israel LTD	Jim Gladen、Simon Mundy
GitLab IT BV	Marissa Farris、Jake Foster、Jack Connors
GitLab PTY Ltd, Australia	Jess Dallmar & Rob Allen、Jack Connors。バックアップ: Jim Gladen
GitLab PTY Ltd, New Zealand	Jess Dallman & Rob Allen、Jack Connors。バックアップ: Jim Gladen
GitLab South Korea	Jess Dallmar、Jack Connors & Rob Allen
GitLab Singapore PTE. LTD.	Jess Dallmar、Jack Connors & Rob Allen。バックアップ: Simon Mundy
GitLab UK Ltd	Marissa Farris、Jake Foster、Rob Allen
JCL	上記リストから署名者を選択してください。米国では、Morgan Wilkins も署名できます。
PEO	オファーを処理する Candidate Experience Specialist。JCL には Morgan Wilkins または Marissa Farris を選択してください

Greenhouse にコントラクトを追加する方法

内部 GitLab ハンドブックで、すべてのコントラクトテンプレートの SSOT としてこのリンクに移動します。このフォルダにアクセスできるのは People Group、Finance、Legal のみです。
ハンドブックページで更新しようとしているコントラクトの正しいエンティティに移動します。
アップロードするコントラクトへのリンクをクリックすると、Google ドキュメントが開きます。
「File」に移動し、「Download」をクリックして「Microsoft Word」を選択します。
Greenhouse にログインし、右上の歯車をクリックして「Configure」に移動し、「Offer Templates」を選択します。
「Upload New」ボタンに移動してクリックします（All Offer Sections の下にあります）。
テンプレート名を入力します（慣例は通常「GitLab エンティティ employment-type、with/without bonus」、例: GitLab Inc full-time, with variable bonus/commission）。
「Choose File」をクリックしてダウンロードしたドキュメントを選択し、「Save Template」をクリックします。
Greenhouse はドキュメントをアップロードし、ページの下部に表示されます。隣に「Test」ボタンがあります。クリックすると、すべての Greenhouse トークンが正しく入力されているかどうかが検証されます。エラーがある場合は通知されます。その後 Google ドキュメントのテンプレートに戻ってエラーを修正し、再ダウンロードして Greenhouse に再アップロードする必要があります（ミスのある元のものを削除した後）。すべてのトークンが正常に機能している場合、緑のチェックマークが表示され、このテンプレートをコントラクトに使用する準備ができています！
1. すべてのトークン/フィールドが正しくフォーマットされているか確認します（{{ }}）。Google ドライブのテンプレートで中括弧（{ }）を含む各フィールドについて、そのフィールド（中括弧を含む）を対応する Greenhouse トークン（中括弧を含む）に置き換えます。例えば、ドライブテンプレートの {Contributor Name} は {{CANDIDATE_NAME}} に置き換えられます。
Greenhouse からコントラクトテンプレートを削除するには、テンプレート名の右側の 3 つのドット ... をクリックし、「delete」をクリックして確認します。

コントラクトテンプレートの SSOT はLegal と People Connect によって更新されたこのハンドブックページにあります。コントラクトへの更新はまずそこで行われ、タレントアクイジションチームは変更を認識して対応する Greenhouse テンプレートを更新できるように通知される必要があります。

これらの手順は、コントラクトが更新される際にPeople Connect および法務チームによって実行されますが、参考のために、テンプレートに変更が必要な場合は以下のタスクを参照してください：

必ずしも明確ではないフィールドのいくつかは補償フィールドです。採用要件と候補者の別々のフィールドがあります。コントラクトには候補者フィールドを使用したいので、Greenhouse では給与の適切なトークンは {{CURRENCY}}、ボーナスは {{BONUS_AMOUNT}}、ストックオプションは {{STOCK_OPTIONS}} です。簡単に混同されるもう一つのフィールドはタイトルです。{{JOB_NAME}} は採用要件の名前で、必ずしも候補者が持つタイトルと同じではありません。適切なレベルと専門性を常に含めて候補者に対して正確であることを確認するには、{{FULL_TITLE__INCLUDING_LEVEL_AND_SPECIALTY_}} トークンを使用します。
中括弧の検索置換プロセスの唯一の例外はベルギーのコントラクトです。編集が必要なフィールドがハイライトされています。
任意の条項を削除する際は、段落/セクションの番号付けが引き続き意味をなすように注意してください。
入力が必要な各フィールドが Greenhouse トークンに置き換えられていることを再確認してください。中括弧が誤って通常の括弧になっている場合があり、常に明らかではありません。
各署名セクションに対して、以下のトークンはドキュメント内のそれぞれの行に単独で記述し、その行に他のものがないようにする必要があります：{{CANDIDATE_SIGNATURE}}、{{CANDIDATE_SIGNATURE_DATE}}、{{COMPANY_SIGNATURE}}、{{COMPANY_SIGNATURE_DATE}}。各署名ページを見つけ、「Signature」、「Name」、「Title」、「Date」セクションの後に Enter キーで新しい行を作成し、対応する Greenhouse トークンをコピーします。見落とすのが簡単なので、各署名セクションに適切な Greenhouse トークンがそれぞれの行に記載されているかを再確認してください。
ほとんどのコントラクトには、可変ボーナス/コミッション、ディレクター/エグゼクティブのボーナス、またはサインオンボーナスのボーナス言語を含むものなど、さまざまなバージョンを作成する必要があります。ベストプラクティスは、すべての追加情報を含むコントラクトを作成してタイトルを付け、完了したら Google ドキュメントで「File」に移動して「Make a copy」を選択することです。その後、必要に応じて情報を削除し、新しいドキュメントの名前を変更して以下の手順を続けます。例については Greenhouse テンプレートフォルダ内の他のドキュメントを参照してください。
可変ボーナス/コミッションプランを含むコントラクトテンプレートについては、すべての段落をトークン {{VARIABLE_BONUS_TYPE_OFFER_SECTION}} に置き換えてください。これにより、Greenhouse は Greenhouse で作成されたオファーパッケージに基づいて正しいボーナスタイプを自動的に選択します。
すでに作成してアップロードされたコントラクトを変更または更新するには、「Greenhouse Templates」フォルダの対応する Google ドライブドキュメントに戻り、更新が必要なテンプレートを開いて（ボーナス構造、フルタイム/パートタイムなどに対応するために各コントラクトの異なるバリエーションがあるため、複数が変更が必要な場合があります）、それぞれを更新します。変更に対応する新しいトークンを追加する必要がある場合は、上記の手順 5.3 に従ってください。変更を終えたら、Google ドキュメントで「File」をクリックし、「Download as」と「Microsoft Word (.docx)」を選択します。次に Greenhouse の「Offer Templates」セクションに戻ります。置き換えるコントラクトを見つけ、名前をコピーして一貫性を保ちます。次にテンプレート名の右側の 3 つのドット ... をクリックし、「delete」をクリックして確認します。「Upload New」をクリックしてテンプレートの名前を貼り付け、新しいバージョンをアップロードします。「Test」をクリックしてすべてが正しく変換されたことを確認し（上記のステップ 9 参照）、新しいテンプレートを使用する準備が整います。

家族関係確認書の送付方法

重要他者または家族を採用することに関する GitLab のポリシーと一致して、GitLab は資格とメリットに基づいた雇用と昇進のポリシーを採用しており、重要他者または家族メンバーの雇用について賛成または反対の差別はしません。現在 GitLab に雇用されている家族との関係を持つ新入社員は、GitLab チームメンバーとともにこの確認書に署名する必要があります。このプロセスはコントラクトの送付と合わせて行われます。

採用担当者から家族関係があることを通知されていない場合は、「Offer Details」に関係が存在するかどうかを示すフィールドがあります。また、プロフィールにFamily Memberタグがあるはずです。ただし、その家族メンバーが誰なのかは表示されません。
採用担当者は Greenhouse プロフィールのプライベートノートに家族メンバーの名前を記載します。記載がない場合は、CES が採用担当者に連絡して現在の GitLab チームメンバーを確認します。
家族メンバーが特定されたら、新入社員と GitLab チームメンバーの両方に DocuSign 経由で家族関係確認書を送ります。
DocuSign に家族関係確認書フォームをドラッグアンドドロップします。
以下の順序で受信者を追加します：

#1 GitLab チームメンバー（署名が必要）
#2 新入社員（署名が必要）
#3 CES（コピーを受け取る）

すべての当事者が署名したら、新入社員の Workday プロフィールにコピーをアップロードします。
Workday に家族関係確認書フォームをアップロードします。
- Workday にサインインします
- 新入社員の名前を検索します
- 画面左側の「Personal」リンクをクリックします
- 「Documents」を選択します
- 「Add」を選択します
- 「Select Files」をクリックして適切な保存済み PDF を選択します
- 「OK」を選択します
- 「Document Category」で「Pre-hire documents & Changes」を選択します
- 「Comment」に「Family Member Relationship Acknowledgement」と記入します
- 「Ok」をクリックしてアップロードします
- Workday で GitLab チームメンバーを見つけて同じ手順を繰り返します
最後に、HelpLab で General People Team リクエストを開き、既存の家族メンバーの Workday プロフィールに確認書をアップロードするよう依頼してください。リクエストに確認書を添付し、チームメンバーの名前を提供する必要があります。

コントラクト署名後の開始日の更新方法

GitLab エンティティのコントラクトが署名され、新しいチームメンバーが GreenHouse で「hired」になった後に開始日を変更するには、Candidate Experience Specialist は以下の手順を実行します：

採用担当者が CES に開始日の変更を通知したら、CES は Greenhouse の「email the team」から「Start Date Change Confirmation」テンプレートを送り、すべての必要なフィールドが入力されていることを確認してください。
ハイリングマネージャーと新入社員の両方から確認を受け取った後、確認メールを PDF として保存して Workday にアップロードします。
GreenHouse を更新します：
- 「Offer Details」
- 開始日の隣の編集ペンシルをクリックします
- 新しい開始日を選択します
- 保存します
- Greenhouse の「Make a Note」セクションに古い開始日と新しい開始日を記載し、オファーを承認した FP&A の担当者（通常は 2 番目の承認者）をタグ付けします
- 保存します
エンティティの給与計算プロバイダー（オランダ）に Greenhouse のメールテンプレートで開始日の変更を通知します。
Slack ワークフローで People Connect チームに更新します。
- プライベート Slack チャンネル #peopleops-alerts-private を開きます
- 左下隅のショートカットボタン（稲妻ボルトのように見えます）をクリックします
- 「New Start Date Workflow」をクリックします
- 「Team Member Name」に新入社員の名前を入力します
- 「Original Start Date（YYYY-MM-DD）」を入力します
- 「New Start Date（YYYY-MM-DD）」を入力します
- 「Reason For Change」を入力します。これにより People Connect チームに新しい日付の理由（公共の祝日、新入社員のリクエスト、ハイリングマネージャーのリクエストなど）が伝えられます。
- オプション: 「Any other changes」を入力します。
- 「Submit」をクリックします
Workday に開始日の変更に関するコミュニケーションをアップロードします。
- Workday にサインインします
- 新しいチームメンバーの名前を検索します
- 画面左側の「Personal」リンクをクリックします
- 「Documents」を選択します
- 「Add」を選択します
- 「Select Files」をクリックして適切な保存済み PDF を選択します
- 「OK」を選択します
- 「Document Category」で「Pre-Hire Documents & Changes」を選択します
- 「Comment」に「Start Date Change」と記入します
- 「Ok」をクリックしてアップロードします

PEO のコントラクトが署名され、新しいチームメンバーが GreenHouse で「hired」になった後に開始日を変更するには、Candidate Experience Specialist は以下の手順を実行します：

新しいチームメンバー、採用担当者、ハイリングマネージャー、および Candidate Experience Specialist に電子メールで開始日を確認します。
メールを PEO の連絡先に転送します。
PEO は新しいコントラクトを生成して新しいチームメンバーに送ります。
- Candidate Experience Specialist は新しいコントラクトが署名されることを確認するために PEO 連絡先にフォローアップする必要があります。
GreenHouse を更新します：
- 「Offer Details」
- 開始日の隣の編集ペンシルをクリックします
- 新しい開始日を選択します
- 保存します
- Greenhouse の「Make a Note」セクションに古い開始日と新しい開始日を記載します
- 保存します
Slack ワークフローで People Connect チームに更新します。
- プライベート Slack チャンネル #peopleops-alerts-private を開きます
- 左下隅のショートカットボタン（稲妻ボルトのように見えます）をクリックします
- 「New Start Date Workflow」をクリックします
- 「Team Member Name」に新入社員の名前を入力します
- 「Original Start Date（YYYY-MM-DD）」を入力します
- 「New Start Date（YYYY-MM-DD）」を入力します
- 「Reason For Change」を入力します。これにより People Connect チームに新しい日付の理由（公共の祝日、新入社員のリクエスト、ハイリングマネージャーのリクエストなど）が伝えられます。
Workday に開始日の変更に関するコミュニケーションをアップロードします。
- Workday にサインインします
- 新しいチームメンバーの名前を検索します
- 画面左側の「Personal」リンクをクリックします
- 「Documents」を選択します
- 「Add」を選択します
- 「Select Files」をクリックして適切な保存済み PDF を選択します
- 「OK」を選択します
- 「Document Category」で「Pre-Hire Documents & Changes」を選択します
- 「Comment」に「Start Date Change」と記入します
- 「Ok」をクリックしてアップロードします

内部候補者のジョブ変更レター署名後の開始日の更新方法

ジョブ変更レター（JCL）が署名され、内部チームメンバーが GreenHouse で「hired」になった後に開始日を変更するには、Candidate Experience Specialist は以下の手順を実行します：

開始日変更リクエストが届いたら、CES は採用担当者に Workday で変更を行うために People Connect チームの HelpLab チケットを上げるよう採用マネージャーまたは PBP と協力するよう勧めます。ハイリングマネージャーまたは PBP は HelpLab チケットを通じて新しい開始日の確認を提供する必要があります。
CES は GreenHouse を更新できます：
- 「Offer Details」に移動します
- 開始日の隣の編集ペンシルをクリックします
- 新しい開始日を選択します
- 保存します
- Greenhouse の「Make a Note」セクションに古い開始日と新しい開始日を記載し、オファーを承認した FP&A の担当者（通常は 2 番目の承認者）をタグ付けします
- 保存します

フランスまたはスペインのコントラクト署名後に開始日を更新する方法

通常の開始日変更プロセスに従った後、以下の手順を実行してください：

この開始日修正レターのコピーを作成します
ハイライトされた詳細をすべて編集し、ドキュメントをデスクトップに保存します
DocuSign で新しいエンベロープを作成し、署名順序を次のように設定します：
- 1 - GitLab France または Spain Signatory（署名）
- 2 - 候補者（署名）
- 3 - Alessio Spaggiari（コピー）
DocuSign のメール本文で TextExpander の「StartdateFS」を使用します
コントラクト用 Slack チャンネル #contracts-to-sign で署名者にレターへの署名を依頼します
ドキュメントが署名されたら、候補者の Workday プロフィールにアップロードします

候補者が署名する前にコントラクトを無効にする方法

まれに、候補者がコントラクトに署名する前にオファーを取り消すことがあります。Recruiter、Hiring Manager、People Business Partner、VP of Talent Acquisition、Contract Employment Counsel と連携し、一貫したコミュニケーションを確保してください。Talent Acquisition チームが候補者に口頭およびメールで通知した後、以下の手順を実行します：

メールが Greenhouse の Activity Feed にエクスポートされていることを確認します。
メールで送信したものと同じ内容を使用して、DocuSign でコントラクトを無効にします。
Greenhouse で候補者を不採用にします。必ず「Reject and Don’t Send Email」を選択してください。

候補者がオファーを辞退し、システム上で採用済みとされていない場合にコントラクトを無効にする方法

候補者が Talent Acquisition チームまたは CES に口頭かメールでオファー辞退を伝えた場合は、Recruiter がコントラクトを無効にしてよいと確認した後、以下の手順を実行します：

DocuSign ポータルに移動し、「 waiting for others」タブで、コントラクトを無効にする候補者の名前をクリックします。
「More」タブで「Void」をクリックします。「Candidate declined offer」など、コントラクトを無効にする理由を入力し、Void をクリックします。
候補者の Greenhouse プロフィールに移動し、Recruiter を CC に入れてコントラクトを無効にしたことをメモします。まだ実施していない場合、これにより Recruiter は GH で候補者を不採用にするよう促されます。

採用済みとされた後にコントラクトを再送する方法

システム上で採用済みとされた後に、候補者へコントラクトを再送しなければならない場合があります。その場合は、以下の手順を実行します：

req がすでにクローズされている場合は、Greenhouse プロフィールで Enablement チームをタグ付けし、状況と、コントラクトを再送するために req を再度オープンする必要があることを説明します。
Greenhouse で候補者の採用を取り消します。（ポジションが Closed の場合、Enablement がこの手順を支援する必要があります）。
正しいコントラクトを再送し、そのための標準手順に従います。
返送されたコントラクトを受け取ったら、候補者を Greenhouse で採用済みとする前に、Slack チャンネル #peopleop-alerts-private で People Connect チームに連絡し、変更内容を正確に説明します。更新された詳細は Workday に反映されないため、People Connect Team が手動で修正する必要があります。
新しいコントラクトを候補者の Workday プロフィールにアップロードします。
People Connect Team に連絡し、コントラクトが更新され、Workday の詳細を修正できることを伝えます。

Talent Acquisition Enablement の場合：

CES チームから通知を受けたら、Job Approval Chain をコピーして Approval Details Notes セクションに追加します。承認者の名前、承認日、求人を再度オープンする理由を含めます。このメモで Finance Business Partner、CES、Recruiter をタグ付けします。
Approvals ページで「Edit Job & Openings」を選択します
再度オープンする必要がある Opening を複製します。
Job Approval セクションで承認をバイパスし、Job Status を Draft から Open に変更します。
req がオープンになったら CES に知らせます。
CES が修正版のコントラクトをアップロードしたら、オファーの主要フィールドが同じままか確認します。同じであれば、オファー承認をバイパスし、完了後に CES に知らせます。
CES チームが候補者を Greenhouse で採用済みとしたら、複製した Opening をクローズして変更を保存します。

PEO のコントラクトプロセスに遅延が生じた場合に候補者へ状況を知らせる方法

CES チームが発行する PEO New Hire Document を候補者が受け取ってから、PEO の正式なコントラクトを受け取るまでに遅れが生じることがあります。この遅れにより、候補者は不安な時間を過ごすことになります。PEO SLA を超える遅延について、PEO から完全なコントラクトをまだ受け取っていない全員に知らせる必要があります。

コントラクトプロセスを開始した Candidate Experience Specialist は、コントラクトが送信されるまで 24 〜 48 時間ごとに PEO をフォローアップし、フォローアップした日付を PEO Tracker に記録します。コミュニケーションが Activity Feed に記録されるよう、Greenhouse から送信してください。PEO SLA の範囲外で候補者にコントラクトが届くことになる特別な事情がある場合、CES はそれも PEO Tracker に記録します。Recruiter は、候補者がコントラクトを受け取るまで 24 〜 48 時間ごとに進捗状況を候補者へ知らせます。遅延を説明する簡単なメッセージだけで十分です。Candidate Experience Specialist または Recruiter は、Greenhouse のリマインダー機能を利用してこれらの更新を管理し、メールを Greenhouse に記録することが推奨されます。

修正コントラクト

コントラクトの修正または変更は、チームメンバーが勤務を開始していない場合は Candidate Experience Specialist が、開始している場合は People Connect Team のメンバーが処理します。

GitLab で勤務を開始する前の修正

修正が必要で、以前のコントラクトが一度も有効になっていない場合、Candidate Experience Specialist は次のように対応します：

Slack チャンネル people-exp_ces で People Connect に、以前のコントラクトを Workday から削除するよう依頼します。
「Contracts and Changes」ドキュメントカテゴリを使用して、チームメンバーの Workday プロフィールの Documents セクションに更新済みのコントラクトをアップロードします。

注：Workday のさまざまなフィールドを更新する必要があるため、すべての変更を People Connect Team のメンバーに知らせることが不可欠です。

転居を予定している新入社員のコントラクト修正

Candidate Experience Specialist は、新入社員の開始日後の転居に伴う報酬変更条件を明確に記した文言があることを確認し、Total Rewards チームが両方の報酬を承認済みであることを確認します。
Total Rewards の承認について確信がない場合、CES は Approval Notes で Total Rewards チームに連絡します。
- 候補者の GH プロフィールの一番下に移動します
- 「Approval Notes」を確認します
- 「Leave a Note」をクリックします
- 承認した Total Rewards チームメンバーをメモでタグ付けし、両方の報酬額が承認されていることを確認します
- Recruiter を CC としてタグ付けします
Total Rewards が両方をレビューおよび承認済みであることを確認したら、適切なコントラクトを生成します
コントラクトの Word 版をダウンロードし、編集用に Google Drive へアップロードします。ドキュメントをクリックして開かず、書式に影響しないよう Drive へ転送するだけにします。
- Google Drive に移動します
- 左側のツールバーの上部にある「New」をクリックします
- 「File Upload」を選択します
- コントラクトを選択します
ドキュメントの上部に行を追加し、転居の報酬カテゴリを記載します
- ID から CA に転居する場合の例：
  - CA の報酬：$ USD
  - ID の報酬：$ USD
Section 10 Location の文言を更新します：
- 変更前
  - 1. 勤務地。GitLab でのあなたの雇用は、永住地が ID 州 Boise 近郊であることを条件とします。永住地をその場所から変更する場合、その変更に先立って Company に通知する必要があります。永住地の変更により、報酬や福利厚生が変更される場合があり、状況によっては雇用が終了する場合があります。
- 変更後
  - 1. 勤務地。GitLab でのあなたの雇用は、永住地が ID 州 Boise 近郊であることを条件とし、あなたは 2021 年 1 月 1 日頃に CA 州 San Francisco へ転居する予定であることを開示しています。永住地をこれらの場所から変更する場合、その変更に先立って Company に通知する必要があります。永住地の変更により、報酬や福利厚生が変更される場合があり、状況によっては雇用が終了する場合があります。
署名トークンが DocuSign でテキストとして表示されないよう、ドキュメントからすべて削除します。
コントラクトを保存し、PDF としてダウンロードします
GH で「Upload Replacement」を選択してアップロードします
通常どおりコントラクトをステージングします
署名順序を変更した後、トークンを再度追加します
送信します
コントラクトが完了したら、People Connect にメッセージを送り、転居が記録されていることを確認します。

GitLab で勤務を開始した後の修正

請負業者が、氏名変更または会社設立を理由にコントラクトの変更を依頼する場合（例：最近会社を設立し、個人としてではなく会社を通じて GitLab に請求したい場合）

People Connect Team のメンバーは、「Contracts and Changes」ドキュメントカテゴリを使用して、チームメンバーの Workday プロフィールの Documents セクションに依頼された変更を記録します。
People Connect Team のメンバーは、社内ハンドブックの Employment Contracts ページにある適切なテンプレートを使用して、新しいコントラクトを作成します。編集する前に、必ずテンプレートのコピーを作成してください。

重要：雇用コントラクトの日付を遡及させることはできません。チームメンバーが請求目的でコントラクトの日付を遡及させるよう依頼した場合、コントラクトに次の補遺を追加します：「請負業者は contractor start date の開始日以降 GitLab に支払いを請求していないため、GitLab は請負業者の基本報酬に従い、この期間について請負業者に支払います」。新しいコントラクトの開始日には、必ず署名のためにコントラクトをステージングした日付を反映します。

People Connect Team のメンバーは、チームメンバーと Director of People Operations の両方が署名できるよう、DocuSign でコントラクトをステージングします。
両当事者が署名したら、「Contracts and Changes」ドキュメントカテゴリを使用して、チームメンバーの Workday プロフィールの Documents セクションにコントラクトをアップロードします。

コントラクト署名後に候補者の採用を取り消す方法

候補者がシステム上で採用済みとされた後に何らかの理由でオファーを辞退した場合、その情報を受け取った人は、Greenhouse プロフィールで @ces がタグ付けされ、候補者が GitLab で勤務を開始しないことを CES が把握していることを確認します。以下の手順は、その人が GitLab で勤務しないことを前提としている点に注意してください。採用済みとされた後にオファーを修正するだけの場合は、上記の再送プロセスを参照してください。

候補者が Greenhouse で採用済みとなり Workday にエクスポートされている場合、チームは以下の手順を実行します：

req がまだオープンであれば、候補者のオファーにある「unhire」ボタンをクリックして Greenhouse で採用を取り消します。req がクローズされている場合は、Enablement に採用の取り消しを依頼します。
Recruiter に Greenhouse で候補者を不採用にするよう依頼します。メモに理由を追加し、候補者から送信されたメールを追加しても構いません。「reject and don’t send email」をクリックします。
Greenhouse で予定されているメールをすべてキャンセルします。
PEO を通じて採用した場合は、この変更を PEO の連絡担当者に直ちに、できればオンボーディング開始前に知らせます。外部給与計算を利用する国の場合は、給与計算会社にも知らせる必要があります。
チャンネル #people-ops-ces で IT、People Connect、Sr. Background Check Specialist にメッセージを送り、ノート PC の注文、オンボーディング Issue、バックグラウンドチェックのキャンセル、および Workday からの削除を依頼します。
Recruiter がまだ Greenhouse のメモで FP&A 承認者をタグ付けしていない場合は、候補者が辞退したことを知らせるため、その承認者をタグ付けしてください。
Recruiter がまだ実施していない場合は、候補者のプロフィールに Rescinded Acceptance という候補者タグを追加します。

Enablement の手順：

Approvals タブにメモを作成し、最後に求人を承認した各 Job Approver をタグ付けします。承認日を記録し、対応は不要であること、ヘッドカウントを追加するものではないこと、すでに承認済みのため代理で再承認することを伝えます。
Approvals タブから、すべての空の必須フィールドに「TEMP」を入力して Draft の Opening をオープンします。
Total Rewards を代理して承認します（Job Approval のステップ 1）。
候補者のプロフィールで採用を取り消します。
Approvals ページから一時的な Opening を削除します。これは 2 段階で行います。まず、Opening をオープンしたときと同じプロセスを使用してクローズし、保存してから再度戻り、Opening の記録を削除します。この段階のポップアップに影響する Greenhouse のバグがあるため、確認メッセージが表示されない場合はブラウザのサイズを変更する必要があります。
当初の承認者を代理して最終承認を行います。
次の手順を担当する関係者に、採用取り消しの状況を知らせます。

ジョブ変更レター

チームメンバーが Greenhouse を通じて新しいポジションに応募して採用された場合、DocuSign を使用して、新しいコントラクトの代わりにジョブ変更レターを作成します。Candidate Experience Specialist がレターを作成します。このドキュメントは Director, Total Rewards、Sr. Director, Global People Operations、または Chief People Officer とチームメンバーが DocuSign を通じて署名します。Greenhouse の「Offer through DocuSign - Job Change Letter」テンプレートを使用し、処理のために [email protected] チームを CC に入れます。

ジョブ変更レターの発効日は、月の 1 日または 16 日にします。Sales または Sales Development のチームメンバーの場合は、月の 1 日のみです。これらの発効日が営業日である必要はなく、給与計算の目的で遵守する必要があります。チームメンバーが Federal, LLC. エンティティから他のエンティティに異動する場合、または Federal, LLC. ではないエンティティから Federal, LLC. エンティティに異動する場合は、JCL を使用できないことに注意してください。このエンティティには税務上の影響があるため、そのような場合は新しいコントラクトを発行する必要があります。

チームメンバーが報酬の変更を伴わない横方向の異動をする場合、開始日は月のどの日でも構いません。

PEO のジョブ変更レターを生成する場合、手順は以下と同じです。ただし、RSU を含まない JCL テンプレートを選択し、RSU の詳細を DocuSign メールで送信します。

Candidate Experience Specialist は、採用済みとする前に追加の候補者プロフィールを統合する必要があります。プロフィールを統合しないと、重複が作成され、Workday への Employment Bot の同期に影響します。署名済みのレターは Total Rewards Analyst が Workday の Documents タブにある Contracts and Changes フォルダへアップロードします。

内部異動が行われ、その JCL の開始日が修正された場合は、Slack の #people-connect_ces チャンネルで新しい開始日を People Connect チームに必ず知らせてください。

チームメンバーが Greenhouse ではなく Workday を通じて昇進する場合、Total Rewards チームがハンドブックページに記載されたとおりにジョブ変更レターを作成します。

CES：ジョブ変更レターの作成および送信方法について、以下の手順に従います。

開始日が月の 1 日または 16 日であることを確認します。Sales または Sales Development の場合、開始日は 1 日にします。これは給与計算のためであり、営業日である必要はありません。
署名者が適切なエンティティと一致していることを確認します。候補者が米国（Federal を含む）にいる場合、Morgan Wilkins が署名者になれます。候補者が PEO を通じて雇用される場合、Morgan Wilkins と Marissa Ferber が署名者になれます（このプロセスは変更される可能性があります）
次に、Generate をクリックします
Greenhouse で Job Change Letter テンプレートを選択します：
- Job Change Letter - OTE/with RSU’s
- Job Change Letter - No OTE/with RSU’s
- Job Change Letter w/ OTE, no RSU’s
- Job Change Letter, No OTE, No RSU’s

JCL はコントラクトと同様に扱う必要があります。RSU は米国向けのものにのみ記載し、その他すべての国では DocuSign メール本文にテキストを記載します。

Send through DocuSign をクリックします
DocuSign にリダイレクトされます。
画面左上で候補者の名前が表示されている箇所をクリックし、「Edit Recipients」をクリックします。受信者の順序を次のように変更します：
- #1 は Director, Total Rewards（署名が必要）
- #1 は Recruiter（コピーを受領）
- #1 Hiring Manager（コピーを受領）
- #2 候補者（署名が必要）
- #3 People Ops（コピーを受領）
- #3 Nitin Upadhyay と Julia Demina（コピーを受領）
- これにより、コントラクトは最初に GitLab の署名者へ署名のため送信され、同時に Recruiter へ CC として送信されます。署名後、記録更新のため People Experience に送信されます。
次に「Done」をクリックします。
JCL が署名されたら、重複プロフィールが作成されないよう、採用済みとする前にプロフィールを統合してください

請負業者からの転換

請負業者からの転換とは、GitLab の請負業者が正規ポジションに移ることです。Recruiter は、候補者が請負業者からの転換プロセスを進めていることを CES パートナーに伝えます。求人に表示される「source」が Contractor Conversion になっていることを確認できます。CES のチームメンバーは通常のコントラクトと同じ手順に従いますが、注意すべき点がいくつかあります：

リファレンスチェックフォーム： 候補者がリファレンスチェックフォームに記入済みであることを確認する必要があります。請負業者が正規ポジションへ移行する場合、これが必要であることを Recruiter に念押しする必要があるかもしれません。候補者はリファレンスを再度提供する必要はありませんが、社外での仕事と PIAA を開示する必要があります。
開始日： 請負業者からの転換では、コントラクト終了日と新入社員の開始日の間に空白が生じないよう、開始日までの期間が短くなる場合があります（例：10 営業日未満での開始、または通常の開始日ではない日での開始の依頼）。
バックグラウンドチェック： 新しいバックグラウンドチェックを開始する必要があるか、Slack チャンネル backgroundcheck-ces で Senior Background Check Specialist に確認してください。コントラクトと正規ポジションの間に空白がなければ、新しいバックグラウンドチェックを開始する必要がない場合があります。
採用済みにする： Greenhouse で候補者を採用済みにした後、peopleops-alerts Slack チャンネルで People Connect に、請負業者からの転換であることをコメントで知らせる必要があります。
ノート PC／IT： すべての請負業者からの転換について、CES は候補者に新しいノート PC が必要かどうかを people-connect_CES Slack チャンネルで IT Ops に確認する必要があります。
- 新しいノート PC が不要な場合、CES は候補者への Welcome メールから「Ordering your laptop」セクションを削除します。

再雇用

元チームメンバーを会社が再雇用する場合も、通常の面接プロセスと標準のオンボーディングを行います。コントラクトに署名したら、CES は統合するプロフィールが残っていないことと、プロフィール右側の候補者タグとして Former Team Member が選択されていることを確認します。Greenhouse アカウントには以前の採用記録が存在するはずです。

再雇用が行われる場合は、#peopleops-alerts-private で People Connect に知らせてください。

オランダの GitLab チームメンバー向けプロセス

この拠点では、一時コントラクト（tijdelijk contract）の期間は 12 ヶ月で、終了日があらかじめ決められています。一時コントラクトを期間満了時に終了するための解雇手続きは必要ありません。ただし、コントラクト延長については、実際のコントラクト終了日の遅くとも 1 ヶ月前（aanzegtermijn）までに通知する必要があります。

オランダの雇用主が最初の一時コントラクトの満了時に 2 つ目の一時コントラクトを提示することは一般的ですが、保証されてはいません。オランダの雇用主として、これは GitLab の標準手順です。2015-07-01 以降、一時コントラクトで雇用主のもとで 2 年以上勤務した従業員は、雇用契約が継続する場合、無期限コントラクトを締結する権利があります。これは連鎖ルール（ketenregeling）と呼ばれます。

新入社員のプロセスは次のとおりです：

Recruiter が採用プロセスに従ってオファーを提示します。
生年月日が入力されておらず、リファレンスチェックフォームにも見つからない場合、Candidate Experience Specialist は GreenHouse のメールテンプレート Contract Info Request - the Netherlands を使用して候補者へ送信できます。
月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを確認します。
Candidate Experience Specialist は DocuSign を通じて署名用のコントラクトをステージングし、Hiring Manager と HRSavvy グループのメールアドレスを CC に入れます。これにより、この拠点の給与計算プロバイダーは、私たちのオンボーディングより十分早くオンボーディングを開始できます。
オランダでは、代わりに別のプロセス（Certificate of Good Conduct／VoGS）を行うため、犯罪歴のバックグラウンドチェックを実施しない点に注意してください。雇用確認と拡張されたグローバル制裁検索のみを含む Netherlands バックグラウンドチェックパッケージを選択してください。

People Operation Specialist がコントラクト更新を担当します。最初の 12 ヶ月の GitLab BV Netherlands 一時コントラクトの終了時のプロセスは、Netherlands Renewal Process セクションに記載されています。このセクションは、ハンドブックの Contracts, Probation Periods & PIAA ページにあります。

GitLab IT BV のコントラクトは請負業者にのみ使用します。オランダのすべての従業員には GitLab BV のコントラクトを発行してください。

オーストラリアまたはニュージーランドの GitLab チームメンバー向けプロセス

GitLab はこの拠点にエンティティを保有しています。この拠点のチームメンバーは全員従業員です。月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを常に確認します。

アイルランド、英国、またはシンガポールの GitLab チームメンバー向けプロセス

GitLab はこの拠点にエンティティを保有しています。英国、アイルランド、シンガポールの給与計算は現在 Papaya を通じて処理されます。これらの国をまとめた更新済みの「Offer Through DocuSign」メールテンプレートがあります。 Papaya は、これらの拠点のチームメンバーに給与計算についてフォローアップします。

北アイルランドは英国に属するため、UK を含む住所を見つけた場合は処理を保留し、候補者がどこにいるか、別のコントラクトとバックグラウンドチェックが必要かを Google Maps で確認してください。

韓国またはフランスの GitLab チームメンバー向けプロセス

GitLab はシンガポール、韓国、フランスにエンティティを保有しています。この拠点のチームメンバーは全員従業員ですが、給与計算は Global Upside を通じて処理されます。オファープロセスの最終ステップで CC に入るよう、正しい DocuSign メールテンプレートを必ず選択してください。

リマインダー：フランスでは、Legal チームがコントラクトを個別に作成する必要があります。これらの依頼を追跡する SSOT ドキュメントがあります。

月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを常に確認します。

フランスおよびスペインのオファー作成

フランスまたはスペインの Offer を作成する req を受け取ります。
Greenhouse で Job setup、Hiring Team の順にクリックし、Sarah Rogers と Darren Burr を Job に追加して Job Admin: FPA and Legal 権限を付与し、保存します。
月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを確認します。
ces_legal_contracts で Legal Team に Slack メッセージを送り、オファーに関する支援を依頼します。チャンネルで依頼する際は、候補者の名前を示し、GH プロフィールへのリンクを含めてください
Legal Team のメンバーの 1 人が次の情報を回答します：
- 使用する GreenHouse のオファーテンプレート
- テンプレートに追加する文言（文言を配置する場所の情報を含む）。この文言は、Legal が提供したとおりに英語側とフランス語側の両方へ英語で配置します。
- オファーにドローに関する文言が含まれない場合、Legal はオファーテンプレートのどの部分を削除するか確認します。

この情報を受け取ったら、GH に移動して以下の手順を実行してください：

設定アイコンをクリックします
左側の「Offer Templates」を選択します
Legal の指示に従ってテンプレートを検索します
使用するテンプレートの右側にある 3 つの点をクリックし、「download」タブを選択します
Google Docs でドキュメントを開きます
Legal Team の指示に従ってすべての変更を行い、ドキュメントを保存します
GH の Offer Templates ページに戻ります
右側の「Upload New」をクリックします
修正したドキュメントをアップロードします
次に GH の通常のオファー作成プロセスに従い、このオファーのオファーテンプレートとしてアップロードしたドキュメントを選択します。
プロセスが完了し、署名者と候補者がオファーに署名したら、このテンプレートを削除することを忘れないでください

イスラエルのオファー作成

イスラエルのオファー作成依頼を受け取ったら、以下の手順を実行してください。

Greenhouse で Job setup、Hiring Team の順にクリックし、Sarah Rogers と Darren Burr を Job に追加して Job Admin: FPA and Legal 権限を付与し、保存します。
イスラエルのチームメンバーの勤務週は日曜日から木曜日までのため、開始日を日曜日にできます。開始日が日曜日になることを People Connect Team に知らせてください。
Slack チャンネル ces_legal_contracts で Legal Team にメッセージを送り、オファーに関する支援を依頼します。チャンネルで依頼する際は、候補者の名前を示し、GH プロフィールへのリンクを含め、報酬の内訳と使用するコントラクトテンプレートを知らせるよう依頼してください。
Legal Team のメンバーの 1 人が次の情報を回答します：
- 使用する GreenHouse のオファーテンプレート
- 報酬の内訳と、Exhibit A に CES が追加する ID 番号
- テンプレートに追加する文言（コントラクト内で文言を配置する場所を含む）。

この情報を受け取ったら、GH に移動して以下の手順を実行してください：

設定アイコンをクリックします
左側の「Offer Templates」を選択します
Legal の指示に従ってテンプレートを検索します
使用するテンプレートの右側にある 3 つの点をクリックし、「download」オプションを選択します
Google Docs でドキュメントを開きます
Legal Team の指示に従ってすべての変更を行い、ドキュメントを保存します
GH の Offer Templates ページに戻ります
右側の「Upload New」をクリックします
候補者のイニシャルを含むタイトルで修正したドキュメントをアップロードします（コントラクトを生成するときにテンプレートを識別できるようにするためです）
次に GH の通常のオファー作成プロセスに従い、このオファーのオファーテンプレートとしてアップロードしたドキュメントを選択します。
プロセスが完了し、署名者と候補者がオファーに署名したら、このテンプレートを削除することを忘れないでください

候補者がオファーに署名したら、ノート PC のリクエストフォームがある「New Hire Welcome Email」を送信してください。GitLab はイスラエルへノート PC を発送できるため、イスラエルのチームメンバーがノート PC を自己調達する必要はなくなりました。

CXC（注：現在ここでの採用は一時停止中です：オファーレターを送信する前に Enablement に相談してください）

GitLab は CXC Global と提携し、ポーランド、ウクライナ、ルーマニア、ロシア、セルビア、スロベニアにいる GitLab チームメンバーを雇用しています。実際の雇用コントラクトは CXC が送信および発行し、現地の労働法に準拠します。また、CXC は GitLab に代わって各国の給与計算および支払い、関連する税務とコンプライアンスも処理します。コントラクト自体は個人と CXC の間で締結されます。

CXC はこれらの拠点で 12 ヶ月のコントラクトを提供し、延長できます。上記の国で設立済みのエンティティ／会社を持つ請負業者のみをサポートできます。オファーの詳細は GitLab の Hiring Team が CXC に提供します。

コントラクトを作成するには：

Recruiter が採用プロセスに従ってオファーを提示します。
Candidate Experience Specialist は GreenHouse から新しいチームメンバーに Contract Info Request - CXC をメールで送信します。
- 「Email CANDIDATE NAME」をクリックします
- ドロップダウンから「Contract Info Request-CXC」を選択します。
- Recruiter を CC に入れます
- 「Send Email」をクリックします
月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを確認します。
Candidate Experience Specialist は試用期間の有無を確認します。
- PEO に雇用されるチームメンバーの試用期間に移動し、候補者の国を確認します。
- 「Offer Details」のドロップダウンで試用期間（ある場合）を選択します。ない場合は、そのフィールドで「N/A」を選択します。
Candidate Experience Specialist は、コントラクトが無期限か有期かを確認します。
- 無期限コントラクトの場合は、「Offer Details」のドロップダウンから「Indefinite」を選択します。
- 有期コントラクトの場合は、「Offer Details」のドロップダウンから「Fixed Contract」を選択し、「End Date」に終了日を入力します。
追加情報を受け取ったら、Candidate Experience Specialist は GreenHouse から PEO フォームを生成します。
- 「Generate」をクリックします
- ドロップダウンから「PEO New Hire Template」を選択します
- 「Generate」をクリックします
Candidate Experience Specialist は、DocuSign を通じて、自分、新しいチームメンバー、適切な CXC 連絡先の署名用にフォームをステージングします。連絡先の詳細は 1password => People Operations Vault => Entity & Co-employer HR Contacts にあります。
Candidate Experience Specialist は候補者を PEO Tracking Sheet に追加し、GitLab とのコミュニケーションを追跡します。
次に CXC が SOW とコントラクトを作成します。
次に CXC が候補者へ直接連絡し、コントラクト署名と CXC の給与計算へのオンボーディングを調整します。
CXC がプロセスを完了するまで 1 週間の期間を見込んでください。GitLab での勤務開始までの通知期間が 2 週間の場合でも、3 週間に延びる可能性があります。この期間をこの拠点の新入社員へ伝えることが重要です。
コントラクトが署名されたら、CXC が Candidate Experience Specialist に知らせます。
Candidate Experience Specialist は候補者を採用済みとします。
CES は「Accepted」の日付を「Sent」の日付と一致するよう調整します。
Candidate Experience Specialist は候補者を採用済みとします。

Global Expansion（GX）を通じて雇用される GitLab チームメンバーの雇用契約書作成

GitLab は Global Expansion と提携し、以下の拠点にいる GitLab チームメンバーを雇用しています：

メキシコ
コスタリカ
ケニア
南アフリカ
UAE
ラトビア
フィリピン
オーストリア
チリ

Recruiter が採用プロセスに従ってオファーを提示します
Nationality フィールドが入力されておらず、Reference Check フォームにも見つからない場合、CES は新入社員に「Contract Info Request-Global Upside」メールを送り、追加情報を収集します
月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを確認します
Candidate Experience Specialist は試用期間の有無を確認します。
PEO に雇用されるチームメンバーの試用期間に移動し、候補者の国を確認します。
「Offer Details」のドロップダウンで試用期間（ある場合）を選択します。ない場合は、そのフィールドで「N/A」を選択します
Candidate Experience Specialist は、コントラクトが無期限か有期かを確認します
無期限コントラクトの場合は、「Offer Details」のドロップダウンから「Indefinite」を選択します
有期コントラクトの場合は、「Offer Details」のドロップダウンから「Fixed Contract」を選択し、「End Date」に終了日を入力します
追加の詳細を取得したら、すべての情報を反映するよう Offer Details を更新します。CES が署名者になります
Offer Documents で「PEO Template!」を生成し、DocuSign を通じて送信します
「Offer through DocuSign -GX - Global Expansion -To User, Self (CES) -Sign and complete」Template を選択します
CES Team のログイン認証情報を使用して GX 1 Platform にログインします（この情報は CES Desk リポジトリにあります）
ランディングページで「+ New Employee」（ピンク色のボタン）をクリックします
灰色のバーの左側にある「+」アイコンをクリックします
新入社員の個人情報を必須フィールドに追加します
- Legal Last Name
- Legal First Name
- Email
- Contact Number
- To Country
Position の詳細を追加します
- Job Title
- Intended Start Date
- Contract Duration
- Projected End Date（有期コントラクトの場合）
Signatory フィールドに CES の名前と連絡先情報を追加します
「Line Manager」フィールドに Hiring Manager の情報を追加します
PEO に雇用されるチームメンバーの試用期間の情報を使用して、従業員と雇用主の通知期間、および試用期間を追加します。
福利厚生情報を追加します：
- Medical Benefits：CES Repository にある Country Guide の情報を使用して、2 つのフィールドに入力します
- Employment Retirement Insurance：CES Repository にある Country Guide の情報を使用します。その国の Guide に何も記載されていない場合は、「Not Applicable」を選択します
- Benefits Policy Duration：コントラクト期間には「auto renew」を選択します
- Visa とバックグラウンドスクリーニングのチェックボックスが 3 つ表示される場合：UAE の場合に限り YES（Visa のみ）を選択し、すべての国のバックグラウンドスクリーニングでは常に「No」を選択します
GX Compensation
- Monthly Basic Salary：数字の「1」を入力します（これを計算する必要はありません）。候補者の年収を Additional Notes セクションに追加し、必ず通貨を含めます
- Local currency：フィールド横の下矢印をクリックし、国を検索します。候補者の Greenhouse Offer でも通貨を確認できます。
すべての詳細が入力済みの場合は「Initiate New Employee」をクリックします（データが不足している場合は「Save and Submit Later」）
次に GX が詳細を確認して従業員のコントラクトを作成します。完了すると [email protected] にメールを送り、レビューを依頼します。最初に GX Platform にログインし、その後 GX から送られたメールのリンクをクリックする必要があります
コントラクトのすべての詳細をレビューし、正確であることを確認します
- 項目が不足している場合は、フィードバックのメモを書いて GX に返送できます。ドロップダウンをクリックし、「REJECT - the following changes are required」を選択して送信します
- すべて問題なければ、ドロップダウンをクリックし、「APPROVE - I am happy with this employment contract」を選択して送信します
GX は [email protected] に 1 ページの DocuSign も送信し、雇用の詳細を再確認するよう依頼します。内容が正確であれば、ドキュメントをレビューして署名してください。DocuSign は「GL CES Team」という署名を自動入力しますが、そのタイトルの前に自分の名前を追加できます。自分の役職を追加して送信します
次に GX が雇用コントラクトを候補者に公開し、署名されるとすぐにメールで知らせます。コントラクトがポータルに手動でアップロードされた際に Desk へメールが届く場合もありますが、すでに GX から連絡を受けている場合は無視できます
正しい Welcome Email の送信に進みます
候補者を GH で採用済みとする前に、他の候補者がすべて不採用になっていることを確認してください。完了したら、候補者を Greenhouse で採用済みとし、「Accepted」の日付を「Sent」の日付と一致するよう調整して req をクローズします

Global Upside を通じて雇用される GitLab チームメンバーの雇用契約書作成

GitLab は Global Upside と提携し、以下の拠点にいる GitLab チームメンバーを雇用しています：

インド

契約書の作成および送信プロセスは次のとおりです：

Recruiter が採用プロセスに従ってオファーを提示します。
Nationality フィールドが入力されておらず、Reference Check フォームにも見つからない場合、CES は新入社員に「Contract Info Request-Global Upside」メールを送り、追加情報を収集します。
月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを確認します。
Candidate Experience Specialist は試用期間の有無を確認します。
- PEO に雇用されるチームメンバーの試用期間に移動し、候補者の国を確認します。
- 「Offer Details」のドロップダウンで試用期間（ある場合）を選択します。ない場合は、そのフィールドで「N/A」を選択します。
Candidate Experience Specialist は、コントラクトが無期限か有期かを確認します。
- 無期限コントラクトの場合は、「Offer Details」のドロップダウンから「Indefinite」を選択します。
- 有期コントラクトの場合は、「Offer Details」のドロップダウンから「Fixed Contract」を選択し、「End Date」に終了日を入力します。
追加の詳細を取得したら、すべての情報を反映するよう Offer Details を更新します。CES が署名者になります。
Offer Documents で「PEO New Hire Template」を生成し、DocuSign を通じて送信します
Template Offer through DocuSign -Global Upside を選択します -To User, Self (CES) -Sign and complete
完了した Statement of Work を PDF 形式でダウンロードし、Egnyte にアップロードします。 -ダウンロードしたファイルのタイトルが新入社員のフルネームであることを確認します
Egnyte で 「/Shared/GPS/Active Clients/GitLab/IN/HR/Employee Master/Client Upload/New Employee Information」 に移動します
Upload をクリックし、新入社員の Statement of Work をこのフォルダに配置します
Greenhouse の「Email the Team」にあるメールテンプレート Email to Global Upside を使用し、新しい SOW を Egnyte にアップロードしたことと従業員の名前をメールで伝えて、Global Upside チーム（[email protected]）に新入社員について知らせます。
Candidate Experience Specialist は候補者を PEO Tracking Sheet に追加し、GitLab とのコミュニケーションを追跡します。
Global Upside がコントラクトを作成したら、Egnyte に配置して CES にメールを送り、レビューと承認を依頼します。 -CES は、コントラクトに送信した正しい情報がすべて反映されていることを再確認します。
新入社員がコントラクトに署名したら、Global Upside が CES に知らせます。
Greenhouse で採用済みとし、「Accepted」の日付を「Sent」の日付と一致するよう調整して Welcome Email を送信し、採用済みとして req をクローズする前に他の候補者がすべて不採用になっていることを確認します。

Remote.com

GitLab は Remote.com と提携し、ブラジル、デンマーク、スイス、イタリア、スウェーデン、ルクセンブルク、ハンガリーで採用しています。実際の雇用コントラクトは Remote が送信および発行し、現地の労働法に準拠します。オファーの詳細は GitLab の Hiring Team が Remote に提供します。

コントラクトを作成するには：

Recruiter が採用プロセスに従ってオファーを提示します。
Nationality フィールドが入力されておらず、Reference Check フォームにも見つからない場合、CES は新入社員に「Contract Info Request-Global Upside」メールを送り、追加情報を収集します。
- 「Email CANDIDATE NAME」をクリックします
- ドロップダウンから「Contract Info Request-Remote.com」を選択します。
- Recruiter を CC に入れます
- 「Send Email」をクリックします
月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを確認します。
Candidate Experience Specialist は試用期間の有無を確認します。
- PEO に雇用されるチームメンバーの試用期間に移動し、候補者の国を確認します。
- 「Offer Details」のドロップダウンで試用期間（ある場合）を選択します。ない場合は、そのフィールドで「N/A」を選択します。
Candidate Experience Specialist は、コントラクトが無期限か有期かを確認します。
- 無期限コントラクトの場合は、「Offer Details」のドロップダウンから「Indefinite」を選択します。
- 有期コントラクトの場合は、「Offer Details」のドロップダウンから「Fixed Contract」を選択し、「End Date」に終了日を入力します。
CES は署名者を自分に変更し、自分の署名用にオファーをステージングします。
追加情報を受け取ったら、Candidate Experience Specialist は GreenHouse から PEO フォームを生成します。
- 「Generate」をクリックします
- ドロップダウンから「PEO New Hire Template」を選択します
- 「Generate」をクリックします
Candidate Experience Specialist は Template Offer through DocuSign -Remote.com を選択し、メールに [email protected] を CC で追加します。
DocuSign で、CES は署名順序を更新し、CES／Signatory を署名する 1 番に、コピーを受け取るその他全員を 2 番にします。
CES は PEO Template を送信し、受信トレイに届いたら署名します。
PEO Template が署名されたら、CES は候補者を Remote.com Platform にアップロードできます（詳細な手順は以下を参照してください）。
Remote が New Employee Contract を作成し、コントラクトが署名されたら Candidate Experience Specialist に知らせます。
CES が候補者による Remote.com コントラクト署名の確認を受け取ったら（Portal で確認可能）、通常どおり Welcome Email を送信して候補者を採用済みとする手順を続行します。
CES は「Accepted」の日付を「Sent」の日付と一致するよう調整します。

新入社員を Remote Platform に追加する方法

Remote Platform にログインします
ページ左側の Onboarding タブをクリックします
ページ右上の「add new employee」をクリックします
「employee」をクリックします
「employment eligibility」ページが表示されます。候補者の詳細を入力して Continue をクリックします
「basic information」ページが表示されます。候補者の詳細を入力して Continue をクリックします
「contract details」ページが表示されます。コントラクトの詳細を入力します

このセクションに入力する際は、以下に注意してください：

Contract Duration：Recruiter が指定しない限り、ほとんどのコントラクトは無期限です
- Probation Period：Remote が指定するデフォルトまたは最小のオプションを使用します。試用期間を決定するには、ハンドブックの試用期間セクションを使用してください。
- メキシコの場合：Remote Platform にチームメンバーを追加する際は、Christmas Bonus として 15 日ではなく 30 日を選択します。
Type of employee：Full time
Annual Gross salary：GH の Offer Details に記載された金額
Annual leave：通常は法定最低日数です。General & Entity Specific Benefits ページも使用できます
- メキシコの場合は 20 日と入力できます
Is this employee approved for outside employment：No
Signing bonus：GH の Offer Details に記載された金額
Other Bonus：保証されたドローは含めません。依頼された場合は、Marissa を関係者に加えてください。Remote は現在、私たちのボーナス体系について、この情報を含められるほど十分に詳しく理解していません。
Commission：No
Equity Compensation：含めません。
Number of paid time off days：Remote が提示する法定最低日数を選択します。選択肢がある場合は、最も少ない日数を選択します（これが法定最低日数のはずです）
Role Description：Job Family 内の Job Description をコピー＆ペーストします。候補者の特定の役割のみが含まれていることを確認し、冒頭と末尾の補足部分は省略できます。
Training requirement：空欄のままにします
Supervisor Name：GH の Offer Details に記載された名前
Experience level：選択する国に応じて、これらの選択肢には異なるバージョンがあります。ポジションに最も近いものを選択し、不明な場合は Recruiter に推奨を尋ねます。
Work Address：Yes を選択します
Benefits - 国ごとに以下を選択します：

国	福利厚生プラン
デンマーク	Standard
ハンガリー	Standard
ルクセンブルク	Premium
ブラジル	Omint Plan（自動的に追加されるはずです）
イタリア	Premium
スイス	None
スウェーデン	None

Life Insurance Coverage - メキシコでの採用の場合、「Life/ADD Insurance of 350 MXN (~18 USD)」を選択してください。Remote を通じて契約するチームメンバーの福利厚生の詳細は、こちらをクリックしてください。質問がある場合は、[email protected] に連絡してください。
福利厚生に関する確認をクリックして続行します
「billing cycle」ページが表示されます。
Monthly Billing Cycle をクリックして Continue をクリックします。
候補者とコントラクトのすべての詳細をレビューできるようになります。必要に応じて編集できます。
レビューしてすべて問題なければ、「invite now」をクリックします。
「add this employee to a single employee plan」オプションを選択してください
候補者が正常に送信されました。Remote のホームページで進捗を確認できます。

新入社員を Papaya Platform に追加する方法

Papaya Platform にログインします
ページ右上の「add worker」タブをクリックします
EOR Worker ブロックの下にある「create new request」をクリックします
ドロップダウンで候補者の国を選択します
Next をクリックします
「worker details」ページが表示されます。候補者の詳細を入力します
Company ID は無視してください
Next をクリックします
「employment terms」ページが表示されます。詳細を入力します
無期限コントラクトの場合の Expected End Date と Organizational Attributes は無視してください
Continue をクリックします
「contract compensation」ページが表示されます。コントラクトの詳細を入力します
Allowances と Miscellaneous は無視してください
Contract Terms で、すべてについて Mandatory Requirements by Local Law タブを選択します
Next をクリックします
「initial employment terms letter」ページが表示されます。コントラクトの詳細を入力します
Papaya がコントラクトより前に Initial Employment Terms Letter を候補者へ送信するかどうかでは、「yes」をクリックします
Next をクリックします
候補者とコントラクトのすべての詳細をレビューできるようになります。必要に応じて編集できます。
Consent Clause のすべての条件を選択します
Papaya がいつ Worker に連絡するかでは、「as soon as possible」を選択します
Submit をクリックします
候補者が正常に送信されました。Papaya のホームページにリダイレクトされます
候補者を送信すると、新しいプロジェクトについて Papaya に知らせるアラートが送信されます
GitLab を担当する Papaya の Customer Success Manager である Amit Bengal（[email protected]）が CES に連絡し、アラートを受け取ったことを確認します。Amit は候補者へ直接連絡する許可を求めるため、できるだけ早く確認してください。Papaya は Platform に送信された情報を検証し、共有されたコントラクト情報についてすぐに質問がある場合は CES または候補者へ連絡します
基本的なオファーの詳細を記載した Offer Overview（Offer Template）が承認のため CES に送信されます（私たちの PEO Template に似ています）。承認されると、Offer Template を添えて候補者へ Welcome Email が送信されます。Welcome Email では候補者に PEO を紹介します。
この段階で、候補者は情報を検証し、依頼の完了に必要なドキュメントを提供するよう求められます。
候補者が情報を検証して必要なドキュメントを提供したら、Papaya はオファーのドラフトを Local Team（候補者の国の連絡担当者）へ送り、その国の法律に照らしてコントラクトをレビューします。所要時間：48 時間
Local Team は担当部分を完了すると、オファーを Papaya の Legal Team へ送信します。その後、Legal Team が最終オファーを承認します。所要時間：24 時間
承認されたオファーは、Papaya Platform の Hidden Documents にアップロードされます。候補者に発行する前に、最終ドラフトを承認するよう CES に通知されます。
質問または修正が必要な場合、複雑さによっては、Local Team（48 時間）へ戻し、その後 Legal Team（24 時間）へ戻してから、再び私たちへ戻す必要があります。
CES がオファーを承認すると、Papaya が候補者へ提示します。
質問または修正が必要な場合、複雑さによっては、Local Team（48 時間）へ送り、その後 Legal Team（24 時間）へ戻してから、再承認のため私たちへ戻し、再び候補者に発行する必要があります。
候補者が承諾すると、Papaya が私たちに知らせます。

GitLab がノート PC を注文できない拠点向けの前払い資金プロセス

こちらに掲載されている一部の国では、新入社員が開始日前に自分でノート PC を調達する必要があります。

CES のチームメンバーは、新入社員がこれらの国のいずれかにいることを確認し、New Hire Welcome Email - Brazil, Costa Rica, Chile, Armenia, or Ukraine Template を送信します。
このメールでは、通常の Welcome Email とは異なる Google Form を使用します。新入社員には 2 つの選択肢が提示され、希望する方を選択するよう求められます：
- GitLab での初日に、購入し NAVAN を通じて経費精算する
- 自己調達のために前払い資金を依頼する
IT は IT Equipment Order Processing Desk で、新入社員の選択内容を記載した Issue を受け取ります。候補者が前払い資金を依頼した場合、IT は Issue 内で AP をタグ付けし、ノート PC 購入の承認を提供します。AP は新入社員の銀行口座情報を収集し、資金を支払います。

GitLab と新入社員：

Recruiter が採用プロセスに従って口頭でオファーを提示したら、このページを使用してコントラクトを作成する方法に従い、Template-GitLab China Employee Offer letterに記入します。
CIIC では、Letter of Employment Intentの中国語版が必要です。
必要な／判明しているすべての情報を Letter of Intents に記入します。まず英語で作成し、その後 Google Translate を使用して中国語に翻訳します。
完了したら、Letter of Employment Intent の GitLab 版（中国語と英語）を DocuSign で新入社員へ送り、レビュー、記入、署名を依頼します。Peopleops と CIIC がコピーを受け取るようにしてください。
すべて署名されたら、中国語と英語の Letter of Intents を印刷し、FedEx で CIIC に送ります。住所は Google Drive の PEO China フォルダ > China Employment Options > CIIC にあります。
Candidate Experience Specialist は候補者を PEO Tracking Sheet に追加し、GitLab とのコミュニケーションを追跡します。
コントラクトが署名されたら、PEO が Candidate Experience Specialist に知らせます。
Candidate Experience Specialist は候補者を採用済みとします。
CES は「Accepted」の日付を「Sent」の日付と一致するよう調整します。
Candidate Experience Specialist は候補者を採用済みとします。

GitLab と CIIC：

GitLab は CIIC と Secondment Agreement を締結しています。更新が必要な場合がありますが、CIIC が確認します。
CIIC はドキュメントを受け取ったら Payment Notice を作成し、支払いのために GitLab（peopleops）へ送信します。これは前払いする必要があり、CFO の承認が必要な場合があります。
CIIC は支払いを受け取った後、新入社員へ連絡して Labor Contract を作成します。

CIIC と新入社員

CIIC と新入社員の両方が Labor Contract に署名したら、その人は GitLab で勤務を開始できます。

ドイツの GitLab チームメンバー向け雇用契約書

2025 年 1 月 1 日から、ドイツでの自筆署名要件が撤廃されたため、DocuSign を通じた電子署名でオファーを発行できます（手順は以下に記載）。現在、ドイツの給与計算はすべて Papaya を通じて処理されています。

CES は、開始日が月曜日、または月の 1 日か 16 日のいずれかであることを確認します
このテーブルに従い、German Entity に記載されている署名者を使用してください
Greenhouse と DocuSign を通じてオファーを送信します。「send through DocuSign」Template を使用し、メール本文に RSU 情報を追加します。
バックグラウンドチェックを開始します。Sterling のドロップダウンから Germany Package を使用してください。

ドイツの候補者には、自筆署名のコントラクトを求める権利があります。（プロセスは後日追加予定）

日本の GitLab チームメンバー向け雇用契約書

GitLab は日本にエンティティ（GitLab GK）を保有しており、この拠点では GitLab GK のコントラクトを使用します。この拠点のチームメンバーは全員従業員です。

月曜日が祝日である場合、または月曜日以外の日付が法的に必要な場合を除き、開始日が月曜日であることを常に確認します。

インターン雇用コントラクト

GitLab は INC エンティティ内でのインターン採用および Code2College プログラムに参加しています。Code2College は、高校生を有給の技術インターンシップに配属する初めてかつ唯一のプログラムです。

Intern Contract Template は、C2C インターンと GitLab に採用されるその他すべてのインターンの両方に使用します。ただし、C2C インターンを処理する場合は、いくつか異なる必須手順があります。プロセスを以下に説明します。

オファーを決定したら、Emerging Talent Coordinator／Recruiter は GH プロフィールで Offer を作成し、通常どおり承認を依頼します。
承認されたら、CES は GH の「INC Intern」Template を使用してコントラクトを送信します。Offer Details で必要な重要情報には、時間給とコントラクト終了日（無期限コントラクトではないため）があります。生成する前に、これらの詳細が Offer に含まれていることを確認してください。
Offer を送信した後、CES は Comprehensive Criminal Check with Employment を選択してバックグラウンドチェックを開始します。重要な注意 - C2C（Code2College）インターンの場合、Sterling で Comprehensive Criminal Check のみを選択します。ほとんどの C2C インターンは未成年のため、Employment Check は必要ありません。
C2C のインターンの多くは未成年であるため、BGC の開始時に CES はインターンの保護者へ Parental Consent Formも送信する必要があります。
- このフォームは DocuSign で送信できます
- 適切なトークンを追加してください
- 配布を次のように設定してください（保護者のメールアドレスは Emerging Talent Coordinator から受け取れます）：
  1. 保護者 - 署名が必要
  2. Emerging Talent Coordinator - コピーを受領
候補者が Offer に署名したら、CES は GitLab Inc Intern Welcome Email を送信します。注：GitLab はこれらのインターンにノート PC を提供します。Welcome Email では、できるだけ早くフォームに入力するよう求めています
req がクリアされたら、CES はインターンを採用済みとできます。
CES は Slack チャンネル #peopleops-alerts で People Connect に連絡し、インターンを採用したことを知らせます。メッセージで C2C かどうかを示してください
インターンがシステム上で採用済みとなった後は、People Connect が責任を引き継ぎ、オンボーディング Issue を作成して TaNewKi Call に関する情報を伝えます。
C2C インターンに「youth work permit」が必要であると通知された場合は、フォームを People Connect へ送信してください。People Connect は「employer」部分を記入し、インターン／保護者へ提出する必要があります。

その他すべての拠点にいる GitLab チームメンバー向けの雇用契約書（IT BV Contractor Agreements）

対象とする拠点の採用状況をレビューします。拠点がまだ評価されていない場合は、IT BV Contractor Agreement を発行します。
候補者が請負業者契約に自身のエンティティを使用したい場合は、Contractor Name と Address で Offer Details を更新します。この場合は IT BV Contractor Agreement - C2C を使用します。
IT BV Contractor Agreement - Independent または IT BV Contractor Agreement - C2C を生成します
Send with DocuSign を選択します
「Offer through DocuSign-IT BV」メールテンプレートを選択します
「To」フィールドを更新して GitLab の署名者を含め、CC フィールドに Hiring Manager を含めます
Preview on DocuSign を選択します
DocuSign で、他のコントラクトと同様に署名順序を更新し、Send をクリックします

エンティティのコントラクトへの転居文言の追加

Candidate Experience Specialist は、新入社員の開始日後の転居に伴う報酬変更条件を明確に記した文言があることを確認します。
CES は Approval Notes で Total Rewards チームに連絡します。
- 候補者の GH プロフィールの一番下に移動します
- 「Approval Notes」を確認します
- 「Leave a Note」をクリックします
- Brittany Rohde をメモでタグ付けし、両方の報酬額が承認されていることを確認します
- Recruiter を CC としてタグ付けします
Total Rewards が両方をレビュー済みであることを確認したら、適切なコントラクトを生成します
コントラクトの Word 版をダウンロードし、編集用に Google Drive へアップロードします
- Google Drive に移動します
- 左側のツールバーの上部にある「New」をクリックします
- 「File Upload」を選択します
- コントラクトを選択します
ドキュメントの上部に行を追加し、転居の報酬カテゴリを記載します
- ID から CA に転居する場合の例：
  - CA の報酬：$ USD
  - ID の報酬：$ USD
Section 10 Location の文言を更新します：
- 変更前
  - 1. 勤務地。GitLab でのあなたの雇用は、永住地が ID 州 Boise 近郊であることを条件とします。永住地をその場所から変更する場合、その変更に先立って Company に通知する必要があります。永住地の変更により、報酬や福利厚生が変更される場合があり、状況によっては雇用が終了する場合があります。
- 変更後
  - 1. 勤務地。GitLab でのあなたの雇用は、永住地が ID 州 Boise 近郊であることを条件とし、あなたは 2021 年 1 月 1 日頃に CA 州 San Francisco へ転居する予定であることを開示しています。永住地をこれらの場所から変更する場合、その変更に先立って Company に通知する必要があります。永住地の変更により、報酬や福利厚生が変更される場合があり、状況によっては雇用が終了する場合があります。
すべてのトークンを削除します
コントラクトを保存してダウンロードします
GH で「Upload Replacement」を選択してアップロードします
Slack の Contracts-to-sign チャンネルに連絡し、将来の転居を想定してステージングしたコントラクトを送信することを Recruiter に知らせます
通常どおりコントラクトをステージングします
署名順序を変更した後、トークンを再度追加します
送信します

雇用オフボーディング

チームメンバーが GitLab を退職すると、People Connect がオフボーディング Issue を作成します。CES チームは @gitlab-com/gl-ces セクションにあるタスクを完了する責任があります。オフボーディング Issue には期限があるため、Issue に設定された期日までに完了する必要がある点に注意してください。これらのタスクを完了することで、GitLab のコンプライアンス維持も確保されます。

オフボーディング Issue がある Employment Issues に移動します。検索バーで「CES: To Do」ラベルを使用して Issue を絞り込み、期日順に対応します。オフボーディング Issue を開いたら、@gitlab-com/gl-ces セクションに移動し、以下の手順を完了します。
Google Calendar を開き、「Interview Calendar」を選択し、上部の検索バーにチームメンバーの名前を入力します。オフボーディングするチームメンバーが進行中の面接に参加していないことを確認します。チームメンバーが進行中の面接に表示される場合は、該当する CES チームメンバーに、Recruiter と協力して面接担当者を交代するよう伝えます。Calendar でグレー表示された面接は、すでに終了しています。
オフボーディングするチームメンバーが Engineering 部門に所属する場合、CES は Hiring Repository の Backend、Frontend、Platform POOLを確認し、退職する面接担当者を Pool から削除します。 CES は、たとえば「Removed John Doe from list of ruby on rails technical interviewers」のようなマージリクエストを通じて変更できます。CES は、オフボーディングする面接担当者を Hiring Repository から削除するためにのみマージ権限を使用し、その他の重要な変更を加えてはいけません。
Greenhouse の Users でチームメンバーの名前を検索し、そのチームメンバーが参加している可能性のある req を確認します。チームメンバーの名前を検索する際は、そのチームメンバーの GitLab メールアドレスが表示されたプロフィールを選択します。これにより Greenhouse のプロフィール設定へ移動します。 Open の Job req を持つ「Job Admin: Hiring Manager」としてチームメンバーの名前が掲載されている場合は、以下の手順を実行してください：
- Job req のタイトルをコピーして新しい Greenhouse ウィンドウに貼り付け、検索します
- req 番号が一致していることを確認し、正しい Job req を選択します（例：7458）
- Job Set up を選択して Hiring Team セクションに移動します
- Hiring Manager のポジションが別のチームメンバーによって補充されていることを確認してください。Hiring Manager セクションが空であるか、オフボーディングするチームメンバーがまだ表示されている場合は、記載されている CES Coordinator に連絡し、Recruiter と協力して代わりの Hiring Manager を見つけ、Interview Plan を更新するよう CES チームメンバーに伝えてください。
- オフボーディングするチームメンバーが、タイトルに「Closed」、「Draft」、「Template」を含む req で「Job Admin: Hiring Manager」として掲載されている場合は、対応不要です。
すべての手順が完了したら、オフボーディング Issue の右側に移動し、「CES: To Do」ラベルを削除して通知を無効にし、「Recruiting Ops」にコメント／通知を残します。（例：@ destinyreyes ces tasks done）

最終更新 September 12, 2026: Merge pull request #526 from kyama0/translation/batch-2026-09-12-1 (a1f3c26a)

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