コンティンジェントワーカーの採用 - 開発部門
GitLabは通常、法人とPEO（Professional Employer Organization）を通じて開発チームに正規雇用のフルタイムエンジニアを採用することを優先しています。しかし、チームが業務遂行を支援する一時的なコンティンジェントワーカーを採用する必要が生じる場合があります。
コンティンジェントワーカーが必要となる状況の例として、次のものが挙げられます:
- チームメンバーが長期休暇中で、一定期間そのポジションを補充する必要がある場合。
- 単発のプロジェクトがあり、迅速な実行が必要で、他のチームメンバーがより優先度の高い業務で手が離せない場合。
- チームに非常に特殊な専門知識や技術的スペシャライゼーションが欠けており、支援のためにコンサルタントが必要な場合。
- 外部の当事者によるオープンソースプロジェクトへの貢献に対して財政的支援を提供する場合。
理由が何であれ、コンティンジェントワーカーの採用には特有の課題とプロセスがあり、通常の採用とは異なります。
次のセクションでは、プロセスに関する一般的な情報をご覧いただけます。ただし、このプロセスのバリエーションについてはサブ部門のリードに相談してください。また、前提条件としてGitLabのコンティンジェントワーカーポリシーも必ずお読みください。
計画と予算承認
正社員採用と同様に、コンティンジェントワーカーについても、ニーズに応じた期間の費用をカバーするために必要な予算を事前に計画する必要があります。
このためには、サブ部門のリーダーとコンティンジェントワーカーの必要性と理由について議論する必要があります。また、必要な経験レベルと契約期間という観点から数字を検討する必要があります。さらに、コンティンジェントワーカーがフルタイムで働くかパートタイムで働くかを決定する必要があります。
予算を検討する際は、コンティンジェントワーカーには給与のみが支払われることを念頭に置いてください。彼らには福利厚生がありません。また、直接採用するか、採用エージェンシーを通じて候補者を探すかについても検討する必要があります。この2つのシナリオでは費用が大きく異なる場合があります。採用エージェンシーやチーム拡張エージェンシーを利用する場合は、エージェンシーが請求する採用費やその他の管理費用を計上する必要があります。
コンティンジェントワーカーを採用することで達成しようとしている目標を概説した簡潔な提案書を作成し、その必要性を満たすためにフルタイムのチームメンバーを採用できない理由を明確に正当化することをお勧めします。提案書には予算とタイムラインの情報も含めてください。必要性を概説し予算承認を求めるIssueの例はこちらです。
マネージャーと予算について合意し、部門長レベルで承認を得たら、採用プロセスの次の段階に進めます。
候補者のソーシング
コンティンジェントワーカーの候補者ソーシングについて最初に知っておくべきことは、彼らは財務部門が定める調達プロセスを通じてプロフェッショナルサービスベンダーとして採用されるということです。つまり、エンジニアリングマネージャーとして、GitLabのタレントアクイジション担当リクルーターからのサポートはほとんど、またはまったく得られません。
戦略を検討する必要があります。自分のプロフェッショナルネットワークやLinkedIn Recruiterなどのツールを使って個人に直接アプローチして直接採用することができます。または、この目的のために採用エージェンシーやチーム拡張エージェンシーを活用することもできます。
直接採用を選択した場合、調達部門によるエージェンシーの審査と承認に関する管理作業が少なくて済みます。ただし、ソーシング作業自体により多くの労力を費やす必要があります。
できることの一つとして、GitLabのリクルーターに、あなたのグループや他のグループの同様の職種で選ばれなかったものの非常に優秀だった過去の候補者をGreenhouse内で探してもらえるよう依頼することです。そのような候補者はあなたのニーズに合ったコンティンジェントワーカーとして最適かもしれません。また、出発点として、それらの候補者に関するコンテキストと面接メモを活用できます。
スタッフ拡張または採用エージェンシーを利用すると、ソーシング作業の時間を節約できますが、エージェンシー自体の審査に追加のオーバーヘッドが必要です。この場合、まず財務部門に確認し、すでにGitLabと取引のあるエージェンシーを探すことをお勧めします。選択したエージェンシーと協力して、そのポリシーや候補者のソーシングと面接における企業との協働方法を理解する必要があります。
どちらの場合も、職務記述書（JD）が必要です。一時的なバックフィルとして採用する場合は、JDがそのポジションの職務記述書にできるだけ近いものになるようにしてください。そうでない場合は、技術的および職務上の要件をできるだけ具体的に記述してください。また、GitLabをユニークにしている文化的規範と価値観を強調することも重要です。コンティンジェントワーカーもこれらの規範を認識し、適応する必要があるためです。
面接プロセス
面接については、この採用を行うエンジニアリングマネージャーとして、インタビューを組み立てる裁量が大きくあります。多様性・インクルージョン・帰属意識に関するガイドラインなど、会社レベルのガイドラインにできるだけ近い形で進めることをお勧めします。面接官の多様性や技術的な審査へのアプローチを含む面接プロセスの定義の基準として、自分のサブ部門やグループのガイドラインも使用できます。
契約と請求
採用したい候補者を特定したら（直接採用またはエージェンシー経由）、実際の契約プロセスは財務部門が概説するプロフェッショナルサービスの調達プロセスに基づきます。
上記のハンドブックセクションで詳細をお読みいただけますが、大まかに関わるステップは以下の通りです:
契約の開始日と終了日を選択する（注意: スタッフ拡張ワーカーの最長期間は24ヶ月）
コンティンジェントワーカーがGitLabのために実施する業務と、この契約に関連する条件を概説した作業範囲記述書（SOW）を取得する（または自分で作成する）。SOWには、日付、個人（および/またはエージェンシー）の名前、契約全期間の最大費用総額（費用が契約期間全体にわたって定期的に支払われる場合でも）を明記する必要があります。
SOWを作成する際は、できるだけ具体的に記述してください。作業の範囲、受け入れ基準、成果物を明確に特定してください。また、チームの働き方に関連する基準を追加することも検討してください。たとえば、コンティンジェントワーカーにIssueへの日次非同期アップデートを追加することを期待しているか、マージリクエストを
x行以下にすることを期待しているか。もしそうなら、SOWに追加することを検討してください。コンティンジェントワーカーまたはベンダー担当者にSOWに署名してもらう。
調達プロセスを完了させる。コントラクターのためにZipリクエストを提出する方法を確認してください。
確定した契約終了日でCoupaにてPOが承認される。注意: Coupaへのアクセス権がない場合は、アクセスをリクエストするか、グループ内でアクセス権を持つ誰かにリクエストを提出してもらうことができます。
ZipでセキュリティとリーガルのレビューをComplete（完了）にする。
オレンジ/レッドデータにアクセスする場合はバックグラウンドチェックを完了させる。
オレンジ/レッドデータにアクセスする場合、コントラクターにはGitLabのノートパソコンが必要です。マネージャーは、ITがコントラクターの国/所在地にノートパソコンを届けられることを確認する必要があります。
承認フローを追跡し、リクエストに対してタイムリーに返答がない場合は必要に応じて個人にリマインドしてください。
Coupaの購入依頼が承認されると、ベンダー/コンティンジェントワーカーはSOWに基づいた定期的な間隔で、割り当てられた予算に対して請求できるようになります。請求書を提出すると、Coupaのリクエスト担当者はCoupaから支払い承認の通知を受け取ります。
オンボーディング
契約処理が完了したら、新しいコンティンジェントワーカーをプロジェクトまたはチームにオンボーディングしたいと思います。これは、業務の性質、チーム、プロジェクトによって、コンティンジェントワーカーごとに大きく異なります。
一般的に言えば、コンティンジェントワーカーは「一時的なサービスプロバイダー（Temporary Service Providers）」と呼ばれることを知っておく必要があります。ハンドブックには、彼らのライフサイクル、アクセスリクエストの作成方法、オンボーディングおよびオフボーディングについての具体的なドキュメントがあります。
一般的なガイドラインとして、以下のことを実施してください:
- GitLabの価値観と文化について学ぶ
- チームのプロセスと儀式についての具体的な事項を学ぶ
- チームのテクノロジースタックについて学ぶ
- コミュニケーションおよび生産性システムへの必要なアクセスをプロビジョニングする（プロジェクトのメンバーシップ、ChatOps、
#productionを含むSlackチャンネルなど）。このためには、アクセスリクエストを利用したり、#it_helpで質問したりすることができます。
アナウンス
チームがコンティンジェントワーカーについて知ることだけでなく、一時的なサービスプロバイダーがGitLabのために働いていることを広く認識させることが重要です。
自分のグループとステージのSlackチャンネルで新しいコンティンジェントワーカーの参加に関する情報を共有することが推奨されますが、#development、#engineering-fyi Slackチャンネル、またはEngineering Week In Reviewドキュメントに短いメッセージを書くことも検討してください。これらの全社的なチャンネルでは、コンティンジェントワーカーが特定のグループのために働く予定であることを記載するだけで十分です。
コンティンジェントワーカーとの協働
私たちはコンティンジェントワーカーを、コードレビュープロセスを含むIssueやマージリクエストへの貢献において、通常のチームメンバーと同様に扱います。
