オンボーディングは入社後の第一印象を決める！ チームのオンボーディングって大事だよねって話
2022年も12月に入り、もうすぐ年末年始です。
あっという間に今年も終わりそうですが、あと数ヶ月経って、4月になると会社によっては新卒のメンバーが入社してきます。
またIT業界やエンジニアという職業は他業種と比べると、比較的転職が多いので、メンバーの入れ替わりが多いです。
人によっては、1~2年ごとに転職してます！って人もいるでしょう！(業務委託ならもっと短いスパンかもしれない！)
そこで重要になってくるのは、オンボーディング(新規メンバーの受け入れ)です！
一応言葉の確認をしておきましょう
オンボーディングとは、乗り物に乗っていることを意味する「on-board」を由来とし、新しい仲間の順応を促進する取り組みを指す言葉です。
リクルートマネジメントソリューションズ 人材育成・研修・マネジメント用語集
人事用語では、新しく会社・組織に加わった人材にいち早く職場に慣れてもらうことで、組織への定着・戦力化を促進するための取り組みのことを指します。
リクルートのサイトの定義を踏まえて、オンボーディングの目的は、会社・チーム視点とメンバー視点では以下のようなことになります。
- 会社視点
- できる限り早く、モチベーション高く、チームやプロジェクト内で業務を始め、パフォーマンスを発揮してもらうため
- 新メンバー視点
- 新しい会社やチームに対する不安やストレスを解消するため
会社としては、人手が欲しいから採用しているわけですし、報酬を払っているのだから、できる限り早くバリューを出して欲しいと思うのは当然です。
しかし大前提として、オンボーディングは新メンバーのためにするものであって、会社やチームの都合を全面的に押し付けることは望ましくありません。
基本的に新しいメンバーは、入社・ジョイン前に面接や面談、場合によってはインターンや体験入社などのプロセスで、ある程度会社やチームの情報を得ているとは思いますが、全貌を知っていることはおそらく稀で、またしっかり仕事ができるかな？など、ジョインする時にある程度不安を感じていると思います。
そのような状態のメンバーに寄り添い、サポートして、新しい環境で、モチベーション高く、円滑に仕事を始められるようにすることが一番重視すべきです。
自分も何度か転職をして、色々な会社やプロジェクトにジョインしたこともあるし、逆に新しいメンバーの受け入れ側も経験したことがあります。
その経験で上記にもある通り、オンボーディングというのは非常に大切なプロセスだと感じているので、この記事で自分なりの考えや実践案を書いていきます！
オンボーディングがしっかりしていない会社やチームはどうなるか？
冒頭でオンボーディングは大事と書いてきましたが、自分の実践案などを紹介する前に、逆にオンボーディングがしっかりしていない、もしくはしっかりとオンボーディングの準備をしていないとどうなるか、を考えましょう！
きっと以下のようなことが起きてしまいます…
- 既存メンバーの対応に時間がかかり、業務への影響が出る
- 新メンバーが新しい会社やチーム、業務への理解が進まず、ギャップを解消できないまま、業務内でパフォーマンスが発揮できない
- 既存メンバーと新メンバーでコミュニケーションがうまく取れない(新規メンバーがチームで孤立する)
- 新しい会社やチームへの業務にモチベーションが低下する
このようなことが起きてしまうと、最悪の場合、新メンバーの早期の離職、またその時の状況があまりにも悪い、もしくはチーム側の離職時の対応に大きな問題があった場合などは、その離職したメンバーからその会社の悪い評判が広がるレピュテーションリスクにも繋がる可能性があります。
人を採用するのが難しい昨今に、せっかく大きなお金と労力をかけて採用したにも関わらず、すぐにその人が離職してしまい、最悪会社やチームの評判が下がることに繋がると、次の採用のハードルは更に高くなり、既存のメンバーのモチベーション低下にも繋がります。
もちろんオンボーディングが全てではないですが、会社としては採用自体はあくまでスタートであって、実際はその先の業務をしてもらうことが本来の目的であるので、採用のハードルが下がっている分、オンボーディングはより丁寧に実施されるべきだと思います。
特にオンボーディングは、新メンバーが会社に入ってから行う一番最初の業務です。
よく第一印象は大事といいますが、業務の場合はこのオンボーディングによって、その第一印象が決まります。
したがって、その対応や準備をしっかりしていて、よりよいものになっていれば、新メンバーの印象はかなりよくなるし、逆によくないものなら、その印象はかなり悪くなってしまいます。
オンボーディングではどんなことをする？
ではまず、オンボーディングではどのようなことをするのでしょうか？
ここでは大きく以下の3つのカテゴリに分けます。
- 会社やチーム概要や業務内容などの伝達・理解
- 新メンバーと既存メンバーでコミュニケーションを取れるようにする(信頼関係の構築)
- 最初のメインタスクの準備
①については、例えば
- 社内やチームのルールやドキュメントを読んでもらう
- ツールの権限設定やSlackなどのツールのセットアップしてもらう
- 新メンバーに実施してほしい特定の作業
などです
これらは基本的に定型業務なので、ドキュメント化などにまとめておくことで大きく省力化することができます。
多くの会社では例えばドキュメントにまとめたり、コーディングに関するものであれば、READMEなどにまとめていると思います。
しかし②・③は大きく省略化することは難しいので、既存メンバーで入社前から入念に準備をし、受け入れ後も丁寧に対応していく必要があります。
これから自分なりにどのようなオンボーディングがよいかの私見や実践例を書いていきます！
オンボーディングはどんなふうに進めるのがいい？
もちろんオンボーディングの進め方は、会社やチームによって異なるので、これという正解はなく、各社各様だと思います。
そこでこのセクションでは、自分の意見や自分が以前の会社のチームでのオンボーディングをどのように進めていたかを参考として紹介します!
会社やチーム概要や業務内容などの伝達・理解
まずは先ほど記述した①~③のうち、手順だけ分かれば基本的に新メンバー自身で実施できることを①を事前に全てまとめておきます。
この方法については、カンバン式でタスクをまとめる方法が一番メンテナンスがしやすく、かつ受ける側や他のメンバーにとってもやりやすい方法かと思いました。
カンバン式で実施するタスクをまとめる
そうすることで、既存メンバーが新メンバーに寄り添って、例えば1つずつドキュメントのURLを共有したり、セットアップ方法を伝える必要がありません(ここに既存メンバーの工数を割くなら、後述のコミュニケーションを行う時間に充てる方がいいと思います)。
基本的には新メンバーに実施してほしいことが一覧化できていればいいのですが、ここに一工夫して、以前の会社ではカンバン式にそれらのタスクをまとめていました。
このやり方は自分が以前副業でお世話になった株式会社ACES(とてもいい会社です！)のオンボーディングを参考にさせてもらっています。
ツールとしてはTrelloを使用していました。
このカンバンで管理すると、以下のようなメリットがあります。
- オンボーディングの進捗を新規メンバー・既存メンバーが視覚的にすぐ確認できる
ToDoやDoneなどのステータスや各カードのチェックボックスで管理できます
- 各カードの編集や並び替えが簡単
- スライドやドキュメントツールよりもメンテしやすいと思います
- 既存のタスクや必要事項を見える化できる
- 意外と忘れているタスクやTODOがあったりするものです
- Trelloではカンバンの各カードにラベルを付与できるので、そのラベルを使って、そのカードのタスクは誰が実行すべきなのかがわかる
- 例えば
全員、iOSエンジニア、Androidエンジニア、あとは業務委託などのカテゴリに分けています
- 例えば
上記は先ほど自分が作ったカードのサンプルですが、各カードにはそのカードでやるべきことや読むべきドキュメントのURLなどがリストで記載してあって、チェックボックスで進捗を管理できるようになっています。
また権限をもらう必要があるものに関しては、メンション先を記載しているので、誰に権限付与を依頼すればいいかも明確にしています。
ここで工夫しているのは、メンション先をグループメンションにしていることです。
もちろんiOSエンジニア全員などはグループメンションを使用するのは当然ですが、マネージャーの場合でも、個人名を書いてしまった場合、その人が退職したり、社内のポジション変更で変わってしまった場合にいちいちここの書き換えが必要になってしまうので、1人しか所属していなくてもグループメンションにしておくことで、Slackでの設定変更のみで済むようにしていたので、メンテコストを下げることができました。
自分がSHOWROOM株式会社のアプリのチームにいたときはこのようなオンボーディングを整備して、このカードに全てのタスクと情報やアクションを記載していました。
基本的にはこれを見れば、基本的な情報やセットアップ、アクションは全てできる！というところまで整備していました。
上記のキャプチャに映っていないところでいうと、サービスの概要のドキュメントを読んだり、検証用のアカウントのセットアップ、試しにPRを出してみるなども記載してあります。
実際にこの運用を始めて、以下のような変化がありました
- 新メンバーの初期セットアップに、既存メンバーがサポートする工数が大きく減った
- 既存メンバーも、このオンボーディングを通してドキュメントをメンテしようとするようになった
- 何かわからないことがあった時に、オンボーディングのドキュメントから探すことができるようになった
- 基本全ての情報がまとまっているので、Wiki的な使い方もできるようになりました
このようなオンボーディングの内容をまとめるのは最初は大変ですが、最初に気合を入れて作ってしまえば、その後はとても楽になります。
また重要なことは、このオンボーディングのドキュメントは、他のドキュメントと同様に、完成することはなく、メンテナンスする必要があるので、新メンバー含めて、メンバー全員でブラッシュアップしていくことです。
そうゆう意味では、このカードの中に、このオンボーディングのドキュメントを改善するってタスクを入れておいてもいいかもしれません。
ちなみにこのオンボーディングと同様に、オフボーディングも整備していて、アカウントの権限取り消しなどを漏れなくできるように、全てリスト化し、メンバーの退職後のトラブル発生リスクが少なくなるようにしています。
よくみるスライドにまとめる方法だと、
- 各スライドのスペースに内容を調整するのが大変
- どの内容を誰がやるのかが書きにくい(基本全員やるものなら、問題ない)
- 新メンバーや既存メンバーがその進捗を整理・確認しにくい
などの課題があります。
(そもそも自分はスライドという形式があまり好きではないので。。笑)
新メンバーと既存メンバーでコミュニケーションを取れるようにする(信頼関係の構築)
これはチームにもよると思いますが、なかなか難しいことだと思います
新メンバーの性格などにもよるし、最近はリモートワークも増えて、メンバー間のコミュニケーションの取り方に困っていることも多いかもしれません。
ここではオンボーディングの話をしているので、その文脈でオンボーディングの中でどのように既存メンバーと新規メンバーのコミュニケーションを行なっていくかを、チームメンバーなどに依存せず、仕組みとしてできそうなことを書いていこうかと思います。
基本的には仕組みやタスクとして落とし込むことで、メンバーによってはやりづらい、もしくは忙しいからできないといったことを防止しやすくなると思います
ここでは以下の軸で考えます
- メンバー間のコミュニケーションをする機会を作る
- 新規メンバーが、既存メンバーやチームに関する情報にアクセスしやすくする
①の「メンバー間のコミュニケーションをする機会を作る」については、当たり前かもですが、
- メンバー間の自己紹介の時間を設ける
- MTGや定例で雑談や質疑応答、困っていること、気になっていることを気軽に聞ける時間を設ける
- 入社後にランチ会など、カジュアルトークできる場を設定する
- 定期的な1on1の実施やメンター制度の導入
- 業務の作業と関係ない、アクティビティなどの実施
- 雑談用のチャンネルを作る
辺りは仕組みとして導入しやすいかもしれません。
新しい環境で、気になることやわからないことも多い一方で、気軽に質問したりすることはしにくいので、聞きやすい環境や雰囲気を作りつつ、雑談や質問タイムなどをしっかり確保することが大事です。
新メンバーが困り事や悩みを抱えたままにならないように、相談相手や体制をしっかり整えましょう！
また仕組みとしては落とし込むことは難しいですが、自分の場合は新メンバーが所属チームメンバー以外にも、よく仕事を一緒にすることになりそうな人には、コミュニーケーションができるようにする場を調整したりしたので、そのような意識をできる限りメンバーで持っておくことも大事かもしれません。
②の「新規メンバーが、既存メンバーやチームに関する情報にアクセスしやすくする」に関しても基本的なことですが、
- チャットの雑談などのやりとりもできる限りにオープンチャンネルで行い、透明性を高くして、誰でも見れるようにしておく
- メンバーの情報や自己紹介の資料など、既存メンバーの情報は、チャットのチャンネルやドキュメントなど、わかりやすく、かつアクセスしやすいところに配置しておく
ここに関しては、会社やチームによってやり方や事情が大きく異なるので、色々な事例を調べてみると、面白いと思います(例えば..)
他社の色々な事例もしれて、おもしろいです！
最初のメインタスクの準備
最後に実際に行うタスクについてです。
エンジニアの場合は、セットアップが終わった後の最初の開発タスクなどです。
入社前にある程度新メンバーがどのようなことをやりたいか、実際の業務でどのようなことをするか、やってほしいかなど、期待値ややりたいことのすり合わせはしていると思いますが、実際にその新メンバーがどれくらいのパフォーマンスを出せるかなど、不透明な部分も多いです。
なので個人的には以下のようなタスクを準備しておくのがいいと思います！
- 仮にうまくタスクが進められなくても、事業やサービスに大きな影響が出ないタスク
- そのメンバーのロールの中心業務を一通りできるような大きい単位のタスク
- タスクのメインの担当者として、責任を持って進められるタスク
①は先ほど書いたように、新メンバーの正確なスキルや実力がわからないので、あまり重要度が高すぎず、うまく進められなくても、他のメンバーがサポートに入ることで建て直せるようなものです。
②はそのメンバーが早く自立的に働くことができるように、また主要なタスクの進め方を把握できるように、大きい単位のタスクを割り当てるのがいいです。
例えばアプリ開発の場合、小さなバグ修正などの散発的なタスクをサブタスク的に割り当てるのはいいですが、メインのタスクは仕様整理・開発→リリースまでを一通り経験できて、その中で発生するタスクやツールの使い方、他のチームやメンバーとのコミュニーケーションに慣れることが重要かと思います。
散発的なタスクのみを行なっていると、どうしても業務の全体感を掴みにくいと思います。
個人的には1番大事なのは③だと思っていて、メインの担当者として割り当てることで、「自分がやらないと！」という意識が働いて、より自発的にタスクを進めるようになります。
もちろん他のメンバーがサポートすることは大前提です。
誰かメインでやってくれて、自分はサポートって立場だと、どうしても気が緩んで、自発的に進めるモチベーションは下がってしまうものです笑
いい意味で新メンバーを追い込んで、モチベーションを上げてもらうには、自分ごとにしてもらうことが一番効果的です。
まとめ
こんな感じで、オンボーディングって大事だよねってことを書いてきました。
タイトルに書いた通り、オンボーディングは入社・チームジョイン後に一番最初に行うもので、新メンバーの会社・チームへの第一印象を決める非常に重要なステップです。
ここに力を入れていて、新メンバーのサポートができている場合は、とても好印象をもって、モチベーション高く仕事を始められる一方、その逆の場合は非常にマイナスな印象を持って、エンゲージメントが低いまま仕事をすることになりかねません。
もちろん既存メンバーは仕事が忙しいし、コストもかかりますが、そこは新メンバーの立場にたって、丁寧なオンボーディングを行うことが、中長期的にはチームや会社のためになります。
せっかく大変な苦労をして採用した人が早期に退職してしまうということを防ぐためにも、採用しっぱなしなどにならず、採用→オンボーディングまでを丁寧に進めるように社内で調整することが重要だと感じました。
もし自社や自チームではこのような工夫をしているなどがあれば、教えていただけると嬉しいです！
