はじめに
この記事は「LITALICO Advent Calendar 2022」カレンダー2の8日目の記事です
株式会社LITALICOの @KakkiiiiKyg です。準管理職としてエンジニアリングマネージャーを務めています。本記事では、この1年間力を入れて取り組んできた私の所属するエンジニアグループのオンボーディングの取り組みについてお伝えできればと思います。
なぜこの1年間オンボーディングに力を入れたのか
直近弊社では、これまで以上にプロダクト開発力の強化のためエンジニア/PdM/デザイナー採用に力を入れています。
画像引用元：株式会社LITALICO 2023年3月期第2四半期決算説明資料
私の所属するエンジニアグループも2021/9月時点では6名体制でしたが、2022/12現在では13名のグループとなりました。そのため、グループの組織力強化のためには新しくご参画された方になるべく早く活躍していただくことが不可欠となり、オンボーディングの仕組みの強化を注力テーマとしました。
オンボーディングを強化していく上で大切にしていた考え
オンボーディングを強化していくための施策を立案していくに当たって、以下の3つの考えを特に大切にしていました。
誰でも仕事で成果を出すまでには段階を踏む必要がある
人が組織に加わって成果を出すまでには以下の過程があると言われています。
参考：中途入社者に活躍してもらう秘訣とは？中原教授に聞いた『中途入社者の早期戦力化』 | エン・ジャパン（en Japan）
どれだけ高いスキルや豊富な経験を持った方でも、組織に受け入れられなかったり（How to liveが確立されない）必要な情報/知識が共有されなかったり（How to learnが確立されない）すれば、仕事で成果を出すことはできません。すぐに成果を出せる方もこの段階をすっ飛ばしている訳ではなく他の人より早くこの段階を踏んでいるだけに過ぎません。
しかし往々にして中途でいらっしゃる方に対しては、周りもなんならその方自身も「即戦力でなければならない」と必要以上にハードルを上げてしまうことが多く「組織適応（How to live）」や「知識・スキル獲得（How to learn）」が十分にできる前に「成果創出（How to work）」のほうばかりを考えてしまいがちです。
新メンバーの方には「なるべく早く成果を出す」というスタンスは持っていただきつつも、受け入れ側としてまずは「How to live」や「How to learn」の土台を整えることが先だと考えます。
新メンバーを活躍させるのは既存メンバー全員の仕事である
先述した「仕事で成果を出すまでの過程」を基にすると、新メンバーの方に最初に必要となるのは組織適応（How to live）なので受け入れ側全員の新メンバーを歓迎する意思がまず必要で、エンジニアリングマネージャーだけが頑張ったり、一部のオンボーディング担当となったメンバーだけが頑張っても、オンボーディングは成功しないと言えるかと思います。中途でいらっしゃる方に対して「お手並み拝見」的なスタンスを持っているなどもってのほかです。
また、多くの中途の新メンバーの方がいらっしゃることで今までより様々なバックボーンを持った方が集まった多様な組織になり、既存メンバーの方にとってはこれまでの仕事のやり方を変えざるを得ない状況も出てきます。
その際により多くの協力が得られるよう、オンボーディングには既存のエンジニアメンバー全員、さらに一緒に仕事をすることになるPdMやデザイナーチームなども含めてなるべく多くの方を巻き込むようにしていました。
（ただこの点については、私のグループのメンバーや隣のPdM/デザイナーチームは皆一緒に働く仲間へのリスペクトとホスピタリティに溢れており、かつ自己変革を厭わない方ばかりで私のほうから特段大きな働きかけを行わなくても皆さん自主的に動いてくれました。本当に感謝です。）
オンボーディング強化は組織力強化の手段でしかない
オンボーディングの強化を進めた理由は、先述の通り組織拡大を見越した上での組織力強化の打ち手の1つとして行うべきと判断したからで、費用対効果を度外視した「ぼくのかんがえたさいきょうのオンボーディング」を作りたかったわけではありません。
そのため、オンボーディング実施のためにエンジニアリングマネージャーの自分が張り付きになったり、既存メンバーに大きすぎる負荷が掛かったりするなど、「オンボーディングは丁寧かもしれないがグループ全体で見たらアウトプットの質・量が落ちている」ということが起こらないように気をつけて仕組みを作っていきました。
たとえば、「オンボーディング担当メンバーをアサインしてその方がオンボーディング期間は新メンバーに対して付きっきりになる」というやり方は取りませんでした。私もそのようなオンボーディング担当になった経験が何度かありますが、その期間は通常の開発業務になかなか集中できず、大きくアウトプットを落としてしまっていました。
なるべく既存メンバー全員がオンボーディングチームとして負荷を分散しあいながら新メンバーの方をサポートしていくような方向になるように心掛けました。
実践していたオンボーディングの取り組み
新しい開発メンバーの受け入れの際に「仕事で成果を出すまでの過程」ごとに行っていたオンボーディングの実際の取り組みは以下になります。
How to live〜組織に適応する〜
まずは「組織適応（How to live）」を目指しました。もう少し目指す状態像をブレイクダウンすると、以下のように考えました。
- 組織から期待されていることが分かっている
- 組織内の上/横/斜めでそれぞれ相談できる人間関係を構築できている
まずは組織に対して、そして一緒に働く人に対して不信感なく信頼して働ける人間関係の構築が何よりも大切だと思っています。既存メンバー全員に協力してもらいながら以下の取り組みを進めていきました。
期待値の擦り合わせ
組織からどのようなことが期待されているのかが分からないと組織への不信感に繋がってしまうため、まずは新メンバーの方と期待値の擦り合わせを行います。弊社では全社共通の「等級と求める期待の指標」があるため、そちらを用いながらどのようなことを組織が期待しているのかをお伝えします。
またこの「新メンバーの成果の期待値の擦り合わせ」はto新メンバーの方自身だけでなく、toPdM/デザイナーやto既存のエンジニアメンバーにも行います。こちらの擦り合わせはどちらかというと過度に新メンバーの方の成果のハードルを上げすぎない期待値調整の意味合いが強く、「仕事で成果を出すまでの過程」の考え方を用いながら既存メンバーと同じように成果を出すのは段階を踏む必要があるということをしっかり伝えておきます。
人間関係の構築
人間関係構築の取っ掛かりとして、ウェルカムランチ会を開催しています。リモートで行うことが多いのですが、なるべく準備に時間が掛からないようにしつつも適度にアイスブレイクになるように、事前に新メンバーの方には簡単な自己紹介スライドを作成していただき、一部虫食い状態にした上で自己紹介をしながら周りの方が質問を通して虫食い部分を当てていくような簡単なレクを織り交ぜて行っています。
また、新メンバーの方には既存のエンジニアメンバー全員、同じプロジェクトで仕事をするPdM/デザイナー全員と1on1の機会を設けています。これも一緒に業務を行うための関係性の構築を目的としたもので、自己紹介から始まり、これまで取り組んできた仕事のことからプライベートなことまでお互いカジュアルに話すようにしています。
相談先の確立
新メンバーの方とは毎週or隔週でエンジニアリングマネージャーの私との1on1の時間を設定させていただいています（既存メンバーの方との1on1ももちろん行わせていただいています）。新メンバーの方については困りごとを気軽に相談していただけるようになるために関係性を構築しつつ、オンボーディングを進める中での疑問点やモヤモヤを感じた点を解消していただく場にしています。
また、オンボーディングプロセスそのものについて新メンバーの方から忌憚ないフィードバックをここで頂くようにしています。後述する取り組みの中にここで頂いたフィードバックから生まれたものがいくつもあります。
さらに、相談先は上横だけでなく斜めにも用意するために、エンジニア横串組織の方にご協力いただいて相談相手となっていただき1on1を定期的に実施しています（これは私の方では何もしておらずエンジニア横串組織のほうで動いていただいている取り組みになります。こういったサポートは大変ありがたいです。）。同グループのマネージャーやメンバーに対してだと言いにくいような悩みについて解消していただく場にしています。
How to learn〜知識・スキルを学ぶ〜
次に「知識・スキル獲得（How to learn）」を目指しました。これももう少し目指す状態像をブレイクダウンすると、以下のように考えました。
- 業務に最低限必要な知識がインプットできている
- 業務を遂行する上での疑問を解消する仕組みができている
ここはよく考えずに既存メンバーへサポートを依頼してしまうと、特定のメンバーにかなりの負荷を掛けてしまうところになるので、なるべく不要な負荷を減らしつつどうしようもないものはなるべく既存メンバー全員に負荷分散するような仕組みを整えていきました。
OJT
個人的な経験から、必要な知識のインプットは実際に案件をこなしながらが一番早いと思っています。バックログにあるちょっとしたUI変更レベルの案件に取り組みながらコードの理解を深めていただきつつ、手元でのコードの変更からデプロイまでの作業に慣れていただきます（私のグループはフルサイクル型で一日に大体3~5回前後の細かいサイクルで自分たちでデプロイまで行っていくような開発スタイルのグループです）。
豊富なご経験のあるミドル/シニアクラスの方でも、まずはちょっとしたUI変更レベルの案件からお渡ししています。人によって必要知識のインプットに掛かるスピードに違いはあっても仕事で成果を出すまでの段階は誰でも一つずつ踏む必要があると考えており、いきなり難易度の高い開発案件をアサインすることはしないようにしています。
最低限必要な知識のインプットのサポート
OJTを行いながら開発案件の合間に最低限必要な知識のインプットを行っていきます。すでに簡単な案件をいくつかこなしていただいているため、新メンバーの方も「プロダクトの全体像がまだ分かっていないから知りたい」「DBのテーブル構造についてそろそろ少しずつ把握しておかないとな」などの感想を持っていることが多いです。
最低限必要な知識の共有は「説明会の実施」や「ドキュメントや動画の作成」で対応します。たとえばプロダクト全般に関しては、私と一緒にプロダクトの主要機能を触ったりインフラ構成図を眺めたり主要機能のコードを一緒に読んだりして質問に適宜答えていきながらインプットしていきます。
データ周りについては、アプリケーションのDBのテーブル数が200以上あったり、ビジネス職の方に提供しているDWH上のデータマート層のテーブルの作りがかなり複雑になってしまったりして新メンバーの方が自力で読み解くには割と骨が折れるので、私とグループ歴の長いメンバーで主要なデータ周りについて話した動画を作成し、新メンバーの方に見ていただいていました。
ER図を見ながらわいわい話す様子
その他の開発業務に関する必要な知識も、まだまだ完璧ではありませんがなるべくドキュメントに残して共有するようにしています。ドキュメントのメンテナンスについては新メンバーの方に読んでいただきながら記述が古くなってしまっているところを見つけてみんなで都度修正していく形で行なっています。
今後の事業/プロダクト戦略についてのインプットもここで行います。こちらはPdMの方に協力していただき、ありものの資料を用いながら中長期の事業/プロダクト戦略や今期のフォーカスポイント、今動いているプロジェクト、普段見ているプロダクトKPIについて話していただいています。
業務上の疑問の解消の場の提供
OJTで開発案件を進めていると疑問に思う箇所が当然出てきます。こちらについても特定の既存メンバーに負担が偏ることがなく、かつ新メンバーの方の疑問になるべく早く答えられるように色々な取り組みを行なっています。
まずは、私のグループでは毎日30分~1時間、全エンジニアが集まって全員自身の作業内容について共有を行なっています。共有する際は変に内容の要約はせずに細かい作業や細かい悩みもどんどん話してもらうようにし、聞く側も分からないことは細かい点もどんどん質問したり悩みに対しては細かい部分もアドバイスしたりするようにしています。これは新メンバーの方のみでなく既存メンバーにとっても自身の相談事を持っていったりフィードバックをもらったりする場になっています。
ちなみにこの定例の議事録の冒頭には昔バズった以下のツイートの画像が貼ってあり「質問するやつはとにかく偉い」の精神で運営しています。
質問するやつはとにかく偉い #beyondmath pic.twitter.com/smW2K4i5tR
— 鯵坂もっちょ🐟『つれづれなる数学日記』好評発売中！ (@motcho_tw) June 2, 2017
新メンバーの方にとっては質問して疑問を解消する場にもなりますし、自身の作業内容を細かく話していると次のハマりそうなポイントに対して先回りしたアドバイスを既存メンバーからもらえる場にもなります。さらに個人的にいいなと感じているところは、グループ歴の長いメンバーからだけでなく、先月新しく参画していただいたメンバーから今月参画していただいたメンバーに自身が躓いたところをアドバイスする、といった新メンバーの方同士の助け合いの光景もよく見られ本当にありがたいなと思っています。また、この毎日の定例で質問やフィードバックが飛び交うのを見ていると、新メンバーの方は「この部分はこのチームでは○○さんに聞くと良い」ということが分かってくるので、このチームで働く上での問題解決の方法も身につけていただけるのも大きいです。
毎日顔を合わせる同期的なサポートだけでなく、SlackやGitHubのIssueを通した非同期なサポート体制もあります。Slackでは自グループのエンジニア部屋や全社のエンジニアが入った相談部屋がそれぞれあり、新メンバー既存メンバー関わらずそこで自身の困りごとを投げると分かる方が回答するという文化が浸透しています。
また私のグループでは、人により程度の差はありますが基本的にGitHubのIssueに作業ログを残してもらっており、全てその内容がSlackに通知されるようにしてあります。この作業ログを見て何か気付いた他のメンバーがそれに対してコメント・アドバイスするといったことが行われてます。
Issue上の作業ログ
Slack通知
質問しやすい環境を作ってメンバーの方の疑問を解消することはもちろんですが、さらにもう一歩踏み込んで、各メンバーの方の作業内容をできるだけ可視化することで、本人は検知できていないがこのまま進めていくと問題が起こりそうな箇所をみんなで先んじて検知しアドバイスし合いながら進めていくという形を少しずつ取ることができてきています。
How to work〜仕事で成果を出す〜
組織からの期待値が分かり、上横斜めの人間関係が構築でき、業務に必要な知識がインプットできた上で、日々の困りごとが解消される仕組みがあると、新メンバーの方が少しずつ成果を出せるようになってきます。その成果創出の量とスピードをさらに引き上げるために振り返りを行うようにしていました。
業務プロセス改善のための振り返り
既存メンバーも含めて、私のグループでは月次で個人振り返りを行っています。各メンバーの方には事前に個人で振り返りを行っていただきドキュメントにまとめてきていただいた上で私と1on1形式で記載内容についてディスカッションを行います。
期待値の擦り合わせで使用した全社共通指標と今の状況を照らし合わせてどんなことができているか/できていないか、来月以降はどのような取り組みを行うかについて話し合います。
また個人振り返りのみではなく、月次でグループのエンジニア全員でKPTも行っています。新メンバーの方が困っていることをグループで解決するという側面ももちろんありますし、逆に新メンバーの方の視点で見たときに既存メンバーにとっては当たり前になってしまっているが望ましくない習慣などについても話し合って改善する場にもなっています。
第三者視点でのオンボーディング状況の確認と軌道修正
オンボーディングの状況は週次で各グループのエンジニアリングマネージャーが集まる定例で細かく共有を行っています。エンジニアリング部門の部長や横のグループのエンジニアリングマネージャーにもオンボーディング状況を確認していただき、その上で意見やノウハウをもらいながらオンボーディング内容のさらなるブラッシュアップ/軌道修正を行っています。この定例の参加者では私が一番経験が浅い人間になるため、いつもアドバイスをいただけて本当に皆さんに助けていただいています。
おわりに
この1年間力を入れて取り組んできたオンボーディングについてまとめてみました。
今回オンボーディングについての記事を書こうと思ったきっかけは、半期ごとに行っている自分の振り返りで直近受け入れた新メンバーの方の数を確認した際に「いや〜自分頑張ったな〜」と思い、せっかくならちゃんと振り返ってまとめようと思ったことでした。
しかし振り返れば振り返るほど、「自分が頑張った」というのは間違いであるということを痛感しました。自分がしたことなど極々一部だけで、これだけ人数が一気に増えているにも関わらずグループが運営できている一番の要因は、同じグループの皆さんが新メンバーの方を歓迎し、新メンバーの方に活躍していただくために自主的にどんどん動いてくださり、仕事の進め方が今までと変わることも厭わず、グループ運営の改善を回し続けてくれたことだということに改めて気付けました。この場を借りてグループのメンバーに感謝できればと思います。いつも本当にありがとうございます。
以上、「LITALICO Advent Calendar 2022」カレンダー2の8日目の記事「1年で人数が倍になったエンジニアグループのオンボーディングの紹介」でした。明日は @nonsaito さんの記事になります。お楽しみに！