GitLab 社の People Engineering ハンドブックを和訳してみた

GitLab はフルリモート並びにそれを維持する為の非同期コミュニケーションに力を入れている企業だと思います。その根底にはオペレーションの工夫があるはずで、その片鱗でも触れてみたいと思い、公開ハンドブックの中でも人事部門エンジニアにフォーカスしてDeepLに放り込んでみました。GitLab の指定ディレクトリ以下の.mdファイルを全てマージして和訳しています。それでは早速どうぞ。

※内部リンクが機能してくれないことに気づきましたが、面倒なのでこのまま放置しますw

People Group Engineering

GitLab の People Group Engineering チームとそのプロジェクト、ワークフロー、データのソースに関する情報です。

概要

GitLab の規模が拡大するにつれ、その成長を管理するためのツールや自動化の必要性も拡大しています。People Groupを支援するために、People Groupエンジニアリングチームがあります。このチームは、People Groupフルスタックエンジニアで構成されており、チームをより効率的にし、中核となるPeople Groupの有効性を向上させます。

責任範囲は以下の通りです(ただし、これに限定されません)。

  • 人材獲得における自動化とAPI統合

  • 雇用問題の自動化

  • SSoTを保証するための統合

  • 雇用botを実行するコードの管理

私たちと一緒に働く

People Groupのプロセスに関連する Issue 、バグフィックス、緊急のリクエストなど、エンジニアリングの支援をご希望の場合は People Groupのプロセスやツール(BambooHR など)(/handbook/people-group/#using-bamboohr)に関する緊急のリクエストなど、People Group・エンジニアリングに関連することであれば、まず以下の方法でご連絡ください。 issue の作成 をしてください。すべての問題はレビューされ、特定の milestones に向けて優先順位付けされます。MR に関する一般的なサポートが必要な場合は、Slack の #mr-buddies で GitLab 従業員全員と協力してください。

バグ報告

既存の統合に関するバグを報告する場合は、以下のテンプレートをご利用ください。 - Bug with a /pops command

緊急のお知らせ

弊社では、一部のアプリケーションにアクセスできなくなった場合に備えて、モニタリングの設定を行っています。具体的には、 Compensation calculator Nominator bot Assessment tool が該当します。この場合、People Groupのエンジニアにテキストメッセージが送られます。すぐに対応が必要な場合は、Slackの #people-connect-eng チャネルをご利用ください。緊急性が高い場合を除き、人に直接メッセージを送ることは避けてください。

ワークフロー

People Group・エンジニアリングボード は、エンジニアリングチームの優先事項に関する唯一の情報源となっています。 Issue は直線的な順序で表示され、Workflow:: ラベルが Issue の現在のステータスを示します。 ラベルは Issue の現在のステータスを示します。

  1. Workflow::Triage: Issue はここから始まります。トリアージされた Issue は、開発の準備をする前にさらに定義する必要があります。 Issue とそれを解決するための提案が定義されると、Workflow::Ready for Developmentに移すことができます。
  2. Workflow::Ready for Development: エンジニアが作業を開始できるように整備された Issue です。問題点が明確に定義されており、作業を開始するのに十分な提案がなされています。すべての詳細が定義されている必要はありませんが、エンジニアは Issue の説明を読むだけで、この Issue の作業を開始できるはずです。
  3. Workflow::Next Up: これらの Issue は、次に取り組むべき Issue として決定されます。このリストは、チーム内のエンジニア1人につき4件程度になるようにしています。
  4. Workflow::In Progress: 開発者が積極的に作業している Issue です。
  5. Workflow::Verification: 開発が完了し、評価の準備ができている Issue 。この時点で、開発したソリューションが( Issue 報告者や他の関係者によって)評価され、元々の問題が解決されていることを確認する必要があります。

  6. 署名が得られれば、 Issue はクローズされます。

Issue はさらに3つの状態に置かれることがあります。

  • Workflow::Waiting: 誰かからのインプットを待っている Issueや、依存関係を待っているIssue。これらは 他者からのインプットや進捗を必要としているIssueです。

  • Workflow::Blocked: これらの Issue は、他の Issue によってブロックされているか、APIエンドポイントが不足しています。People Ops Engineer は、 Issue がブロックされた理由を常に追加します。

  • Workflow::On Hold: これらの Issue は、現在保留されており、リクエスターにその旨が通知されています。重要なアイデアであることに変わりはありませんが、リクエストに応える為のキャパシティやリソースがない可能性があります。キャパシティやリソースに変更があった場合は、チケットのステータスを再検討します。

新規チケットのトリアージ

新しいチケットが7営業日以内にトリアージされることをパフォーマンス指標として設定しています。People Engineering チームの全員が新しいチケットのトリアージを行うことができます。新しいチケットが入ってきたときにすること:

  • テンプレートにすべて記入されているかどうかをチェックし、記入されていない場合は、作成者に記入してもらい、Workflow::Waitingというラベルを追加します。

  • 作成者にフォローアップの質問があるかどうかをチェックし、あれば Issue の作成者に ping を送信して質問をし、Workflow::Waitingというラベルを追加します。

  • プロジェクトのラベルを決定します (例: ~p-compensation-calculator, ~p-assessment-toolなど)。

  • 優先度のラベルを決定する(prioritiesを参照)。

  • チームのラベルを決めます(PopsEng::Team::People Success, PopsEng::Team::People Operations など)。チームごとに Issue を分類したGitLabのボードもあります。

  • 新規プロジェクト(~PopsEng::New Project) なのか、バグ(~PopsEng::Bug)なのか、既存のプロジェクトやインテグレーションへの追加(~PopsEng::Addition)なのかを判断します。

  • チケットの作業を開始するのに必要な情報がすべて揃ったら、 Workflow::Ready for Development または Workflow::Next Up のいずれかのラベルを付けます。

注:バグについては、別のパフォーマンス指標があり、1 営業日以内に対応することが求められています。これは、いずれかの統合機能にバグがあると、非効率的で手作業になることが多いためです。

優先順位

チケットを完全なトリアージとする前に、以下の情報が必要です。 - コンプライアンスに関連しているか?

  • 問題はどのくらいの頻度で発生しているか?毎日、毎週、毎月、毎年?

  • 何人の従業員がこの問題の影響を受けているか?

  • 現在、この作業を行うために必要な手作業(時間)はどのくらいか?

これらの知識を念頭に置いて、私たちはチケットの優先順位を以下の表で決定します。

優先度 コンプライアンス インパク 頻度 関係するプロジェクト
p1 (~PopsEng::Priority::1) yes Any daily, weekly or monthly n/a| | p1 (~PopsEng::Priority::1)
p1 (~PopsEng::Priority::1) no OKR progression n/a n/a
p2 (~PopsEng::Priority::2) no Company daily, weekly comp calc, nom bot or assessment tool
p3 (~PopsEng::Priority::3) no Division, Department or Team daily, weekly nom bot or assessment tool| | p4 (~PopsEng::Priority::3) | n/a
p4 (~PopsEng::Priority::4) no Any daily, weekly n/a
p5 (~PopsEng::Priority::5) no Any monthly, yearly n/a |

私たちの Issue は、優先度に応じてラベル付けされます。表の外にあるものは優先度のラベルが貼られず、バックログに追加され、優先項目が完了した後に作業されます。 これは最初のイテレーションなので、ラベルのないものは、別のラベルをつけるべきだったかどうか、この表を作り直す必要があるかどうかを検討します。

カンバン方式

現在、私たちは毎月のマイルストーンから脱却し、カンバン方式で作業を進めています。ボードこちらからご覧いただけます。カラム Workflow::Next Up は次の作業を決定するものです。

People Engineering Team は、このカラムを 1 名あたりチケット 4 つ程度に保つようにしており、次の優先順位が明確になるようにしています。何がこの欄に移動されるかを決定するために、私たちは優先度ラベルを使用します。ただし、優先度ラベルには2つの例外があります。 - bug と表示されたチケット:既存のプロジェクトや統合が壊れていることが多く、早急に修正する必要があるチケットです。

  • code maintenance と表示されたチケット: ライブラリの更新やリファクタリングなど、コードが標準に準拠し、安全であることを確認するために計画する必要があるチケットです。

レビュープロセス

  1. マージリクエストを People Group のエンジニアリングチームの誰かに割り当てます。
  2. 彼らはそれをレビューします。レビューが完了したら、再びあなたに戻ってきます。
  3. マージリクエストがまだ承認されていない場合は、フィードバックに対処し、レビュー担当者に割り当て直します。
  4. マージリクエストが承認されるまで、前の2つのステップを続けます。
  5. マージ権を持っている場合は、マージ要求をマージします。マージ権を持っていない場合は、レビューアにマージを依頼します。

現在のプロジェクト

私たちは、People Group をサポートするために、いくつかの自動化やツールを構築しました。以下のページでは、これまでに作成したさまざまなプロジェクトや自動化の詳細を紹介しています。

雇用関連

業務支援ツール

未分類

データ

Single Source of Truth

すべての自動化のために、主に2つのソースを使用しています。

  • BambooHR : 従業員に関連するすべての情報の信頼できる唯一の情報源として機能します。Bamboozled という Ruby gem を fork し、従業員の詳細情報へのアクセスが制限されたbotユーザーを使って BambooHR と対話しています。

  • Greenhouse : 採用選考中の候補者に関するすべての情報を一元的に管理しています(採用前の情報も含む)。Greenhouse という Ruby gemを fork し、候補者の詳細にアクセスできるユーザーを使用してGreenhouseと対話しています。

特定の統合や自動化のために他のソースを使用している場合は、その旨をセクションに記載しています。

守秘義務

あるプロジェクトが一定のアクセスレベルのAPIトークンを使用している場合、公開プロジェクトを ops.gitlab.net のプライベートプロジェクトにミラーリングします。これらのプロジェクトは、スケジュールされたジョブを実行するためにのみ使用されます。計画、コーディング、共同作業にはすべて公開プロジェクトを使用します。

PeopleOpsチームのChatOpsへのアクセス

PeopleOps チームのメンバーがこのページに記載されているチャットコマンドを実行するには、employment-automation プロジェクトに招待されている必要があります。これはプロジェクトのオーナーが行うことができます。

プロジェクトのメンバーになると、任意の /pops コマンドを実行することができます。PeopleOps のbotはまず GitLab アカウントに接続するよう求めてきすので、提示されたURLをクリックして認証してください。これで /pops コマンドを実行できるようになります。

Greenhouse <> BambooHR sync

GitLab 従業員の Greenhouse と BambooHR の同期とそのプロファイルに関する情報です。

概要

従業員データの唯一の情報源が BambooHR であることを踏まえると、応募者が採用されたら BambooHR にその情報が同期されることが望ましいです。Greenhouse と BambooHR を同期させる仕組みを作ることで、手作業によるデータ入力を省くことができます。

候補者が採用されたとマークされると、conservatory app に webhook が送信されます。

同期されるフィールド

同期は一方通行です。Greenhouse からデータを取得し、BambooHR に追加します。BambooHRのいくつかのフィールドは Greenhouse からのデータを使って計算されています。

Greenhouseのデータ BambooHRのデータ
first_name (応募者データ) - プリファードネーム firstName
last_name (応募者データ) lastName
first_name の中の引用符で囲まれた部分(応募者データ) preferredName| | 。
last_name の中の引用符で囲まれた部分(応募者データ) customPreferredLastName
candidate_country (オファーデータ) country
state_of_team_member (オファーデータ) state
starts_at (オファーのデータ) hireDate
email_addresses.personal (応募者データ) homeEmail
department (オファーデータ) department
division (オファーデータ) division
employment_type (オファーデータ) customFullOrPartTime
id (Greenhouse 応募者) customCandidateID
candidate_country を通じて正しい値にマッピングされます customPayFrequency
candidate_country を通して正しい値にマッピングされます customRegion
hiring_manager からコピーされたものです customCostCenter
locality (オファーデータ) customLocality
specialty (オファーデータ) customJobTitleSpeciality
level_of_role (オファーデータ) customRole
このファイルを使用して、Greenhouse entity によってマッピングされています。 customEmployeeCorptoCorp
starts_at (オファーデータ) customHireDate
stock_options (オファーデータ) customShares1
stock_options (オファーデータ) customTotal
rsu_$_value (オファーデータ) customRSUValue
entity (公開買付けデータ) customInc/BV
"Hired" (ハードコードされた値 - Greenhouseのものではない) customNotes
starts_at (オファーデータ) date
job_title (オファーデータ, BambooHR 上にタイトルが存在する場合のみ同期可能) jobTitle
hiring_manager (オファーデータ) reportsTo
starts_at (オファーデータ) startDate
このファイルを使用して Greenhouse entity によってマッピングされています。 location
salary (オファーデータ) / pay_frequency rate
契約者の場合は Contract 、それ以外は Salary となります。 type
"Exempt" (ハードコードされた値 - Greenhouse にはありません) exempt
"Hire" (ハードコードされた値 - Greenhouse にはありません) reason
契約先や給与の支払い頻度によって値が異なります paidPer
candidate_country を通じて正しい値にマッピングされます。 paySchedule
ローカル通貨を使ってUSDレートにマッピングされます。 customCurrencyConversionFactor
通貨変換ファイルの最新更新日 customCurrencyConversionEffectiveDate
starts_at (オファーデータ) customEffectiveDate2
starts_at (オファーデータ) customEffectiveDate3
salary * customCurrencyConversionFactor customUSDAnnualSalary
salarycurrency を加えたもの customLocalAnnualSalary
starts_at (オファーデータ) customDate
[このファイル]を使用して Greenhouse offer entity によってマッピングされています。 customEmployeeType | customType
RSU, ISO, または International にハードコードされます。 customType1
Stock Options または Restricted Stock Units にハードコードされます。 customShareVehicle
(ハードコードされた値 - Greenhouse のものではありません) customReason
Yes customVariablePay
bonus_currency_&_amount_(amount_per_year_as_defined_by_previous_field) (オファーデータ) customAnnualAmountLocal
customAnnualAmountLocal * customCurrencyConversionFactor customAnnualAmountUSD
customAnnualAmountUSD * customUSDAnnualSalary customOTEUSD
customVariablePay * salary customOTELocal
job_code (オファーデータ - BambooHR 上にジョブコードが存在する場合のみ同期可能) customJobCode
job_grade (オファーデータ) customJobGrade
sales_geo_differential (オファーデータ) customSalesGeoDifferential
ghp_id (オファーデータ) customNumber
starts_at (オファーデータ) customBonusdate
signing_bonus_currency_&_amount (オファーデータ) customBonusAmount
"Signing Bonus" (ハードコードされた値 - Greenhouse のものではありません) customBonustype
"Paid Signing Bonus" (ハードコードされた値 - Greenhouseからのものではありません) customBonuscomments
family_relationship (オファーデータ) customRelationship
新しい雇用形態の行が追加され、値が Active に設定されます。 employmentStatus
starts_at (オファーデータ) customEffectiveDate6
candidate_country を通じて正しい値にマッピングされます customPayFrequency2| job_code (オファーデータ)
job_code (オファーデータ。BambooHR 上にジョブコードが存在する場合のみ同期可能。) customJobCode2
job_grade (オファーデータ) customJobGrade2

上記のフィールドを同期する以外にも、以下のような同期を行っています。

  • GreenhouseとBambooHRの間のドキュメントについて。Greenhouse と BambooHR の間で同期している書類は、attachments の中にあります。オファーレター(署名入り)と履歴書のみを同期します。署名済みのオファーレターは BambooHR の Contracts & Changes に、履歴書は BambooHR の Resumes and Applications に同期されます。これらは新しい従業員と共有されるように設定されています。

  • 雇用状況: 従業員にリンクされているエンティティによって異なります。ハンドブックに記載されているプロセスに従います。試用期間に変更があった場合は このファイルにも変更を加える必要があります。

  • BambooHR では、Greenhouse に登録されている countrystate を使って、国別の発生ポリシーを設定します。

必要なデータが不足している場合、この応募者についてslackメッセージを送信するようシステム側で設定しています。現在、このケースでは手動による同期が必要です。

進捗状況

現在、同期に関するプロジェクト全体としては2回のやり直しを経て、People Experience と Total Rewards チームの手作業のほとんど(すべてではありません)を置き換えました。 未解決の問題は こちらにあります。 同期に別フィールドを追加したい場合は、遠慮なくcreate a new issueしてください。

不明な従業員

採用情報が同期されていない場合、People Experience チームは以下を実行できます。 Slackのコマンドです。

/pops run syncnewhire <id_in_greenhouse>

これにより、上記のようにこの人物が同期されます。従業員IDは、Greenhouse の従業員のURLを見ればわかります。これは、/people/と?マークの間に記載されている11桁の数字です。チームが何が悪かったのかを調査するために、GitLab issue も作成することをお勧めします。

Career Mobility Automation Flow

People Operations と People Experience チームのキャリア・モビリティ関連のタスクをサポートするために導入している自動化に関する情報です。

はじめに

People Group のエンジニアリングチームは、手作業をできる限り減らすことを目指しています。私たちが行っていることの一つに、雇用の自動化に関連するフローがあります。

キャリア・モビリティ

注:このセクションでは、People Engineering が関与したオフボーディングの項目についてのみ説明します。GitLab での昇進や異動については、このハンドブックのページに詳しく書かれています。

タイムラインフロー

  1. PEA がキャリア・モビリティの Issue を作成するための Slack コマンドを実行する
  2. キャリア・モビリティの Issue が作成され、従業員が割り当てられる
  3. キャリア・モビリティの Issue が自動的に機密扱いになる
  4. 上司とインタビュートレーニングの Issue は、ピープルマネージャーの場合に開かれます。
  5. アクセスリクエストのリマインダーが Issue にコメントされる

キャリア・モビリティの Issue 作成

People Experience Associate がキャリア・モビリティの Issue に使用するSlackコマンドは以下の通りです。

/pops run careermobility <id_in_BambooHR_URL>

このSlackコマンドは、employment プロジェクトのパイプラインをトリガーし、transition というジョブを実行し、新しく作成されたキャリア・モビリティの Issue へのリンクを返信します。この Issue は、以下の人に自動的に割り当てられます。

  • コマンドを実行したPeople Experience Associate

  • 従業員

  • その従業員の前任上司

  • その従業員の新しい上司

  • 従業員の部署のピープルビジネスパートナー

この問題は、team member's epic に追加されます。

秘密にする

時にはbotではなく人間がIssueを作成することもあり、その場合、Issueを機密扱いにすることを忘れてしまうことがあります。私たちは、trainingプロジェクトでIssueを機密扱いにするためのパイプラインを毎日実行しています。これには上司や面接官のトレーニングの問題も含まれており、 employment プロジェクトはいずれにしても GitLab 従業員の内部で行われます。

上司と面接トレーニングの Issue

これはオンボーディングの際に作成する上司と面接トレーニングの Issue と同じです。ただし、オンボーディングの場合は7日目以降に作成し、キャリア・モビリティの場合はキャリア・モビリティの Issue と同時に作成しています。

こちらをご覧ください。

アクセスリクエストのリマインダー

5日間経過しても未解決のキャリア・モビリティの Issue を検索するジョブが 1 日に 1 回実行されます。キャリア・モビリティの Issue を作成した従業員に対して誰からもメンションが付いていない場合、その Issue に Note が作成され、アクセスリクエストの作成をリマインドします。

Bamboo Audit

私たちが毎週、毎月行っている BambooHR の自動監査についての情報です。

概要

BambooHR の SSoT データが常に正しく、コンプライアンスに準拠していることを確認するために、このデータの監査を行っています。People Engineering は、これを手動プロセスから自動プロセスに移行するための支援を行っています

Weekly New hires

毎週水曜日の午前10時(UTC)に、前週に入社した従業員全員の監査を行います。スプレッドシートGoogle Drive のフォルダに作成され、Total Rewards と VP People Operations, Technology & Analytics に共有されます。スプレッドシートには監査した従業員全員をリストアップし、チェックが必要な列をマークします。

毎月の全従業員

毎月1日の午前10時(UTC)に、GitLab で活動している従業員全員の監査を行います。スプレッドシートGoogle Drive のフォルダに作成され、Total Rewards と VP People Operations, Technology & Analytics に共有されます。スプレッドシートには、監査を行った従業員と、 needs to be checked のマークがついた従業員がすべてリストアップされます。

GitLab のユーザー名

従業員が tools and tips page で説明されている手順に従って GitLab のユーザー名を変更しないことがよくあります。これによりBambooHRのデータが不正確になったり、古くなったりします。

この状況を改善するために、毎週水曜日、BambooHR に保存されているすべての GitLab ユーザ名 (customGitLabUsername フィールド) を監査し、それらのユーザ名が gitlab-com グループ のメンバーであることを確認します。BambooHR の customGitLabUsername がグループに入っていない場合は、Slack の #peopleops-alerts にメッセージが自動的に送られます。

People Connect Bot

People Engineering チームが作成した Slack People Connect bot に関する情報です。

People Connect Bot

People Experience チームの Slack と GitLab Service Desk の接続には、Slackのカスタムアプリ People Connect Bot を使用しています。

このbotは技術的にはどのチャネルにも追加できますが、コード的には次のチャネルからのメッセージだけを読むように設定されています。

  • 公開チャネル #people-connect

  • botと一緒に始めた DM チャネル

誰かがこのチャネルや DM に新しいメッセージを追加するたびに、botはこれを受け取り、GitLab People Connectのプライベートプロジェクトに新しい Issue を作成します。このプロジェクトは、特定のメールでサービスデスクを利用するようにも設定されている。

その Issue に PEA が Note を追加すると、People Connect Bot に GitLab webhookが送信され、Slack スレッドに Note が投稿されます。従業員が返信すると、進行中の Issue に Note が追加されるといった具合です。

PEA が Issue をクローズした後、従業員がスレッドに返信した場合、Issue は再オープンされます。これにより、 Issueが失われることはありません。

BambooHRへの接続

BambooHR と People Connect bot の間には、読み取りの接続があります。GitLab 上で新しい Issue が作成されると(Slackやメールがトリガーとなって)、従業員に関連するラベルが追加されます。 - department

  • division

  • 在籍期間

  • 地域

例えば、People Success 配属されて 1 週間目の人が、botに何かを尋ねるメッセージを書いた場合、以下のようなラベルが追加されます。

  • Department::People Success

  • Division::People Group

  • Tenure:: < 6 months

  • Region::JAPAC

これは、BambooHR のこれらのフィールドへの読み取りアクセス権があることを意味します。

調査

People Connect チームが Issue に Status::Resolved というラベルを付けると、リクエストを出した従業員にアンケートが送られます。アンケートへの回答はラベルに変換され、Issue に追加されます。例えば、Survey::Satisfaction::Neutral は、誰かが「インタラクションにどれだけ満足したか、中立的に感じた」と答えた場合に追加されます。

現在、この機能は Slack のメッセージや DM で開始された Issue にしか使えません。2021-07-07 までに、メールで開始された Issue でもこの機能を有効にすることを目指しています。また、すでに解決済みとされている Issue については、過去にさかのぼってアンケートを実施します。

要望・バグ

botに関する問題やプロセスに関するフィードバックは、ここで作成できます。

Offboarding Automations

People Operations チームと People Experience チームのオフボーディング関連のタスクをサポートするために導入している自動化に関する情報です。

はじめに

People Group のエンジニアリングチームは、手作業をできるだけ減らすことを目指しています。その一環として、雇用タスク自動化に関連する作業を行っています。

オフボーディング

注:このセクションでは、People Engineeringが関与したオフボーディングの項目についてのみ説明します。GitLabでのオフボーディングについては、このハンドブックのページに詳しく書かれています。

Timeline Flow

チャート

自動化

Voluntary offboarding email

従業員が自発的に GitLab を退職する際に、オフボーディングインタビューやよくある質問を説明したメールが自動的に送信されます。

パイプラインは1時間ごとに実行され、オフボーディング用のスプレッドシートをスキャンして、前回の実行以降に新しい行があるかどうかを調べるようになっています。各行ごとに、従業員の国に応じて異なるテンプレートを使用して、離職する従業員にメールが送信されます。

オフボーディングの Issue 作成のスケジューリング

15分ごとにパイプラインが離職者用スプレッドシートをスキャンし、過去15分以内に Garden Leave (Non-US) Start Date/Last Working Day (US only) Start Date が発生した行を探します。どちらも指定されていない場合は、予備としてTermination Effective Dateが使用されます。この基準に一致する各行に対して、People Experience Associateが/pops run offboarding <id_in_BambooHR_URL>を実行した場合と同じアクションが実行されます(手動で開始したオフボーディングの Issue 作成オフボーディングのマージリクエストのセクションを参照)。

手動プロセスは、自動化に失敗した場合のバックアッププロセスとして残されています。また、オフボーディングする従業員をオフボーディングスプレッドシートに追加できない例外的なケースにも対応しています。

手動でのオフボーディング Issue 作成

People Experience Associate がオフボーディングの Issue に使用する Slack コマンドは以下の通りです。

/pops run offboarding <id_in_BambooHR_URL>

オフボーディングの Issue は、コマンドを実行した People Experience Associate に自動的に割り当てられます。 コマンドを実行した人と、退職する従業員の上司に自動的に割り当てられます。

このジョブでは、退職する従業員の様々な詳細情報を取得します。例えば、居住国、雇用された企業、部門、部署、役職などです。これらの詳細のそれぞれについて、employment プロジェクトのoffboarding_tasks フォルダにタスクファイルが存在するかどうかをチェックします。これらのタスクファイルは country_<country name>.md, entity_<entity name>.md, division_<division name>.md, department_<department name>.md などのフォーマットで構成されています。そのようなファイルが見つかった場合は、それらのファイルの内容もオフボード問題に含まれます。

この Issue は、team member's epic に追加されます。

オフボーディングのマージリクエス

また、offboarding コマンドは、www-gitlab-com プロジェクトへのマージリクエストを作成します。このMR には以下が含まれます。 - data/team_members/person ディレクトリから個別ファイルを削除すること

  • 前項のファイルで使われていた画像を削除する

  • オフボードになった従業員がレポートを持っていた場合、reports_to を調整する

  • その従業員がペットの写真を持っていた場合は、その写真を削除します。

  • CODEOWNERS ファイルの更新:上司に変更、または上司がそのファイルのコードオーナーになっている場合は削除。

Guardianからの削除

従業員が GitLab を退職する際には、Guardian からも terminated してもらう必要があります。私たちは退職した従業員を毎日チェックしています。前日に新たなオフボーディングの Issue が発生していないかどうかを毎日チェックします。その際、その従業員がアメリカにいるかどうかをチェックします。一致するものがあれば、04_employee_termination_mmddyyhhmmss.csv という名前のファイルを作成し、そのファイルにユーザーの従業員IDと退職日を追加します。これを Guardian にアップロードして、Guardian が処理できるようにします。

従業員がどのようにGuardianに追加されるかについては、こちらを参照してください。

リダイレクトルールのリマインダー

従業員が退職すると、退職者のために Google Workspace にリダイレクトルールが設定されます。5 日後にこのリダイレクトルールを削除する必要があります。People Experience Associates がルールを削除することを忘れないように、botが GitLab issue comment を残してリマインドをするスケジュールされたパイプラインが設定されています。

現在、パイプラインは毎日午前4時00分(UTC)に実行されるようになっています。現在の日付から 5 日前に作成されたすべてのオフボーディング Issue についてコメントします。

Onboarding Automation Flow

People Operations チームと People Experience チームのオンボーディング関連のタスクをサポートするために導入している自動化に関する情報です。

はじめに

People Group のエンジニアリングチームは、手作業をできるだけ減らすことを目指しています。その一環として、雇用の自動化に関連する作業を行っています。 このページに記載されている内容は、従業員がすでに BambooHR を利用していることを前提としています。BambooHR への同期方法については、このハンドブックのセクションをお読みください。

オンボーディング

注意: このセクションでは、People Engineering が関与したオンボーディングの項目についてのみ説明します。GitLab でのオンボーディングについては、このハンドブックのページに詳しく書かれています。

タイムラインフロー

チャート を参照してください。

Sync to Guardian

I-9 フォームは、米国での雇用のために雇われた個人の身元と雇用許可を確認するためのものです。すべての米国の雇用者は、米国での雇用のために雇った各個人について、I-9 フォームを適切に記入しなければなりません。GitLabでは、このプロセスを支援するために Guardian を使用しています。

このツールを手動管理する手間を省くために、BambooHR と Guardian の間にはカスタム同期設定がされています。この同期設定は、CSV ファイルをアップロードすることで実行されます。このプロセスでアップロードされるファイルは4種類あり、そのうち2つは完全に自動化されており、残りの 2 つは People Experience Associate によるトリガーが必要です。

注意:この同期設定は、BambooHR で国名が "United States" になっている従業員のみを対象としています。その他の従業員はこの同期設定では無視されます。

新入社員

このカスタム同期は新規採用者を Guardian に同期します。毎日 7 日以内に入社日を迎える従業員をチェックします。入社予定者がいる場合は 01_employee_add_mmddyyhhmmss.csv という名前のファイルを作成します。対象となる従業員全員について、以下の情報がファイルに書き込まれますされます。

  • hire date: GitLabで働き始める日

  • employee id: BambooHR で割り当てられた固有の従業員 ID (BambooHR のユーザ ID とは異なります)

  • legal entity: GitLab Inc または GitLab Federal LLC のいずれか。これは BambooHR の location フィールドに何が記入されているかによります。

  • first and last name

  • personal email address

なお、従業員が入社直前に採用決定された場合(ここでは、入社日まで7日を切っている場合と定義します)、その従業員はこのカスタム同期ではピックアップされません。しかし、People Experience Associate が Slack で以下のコマンドを実行すると、Guardian に新しい従業員のファイルが作成されます。

/pops run uploadtoi9 <ID_IN_BambooHR_URL>

採用者の更新

Guardian への更新を同期します。入社日や法人格、従業員の名前などに変更があった場合、Guardian にも反映させる必要があります。これは、People Experience Associate が以下の Slack コマンドを実行して起動する必要があります。

/pops run reuploadtoi9 <ID_IN_BambooHR_URL>

これにより、BambooHR で従業員をフェッチするパイプラインが起動します。以下のような命名規則のファイルが作成されます: 02_employee_update_mmddyyhhmmss.csv

このファイルには新入社員と同じフィールドが追加されます。このファイルは Guardian にアップロードされ、Guardian によって処理されます。

従業員の再雇用

再雇用者を Guardian に同期させます。再雇用とは、Guardian に以前の I-9 記録があり、解雇された従業員が再雇用されることと定義します。これは、People Experience Associate が以下の Slack コマンドを実行してトリガーする必要があります。

/pops run rehirei9 <ID_IN_BambooHR_URL>

これにより、BambooHR で従業員を取得するパイプラインが起動します。以下のような命名規則のファイルが作成されます: 03_employee_rehire_mmddyyhhmmss.csv

このファイルには、新入社員と同じフィールドが追加されますが、列 rehire が追加され、値が yes に設定されます。このファイルは Guardian にアップロードされ、Guardian によって処理されます。

I-9 が Guardian に記録されていない場合は、上記の New Hire Pops コマンドを実行する必要があります。

オンボーディング Issue の作成

オンボーディング Issue の作成は半自動プロセスです。つまり開始するためには People Experience Associate によってトリガーされる必要があるということです。このトリガーには Slack のコマンドを使用します。

/pops run onboarding <id_in_BambooHR_URL>

入社時の Issue はコマンドを実行した People Experience Associate と、入社予定者の上司に自動的に割り当てられます。

すべての入社予定者に適用されるオンボーディングのタスクは、一般的な onboarding.md ファイルに記載されています。これはオンボーディングの Issue にデフォルトで含まれます。

このジョブは、採用される従業員の様々な詳細情報を取得します。住んでいる国、雇用された企業、部門、部署、役職などです。プロジェクトの onboarding_tasks フォルダにあるタスクファイルの存在を確認します。これらのタスクファイルは次のようなフォーマットになっています。country_<country name>.md, entity_<entity name>.md, division_<division name>.md, department_<department name>.md, role_<exact job title>.md などです。そのようなファイルが見つかった場合、ファイルの内容もオンボーディング Issue に含まれます。

役割のテンプレートは年功序列を考慮しません。例えば、SDR 1、2、3はすべて SDR テンプレートを受け取ります。

オンボーディング Issue でテンプレートがリンクされていないという質問を上司から受けた場合、テンプレートの命名規則を確認し、BambooHR のエンティティ、部門、部署などとすべてが一致していることを確認してください。すべてが一致しているように見える場合は、People Group Engineer に連絡して追加のサポートを受けてください。

注:People Experience Associate がインターンのオンボーディング Issue を作成する必要がある場合は、同じ Slack コマンドを使用できます。

この Issue は、team member's epic に追加されます。

雇用問題がどのように設定されているかについて詳しく読みたい場合は、このセクションをお読みください。

入社アナウンス

翌週に GitLab に入社するすべての新しい従業員のリストを含むメッセージを自動的に送信するように、スケジュールされたパイプラインを設定します。これには氏名、メールアドレス、入社日、役職、採用プロセスの詳細な内訳と概要を時系列で示した Sisense chart へのリンクも含まれています。

このメッセージを作成している間に、「データがない」という入社予定者がいないかどうかを確認します。漏れている入社予定者がいる場合は、メッセージが #peopleops-alerts に送信されます。そのメッセージを見かけたら People Experience Associate はデータを確認し、次のコマンドを実行してパイプラインを再実行します。

/pops run joiningannouncement

不足しているデータがない場合は、メッセージが直接 #team-member-updates に投稿されます。

現在、このパイプラインは毎週木曜日の午前8時00分(UTC)に実行されるようになっています。

GitLab.com への招待

私たちは毎日スケジュールされたパイプラインを実行しており、翌日からの従業員を二つの主要な GitLab グループに招待しています。

  • gitlab-com

  • gitlab-org

招待メールは、翌日にアクセスできるようになる GitLab のメールアドレスに送られます。

セルフサービスの有効化

私たちの部署のメンバーは、従業員が GitLab に入社した初日に入社者の BambooHR 上のプロファイルを更新することになっています。これを行うためには、BambooHR で self-service のアクセスレベルを有効にする必要があります。私たちは毎日スケジュールされたパイプラインを実行し、次の日から従業員のためにこれを有効にします。

オンボーディング メール

これは、入社初日の朝に入社者に送信される email です (Issue のタイトルにあるオンボーディングの日付に基づいています)。このメールの CC には people-exp@domain も追加されます。

毎日、スケジュールされた3つのパイプラインを実行します。それぞれ特定の地域向けに設定されています。

  • Americas at 10 AM UTC

  • EMEA at 4 AM UTC

  • JAPAC at 6 PM UTC

JAPACのパイプラインの場合は、翌日入社予定の人を取得します。EMEA と America のパイプラインでは、開始日が現在の日と同じである従業員をすべて取得します(つまり、誰が今日開始するのか)。その後、パイプラインはメールを送信する必要のある地域の入社予定者をフィルタリングします。これは、メールの送信が遅すぎたり早すぎたりしないようにするためです。入社予定者の地域は BambooHR のプロフィールで設定されている地域から決定されます。この仕組みはまだ初期段階で、もし国別に分ける必要が出てきた場合は再実装します。

私たちは地域以外にもいくつかのデータを取得しています。

  • 入社予定者のオンボーディング Issue のURL

  • 入社予定者の氏名

上記のデータは入社予定者に送信するメールの内容に使用されます。メール送信に使われるメールアドレスは onboarding@domain で、reply-to: people-exp@domain と設定されていますが、これは onboarding@ への返信を誰も監視していないためです。このメールアドレスは自動化のために厳重に使用されます。

Swag Email

これは従業員の入社日に送信される email で、Swag Store(自社ブランドショップ)で割引を受けるためのコードを受け取ることができます。このメールは、 people-exp@domain に cc されます。

毎日午前9時(UTC)に、スケジュールされたパイプラインを実行します。このパイプラインは、対象となるすべての従業員を取得します。対象となる従業員は:

  • GitLab に入社して初日を迎えた従業員

メールの送信に使用されているメールアドレスは onboarding@domain で、 onboarding@domain への返信は誰も監視していないため、 reply-to: people-exp@domain が設定されています。このメールアドレスは自動化のために厳密に使用されます。

アクセスリクエスト Issue 作成

従業員が業務に必要なツールにアクセスするためには、アクセスリクエスト(AR)の Issue を作成する必要があります。従業員が良いオンボーディングを経験できるように、AR Role based entitlement issue をbotで作成することで、このプロセスを自動化しました。

毎日、3つのパイプラインを実行しています。それぞれのパイプラインは、特定の地域向けに設定されています。

  • Americas at 10 AM UTC

  • EMEA at 4 AM UTC

  • JAPAC at 6 PM UTC

JAPACパイプラインでは、入社日が今日の新入社員を取得します。EMEA と America のパイプラインでは、入社日が前日である新入社員をすべて取得します。その後パイプラインはメールを送信する必要のある地域のメンバーをフィルタリングします。これはIssueの作成が遅すぎたり早すぎたりしないようにするためです。新入社員の地域は BambooHR のプロフィールに設定されている地域から決定されます。

これらのメンバーに対して、アクセスリクエストの Issue を作成できるかどうかがチェックされます。この機能は role baseline access requests tasks directory にテンプレートが設定されているロールを持つメンバーに対してのみ動作します。

テンプレートはロールレベルで作成されますが、スペシャリティレベルでも作成することができます。例えば、 Security Engineer, Strategic Security というロールを持つ人がいるとします。コードは2つのテンプレートを探します。 role_security_engineer.mdrole_security_engineer_strategic_security.md です。

注:両方とも作成する必要はありませんが、2つあればコードは両方を使って Issue を作成し、1つだけであれば見つけた方を作成します。

Issue は AR project に作成されます。

botは、ARを作成できた人のリストをSlack(#peopleops-alerts)で発表します。また、ARを作成できなかった人のリスト(役割付き)も発表されます。こうすることで、各チームがこのロールのテンプレートを追加できるようになります。

Issue を作成できない場合は、採用botがオンボーディング Issue にコメントを残します。このコメントには上司がタグ付けされて通知され、Issue を作成し必要に応じて今後の採用活動のためのテンプレートを作成するよう依頼されます。

注:People Operationsはテンプレートの作成や管理を担当していません。各チームがそれぞれの役割に応じたテンプレートを作成する責任があります。このことはプロジェクトの README でも説明されています。

People GroupのエンジニアがARオートメーションについて説明しているビデオを紹介します。このビデオは自動化の仕組みやテンプレートの追加方法などを説明しています。

チームページの準備状況の確認

毎日午前 9 時(UTC)に、前日の入社者をすべて取得して、チームページに同期できるかどうかをチェックするパイプラインを実行しています。現在のところ、同期できるかどうかを判断するために必要な項目は、GitLab のユーザー名だけとなっています。

もし GitLab のユーザー名が(Issue や BambooHR のプロフィールから)わからない場合は、オンボーディング Issueに Note を残し、BambooHR のプロフィールを正しく記入してもらうようにします。

チームページへの同期

毎日午前 9 時 (UTC) に、新しい従業員を www-gitlab-com プロジェクトに同期させるパイプラインを実行し、チームページに表示されるようにします。

入社日が2日前のすべての新入社員を取得し、彼らがチームページへの同期をオプトインしたかどうかを確認します。オプトインは BambooHR のプロフィールで Export Name/Location to Team Page?Yes に設定することで行われます。これは新入社員が初日に行う作業です。

彼らが Yes を選択した場合は、私達はいくつかのデータ(氏名、役職、入社日、部署、国)を取得し、チームページのエントリーに追加できるようにフォーマットします。オプトインしなかった場合は、チームページにエントリーを追加します。ただし、そのエントリーは匿名化されます。新しい従業員が増えるごとに、data/team_members ディレクトリに新しいファイルをコミットします。

次に私達は www-gitlab-com プロジェクトにマージリクエストを作成して、マージできるようにします。

このマージリクエストは、People Experience Team に割り当てられ、パイプラインが成功したらマージするように設定されます。

新入社員が必要なデータを入力していない場合は、同期することができません。後日、People Experience Associate が以下のSlackコマンドで同期することができます。

/pops run teampageindividual <bamboo_id>

これによりパイプラインが起動し詳細が取得されます。なお、その従業員がすでに同期されている場合は同期を中止します。

Modern Health への同期

Modern Health では、アクティブな従業員全員の情報を毎週更新しています。このプロセスは AWSUpload to AWS S3 機能を使って自動化されています。毎週金曜日の午後1時(UTC)にスケジュールされたジョブを実行します。このジョブは BambooHR からすべてのアクティブな従業員を取得し、以下の内容を CSV ファイルに保存します。

  • First name

  • Last name

  • Work email

  • Employee ID

  • Department

  • Start Date

この CSV ファイルは、Modern Health が管理している S3 バケットにアップロードされます。新入社員が Modern Health にアクセスできるようにファイルを処理してもらいます。

ハラスメント防止研修のSlackリマインダー

私たちは 6 日前に入社した社員を毎日チェックするパイプラインを持っており、彼らにハラスメント防止研修の受講を促すリマインダーを送っています。

上司と面接トレーニングの問題

毎日スケジュールされたパイプラインが実行され、1週間前に入社した社員の中にピープルマネージャーがいないかどうかをチェックしています。現在、BambooHR にはこのチェックを行うためのフィールドがありません。役職名が以下の文字列で始まっている従業員はピープルマネージャーです。

  • Team Lead

  • Manager

  • Senior Manager

  • Director

  • Senior Director

  • Chief

  • VP

  • Vice President

また、役職名の末尾が以下である場合も、その人はピープルマネージャーであると考えます。

  • Area Sales Manager (エリアセールス上司)

Interview TrainingBecoming a Manager という Issue を People Group Training project で作成しています。

オンボーディングのコンプライアンスチェック

GitLab に入社して 15 日目のメンバーを、毎日スケジュールされたパイプラインで取得します。彼らのオンボーディング Issue で、何かしらコンプライアンスのタスクが開かれているかどうかを調べます。

コンプライアンスのタスクには :red-circle のアイコンがついています。未解決のタスクがある場合、オンボーディング bot はユーザーに未解決のタスクを終わらせるようにタグ付けします。

オンボーディング Issue の終了

オープンから 30 日以内にオンボーディング Issue を解決することが期待されています。このことを新入社員へリマインドするために、GitLab Issues の due date 機能を使っています。オンボーディング Issue が作成されると入社日に 31 日間を加えて期限を自動的に計算します。GitLab は期限が近づいたときに、その Issue をアサインされた全員にリマインドメールを送信します。

この期限に加えて、オンボーディング Issue を完了してクローズするためにさらに30日間の猶予が与えられます。合計すると、新入社員はオンボーディング Issue を完了するのに約 60 日間の猶予があるということになります。

私達は期限切れの Issue(60日以上未完了のままの Issue)をクローズさせるためのパイプラインを開発する予定です。このパイプラインでは、未解決の Issue が自動的にクローズされるという事と、オンボーディングのタスクが残っている場合に新入社員がすべきことを Issue にコメントします。

現在このパイプラインは毎週金曜日の午後9時30分に実行されるようになっています。このパイプラインはその日から60日以前に作成されたすべてのオンボーディングの Issue をクローズさせます。

メールでの価値観チェック

これは、入社 90 日後に従業員に送られる email についてです。

毎日午前10時(UTC)にスケジュールされたパイプラインを実行します。このパイプラインは、バリューズチェックインを受け取る資格のある従業員をすべて取得します。 対象となる従業員には、2通のメールを送信します。

  • 1つは従業員に

  • 1つは従業員の上司に送信:上司は BambooHR 上の従業員の上司によって決定されます。

メールの送信に使用されるメールアドレスは peoplespecialists@domain で、reply-to: peopleops@domain が設定されていますが、これは peoplespecialists@domain への返信を誰も監視していないためです。このメールアドレスは自動化のために厳密に使用されます。

試用期間終了メール

これは email についてです。 従業員の試用期間が終了する際に送信されます。このメールは従業員の上司に送られ、CCは people-exp@domain になります。

毎日午前9時(UTC)に、スケジュールされたパイプラインを実行します。このパイプラインは対象となるすべての従業員を取得します。対象となる従業員とは:

  • BambooHR のプロフィールに記載されている国が、法的に試用期間のある国である

  • 試用期間が 14日 以内に終了する

メールの送信に使用されているメールアドレスは. onboarding@domain で、onboarding@domain への返信は誰も監視していないため、reply-to: people-exp@domain が設定されています。このメールアドレスは自動化のために厳密に使用されます。

オランダの雇用契約終了メール

これは従業員の契約終了の2ヶ月前に、従業員の上司に送られる email についてです。このメールは peopleops@domain と関連するピープルビジネスパートナーもccに追加されます。

毎日午前9時(UTC)に、スケジュールされたパイプラインを実行します。このパイプラインは、対象となるすべての従業員を取得します。対象となる従業員は以下の通りです。

  • オランダに住んでいる従業員

  • temporary contract が2ヶ月後に終了する従業員です。

メールの送信に使用されるメールアドレスは peoplespecialists@domain で、reply-to: peopleops@domain が設定されています。このメールアドレスは自動化のために厳密に使用されます。

People Engineering Howtos

People Group のタスクに関連する GitLab のメール自動化プロセスに関する情報

概要

People Operations チームでは様々な理由でいくつかのメールを送信しています。可能な限りこれらを自動化するようにしています。

オンボーディングのメールテンプレートの更新

オンボーディングメールのテンプレートに変更が必要な場合は、以下の手順で進めてください。

  • MJML のページにアクセスします。

  • MJML オンボーディングテンプレートと、html バージョンを開く。

  • テンプレートをコピーして、左のMJMLサイトに貼り付ける。

  • 関連する変更を行い、ウェブサイトの左上にある View HTML を選択します。

  • HTML バージョンを HTML テンプレートにコピーします。

  • ブラウザから MJML 版を MJML テンプレートにコピー&ペーストします。

  • 通常通りアップデートした状態で Merge Request を送信します。

雇用に関する Issue

当社のオンボーディング、オフボーディング、キャリア・モビリティー Issue を作成するために使用されるコマンドに関する情報

雇用に関する Issue

People Experience Associates は GitLab の ChatOps を利用してオンボーディング、オフボーディング、キャリアモビリティの Issue 作成を自動化しています。Slack コマンドを実行すると employment-automation プロジェクト内のパイプラインが起動し、関連するジョブが実行され、新しく作成された Issue へのリンクが返信されます。

これらの雇用に関する Issue が作成されると、その従業員の Epic にも追加されます。既存の Epic がまだない場合は Team Member Project に Epic を作成します。この Epic には従業員の名前がタイトルとして含まれており、これが Epic の検索方法にもなっています。

Issue の作成に使用されるテンプレートと Issue 自体は2つの異なるプロジェクトにあります。テンプレートは people-group にあり、Issue はTeam Member Epicsにあります。テンプレートは公開されていますが、Issue は非公開です。テンプレートの更新は Employment Templates プロジェクトで行います。

オンボーディング Issue

このセクションを参照してください。

オフボーディング Issue

このセクションを参照してください。

キャリア・モビリティ Issue

このセクションを参照してください。

Epic

従業員すべての雇用に関する Issueを 1 つの Epic に追加します。整理するために Epic を閉じるための自動化を設定します。

リンクされている未解決の Issue がない Epic を閉じるためのスケジュールされたパイプラインがあります。このパイプラインでは自動的にクローズされるというコメントが Epic に追加されます。

現在このパイプラインは毎週水曜日の午前11時00分(UTC)に実行されています。

クローズされた Epic に新しい Issue が追加された場合、私達がその Epic を再度オープン状態にすることに注意してください。

People Group Engineering

People Operations が持っているアクセス制限のある内部ハンドブックに関する情報です。

概要

このプロジェクトは(アクセス上の理由から)gitlab-com グループの外でホストされており、 here で入手できます。ただし、アクセスするには招待される必要があります。

プロジェクトにアクセスできるようになると、People Operations internal ハンドブックにアクセスできるようになります。

使い方

社内限定や公開ハンドブックでは公開できないものにのみ使用します。非常に限られた量の情報しか載せてはいけません。

アクセス方法

アクセスリクエストを作成し、Director, People Operations に割り当てます。Director があなたをプロジェクトのメンバーとして追加します。プロジェクトにアクセスできるようになると、ホストされているページにもアクセスできるようになります。

Miscellaneous

チームページへの同期、ジョブファミリーなどに関連する自動化の情報です。

チームページ入力 専門分野

1 日に 1 回、エンジニアリング部門とプロダクト部門の従業員の専門分野を同期するパイプラインを実行しています。つまり、従業員がファイル内のそのフィールドを編集すると、同期が再度実行されたときに上書きされてしまうということです。この理由は、BambooHR をこのデータの唯一の真実の情報源とみなしているからです。そのため、従業員や上司はまず BambooHR で修正を行う必要があり、それがチームページのエントリーに自動的に反映されます。

専門分野に何を記入するかを決定するために、まず、複数選択の専門分野フィールドを見ます。このフィールドに何も表示されない場合は、シングルセレクトの専門分野を調べます。

Parental leave PTO to BambooHR

2020-12-18 から、PTO by Roots で前日に新たな育児休暇の PTO が申請されていないかどうかを毎日チェックします。その日に作成された PTO イベントがあれば、その従業員の BambooHR プロファイルに3つの雇用ステータスを追加します。 - Parental Leave: PTO イベントの開始日が含まれています。

  • End of Parental Leave: PTO イベントが終了した日が入ります。

  • Active: PTO イベントの終了日 + 1

機密データ準拠の PTO by Roots export

毎週、スケジュールされたジョブが ± 4 週間の期間に発生したすべての PTO イベントを照会します。そしてこれらの PTO イベントから機密情報(例えば取得した PTO の種類)がフィルタリングされます。除去されたデータは Google Cloud Storage のバケットにアップロードされ、データ分析チームが利用できるようになります。

データ分析チームは、この情報のサブセットを Sisense 経由で公開し、「30日間の従業員あたりのマージリクエスト数」などの指標について、より正確なグラフを作成できるようにします。

オランダの発生調整

1月1日にスケジュールされたジョブが実行され、オランダにいる各従業員の Employee Accruals の残高がマイナスであれば、それが0日に戻されます。

同様のスケジュールされたジョブが7月1日に実行されますが、この場合、オランダにいる各従業員の Employee Accruals の残高が10日を超えると、10日に戻されます。

クローズされたトレーニング Issue を機密扱いにする

1 日 1 回、トレーニングプロジェクトのクローズドな Issue が、コンプライアンスのために自動的に機密扱いにされます。

雇用通知書

1 時間ごとに、スケジュールされたジョブが、雇用通知書のスプレッドシートに新しいエントリがないかをチェックします。各エントリーに対して、従業員の BambooHR データを使って雇用証明書が作成されます。この書類は、従業員の仕事用の電子メールアドレスに直接送信されます。

CXC 契約更新メール

毎日、スケジューリングされたジョブが2週間後に CXC 契約の期限が切れる従業員を探します。その従業員には、契約更新の手続きを促すメールが送信されます。GitLab CXCの連絡先(環境変数 CXC_CONTACT_EMAIL に記載されているメール)も、更新プロセスを開始するためのリマインダーとしてこのメールにコピーされます。

Entities sync

週に一度、BambooHR のロケーションが GitLab のグループに同期されます。従業員は正しいグループに追加されます。グループ(エンティティ)のリストは、エンティティプロジェクトで確認できます。

ある GitLab エンティティの全メンバーに影響を与えるマージリクエストや Issue を作成するときには、直接メンバーになっている全メンバーに @gitlab-com/entities/<entity-name> を使って ping することができます。

例えば、カナダ法人の場合は、@gitlab-com/entities/canada-corp とします。

On-call scheduling spreadsheet

毎月最初の日に、GitLab に3ヶ月以上在籍している従業員の情報を含むスプレッドシートを作成します。このスプレッドシートはエンジニアがオンコール対応の計画を立てるのに使われます。

同期されるフィールドは BambooHR とチームファイルから取得されます。

  • Name

  • Job title

  • Division

  • Department

  • Subdepartment

  • Role

  • City

  • Country

  • State/province

  • Weekend availability

Slack Integrations

People Engineering チームが作成した Slack の自動化に関する情報です。

インテグレーション

いくつかの小さな自動化のために、Slack との統合を使用しています。私たちがセットアップしたすべての統合の概要を見ることができます。これらの統合では、 PeopleOps Bot という名前のSlack bot を使用しています。

記念日のアナウンス

その週に記念日を迎えた従業員全員にお祝いのメッセージを Slack のチャンネル #team-member-updates に自動的に送信するように、パイプラインを設定します。メッセージにはその週に記念日を迎えたチームメンバー全員のリストと、彼らが GitLab で迎えた年数が含まれます。

現在、このパイプラインは毎週木曜日の午前10時(UTC)に実行されることになっています。

誕生日アナウンス

毎週月曜日の朝、その週に誕生日を迎える従業員を祝福するメッセージを、Slack のチャンネル #celebrations に自動的に送信するように、スケジュールされたパイプラインを設定します。Slack のプロフィールで GitLab の誕生日をオプトインしている従業員だけが、お祝いのメッセージに表示されます。

オプトインするには、Slackで以下の手順を実行してください。

  1. 右上の自分のプロフィール写真をクリックする
  2. Edit profile をクリックします。
  3. GitLab Birthdays の欄までスクロールダウンして、Yesを選択する。

育児休暇 おかえりなさい

毎日スケジュールされたパイプラインが実行され、3日後に育児休暇から戻ってくる人をチェックします。 必要に応じて PTO を取得できることをリマインドするダイレクトメッセージを送ります。 また、育児休暇からの復帰に関するハンドブックへのリンクを送ります。

このパイプラインは、PTO by Rootsと直接統合されています。

入社予定の新入社員に対して、BambooHR に欠けている情報を People Experience Associates に知らせる。

新入社員の発表を正確に行うためには、翌週に入社する人達の BambooHR 詳細情報が可能な限り揃っていることが必要です。PeopleOps チームを支援するためにスケジュールされたパイプラインを実行し、すべての新入社員の BambooHR の詳細が完了しているかどうかを確認します。このパイプラインは People Experience Associates の #people-connect-alerts チャネルに詳細情報が不足している人と、各人について不足している詳細情報を通知します。

People Experience Associates は新入社員のアナウンスが送信される前に、これらの欠落した詳細を修正するための十分な時間が必要であるため、このジョブは毎週水曜日の午後 2 時に実行されるように設定されています。

オフボーディングシート

オフボーディングが必要な従業員を記録する Google シートがあります。統合機能は今日または明日にオフボードする必要がある人がいるかどうかを毎日チェックします。オフボーディング対象者が出てくると、その旨のメッセージと Google シートへのリンクが投稿されます。このメッセージは Slack のプライベートチャンネル people_exp_ops に投稿され、個人情報は含まれません。

従業員サーベイ

従業員が以下のアンケートに回答するたびに、フォームへの入口が Slack のプライベートチャンネル employment-survey に Slack メッセージとして送信されます。このようにしてPeople Experience チームは議論し、行動を起こすことができるのです。 - オンボーディング調査

  • バリューチェックイン

  • キャリア・モビリティ・バリュー・チェックイン

  • キャリア・モビリティ 満足度調査

リファラル採用ボーナスのリマインダー

その週に勤続 3 ヶ月の記念日を迎えた従業員全員のリストを、 Slack チャンネルの #people-connect-alerts に自動的に送信するよう、スケジュールされたパイプラインが設定されています。そのリストは各記念日ごとに BambooHR と Greenhouse のプロファイルがリンクされており、People Experience Team はそれを見てリファラル入社者がいるかどうかを確認できるようになっています。People Experience Team が紹介者にボーナスを支給します。

このパイプラインは、毎週金曜日の午前10時(UTC)に実行されるよう設定されています。

Nominator bot

People Engineering チームが作成した Slack Nominator bot に関する情報です。

ノミネーター

私達は Slack のカスタムアプリ、Nominatorbotを使っています。これは従業員が他の従業員に対して discretionary bonuses の推薦に使うものです。

誰かを推薦するには、/nominate と入力してください。ダイアログが開くので追加情報を入力します。記入した後、ダイアログを送信します。このデータはデータベースに保存され、Slack を通じてノミネート者の上司に送られます。

その後、上司はこのノミネーションを承認するか否かを決定することができます。

承認されると、bot はこのノミネーションを 2 階層上の上司と People Group に送信します。それぞれが承認する必要があります。最終的に承認されると、BambooHR のボーナステーブルに追加されます。推薦者と推薦された人の上司も最終承認について更新されます。上司には推薦内容が記載されたメッセージが届き、これを推薦者と共有し、Slack の #team-members-update チャネルで共有することが求められます。

ノミネーションが拒否されると、拒否理由を尋ねるポップアップが出ます。これは理由を知るための集計にのみ使用されます。この情報はホームビューには表示されません。ノミネーターは却下されたことが分かりますが、理由までは分からないようにしています。bot は却下した人に対してメッセージを送り、ノミネーターにフィードバックを共有するよう求めます。

Features

ノミネーションのの更新

2021-03-05 以降、すべての承認者は推薦を update することができるようになりました。推薦文は有効ですが、十分な情報が含まれていない場合があります。更新ボタンをクリックすると承認者は推薦メッセージを編集することができます。更新されると、承認(または拒否)され、更新されたメッセージが次の承認者に送られます。

承認者の再トリガー

時には承認者がいないために承認がスタックしまうことがあります。ノミネーターは、Nominatorbot のホームセクションを使って、bot を使って正しい承認者へ新しいメッセージを送ることができます。再トリガーを許可するのは以下の場合のみです。

  • その推薦がまだ承認されていないか、拒否されていない場合

  • ノミネーションが 24 時間以上前に作成されたか、最後のレビューが 24 時間以上前に行われた場合。

  • すでに再トリガーが送信されている場合は、24 時間以上前である必要があります

この再トリガー機能の使用には注意が必要です。承認者がノミネートの承認または却下に数日かかっているのには、正当な理由があるかもしれません。

管理者としてノミネーターの状態をフォローする

ノミネーターを承認した後、その人のフォローアップをしたい場合についてです。Nominatorbot のホームセクションには、 Reviewed Nominations というボタンがあります。このボタンをクリックすると、あなたがレビューしたすべてのノミネーターとその現在のステータスがリストに表示されます。

よくある質問

どのようにして人を推薦すれば良いのでしょうか?

Slackのどこかで、/nominate と入力すると、フォームを送信するためのモーダルが開きます。または、Nominator の Home タブにある Nominate! ボタンをクリックしてもいいでしょう。これは、/nominate と入力したときと同じように動作します。

推薦文を投稿できないようなのですが?

Slackで推薦状を提出できないという報告が時々あります。すべてのフィールドに入力されていることを確認してください。How does this meet the criteria? という質問にも回答するために、下にスクロールする必要があるかどうかは必ずしも明確ではありません。

最近、誰かを指名したのですが、まだ返事がありません

まず最初にやるべきことは、Slack の Nominator's Home セクションを見てみることです。そこにはあなたが推薦したすべての候補者と、そのステータスが表示されます。すべてのノミネートについて、私たちは次のように表示しています。

  • the nominee

  • the status

  • values

  • the message

ステータスは、ノミネートがどこで止まっているかを確認するためのものです。さまざまなオプションがあります。

  • Waiting for manager approval:推薦した人の上司がまだ承認していないことを意味しています。

  • Waiting for second level approval:推薦した人の上司の上司がまだ承認していないことを意味します。

  • Waiting for People Group approval:People Group チームの誰かがまだ承認する必要があることを意味しています。

また、次のようなステータスもありますが、この時点で候補者承認フローは終了しています。

  • Rejected:残念ながら推薦が却下されました。却下した人から本人へ連絡するようをお願いをしていますので、bot はこのような場合には連絡しません。

  • Approved:推薦が承認されたことを意味します。この場合、bot はあなたに連絡を取るべきでした。

次に、現在の承認者が 24 時間以上前に承認依頼を受けたことを通知された場合、このホームセクションの指名の横にある Remind Approver ボタンを使うことができます。これにより、元のメッセージに次のようなメッセージでスレッドが立てられ、現在の承認者に通知されます。

:wave: <@#{channel}> Friendly ping to forget about this nomination.

上記の方法でも問題が解決しない場合は、People Group Engineering の担当者にご相談ください。

候補者の名前が必要になりますので、DMのみでお願いします。

ノミネートを承認しましたが、返事がありません。

最初に注意していただきたいのは、推薦が完全に承認されると、推薦者の上司のみが返事を受け取るということです。つまり、あなたが第2レベルの承認者であっても、何の通知も受け取れません。

ただし、すべての承認者は Slack の Nominator's Home タブに、自分が承認したすべての候補者を見ることができるセクションがあります。

  1. Slackで、Nominator の会話を開きます。
  2. Home タブをクリックします。
  3. Reviewed nominations (レビュー済み候補)をクリックします。

これにより、あなたが確認したすべての候補者が読み込まれ、候補者がどのような状態にあるかを確認することができます。上記の 最近、誰かを指名したのですが、まだ返事がありません という質問で述べたものと同じです。

Actions performed by Engineer

オフボーディング

ピープルマネージャーがオフボードするとき、その人がまだ保留中の候補を持っていることがあります。これらが滞らないようにするために、オフボーディング Issue でピン留めして、本番シェルで次のスニペットを実行しなければなりません。

/cnb/lifecycle/launcher bundle exec rake offboarding:run[BAMBOO_ID]

これにより、マネージャーやその上の上司の承認者で止まっているノミネーションを検索し、新しいマネージャーに承認依頼を再送します。

  • レポートに新しい上司が割り当てられている場合にのみ、この処理を行うことができます

  • 実行中のスクリプトを実行することに抵抗がある場合は、最初に dry run バージョンを実行することができます: /cnb/lifecycle/launcher bundle exec rake offboarding:dry_run[BAMBOO_ID]。これで再トリガーしたい候補者が表示されます。

オフボーディング Issue をチェックして、People Experience チームが完了したことを確認するのを忘れないでください。

要望とバグ

今後のイテレーションこちらをご覧ください。 bot に関する問題やプロセスに関するフィードバックは、こちらからお願いします。プロジェクトへの貢献を歓迎します。

Inclusive Language Check

オープンソース Ruby gem を使用して、すべてのジョブファミリーに対して包括的な言語チェックを行います。

現在、そのライブラリは以下をカバーしています。

  • 男性的な表現と女性的な表現の使い分け

  • 性別を表す代名詞の使い方

  • 誤用された言葉

  • 固定観念と成長観念

次のような結果は、パイプラインの失敗につながります。 - 男性コード化された言葉の使用率が高い:女性コード化された言葉よりも男性コード化された言葉の使用率が高いことを意味します。

  • 誤用された言葉の使用は、多様なグループを排除する可能性がある。

  • 固定コード化された言葉の使用率が高い:これは、ジョブファミリーが成長コード化された言葉よりも、固定コード化された言葉を多く使用していることを意味します。

  • 性別を表す代名詞の使用:すべての人を包括したいと考えています。

    • パイプラインを実行する前に、このオンラインツールを使ってジョブ・ファミリーをチェックする必要があります。
    • 微妙に男性的にコード化されていたり、固定的にコード化されていたり、誤用された言葉を使用していると、パイプラインは失敗し、承認フローに従う前に修正する必要があります。男性的な表現や固定的な表現の代わりに使用する推奨語については、このリストを参照(および追加)してください。
    • パイプラインが失敗した場合は、まずエラーを読むことをお勧めします。テキストのどこが間違っているのかが書かれています。例えば、以下のようになります。 ```
    • ["ATTENTION: In /builds/gitlab-com/www-gitlab-com/sites/uncategorized/source/job-families/marketing/reference-program-manager/index.html.md you're using masculine gender-coded language", "Masculine coded words used: analyst, analytical, decision, driven, leader"].

    • ["ATTENTION: In /builds/gitlab-com/www-gitlab-com/sites/uncategorized/source/job-families/marketing/production-designer/index.html.md you're use fixed-coded language", "Fixed coded words used: established"]. ``` このケースでは、失敗したジョブファミリーが2つあり、それぞれ異なる理由で失敗しています。ここでは2つのことができます。

    • テキストをより包括的なものに修正し、変更をコミットすると、パイプラインが再び実行されます。

    • 同意できない場合や、パイプラインが誤検出をしたと感じた場合は、そのファイルをこのリストに追加することができます。このリストのファイルは、包括性チェックでは無視されます。あなたのジョブファミリーをスキップレベルに追加することを要求する場合は、マージの前に求められるので、MRに包含性チェックのスクリーンショットを貼り付ける必要があります。