新しいチームに加わるエンジニアのための "被" オンボーディングガイド v0.1.1
yktakaha4 こと、髙橋です。
コロナもあって運動不足なので、最近気が向いたときだけ夜にランニングしてるのですが、走り終えたら脳に血が通ってきた感じがしたので、ちょっと一筆したためたいと思います。
私はシステムエンジニアで、2021年1月からLAPRAS株式会社で働いているのですが、
4月の頭にあった入社3ヶ月面談にて、社長より無事試用期間を終えた旨を伝えられました。よかった。
入社エントリ代わりに↑の記事を書いた当時はまだオンボーディング期間でした。
そこからまだ3ヶ月しか経っておらず、理想的な自己と比較して途上のこと、力不足を感じることなど沢山あるのですが、
区切りとしてはちょうど良いので、オンボーディング期間に意識したらいい感じになったこと・意識できなくて反省したことをまとめたいと思います。
もっとも、私自身に独自のオンボーディング観がありそれをご紹介するという話ではなく、
単に先達の残した知見を自分のケースに当てはめた結果どうなったか...という経験譚になります。
あしからず...🦵
ということで、今回のオンボーディングにおいては、私はこちらの記事を折を見て読み返していました。
なにを隠そう、執筆者のrockyさんはLAPRASの現CTOその人です。
これはヨイショしようとしたからでも、「オンボーディング エンジニア ガイド」で検索したら一番上に出てきたからでもなく、
近しい環境で書かれた記事の執筆者がそばにいる状況の中でそれを活用しない手はない（リモートなのでそばではない）と思ったのと、
仮に書かれていることが自分にあまり当てはまらなかったとしても、書いた理由や背景を聞けばそれがそのままその人やコンテキストの理解につながると考えたからです。
それでは見ていきましょう...！
"被" オンボーディングガイドv0.1.0について
今回参考にした "被" オンボーディングガイドv0.1.0 について紹介したいと思います。
実際のガイドに関する部分の見出しを抜粋してみると、以下のようになっていました。
- いきなり目立った成果を出そうとして消耗しない
- 目標とスケジュールを設定して共有する
- 進捗を共有して必要であればスケジュールを変更する
- フィードバックをもらって現状を正しく認識する
- ギャップがあれば解消する方法を考える
- 現状の仕組みを作り上げたことに対する敬意と感謝を忘れない
- 実務上のサポート（をリクエストする）
- システムを触る
- システム全体像のインプット
- ペアプロ・ペアOpsもといペアワーク
- 自分の関わっていないPullRequestを見る
こうして眺めてみると、筆者は一貫して現状を把握せよと言っているように思えます。
最初の項のひとことめは、それを端的に表現する一語ではじまっています。
まずは危険性を認識する
ここでいう危険性とは、自分より能力が高い人ばかりのチームに入ってしまったとか、メンバーの性格が伺えないうちに我を出しすぎると煙たがれる...といった他者や環境の話ではなく、
ひとえに自己認知能力が低下している事実を適切に認識しようという投げかけであると感じます。
私はエンジニア歴9年・LAPRASが3社目の会社というキャリアなので、自己認識としても会社からの期待としても、一定の業務経験のある中途採用のエンジニアということになると思いますが、そうしたキャリアとは無関係に、環境が変わった直後は誰しも本来の実力発揮が難しい状態にあるというのは、直感的にも納得がいきます。
画像はオンボーディング計画の序文です。
いかなる問題であっても、客観的に認知できれば事前に対策を打つことができます。プログラムにバグを埋め込む前に自動テストを書く...みたいな話と思います。
オンボーディングにおいて筆者は以下が効果的であると書いています。
- 目標とスケジュールを設定して共有する
- 進捗を共有して必要であればスケジュールを変更する
聞いてみれば当たり前のことだな...と思われるかもしれませんが、
今回得られた感触としては、ここで扱われる目標・進捗・スケジュールの共有は非常に重要で、オンボーディング、引いてはその後の長期的な生産性にも影響してくる事柄であるように感じられました。
オンボーディングが始まる少し前を振り返ると、（嬉しかった）内定通知の後に、オファー面談というものがあったことを思い出します。
この場では、採用候補者としての自己に対しての現時点での評価・期待と、それに対する報酬について話し合いがなされたものと思います。
つまり、ここで言われる目標とは、入社契約書にサインする前に候補者・採用者間で、漠然と（ただし確かに）合意した何かを多かれ少なかれ引き継いでおり、そこには相互に「入社後にこうなってくれるといいな」という楽観的な感情が多く含まれています。
話が少し飛びますが、弊社が組織運営において採用しているホラクラシーにおいては、そうした明文化されていない責務を暗黙の期待と呼び、これが放置されると組織に対してひずみを生むとされています。
先ほど話した危険性の話も踏まえて考えれば、
オンボーディング期間においては、自己認知能力の低い状態で、暗黙の期待に対して、ゼロから一定の成果を出せるようになる必要があるということとなり、いかに不安で心細い状況であるか想像できると思います。
また、これに加えて、オンボーディングする側は組織において着任歴の長い人物が担当することもままあり、これにより生まれる情報の非対称性も、問題を複雑にさせる一因となっているように感じます。
では、どうすればいいのでしょうか。
つまり、暗黙の期待と情報の非対称性を最小化した、進捗を評価できる目標をオンボーディング期間にスケジューリングすればよい...ということになり、明文化された具体的で小規模なゴールを細かく用意して、その達成状況を継続的に評価することができれば、今まで説明してきた問題に対して恐れずに取り組むことができそうです。
例えば、現在のLAPRASではオンボーディング計画として、esaのドキュメントとして以下のようなドキュメントを作っています。
期待は期待として伝えた上で、実際の目標についてはxヶ月の間にとか、○○ができる...といった、具体的で短期的なものをしっかりと規定するのが重要であると感じます。
また、注意したいのはこれはオンボーディング完了時の状態で、このチェックリストの細目をトレーナー役の社員（私はchanmoroさんが担当してくれました。めっちゃ真面目・真人間でした）と詰めていくことも、オンボーディングの一環としておこなっているということです。
もしあなたが着任したチームに明確なオンボーディングプロセスがなかった場合は、オンボーディングを受ける側から問いかけを続けて、短期的・小規模な目標を作りながら少しずつ視野を広げていくとよいと思います。
更に、こうした具体的な目標の束は一度作ってしまえば今後の新規着任者に対して部分的に再利用することができるため、組織やチームのスケールに対しても並行して対処できるというのも魅力的です。
もう少し具体的に開発着手状況を把握するためのツールとして、以下のような実績解除マップを作成することも効果的だと感じました。
例示している部分では開発プロセスのみですが、この下に要素技術（例えば、gRPCやKubernetesに関連する開発を担当したか）だったり、特定のドメイン知識（ユーザーのスコアリングに関する実装を改修したか）などが項目として並んでおり、
週や月の1on1で、消化したIssueなどを振り返りながらチェックを埋めていくことで、定期的な振り返りや着手状況の可視化が期待できます。
こちらのドキュメントもオンボーディング計画と同じく、全メンバーで運用すると誰がどの領域に対して知見を持っているか俯瞰して見ることができるようになるため、オンボーディング運用フローの中に組み込めるとよさそうです。
そのほか、敬意と感謝を忘れないという心構えであったり、（好きな本にTeam Geekを上げる方が多い）、ペアプロ・スクラムなど問題に対してチームとして取り組むことの重要性が説明されていますが、これらについてはぜひ元の記事を読んで頂くのが早いと思います。
自分はもったいぶった書き方をしてしまいがちですが、rockyさんの文章は思考を追従する感じというか、ライブ感があってよいのです。ちなみに分報もそんな感じでよいです。
バージョンのインクリメントに寄せて
ここまで書いてきて、自分のオンボーディングはさも順風満帆であったかのようですが、実際は課題や悩みも多々ありました。今もあります。
ここではそこからひとつ取り上げ、解決に向けてどのように取り組んだかと、そこから得られた教訓をもってオンボーディングガイドのバージョンアップの提案をしたいと思います。
LAPRASが掲げるバリューの1つとしてリスペクト・ベースというものがあり、他者に対するフィードバックを積極的におこなうことが推奨されています。
肯定的なフィードバックは気軽に行いやすく、実際会社でもUniposを導入して #la-plus というチャンネルでちょっとした感謝（Amazonギフト券に交換できるポイント）を送りあっています。
画像は先日行われたLAPRAS2周年記念YouTube配信の企画者たるnagasakoさんに対して感謝するdenzowさんです。
逆に、改善点を伝えたりといった、受け取り手がネガティブな感情を受けやすいものについては、建設的フィードバックとしてSlackのワークフローを使って相手に対して直接伝えられる（リスペクトを持って伝えるために非匿名）ようになっているのですが、
ある時、会議やデイリースクラムの場で話を拡散しやすい・話のゴールが分かりづらい という指摘を、近いタイミングで複数の方からもらうことがありました。
こうした、各個人の性格や資質に起因する問題は、事前に対処法を準備することが難しいことに加え、解決するには一定の時間を割く必要があるため、放置→オンボーディングスケジュールに支障したり、本来計画したオンボーディングを進捗することが責務であるはずのトレーナーに対して強い負担がかかってしまったり...といった延焼を発生させやすく、計画者側としては悩みの種だと思います。
無論、オンボーディングを受ける側に対しても心理的な負荷になりやすく、パフォーマンスを下げてしまう一因になりかねません。
こうした計画外の問題に効果的に対処するための役割として、LAPRASのオンボーディングではメンターという役割の人をひとり設定するようになっています。
メンターは、やることとしてはオンボーディングを受ける人と定期的に1on1をおこなう...というシンプルなものですが、サポーターと異なり自発的・自律的な発達を促すことや悩みの解消といったパフォーマンスの最大化が責務となっています。
以下は、メンターの手引きという社内資料からの抜粋ですが、個人的によいなと思っているのが、悩みを抱えることが多いものですという見込みに基づいて予防的にコストを割いているという点です。
これによって、うまくいかないことがあっても立ち直るための猶予を持てたり、うまくいっている時はそれをより加速させる取り組みができたりと、計画したオンボーディングとは独立して課題に対処する体制作りを目指しています。
私の場合は、前CTOで現SREのshowwinさんに担当してもらっていたのですが、事前に以下の形式でGoogleドキュメントに話したいことを簡単にまとめてからおこなうフォーマットになっていて、個人的にはこれがとてもよかったです。
# yyyymmdd
## 先週の調子は？ (絶不調、不調、普通、好調、絶好調)
## 今日の1on1で特に話したいことは？ (取り上げたい課題や懸案、祝福したい達成事項)
## 前回の1on1以降、実行したことは？ (その中でうまくいったこと、いかなかったこと)
## 今日の1on1を通して得たいものは？
## その他 (例: 新たな発見、最近の変化、人生の状況)指摘を受けた問題についても、例えば解決方法が一呼吸おいてから話してみるくらいの些細なことであっても、それが単なる自戒として決めたことと、チームの誰かと合意したことでは大きな違いがあるように感じます。
課題に対して他者が介在すると、その視点から見て前回1on1した期間と比べて改善したか...といった相対的な解決を積み重ねることができるようになります。
また、仮に問題が根治できていなかったとしても（未だ私の話はゴールを見失うことがあると思います）、精神的な安堵を得ることができますし、メンターとメンティーという、ひとつのチームとして解決に取り組める点においても、一人で対処するより遥かに優れていると思います。
ということで、私は0.0.1相当のアップデートとして、計画と想定外の事象へ個別に対処するという知見を加えたいと思います！
（この記事にいいねが沢山ついたら、rockyさんに追記を提言したい...）
ということで、長くなってしまいましたが終わります☕️
既にkawamataさんなど自分以降にジョインした方も増えており、しかも早々にフロントエンドの技術的改善もバリバリ進んでいてめっちゃ頼もしいです...！
そして次こそは、自分も技術的な取り組みの記事を書けるようがんばります...
この記事が気に入ったらサポートをしてみませんか？