以前 オンボーディングプラクティスの紹介記事 を紹介しました。 しかし、その記事を読まれた方の中には「ちょっと内容が綺麗すぎない？本当？」と感じた方もいらっしゃるかと思います！
そこで今回の記事では、新入社員が実際にオンボーディングを受けてみて、本当に効果的なプラクティスであったのかを実証・紹介しようと思います！
「ふーん「HRMOS」おもしろそうじゃん」と思ったそこの貴方、ぜひとも カジュアル面談 にどうぞ〜。
君の名は？
まずオンボーディングを実際に受けてみた執筆者の背景を紹介します。
- 社会人歴4年目のソフトウェアエンジニア
- 2021年ビズリーチにソフトウェアエンジニアとして入社
- 前職は医療系 IT 企業に所属
- Rails や React を主に使っていた
前職とは事業規模や業種、技術スタックも異なるため、完全に無知でジョインしています。 そのような状態でオンボーディングを受けてみました。
オンボーディングを成功させるはずの7つのプラクティスとその実証
さて、ここからは 3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス を実証していこうと思います！
実証1. 既存メンバーを広く巻き込む
カリキュラムとして30程度のコンテンツを作成しています。それぞれは0.5〜2時間程度の講座ないしは自習コンテンツになっています。これらのコンテンツは技術的なものから業務的なものまで含み、組織をまたいだ十数人が講師や作成に関わっています。
現場でその業務・タスクを触っている人が実際にドキュメントを作って講座を開いてくれたので、彼らの生の声が聞けました。
現場で業務に携わっている専門家なので、ドキュメントも現場に適した形でしたし、疑問にも明確な回答を返してくれたのでスピード感もありました。
PR 運用フローの講座で「話は変わるんだけど、インフラ構成ってどうなってるの？」と聞いたとしても、現場の方はもちろん詳しいので的確にインフラ構成図を持ってきて各コンポーネントについての説明もしてくれます。 このようにドキュメントも現場の状態に即したものでしたし、疑問を持ったらすぐに解決できる仕組みになっていました。
実証2. 事務局とメンターが重層的に支援する
実務で近い位置にいる人（通常は同一チームの人）をメンターとして設定しています。事務局が俯瞰的にサポートする一方で、メンターは受講者と同じ目線に立ってサポートします。
メンターがいることで「誰に聞いていいのかわからない」ということが、まずありませんでした。
とりあえず事務局・メンターに聞けばいいやという安心感もありましたね。 また、同チームの人がメンターについてくれると、着手中の業務とオンボーディングの調整がしやすいので、業務と並列実行できるという点もありがたかったです。
実証3. 柔軟に業務に編み込めるPUSH/PULL方式
受講者自らが日程を調整してもらうPULL方式。初期の一部のコンテンツのみは事務局から予定をアレンジするPUSH方式。初期のPUSHと中盤以降のPULLを併用することで確実にかつ柔軟にオンボーディングをこなしていけるようにしています。
すべての予定が事前に組まれているわけじゃない、というのが僕には合っていました。
自分でペースを決めていいので、隙間時間でちょいちょい進めたり、気が向かないコンテンツはその時はやらなくていいのが素晴らしかったです。 また PUSH 型のコンテンツも定期的にあるため、一人でずーっとオンボーディング作業を進めなきゃいけないということもなく、うまーくバランスが取れているなと感じました。
しかし僕などは TODO タスクはさっさと片付けてしまいたい人間だったので、短期間に色々詰め込みすぎてしまった感は否めませんでした😞 スケジュールをうまく調整する技能は必要そうです。
実証4. 歴史・文化などを含め"土地勘“を身につける
歴史としてこの変遷を紹介することで、見知らぬ単語や状況に遭遇したときに勘を働かせられるように支援しています。昔からのメンバーですら薄れてしまう過去の記憶を残していくことは単なる懐古趣味ではなく、実質的な効果があるといえます。
なぜプロジェクトがこの形になっているのかや、その単語がどういうニュアンスで使われているのかがわかって、コミュニケーションが取りやすくなりました。
例えば、プロジェクトの構成が一見不思議になっている理由（もちろん妥当な理由があります）がわかったり、survey, hrx など「HRMOS」特有の単語が意味する機能や、個別の module の概要について理解できました。
ただ、「HRMOS」はそこそこの規模のプロダクトなので歴史もありますし、独自の文化もあります。 それらをすべて、入社直後の短期間で把握するのは無理なので、今後のためにあくまで頭の片隅に知識を入れておくくらいの温度感でいいのかなーという印象でした。
実証5. 2次利用3次利用を見据えたコンテンツづくり
設計ガイドライン、環境構築のREADME、性能向上のTIPSなど、口頭伝承されがちであったり更新が滞りがちなものは多々ありますが、オンボーディングでの利用が意識されることで優先度が上がりやすくなります。
オンボーディングのたびに、それらのドキュメントが更新されてレベルアップしているのが履歴からわかりました。
「HRMOS」では主に Confluence でドキュメントが管理されています。 オンボーディング受講者からの「この Confluence の内容がわかりづらかった」という意見だったり「この手順だと動かなかった」といったフィードバックをもとにドキュメントを改善するので、陳腐化しない良い仕組みだなと感じます。
また Confluence の編集権限が誰にでもあるので、それらのドキュメントは新入社員でも本当に気軽に更新できるのがよいなーという印象です。 とはいえ心理的なハードルは（新入社員なら尚更）高いので、ハードルを下げるための仕組みはもう少し欲しいかなーと感じました。
実証6. 事務局が中心となって振り返り、次に繋げる
多人数が関わるため毎回のオンボーディングで大小の非効率や不手際は発生するものですが、事務局が主体的に集約し次につなげていくことで少しずつ構成と運用が改善されてきました。
オンボーディング系のもろもろを積極的にフォローしてくれる存在で、何度もお世話になりました。
オンボーディング全体を統括してくれる存在として「事務局」なるものがあります。事務局というとお硬いですが、実際には部署内に担当のメンバー (エンジニア) がいるだけです。 オンボーディングが終わった後にもヒアリングの時間を設けたり、資料のアップデートを掛けたりの取りまとめをしてくれるので、次のニューカマーがくるときには随所がさらにブラッシュアップされていました。
実証7. 現場主導であるからこその鮮度
過去の受講者はその後、自発的にオンボーディングをサポートしています。受講者がオンボーディングの効果を実感してくれるからこそ、多少の労力を払ってでもコンテンツを作ってくれたり、講師を買って出てくれるというポジティブなサイクルが回っており、現在までオンボーディングが続いてきた最も大きな理由となっています。
たしかに現場の温度感もわかりやすいですし、輪の中に入りやすかったです。
先述の通り現場のメンバーがドキュメントを更新してくれたり、フローを整備してくれるからこその結果かなと思います。 これからは自分も積極的にオンボーディングの講師を担当したいですね。
とはいえ、良いオンボーディングコンテンツはどうしたら作れるのか、コンテンツとして必要なものを選別するノウハウは、まだまだ貯めていく必要がありそうです。
リモートでオンボーディングを成功させるはずのプラス3つのプラクティスとその実証
ここからもオンボーディングプラクティスの記事と対応した内容ですが、主にリモートワークに着目したものになります。
実証1+. 分単位のスケジューリングでウェルカム
会社全体の数日間のオリエンテーションの最中からコンタクトを開始し、配属のタイミングを見計らってオンボーディングのコンテンツをスケジュールしています。 まさに分単位のスケジューリングでオンボーディングの予定を組みます。
宙ぶらりんになる時間が少ないのはありがたかったです。
「この時間にはこのオンボーディングをするよ」という Push 型コンテンツが数多くあるおかげですね。 ジョイン当初は手持ち無沙汰の時になにすればいいかわからず右往左往しがちだと思うのですが、それがないというだけで安心感がありますね。
また先述のように Pull 型コンテンツもあるので、空いた時間を分単位で自分で制御できるので、気軽さもありました。
実証2+. 論理世界こそ神は細部に宿る
各種のアカウント発行、セキュリティグループ追加、などは早期に行いました。
アカウント発行がされておらず AWS/GitHub に入れない……とかは全然なかったですね。
おかげさまですぐに開発に着手できました！
受講者に気を配ってもらいたいところについてオンボーディングでの言及をしました。アバター統一、マイクやスピーカーの選び方、などです。
マイクの品質が悪かったりすると認知負荷が高くなる気が個人的にはしてるんですが、みなさん音質をすごく気にしてらっしゃって無駄な負荷がなくて快適でした。
マイクやスピーカー、カメラ、いかに"リアル"以上にコミュニケーションを滑らかにするかというドキュメントまであるくらいでした。
実証3+. 論理的な居場所を醸成する
月ごと（同月入社が複数人の場合もあります）にSlackの専用チャネルを作り、ちょっとした質問や感想などのやりとりのために受講者が自由に使えるようにしています。
気軽に発言できたのはありがたかったです。
開発から雑談まで幅広いチャンネルがいっぱいあったんですが、とりあえず困ったらこのチャンネルで相談してね！という専用チャンネルがあるのはよかったです。
プラクティスの実証結果
めちゃよかったです。
- オンボーディングを受けつつ業務もこなしたけど、2週間程度で業務の軌道に乗れた
- オンボーディング後は PR も出しまくれるようになった
- 改善提案だけでなくダジャレなども気軽に発言できる状態になった
残念ながら（?）僕の中で重大な制度・運用面でのバグを見つけることができず…….。 とはいえ、もちろん改善ポイントもいくつかありました。
業務と並行して進めてしまえるので、忙しくなってしまうケースもある
業務の隙間に30分の講習会をいれまくると忙しくなるケースもあったので、匙加減は大事だなーという感想です。 ご利用は計画的に。
「オンボーディングは N 日以内にクリア必須！」というルールは全くないんですが、僕はシュッと終わらせたかったので詰め込みで受講してました。 しかし「講習はリスケ願います〜」と担当の方にお伝えすれば全然リスケできたので、とても困るというケースには遭遇しづらかったです！
知識のドキュメント化が進んでいるがゆえに、ドキュメントが非常に多く見つけ出しづらい
ドキュメントはめちゃくちゃ多いです。開発の Tips から運用ルールなどほとんどがドキュメント化されています。 その状態で本当に欲しい情報にアクセスするのは少し大変かなーという印象でした。
また、「HRMOS」ではドキュメント管理ツールとして Confluence, Miro, Figma などを活用しています。 それぞれ用途が違うのでツールの種類が多いのは全く問題ないのですが「あれ、オンボーディングで見たあの資料どこにあったかな」と、ツール間で迷子になるケースに遭遇する確率が高いように思えました。
多くなってしまったドキュメントを定期的に一つの箇所にまとめたりすることで、ドキュメントの見つけ出しにくさも解消していくといいですね。
開発が日進月歩なので、ドキュメントが古くなりがち
オンボーディングの度に参照されるドキュメントは更新されますが、参照頻度が低いモノは更新が漏れがちです。
タレントマネジメントという領域は非常に複雑なドメインです。 当初の仮説が開発中に否定されるということも珍しくなく、最初に仕様が後々変更になる場合が多々あります。 それらがまとまったドキュメントも定期的に更新をかけることで、誰がいつ見ても正しい理解が得られるようになっているとさらに嬉しいですね。
まとめ
「HRMOS」のオンボーディングを実際にリモートで受けて、過去の記事の実証をしてみました！
リモートオンボーディングを受けた後もほとんどのメンバーはまだ実際に会ったことがないのですが、何も障害なく業務が進められています。 改善点はたしかにありましたが、継続的に改善される仕組みになっていて、非常にいい感じでした！
コロナ禍においてリモートワークが主流になっているので（※2022年2月現在）、リモートオンボーディングをいかに設計するかというのは非常に重要な課題だと思います。 でも「オンボーディングって具体的にどうすればいいのかわからない」「どう改善したらよくなるんだろう」といった悩みをもつ開発チームの方に、今回の事例がお役に立てば嬉しいです！
詳しいお話はぜひ カジュアル面談 で！
