【Quipperブログ】オンボーディングのはじめかた

こんにちは。Quipper採用担当の鈴木です。今回の記事は、SREの@chaspyによる「オンボーディングのはじめかた」です！是非、ご覧ください！

こんにちは。SREの近藤（@chaspy）です。今回、SREチームではじめてオンボーディングプロセスを実施しました。本日はその内容について紹介します。

オンボーディングとは

Onboardingとは、新しく入社した従業員が組織の中で効果的に成果を発揮するために、必要なナレッジ、スキル、行動を習得するメカニズムのことを言います。

これは単なる社内サービスへのアカウント登録作業ではありません。また、関連する技術的な研修を受けさせるだけでもなければ、OJTという名のもとに振ったタスクをやりながら覚えてもらうだけでも不足しているでしょう。なぜなら習得すべきことは技術的なスキルだけではないからです。確かに、実際の仕事を通じて学ぶことはできるはずですが、より短期間で、より効果的に必要なことを身に着けてもらうためには何らかの学習のための仕組み（Mechanism）が必要です。

なぜやるのか

上記で述べた通り、やる理由は新しく入ったメンバーの早期の戦力化です。新しく入ったメンバーは様々なバックグラウンドを持っているでしょう。例え特定技術・ドメインで豊富な経験があったとしても、逆に特定の分野が苦手だったり、組織にとって暗黙的に行われているルールを掴めずにうまく力を発揮できないかもしれません。新しく入ったメンバーは通常採用面接・試験を通過し、活躍できる可能性を持っている人たちです。そのような様々なバックグラウンド持った、素晴らしい力を持った各メンバーになるべくはやく活躍してしてもらうためにも、オンボーディングは重要な取り組みと言えます。

Quipperエンジニアリングマネージャの @ohbarye のメモによると、シニアでも手を抜かないと書いてあります。この点は私が今回オンボーディングをやろうと思った大きな理由の1つです。

Senior Engineer（Senior SRE）として入社した方には、チームをリードし、今までにない新しいバリューを発揮してもらうことを期待しています。しかし、発揮できるまでには必ず未知の領域が存在するはずであり、それをオンボーディングによって手助けすることはシニアエンジニアであれど（あるいは、シニアエンジニアであるからこそ）早期に価値を発揮してもらうことに確実に寄与すると考えました。

ゴールの設定と価値観の言語化

まず、オンボーディングをやる際に、ゴールを定める必要があると考えました。

早期の戦力化を達成するためには、何が達成できたらよいでしょうか？これを考えるために、私は現在のSREチームの活動を Mission・Responsibility・Routine Work という3段階にブレークダウンしてみました。

Mission
- Make it reliable and stable our services
Responsibility
- Proactive approach for stability with monitoring services.
- Fixes server instability / failure
- Response to @sre (and your individual mentions) in slack/github
Routine Work
- Change an infrastructure with code
- Review Pull Request
- Response to @sre in slack/github
- React an alert
- Take long term task
- - i.e. Improve a developer's experience
  - i.e. Replace an application platform

これらから何が見えてくるでしょうか。

まず、チームの Mission を元に Responsibility が決定されます。私たちの普段の業務（Routine Work）は Responsibility を果たすためであるべきです。そして、ここであげられた普段の業務はそのままオンボーディングのゴールとなります。質・速度の差はあれど、まずこれらを基本的に1人で実行できることがゴールとなります。

また、これらを言語化することよってチームの価値観（Value）が見えるようになります。これらを事前に共有しておくことでメンバーは主体的（Proactive）な行動を行なうことができます。入ったばかりだからこそ、些細なことで迷いが生じると思いますが、その迷いを減らすことにも役立つはずです。

余談ですが、Quipper SREチームはあまりルールを多く持っていません。個人が多くの裁量を持ちながら、プロダクトの信頼性をいい感じにしていくためにはQuipperの5つの行動指針のように価値観が共有されてることが重要ですね。

具体的で順序建てられた学習体験の設計

これはFirst SRE BookのAccelerating SREs to On-Call and Beyondを参考にしました。この章はオンコールローテーションにおけるNew Joinerの育成に関する指針ですが、内容は非常に参考になります。

特に

Note that the preceding section does not directly encode procedures, diagnostic steps, or playbooks; instead, it’s a relatively future-proof write-up focusing strictly on enumerating expert contacts, highlighting the most useful documentation resources, establishing basic knowledge you must gather and internalize, and asking probing questions that can only be answered once that basic knowledge has been absorbed.

という点が非常に重要だと感じました。学習体験という意味でも、答え（手順）を羅列しても意味がなく、またそういったものを最新化し続けるのもコストになります。

上記を踏まえて、通常業務（Routine Work）を一人で行うために、以下のような単位に分解して学習できると考えました。

Learn our SRE team with SRE Handbook

- SRE Handbook is a guidebook on infrastructure, services, and jobs you are using

Take Small Task

- To learn the culture of the team including infrastructure deployment and review process

Learn a Monitoring / Logging

- Monitoring and logging are the core components for SRE.

Review Pull Request

- Learn about each repository while reviewing team members pull request

Take Long Term Task

- He/She will focus on ourselves and advance tasks with high difficulty

上記を1つずつ説明します。

Learn our SRE team with SRE Handbook

まず、SREが扱う業務内容、あるいは扱うインフラ・サービスを包括的にまとめたドキュメントが必要だと考えました。これは私が入社後分からないことだらけだったので、自分の理解のため（そして次に入るひとのため）に作っていたものです。

入社して最初の一週間の間（おそらく個人PCのセットアップと、各種アカウント登録が終わったあと）ぐらいのタイミングで、このドキュメントを使って、口頭で説明を行いました。

なぜこのような包括的なドキュメントが有用なのでしょうか。それは人間が何かを理解するときに、全体と個別を行き来しながら、物事の構造化を行なうからです。まず最初に全体理解しておくことで、今後発生した個別の事象の位置づけ、理解、処理することが容易になります。

また、私たちは Wiki のようなドキュメントが陳腐化してしまうことをよく知っています。このようなドキュメントを陳腐化させないためには、そもそも更新が頻繁に必要にならないようにに大局的なことだけを書き、手順などの詳細を書かないことが非常に重要です。

Take Small Task

ドキュメントを使って全体感を理解したあとは、SREチームの（インフラのデプロイ・リリースなどの）慣習を体験できる小さなタスクをいくつか持ってもらいました。

上記で述べた通り、あまりSREチームはルールを持っていないのですが、インフラのデプロイに関してはある程度ルールがあります。ブランチ規約、コミットメッセージ、Pull Request に何を書いてどういうプロセスでインフラを変更するか、ということを一通り体験します。これは Quipper のインフラを理解することにも同時に役に立ちます。

Learn a Monitoring / Logging

SREとしてサービスの信頼性・安定性を担保するためには Monitoring / Logging が必須です。Quipper では Monitoring を Datadog、Logging は BigQuery と StackDriver Loggingを使っています。Monitoring / Logging それどれどのような仕組みでデータが流れ、どう活用するか、アラートはどういう条件で発生するか、ということを時間をとって説明し、理解してもらいます。

Review Pull Request

Quipper のインフラはほぼ100%がコード化されており、仕事＝ Pull Request と言っても過言ではありません。Pull Request の Review は、作成したひとのブロッカーになるので、非常に重要な仕事です。そして、新しく入ったメンバーにとっては非常に難しい仕事でもあります。作成したひとは Context 、 Background などを可能な限り書きますが、新しく入ったメンバーにとってはまずそのリポジトリが何のためにあって、どのように利用されているかを知るところからはじまります。これをまだ慣れない中、1つ1つキャッチして理解するのは難しいです。そのため、オンボーディング期間中はメンターあるいは既存メンバーが、Repository / Pull Request の概要と、レビュー観点を伝えることで、思考するスコープを狭めた上でレビューをアサインするということを行いました。

Take Long Term Task

Quipper SREでは、普段の業務の50%を運用業務に、残りの50%を中長期的な改善活動を行っています。今回は入社して間もないうちにこの大きいタスクも並行して持ってもらいました。最初から通常業務の50%の割合で長期的なタスクを既存メンバーのフォローをもらいながら進めるのは、時間管理的な意味でも、技術的な意味でも難しいことです。しかし、このタスクを通じて、我々のプラットフォームの重要な点を学びながら、完遂することができたので、これは早い段階で実施していてよかったと思いました。

その他やってよかったこと

Check List

「これだけは（遅かれ早かれ）必要になるからやっておこう」といったリストは事前に渡しました。よくログインするサーバへ簡単にログインするためのスクリプトや、私たちが管理するプラットフォームに関する情報取得方法等です。このチェックリストはドキュメントには記載していないものの、GitHub issue でチェックリストとして行ったので、きっと次のオンボーディングのときにも加筆・修正されて役立つことでしょう。

1on1 Meeting

Quipper では Engineering Manager と Engineer の 1on1 Meeting は定期的に行っており、特に新しく入ったメンバーとは週に1度行っています。SRE Team の Engineering Manager は CTO の @masatomo が兼務しており、並行して現場に一緒働くメンバーとして（オンボーディングのメンターとして) 私とも週に1度行いました。

Meeting では主に「最近やっていること」「これからやること」「困っていること」を軸としながら、オンボーディングのゴールに対する達成度合いを確認し、短期的（翌週に向けての）なアクションを明確にしていました。普段から話せる距離で仕事はしているとはいえ、時間をとってこれを確認することは重要だったと思います。