オンボーディングされる技術
転職、社内異動などにより自身の所属チームが変わることがあると思います。
その際にチームにどの程度馴染めるか、いち早くキャッチアップできるかはオンボーディングされる側のスタンスも重要になってきます。
私は正社員・業務委託を通して15チームに所属してきました。(最短1ヶ月、最長1年半、研修は含めず)
オンボーディングされる側として気をつけるポイントを理解していなかったことで不要なハレーションを生んでしまったこともあります。
そういった自身の反省も踏まえて、何をすべきで、何を避けるべきか、ポイントを整理しておきます。
※転職時を想定して記載していきます。
オンボーディングの目的
オンボーディングする側はオンボーディングプロセスの設計をしているのでオンボーディングの目的を定義しているはずです。ただ、オンボーディングされる側としても目的を把握しておいた方がオンボーディングの意図を汲み取りやすくなるため記載しておきます。
オンボーディングの目的は主に以下の2つです。
- チーム定着(離職防止)
- 早期戦力化
「チーム定着(離職防止)」はオンボーディングされる側が関与し辛い部分ではあるので、基本的にはオンボーディングする側に任せましょう。歓迎会や社内交流イベントなどあれば積極的に参加する、くらいでよいと思います。
「早期戦力化」はオンボーディングされる側から関与できる部分が多いので以下に記載している内容を参考にしてみてください。
入社前にやった方がよいこと、やらない方がよいこと
オンボーディングは入社前から始まっています。入社後に爆速でスタートを切れるように準備をしておきましょう。
やった方がよいこと
- 前職の知見、考えたことをまとめる
- 転職というタイミングで思考のバックアップを取得するイメージ
- 整理して記載しておくと後々自分の心境や考え方の変化を辿れるのでおすすめです
- 仕事以外のこと
- 旅行する、映画を見る、家族・友人・恋人とゆっくり過ごすなど
- 仕事に関係するけどゆっくり時間があるときだからできること
- 使ったことのない技術を使って開発してみるとか
やらないほうがよいこと
- 入社に向けた予習
- やろうとしても結局そんなにやらないです(自分の場合は)
- 「やらないとな〜〜」と思って頭に残り続けているストレスの方が大きかったです
- 転職の合間の休みにリフレッシュすることも大事な準備
- 自分から進んでやる必要はないけど、言われたらやった方がよいとは思います
- 「この本はみんな読んでいるから読んでおいてね」とか
- やろうとしても結局そんなにやらないです(自分の場合は)
PCの環境を整えるのは最優先
仕事中のほとんどの時間はPCを触っているので複利で効いてきます。最優先で整えましょう。
(キーボード設定、通知設定、アイコン設定、etc...)
昼休みや、研修が1時間の予定が50分で終わったときなど間の時間を活用して整えていきます。
入社直後というモチベーション・緊張感が高い時期を利用して爆速でキャッチアップする
「入社直後というモチベーション・緊張感が高い時期を利用して爆速でキャッチアップする」を基本方針として以下の行動をするとよいです。
- 共有されたドキュメントを全部読む
- 共有されていないドキュメントも可能な限り全部読む
- ドキュメントがあまりない会社の場合はSlackの過去ログを読む
- 人間関係を把握する
- 顔と名前を一致させる
- 役割を把握する
- 趣味や好きなものを知る
- プロダクトを使い倒す
- アーキテクチャを把握する
- ソースコードを読む
- GitHubのRepositoryの分割方針の把握
- ディレクトリ構造の把握
- 使用しているライブラリの把握
オンボーディングされる側のスタンス
- アンラーニングする
- せっかく新しい職場に来ているのでそれまでのやり方に囚われずに一旦受け入れてやってみる
- 自分の経験ですが、「アジャイル開発ならスクラムをやるべし!」と思っていましたが、スクラムをやらないでも上手く機能しているチームに出会って考えが変わったことがあります。
- あなたの知見が活かせる場面は必ず訪れるので焦る必要はないです
- そもそも現状分析が足りていない人の提案はチームの状況に適していない可能性が高く提案自体が刺さりづらいというのもあります。
- せっかく新しい職場に来ているのでそれまでのやり方に囚われずに一旦受け入れてやってみる
- 試されている自覚を持つ
- オンボーディングする側が「お手並み拝見」スタンスなのは良くないです
- オンボーディングされる側としては「この人にはどのような仕事をどのような粒度で任せて大丈夫かな?」と思われている自覚を持った方がよいです
- 具体的に何をしたらよいか
- 言われたことを言われたとおりにやる
- 自己流でやらない
- 🙅「こっちの方がよいと思ったんですよね」
- 報告・連絡・相談を適切なタイミングで行う
- 一度で覚える
- 「分からなかったらいつでも聞いてね」と言われますが、一度で済むならそれに越したことはないです
- オンボーディングする側は「いつでも聞いてね」、オンボーディングされる側は「1回で覚えたろ!」です
- 一度で覚える意識を持ちつつ、困ったらすぐに相談する
- 「分からなかったらいつでも聞いてね」と言われますが、一度で済むならそれに越したことはないです
- 言われたことを言われたとおりにやる
- 難しいタスクをこなすとか大きい成果を上げるとかは将来的に期待されているが入社直後の話ではないです
- 一部それができるビジネスエリートの方もいますが、基本的なことをやって信頼を得る動きをした上での話です
- 優先順位を間違えないようにしましょう
- 困ったらすぐに相談する
- 入社直後は、相談するべきか自分で解決するべきか判断するのが難しいので迷ったときにはすぐに相談しましょう
- 相談するときは誰にどのように相談するかわからないこともあったりするので、相談ルートをあらかじめ決めておくと良いです
- Slackであれば自分専用のオンボーディング用のチャンネルを作成するなど
- チームメンバー全員を招待してそこで疑問点やオンボーディング進捗などを書いていくことで何かしらアドバイスやサポートをもらいやすくなります
TIPS
- 推奨はできませんが、残業したり休日の時間を使ったりするとより早くキャッチアップして周囲に差を付けることができます。
- リモートワークだとPCが触り放題だったりしますよね
- 「前職までの知見を発揮して色んな改善や提案を進めて欲しい」と上司や採用担当に言われても鵜呑みにしない
- チームの信頼を得る前に提案ばかりしていると「アンラーニングできない人」と思われてしまう
- まずは任されたタスクをやり切ることに集中する
- 次回以降のオンボーディングに活用できるようにオンボーディング中に詰まった箇所や考えたことのメモを貯めておく
- オンボーディング完了後にメモを共有することで1つアウトプットを出すことができます
- 最初に大きすぎるタスクをもらわない
- エンジニアであればチーム配属から1週間以内にPRがマージされるくらいにしたい
- 見積もりが1週間以内なので新入社員ということを踏まえると1〜2日で終わるようなタスクがちょうどよいです
- 入社から1ヶ月後くらいに上長と話す機会を作って期待値調整する
- 入社前後のどこかのタイミングで話していると思いますが、社内の解像度が高まったタイミングで改めて認識を揃える時間を取るとよいです
まとめ
オンボーディングされる側として気をつけたいポイントについて記載しました。
これらをきっちりやり切ることでチームメンバーから「信頼」を得ることに繋がるはずです。
その後は獲得した「信頼」をうまく活用してさらなる成果を出していきましょう!
この記事が、新しい環境で力を発揮し、スムーズなスタートを切る手助けとなることを願っています。
Discussion