サポートのオンボーディングバディ

新しいサポートエンジニアのオンボーディングバディに任命されました。おめでとうございます！あなたは、新しい人が私たちの顧客、チーム、そして製品に最大限貢献できるようになるために、その人を支援する重要な役割を担うことになりました。

責務

サポートのオンボーディングバディの責務は、GitLab のオンボーディングバディの責務 を拡張したものです。まずそのページに目を通してください。

1. 新人サポートエンジニアが オンボーディングモジュール で詰まっている箇所をすべて支援する。
2. 新メンバーと頻繁にコミュニケーションを取り、行き詰まったときには直接助けるか、助けを得られる先を案内する。
3. 日々の業務について学べるよう、頻繁にコールやペアリングセッションを行い、新人サポートエンジニアが役割に適応・習熟できるよう支援する。
4. 新人サポートエンジニアが当初のコンフォートゾーンを越えるようなチケットに取り組むよう促す。
5. 最初の 2 週間に外出予定がある、または多数のコミットメントを抱えている場合は、自分以外の人にこの役割を引き受けてもらうか、コミットメントを整理してこの役割に確実に時間を割けるようにできないか、マネージャーと相談しましょう。
6. モジュール、アクセスリクエスト、オンボーディング Issue は頻繁に更新されるため、変更内容をレビューして適切にガイドできるようにする。
7. 進捗のペースや取り組むモジュールについて、新メンバーの直属マネージャーが望む方向性と認識を合わせる。

構造

オンボーディングバディとしての期間中、新人サポートエンジニアがオンボーディングを完了するまでの間、隣で並走することになります。下記の期間はあくまで目安と捉えてください。実際のペースは新人サポートエンジニアの進み具合によって決まります。

アイデアと提案

人それぞれニーズは異なるため、以下は個別ニーズに合わせてカスタマイズするためのアイデアの一覧と捉えてください。下記すべてが必要な人もいませんが、誰でも少なくとも一部は役立つはずです。

最初の 1〜2 週間

• 互いを知り合うために顔合わせをする
• 一般的な質問に答え、お互いに親しくなる。
• どのくらいの頻度で状況を確認してほしいか、非同期と同期のコミュニケーションのどちらを好むかを尋ねる。
• 自分の「スケジュール」と日々の働き方について話し、いくつかの典型的な 1 日の例を案内する。
• Slack や Navan などのツールの使い方について話す。
• 役立つ Slack チャンネルや、毎日チェックすべき Slack チャンネルを紹介する。
• SWIR と、最新情報を得る方法（ダイジェスト Issue（および「ニュースレター体験」のための ラベル購読）、#spt_swir Slack チャンネル、音声版）について説明する。
• オンボーディング期間中に読むと役立つハンドブックページを紹介する。
• GitLab の アーキテクチャ図 を紹介する。
• 製品関連や support-team-meta の Issue をいくつか紹介し、何にでもコントリビュートできることを明確に伝える。
• 書籍やトレーニングは経費精算可能であることを思い出させ、Spending Company Money ページを紹介する。高額な場合は先にマネージャーに相談する。
• オフィス機器手当があることを伝え、機器の経費精算ハンドブックページ を紹介する。
• 手当の使い方、Navan での経費申請方法を説明する。
• テスト環境 を紹介し、GitLab Sandbox Cloud for GCP に触れてもらう。
• ハンドブックやドキュメントで更新が必要な箇所を見つけたら、MR を作成するよう促す。
• GitLab チームページ を自分の情報で更新する手助けをする（オンボーディング Issue のチェックリスト項目の 1 つです）。
• 質問しづらいことや助けが欲しいことがないか、非同期で Slack の状況確認をすることも検討する。
• 一度に圧倒されないよう、共有する情報を複数のミーティング／ペアリングに分割することも検討する。

3 週目以降

• 開いているモジュールを一緒にレビューし、次を確認することを忘れずに行う:

  • 何かのタスクで助けが必要かどうか、また終わったタスクのチェックを入れてモジュールをクローズすることをリマインドする
  • 現在のパスに合わない開きっぱなしのモジュールがあれば、それについて話し合う

• ペアリングセッションとは別に定期的なチャットの時間を設ける、もしくは通常のミーティングの一部の時間を使って、進捗、懸念事項、助けが必要なことを話し合うことを検討する。

ペアリング

• Zendesk と私たちの使い方の紹介:

  • Zendesk と使い方を一通り案内する
    • さまざまなマクロの使い方を紹介し、最もよく使われるものについてアドバイスする。
    • Zendesk のさまざまなアプリの活用方法を紹介する。
  • チケットワークフローのハンドブックページ について質問があれば答える
  • 自分が普段、どうチケットを選び、どう回答しているかのプロセスを共有する
  • 署名内の挨拶文の設定 について話す

• チケット業務:

  • pairfy を使ったチケットペアリング Issue の作成方法を見せる
  • 安心して取り組んでもらいたい一方で、新メンバーには 低い恥の閾値 というバリューに沿って、コンフォートゾーンを越えてもらいたいとも考えています。「愚かな質問は存在しない」ことを強調し（直近で自分がした「素朴な質問」を共有してもよいでしょう）、いろいろな公開 Slack チャンネルで質問するよう促す
  • あるトピックで詰まりを感じたときに、その分野の専門家とペアリングをセットアップしてもらう。混乱を避けるため、専門家のフルネームまたは GitLab ユーザー名で具体的に伝える。
  • GitLab のカレンダーを案内し、自分のリージョンで成長に役立ちそうなグループペアリングを紹介する。リンクを送ることも検討してください。

• チケットでのペアリング:

  • 画面共有して、簡単なチケットをいくつか一緒に回答する
  • コールに自分のチケットを持ってきていれば、それから先に回答する
  • 画面共有とチケット回答を交互に担当する
  • 可能なときは問題を再現する。お気に入りの方法（Docker、GitLab Sandbox Cloud for GCP など）でインスタンスを素早く立ち上げる方法を見せる
  • ワークフローを確認するときには「ハンドブックファースト」のバリューに従い、模範を示す

• 顧客コール:

  • 顧客コールがあるときに、シャドウできるようピンする
  • シャドウできる顧客コールの探し方を見せる
  • 可能であれば、相手の最初の顧客コールに同席する。それが難しい場合でも、シャドウしてくれる人を確保できるよう最大限の手配を行う

その後にやること

• オンボーディング Issue をクローズした後、さまざまなフォーカスエリアについて話し合い、次にどのトレーニングモジュールに興味があるか尋ねる。該当する領域の専門家や、（あれば）spt pod の Slack チャンネルを案内する。専門家のフルネームとチャンネルを DM で送るか、共有ドキュメントに追加する。
• 頻繁な状況確認／チャット／ペアリングを継続することを検討する（例: 月 1 回）。
• 最初の数か月の間に、相手の学びになりそうな興味深い案件があれば、ピンしてペアリングやシャドウへの参加を打診する。

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