”資料を渡すだけ”から脱却して効果的なオンボーディングにするための改善事例

新メンバーを受け入れるとき、オンボーディングと称して既存資料をドサッと渡して「読んでおいてね」と伝えて済ませてしまうこと、ありませんか？

私たちのチームもかつてそうでした。
しかし、このオンボーディングは新メンバーが最速でパフォーマンスを出すために最適なやり方なのでしょうか？

もっと良いオンボーディングにしたいと思っても、その機会は多くて年に数回。ついついメンテナンスは後回しにされがち。いざメンテしようにもどこをどう直せば良くなるのか分からない…。
と、改善意欲があっても手が動かせない状況にも陥りやすいのが、オンボーディングの難しいところですよね。

今回の記事では、かつて私がマネジメントしていたLINE NEWSのフロントエンドチームのオンボーディング改善事例を紹介します。事例を参考に、ご自身のチームにあったオンボーディングはどういうものか、想像しながら読んでもらえると嬉しいです。

• オンボーディングの真の役割を問い直す
• ターゲットをタイプ分けする
• ターゲットのタイプ毎にユーザーストーリーを描く
• これまで実践してきたオンボーディングをマッピングする
• アクションのタイムラインを設計する
• その他のオンボーディングを充実させるTips
  • 「新メンバーによるオンボーディング改善」をオンボーディングに組み込む
  • オンボーディングの責任範囲を明記する
  • 過剰なものを削ぎ落とす
  • ドキュメントを使うものと、モブワークを使うものとを分ける
• おわりに

オンボーディングの真の役割を問い直す

オンボーディングは誰のためのものでしょうか？

私は新メンバーのためだけではないと考えています。新メンバーのメンターのためであり、受け入れるチームメンバーのためでもあります。

三者にとって意味のあるオンボーディングを目指すことが、私たちのオンボーディング改善のスタート地点でした。

ターゲットをタイプ分けする

オンボーディングとは、資料を読んでもらうことでも、説明会を開くことでもありません。それらは手段の1つにはなり得ますが、目的そのものではありません。

上述の通り、私たちにとってオンボーディングの目的は

• 新メンバーが最速でパフォーマンスを出す(メインターゲット)
• メンターが迷うことなくメンタリングでき、かつその品質が一定になる
• 受け入れチームの期待値が揃う

の3つです。

この三者の目的を達成するために、まずはメインターゲットである「新メンバー」がどういう人か解像度を上げることから始めてみます。私たちのチームでは4種類に分類しました。

私たちは「エンジニア歴」と「関わる期間の長さ」で分類しましたが、チームによっては「技術領域」や「得意ドメイン」などかもしれません。これまでに受け入れてきた人たちを思い浮かべながら分類すると良いでしょう。

ターゲットのタイプ毎にユーザーストーリーを描く

次に、この4タイプの新メンバーがパフォーマンスを発揮するまでに経験すべきことを描きます。これを「ユーザーストーリー」と呼ぶのは、ユーザー(新メンバー)の目線でどんな体験が必要かを考えるためです。

ストーリーを考えるための骨組みとして、オンボーディングを4つのフェーズに分けましょう。

1. How to Live (職場に適応する)
2. How to Learn (知識・スキルを得る)
3. How to Work (仕事を完遂する、成果を出す)
4. How to Influence (周囲に影響を与える)

フェーズごとにストーリーを洗い出していきます。

例えば、1番目の適用するフェーズでは「チームに馴染む」「よく使うコミュニケーション方法を知る」などで、2番目の知識を得るフェーズでは「デプロイフローを知る」「プロダクトの収益モデルを知る」などでしょうか。

成果を出すまでに必要な体験を粒度問わず洗い出します。

一通り洗い出し終わったら、先程のターゲットのタイプと掛け合わあせて、「新メンバーのタイプ毎にどのストーリーを経験すべきか」を整理していきます。

LINE NEWSでは、「4つの新メンバーのタイプ」x 「4つのフェーズ(12のストーリー)」を表にまとめていました。

少し表の解説をします。
Rowには、オンボーディングの4つのフェーズ(緑色のブロック)と、それぞれのフェーズで必要なストーリー(グレーの行)があります。たとえばHow to Liveのフェーズには「チームの雰囲気を知る」「チームメンバーとの関係性をつくる」「Managerと期待値を揃える」の3つのストーリーがあります。

Columnには、新メンバーの4つのタイプが並んでいます。
それぞれのタイプが、各ストーリーを経験すべきかについて「Essential(必須)」「Recommended(推奨)」「Optional(任意)」「空欄(不要)」の4段階で表現しています。

具体例を1つピックアップして詳細を見てみましょう。
表の真ん中あたりにあるHow to Learnの「配属先Small Teamの開発環境・ルールを理解する」ストーリーは、

• 新卒タイプには Essential
• インターン生タイプには Optional
• 中途採用タイプには Recommended
• ヘルプアサインタイプには None

となっています。

当時のLINE NEWSプロジェクトでは、エンジニアは3つのSmall Team(職能横断なスクラムチーム)に分かれて開発をしていました。

『新卒タイプ』にとっては馴染のない開発体制であろうことから「必須」のストーリーとしましたが、1ヶ月間のみ協業する『インターン生タイプ』に開発環境・ルール・運用をすべて理解してもらうのはオーバーヘッドが高いので「任意」としていました。

＊＊＊

これがオンボーディングの全体像になります。
どんな新メンバーが何を経験すべきかが明らかになりました。

上述した三者の目的である

• 新メンバーが最速でパフォーマンスを出す(メインターゲット)
• メンターが迷うことなくメンタリングでき、かつその品質が一定になる
• 受け入れチームの期待値が揃う

を満たすアウトラインが整った状態です。あとはストーリーを実現する具体的なアクションを埋めていけばオンボーディングが完成するであろうことが、すでに感じ取れるのではないでしょうか？

これまで実践してきたオンボーディングをマッピングする

これまで実践してきたオンボーディングアクションをストーリーにマッピングしていきます。

たとえば

• 初日に自己紹介ミーティングに参加する
• プロダクトコードを修正しPRを作成する
• マージからデプロイまでの流れを資料で読み、サンプルプロジェクトで試す

といったような具体的なアクションが、どのストーリーに当てはまるかを考えていくわけです。

もし該当するストーリーがない場合はストーリーの追加が必要か、もしくはそのアクションが不要な可能性を示唆しています。

マッピングが完了すると、「実践できていないストーリー」や「過剰に取り組んでいるストーリー」が浮き彫りになるはずです。これを1つずつ修正していくことで、過不足のないオンボーディングが出来上がっていきます。

「ストーリーとアクションをマッピングする」アプローチは、マクロとミクロの視点のかけ合わせとも言えます。この作業を通じてオンボーディングの網羅性が高まります。

「オンボーディングの全体像」と「過不足のないオンボーディングアクション」が出揃ってくると質が高まることはもちろん、「メンターが何をすべきか」や「オンボーディングを完了したメンバーは何ができるのか、の期待水準」が明らかになるのが、イメージできると思います。

アクションのタイムラインを設計する

ここまででオンボーディングの全体図は完成しました。これにてオンボーディングのメンテナンス完了です！

…としてもいいのですが「メンターが迷うことなくメンタリングでき、かつその品質が一定になる」目的を果たすためには、もう少し具体的なメンタリングのガイドラインとなる側面があっても良さそうです。
それがオンボーディングタイムラインです。

まずはLINE NEWSの実例から見てみましょう。

横軸を時間軸とし、それぞれのアクションをどのタイミングで実施するかを表現しています。

付箋の色は

• 単発アクション
• 継続アクション(の初回開催時)
• 資料を使うアクション(メンターが事前に資料の更新状況を確認すべきもの)
• 新メンバーが任意のタイミングで実施すれば良いアクション

を表します。

初めて/久々にメンターする人にとって、オンボーディングの流れの可視化されているといくらか安心して臨めるのではないでしょうか。
新メンバーから「来週からSmall Teamにジョイン予定なんですが、事前に確認しておくべきことはありますか？」と聞かれてオンボーディングアクションの漏れに気づく…なんてこともなくなりますね。

オンボーディング前に付箋を貼ったり剥がしたりしてプランニングに使うこともできますし、完了したアクションを剥がしてタスク管理することにも使えます。

その他のオンボーディングを充実させるTips

「新メンバーによるオンボーディング改善」をオンボーディングに組み込む

オンボーディングの一環として、オンボーディングそのものに対するフィードバックと修正をしてもらうと、双方にとってハッピーです。新メンバー目線でオンボーディングをより良くできますし、新メンバーが成果を出す場としても機能します。

オンボーディングの責任範囲を明記する

オンボーディング完了時点で新メンバーがどういう状態になっているかを明記することで、オンボーディングの責任範囲が明確になります。例えばLINE NEWSのオンボーディングでは「フロントエンド知識のインプット」は責任範囲外としています。フロントエンドの根源的な知識は採用のタイミングで確認済みで、ライブラリの利用ナレッジ等は業務の中でキャッチアップすることを想定していたからです。

過剰なものを削ぎ落とす

今回の改善方法は、足りないものに気づきやすいアプローチです。反面、オンボーディングのボリュームが増しがちです。オンボーディングにどれだけの時間を費やすかは受け入れるチームの状況によって変わるはずです。

ボリュームがあると感じた場合は、オンボーディングの責任範囲を見直しながら『削ぎ落とし』をすると良いでしょう。私たちも一通りの改善を済ませた後は、新メンバー加入のたびに削ぎ落としをしていました。

ドキュメントを使うものと、モブワークを使うものとを分ける

ドキュメントとして残しやすい形式知と、そうでない暗黙知とを分けることは重要です。うまく分別できれば「すべてをドキュメントに残さねば」の圧から解放されますし、ドキュメントの総量を少なく維持できれば最新性を保ちやすくなります。

暗黙知のほうは、モブワーク(モブプログラミングやモブ環境構築など)で口伝していく方法をとっても良いです。特に最初の環境構築はモブワークがおすすめです。

おわりに

オンボーディングをターゲット、フェーズ、ストーリー、アクション、タイムラインに分けて考えることで、私たちのオンボーディングのクオリティはグッと高まりました。

まだまだ改善の余地は残っていますが、「このオンボーディングが過不足なく、一定のクオリティであること」に根拠を持てるようになりました。感覚ではなくロジックで作り上げたことで、より良くするための議論のスタート地点に立てた、とも言えます。

オンボーディングの改善は後回しになりがちなタスクです。
しかし、新たに加わった新メンバーがいち早くパフォーマンスを発揮できるよう、自らオンボーディングを整えられたチームには、自律性や持続可能性の片鱗があるはずです。

新メンバーにとってだけでなく、チームにとって重要なオンボーディングの改善に、この知見が少しでも役立てば幸いです。