入社初日のオンボーディングフローを作った話
Linc'wellへ入社して1年半ほど経ち、社員のエンジニアだけでも2倍以上の人数になりました。入社当初は現開発部長が一人で社員、インターン、業務委託のオンボーディングを行っていましたが、人数が増えるにつれ負担が大きくなってきました。
そんなどこの会社でも起こりうる課題に対して、弊社でやってみたことを紹介したいと思います!
オンボーディングの課題
主に以下のような課題がありました。組織が小さいうちはまったく問題ならないことではありますが、拡大に伴い課題となってきました。
- オンボーディングをできる人が限られている
- 招待が必要なツールやサービスが多く、招待が漏れてしまうことがある
- ドキュメントの保守ができていない
やってみたこと
オンボーディングをできる人が限られている
オンボーディングは受けたけど、そもそもオンボーディングって何を準備して何をするんだっけ?という状態でした。
そこで、これまでのオンボーディング時の資料をもとに社員・インターン・業務委託のそれぞれのオンボーディングテンプレーを作成し、テンプレートの中にTODOを記載することでオンボーディング担当者が準備することを明確にしました。
以下のような内容がテンプレートには記載されています。
- 事前対応事項
- 各ツールへの招待
- 会議体
- 毎日やること
- プロダクトの頭出し
- この後やってほしいこと
- プチ歓迎会の日程設定(Discord上で気軽に参加できる歓迎会を開催しています)
これにより、テンプレートのTODOを消化していけば誰でもオンボーディングを行うことができるようになりました。
招待が必要なツールやサービスが多く、招待が漏れてしまうことがある
チーム毎に招待が必要なツールのリスト化を行い、Slackのワークフローの中で新メンバーの招待を進められるようにしました。最初はアカウント招待のみだったのですが、「これも入社時に設定してもらった方がいいよね?」という内容が増え、今ではこんな感じになっています。
リモート組織だと関わりが少ないメンバーに認知してもらう機会が少ないため、Slackの全社向けのチャンネルに自己紹介の投稿もお願いしています。
ドキュメントの保守ができない
上記2つの取り組みである程度改善はできたものの、今度はドキュメントを最新化できていなかったり、分かりづらい記述がそのままになっているという課題が出てきました。運用に慣れてくるとちょっとした不便や違和感を感じなくなってしまい、新メンバーに指摘されてはじめて気がつくことが多くあります。よね?
その課題の解決のためにオンボーディングの保守担当を決め、新しい人が入社したらその担当を引き継ぎ、記憶が新しいうちに違和感に感じた箇所の修正やフローの改善を行なっていただくようにしました。
新鮮な気持ちのうちに改善を積み重ねていただけるので、ドキュメントの質が上がっていると感じています。
取り組みの成果と今後
現在では各プロダクトチーム毎に受け入れを行うようになり、負荷分散は達成されたと言えそうです。また1年前と比べても必要な情報を適切に届けらるようになったと思います。
一方で上記の取り組みは、入社初日の受け入れをスムーズにすることが中心で、入社~活躍していただくまでに必要なドメイン知識や技術のキャッチアップのための仕組みは整えきれていないのが現状です。今後は医療という複雑な領域でよりスムーズに活躍していただける仕組み作りをしていきたいと思います!
Discussion