キャリア/中途入社者のオンボーディングをゼロから設計し直した話 - Cybozu Inside Out

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。

こんにちは。開発本部でオンボーディングを担当している @karihei です。この連載ではサイボウズの開発本部で行われているオンボーディングを全3回に分けてご紹介する予定です。

連載の目次は以下のとおりです。

【キャリア/中途入社】キャリアオンボーディング設計してみた編
【新人研修】参加してみた編
【新人研修】設計してみた編

今回はキャリア/中途入社者（以下キャリア入社）向けに行われているオンボーディングについて、この1年で改善した取り組みをご紹介したいと思います！

　キャリア入社あるある

キャリア入社者の特有の声として「早く現場に慣れたい」というものがよく挙げられます。キャリア入社の性質上、期待されていることが明確な上、早く貢献しなくてはという焦りの気持ちが強くなりがちです。

実際に直近2〜3年にキャリア入社した方にヒアリングしたところ、他にもこんな声が見られました。

「どこに何があるか分からず、聞くタイミングに迷った」
「チームの文化や暗黙のルールを把握するのに時間がかかった」
「入社直後は色んな情報を覚えなくてはならず、インプット過多になりがちだった」

これらの声をふまえ、オンボーディングの仕組みを見直すことにしました。

まずは現状の整理から

改善前のオンボーディングは以下のような状態でした。

ここで問題になってくるのが以下の3点でした。

チームによってオンボーディングの内容や密度が異なる
同じテーマだけど別々で資料を用意してしまっている（車輪の再発明になってしまっている）
資料がどんどん古くなり、メンテコストがかかる

チームによってオンボーディングの内容/密度が異なる

頻繁にメンバーを受け入れていて、オンボーディングに慣れているチームだとそれだけ資料も充実していきます。それとは対称的にオンボーディングに慣れていないチームだと資料の密度にも差が出てきてしまいます。その結果AさんとBさんの間で知識の差ができてしまう、といったことが発生してしまう恐れがありました。

車輪の再発明になってしまっている / メンテコストがかかる

本来ならば本部全体を通して知っておいたほうが良い知識や文化を、各々のチームのオンボーディング内で全く同じ内容の資料を作ってしまう、といった二度手間が発生してしまっていました。また、作った資料（例えば中期戦略を説明した資料など）は毎年アップデートされるため、そのたびに内容を更新しなくてはいけないというメンテナンスのコストも発生してしまいます。

やったことその①：まずは資料の共通化

各チームへヒアリングを行い、共通化できそうな資料はすべて本部のオンボーディングとして共通資料としてまとめることにしました。まとめた資料はkintoneでデータベース化し、どのチームから見ても同じ資料を参照できるようにしました。資料の内容に更新があった場合もこちらの共通資料を更新するだけで済むのでメンテコストも抑えることができます。

さらに、新卒入社向けの研修資料とも共通化を行い、新卒⇔キャリア間での知識差も埋めるようにしました。

やったことその②：キャリア入社者専用の研修期間を設ける

今までは入社してすぐにチームにジョインし、チーム内オンボーディングを受けてもらっていましたが、その前段階として本部オンボーディングを新設し、独立して受けてもらうように変更しました。各オンボーディングを直列的に実施することで、入社1〜2週間はインプット過多になりがちなキャリア入社あるあるを軽減し、情報を整理しながらオンボーディングを受けてもらえるように設計しました。

やったことその③：体系的に学べるようeラーニング化

共通化した資料を順序立てて体系的に学べるように、kintoneを使ってeラーニング化しました。

以下は実際に使われているオンボーディングプランの一部です。

これらを順番に視聴することで知識のベースを揃えていきます。（資料は動画やPDFなど様々です）

また、資料を共通化することの弊害として、人によっては前職の経験などで学習する必要のない資料も出てくるかと思いますが、こちらは事前に受け入れ担当者が必修/選択を選べるようにし、個人ごとにオンボーディングプランを設計できるようにしました。

改善を進めていくにあたって

この改善を進める中で私たちが意識していたのは「共通化すべきものと、チームに委ねるべきものを分ける」ということです。

すべてを本部側で共通化してしまうと、各チームの持つ独自の文化や業務の特性が失われてしまいます。逆に、すべてをチームに委ねてしまうと、冒頭で挙げたような密度やベースラインのズレが生まれてしまう。だからこそ、「開発本部として全員が知っておくべき土台の部分」と「チームごとに個別に伝えるべき実務の部分」を明確に切り分け、前者を共通化・仕組み化することに注意を払いました。