中途入社のチームオンボーディング設計まとめ（3ヶ月連続受け入れを通して）

LITALICOに中途入社して早2年目の @tanakashi です。LITALICOアドベントカレンダーのために始めたQiita投稿も、とうとう3記事めになりました😳

今年の頭からアシスタントマネージャーに昇格したのですが、その際に稀有な経験をし、社内に共有するついでにアドベントカレンダーにしてしまおう〜！ということで、執筆しております。

稀有な経験

3ヶ月連続で、中途入社の社員を1人ずつ連続オンボーディングすることになりました！
状況は下記のような感じ。

• 今までいたマネージャー・メンバーは異動などの事情で、最終的に残るのは自分と今回お迎えする新入社員3名（自分以外は全員新人になる）
• 最後に入社する1名を迎えるまで、自分の担当していた開発業務も継続
• プラス、事業を横断する開発・複雑な実装に関しての技術面も自分で見る

圧倒的に効率化しないと、、何も回らなくなる、予感…………😨！！！！！

逆に短期間で連続受け入れをする機会は、人事系の仕事に就いていない限り早々ない体験かなと思い、今回ちゃんと整えられれば別グループにも展開できるぞ〜🎉のつもりでガシガシやりました。

組織的な前提

書いてる人の当時の状況

• 今年の4月からアシスタントマネージャーに昇格（それまでは同部署の1プレイヤー）
• マネージメント業は初経験のひよこ🐥

所属グループの状況

組織図

エンジニアリング統括部から生えた部署の内、エンジニアが集結したグループ

実業務時の組織連携

• 基本的には事業単位で動くため、メインで関わるのは他グループのディレクター/デザイナーであり、他部署の事業部メンバーやマーケターになる。
• 1事業に対し、割り当てられるエンジニアは基本1名。
• 同部署内のエンジニアは自チームのみのため、開発面での知識・ノウハウ共有は自チーム内で横断的に回していく必要がある。

自チームにおける業務

前提

• 技術的に大きく難しい依頼が来ることはあまりない
  • 最終的な設計を考えることは必要だが、入社してすぐに臨むことはない
• 短い期間で開発〜リリースまで回す施策が多い
• 1人で案件についてコミュニケーションをとり、マネージャー/ディレクター/事業部・マーケとこまめに会話をしていく必要がある

ジョイン直後の担当エンジニアとして求められること

• ❌難易度の高い開発を1人でガツガツこなす
• ⭕自分が取り扱うシステムの全体感や、かかわる関係者を把握し、必要に応じて他者と連携しながら、開発をこまめに回していく

オンボーディング設計

オンボーディングのゴール

理想状態

• 1人でリリース工程まで行える状態にする
• 設計・開発部分について、分からないことがあったら助けを求められる
• 担当事業の開発窓口として振る舞える

その状態に導くために気を付けたこと

• まずは構成・開発フローを含めた全体感を理解してもらう
• どういった時に、誰に頼れば良いかを明示し、1on1などで繋いでおく
• オンボーディング期間中は窓口業務も含めて必ず他のひとがフォローに入れる状態にする

入社後1ヶ月の動き イメージ感

• 1週：本部の研修
  • 進捗管理程度
  • 進むときに手が止まることはないか？を確認
• 2週：自グループの研修
  • 研修内容
    • 全体感の講義
    • 業務に直でかかわるメイン知識
    • 環境構築
  • 研修時に心がけてほしいことを伝える
    • 基本聞くだけでよい、理解は実務を通して覚える
    • 忘れても大丈夫、大事なのはなんとなくこういうことだ、というイメージを持ってもらう
    • inputだけだと疲れるから、1人で手を動かすだけの時間を設ける
• 3週〜4週：実践
  • メインで動いてもらう
    • 他メンバーはサポートで入る程度。
  • 最初はペアプロで徐々に抜けていく、基本自由に動いてもらう
    • 危ないところだけサポートするイメージ
    • だんだん相手発信があればサポートするよ、にする
    • コードレビューだけ最初は丁寧に行う
  • 1行のコード修正からジョイン
    • まず「必ず成功する」体験をさせる
    • その後に裁量を増やしていく

用意するオンボーディング資料

前提

オンボーディング対象者の想定

• 新入社員（会社自体の変更）
• 社内の別部署から訪れるメンバー（社内異動）
• 担当事業を変更することになったメンバー（チーム内の担当変え）

※入社だけではなく、それ以外の「新しくその事業の開発に触れるひと」を対象に資料を設計

資料の役割

• オンボーディングを受ける側
  • オンボーディング期間中に必要となる情報を、その資料だけ見て把握できる
    • 「迷ったらここを見る」で完結する状態
• オンボーディングする側
  • オンボーディング準備・実施している際の進行状況を把握できる
  • オンボーディング時の関係者を把握できる

注意

• オンボーディングに使用しない情報は別に置く（迷わせることがあるため）
  • オンボーディングには関係ないけど「時間がある時に読んでほしい」といった情報は別にまとめる
• あくまでオンボーディングに関するもののみを集約する

作成した資料(一部抜粋)

00. 全体像

• 入社後〜1ヶ月のオンボーディング期間
  • 週ごとにどういったことを行うか目安を記載
  • また、1ヶ月後にどういった状態になるかも記載
• このシートの役割、シート内にある情報についての説明
  

01. インプット一覧

• 基本的にMTGを通してインプットしていく内容を記載
  • MTGせずに「各自で読んでおいてね」の資料は、別途wikiなどに用意している。オンボーディング期間中に実施しないと判断しているので、ここには記載しない。
• 引き継ぎ時のゴールなども設定し、他のオンボーディング対応者にもそれを見ればオンボーディングされている側がどういった状況である・どういう状態に連れて行くかを明示。
• オンボーディングする側の管理進捗などは、グループ化して折り畳めるようにする。オンボーディングされる側が、最終的に自分に必要な情報に集中できるようにする。
  

02. ツール類 〜 05. 連絡ツール

基本的にインプット一覧と同じノリで作成。シートごとの特徴は下記の通り。

• 02.ツールまわり
  • 進捗管理は、入社前に準備できること／入社後に準備できること　と、フェーズによってタスクが違うので、セルを分ける。
  • また、本人がやること／MG・担当エンジニア・担当ディレクターがやることなど、ものによって関係者が違ってくるため、「誰が」「何をする」まで記載。
• 03.関係メンバー
  • 入社後1on1などがあれば「予定を設定したか」「いつやるか」などもまとめていた。
  • また、いろんなメンバーがいるため、「主な連絡ルート」も記載。
• 04.主な会議、 05.連絡ツール
  • カレンダー／Slackチャンネル招待が漏れないように、招待したかのチェックもここで管理。

（※内容をぼかすのが難しかったのでスクショは省略）

その他工夫

基本的な方針として「最低限これだけあれば動ける」レベルに、インプットの情報を絞る。
また、そのインプットの内容（カテゴリ・質・量）が、3人全員大体同じくらいであることを心がける。

• 基本、どの事業にジョインさせる際も情報量を揃える。
  • 「共通」「事業固有の概要」とカテゴリを分け、リポジトリのwikiも全事業でカテゴリを共通化。「このページを説明すれば良い」という状態にする。
  • 事業ごとの差分に関しての細かい説明は、オンボーディング対象外として「実務で触れる機会があれば教える」とする。
• 業務においてマーケティング知識も必要になる部分はあるが、まずは開発に集中してほしいため、今回のオンボーディングからは削ぐ。

ここ以外にも「選択と集中！」を心がけて、網羅性があり全体感が分かれば良い、程度におさえて資料を作成・研修していきました。

フォローをする際の心構え・大事にしたこと

ひとことで言えば「心理的安全性の確保」。

• 成功体験を重ねさせる
  • 大きなことからの挑戦はさせない。まずは「できる」を積み重ねる。
  • その上で、良い形の失敗体験をさせるために、小さな失敗は積極的にさせる。
• DMや質問は、他人と会議をしている時以外では最優先で返す。
  • 基本は「ありがとうございます！」「助かりました！！」など文章で伝える。
  • 余裕がなければリアクションだけでも返す。
• 「分からないことは聞いてね」ではなく、「不安なら・戸惑うことがあったら聞いてね」にする。

環境が変われば今までのようにパフォーマンスを発揮できないのは当然。
むしろそのパフォーマンスを引き出すためにオンボーディングを行うので、小さな不安要素は積極的に取り除きにかかる。その上で成功ばかりはさせずに、小さく失敗させて、すぐフォローする。

※めちゃくちゃ地味だけど、これによって信頼関係も構築されるので、オンボーディングを終えた後もコミュニケーションが円滑になっている印象。

オンボーディングを終えての感想

• 大変だったこと
  • 「ひとが一度にインプットできる情報量って！？なに！！？」と慌てふためいていた。これは3ヶ月間でなんとなく見えてきてよかった。一番最初の方にはたくさん情報詰め込みすぎたので大変失礼いたしました（反省）研修の設計ってめちゃくちゃ大変なんだなと思いました（小並感）
  • 設計した上で、それに対応する資料の整備が……🤤
  • 毎日1on1（2週間）は正直なかなかハードだった……。でもそのおかげで、いつ実践へ繋げるか？を把握しやすかったり、メンバーの個性を理解するのに役立った。でも大変だった（震）
  • 事業ごとに開発フローの差分が多く、現状を把握するために情報収集したりするのが苦労した。今後はこの差分をできる限り潰す。いらない差分はダイエット対象ですよ😠
• 有り難かったこと
  • 周囲のフォローがすごく有り難かった……。具体で業務を手伝ってもらうというよりは「大変そうだけど大丈夫？」と心配してもらったり、それ以外の業務に関して「ここは調整しておくね」などの声掛けがあったので、困った時に安心して頼れることができた。
  • 今が”非常事態”であることを上司が認識してくれていた。通常業務が回らない時も、それを理解した上での声掛けをしてもらっていた。圧倒的感謝。

甘く見ていたつもりはなかったけど、やっぱり新しい人の迎え入れって本当に大変なんだなと思ったし、私が入社した時も転職した時もいろんな人のサポートがあったんだな〜と痛感しました。ひとはひとに支えられ、そしてひとを支えるようになる。この循環を大事にしたい。

まとめ

チームオンボーディングは、それぞれのチームの状況や、固有の性質なども多く関わってくると思います。
全部が全部そのまま活かせるわけではないと思いますが、もし悩んでいる方がいらっしゃったら少しでもプラスになれば🙏🙏🙏

ここまでお目通しいただきありがとうございました！明日は @bashiiko さん、@t-konta さんの記事になります🤩