はじめに
チームにジョインしてくれるメンバーを迎えるに際して、オンボーディング作業をするかと思います。
そのオンボーディングですが、チームの成長が続いたり、新たなルールが追加されるとオンボーディングの内容もどんどん増えていくかと思います。
自分のチームでは、チームのルールや決まり事、どのような技術構成なのかなどを1度に全て説明するオンボーディングを行っていました。
ただ、全部伝えるようなオンボーディングに違和感しかありませんでした。
そのため、オンボーディングではどのようなことをすればいいのかやどのようなステップで進めればいいのかの個人的意見を簡単に記事にまとめようかと思います。
オンボーディングとは
改めてオンボーディングとは何かを簡単に共有します。
オンボーディングとは、新しく組織に加入したメンバーが、スムーズに組織に溶け込み、早期に戦力化するための取り組みのことです。
改めて、内容を確認すると、チームの決まり事やルールを全部説明するオンボーディングは本当に上記の目的を達成していると言えるのか疑問があります。
オンボーディングにおける問題点
こちらは「プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ」に記載のあった内容を抜粋します。（こちら、とてもいい参考書でした）
シニアな開発者は、新人にたくさんの新しい情報を一度に投げつけてしまいます。その結果、情報量が多すぎて処理しきれず、新人の脳に高い認知的負荷がかかります。シニア開発者は、例えば、コードが対象とするビジネス領域、開発ワークフロー、コードベースの内容などを一気に紹介してしまいがちです。
紹介が終わると、シニア開発者は、新人に質問をしたりタスクを与えたりします。シニア開発者は、小さなバグを直したり、小さな機能開発をするなどのタスクを与えますが、シニア開発者本人は、それを非常に簡単なタスクだと考えがちです。
ところが、新人は、そのビジネス領域やプログラミング言語における関連するチャンクの不足、あるいは関連するスキルが完全に自動化されていないがゆえに、高い認知的負荷を引き起こし、うまくオンボーディングできない状態になってしまいます。
シニア開発者が新人に同時に多くを学ぶことを求めていることです。そのために、新人のワーキングメモリ（※）の容量に過剰な負荷がかかってしまい、うまくオンボーディングができなくなってしまっています。
※ ワーキングメモリ：業務中に必要な情報を一時的に保持し、処理する能力
新人のワーキングメモリが過負荷に陥ると、新しいコードベースの理解が効果的に進まず、新しい情報も記憶できにくくなってしまうことがあります。それが原因となって、双方にフラストレーションが溜まり、間違った思い込みが発生してしまうケースがあります。
シニアになればなるほど、新人への説明やトレーニングを効果的に行えなくなる理由の1つに「専門知識の呪い（curse of expertise）」があります。これは、何かのスキルや知識を十分に習得してしまうと、その習慣がいかに大変だったのかを忘れてしまうということを意味します。この呪いにかかると、その習慣がそんなに難しいものに感じられず、新人が同時に処理できる新しい物事の数を過大評価してしまうようになってしまうのです。
上記を読んだ時、グサグサと心に刺さりました・・・
ただ、今までのオンボーディングにおける違和感が解消された気もしました。
また、改めて今までのやり方は間違っていたんだなと再認識できました。
適切なオンボーディングをするためには
オンボーディング対象者のレベルを把握する
どの開発者もそれぞれ得意・苦手分野が存在します。
何が得意で何が苦手なのかを事前にヒアリングすることは、とても大切なことです。
例えば、プログラミングは得意だけどアプリケーションの仕様把握には時間がかかっている。アプリケーションの仕様把握はスムーズにできているけど、プログラミングが苦手などです。
チームに入る前の段階でヒアリングができているといいかなと思っています。
また、ヒアリング結果をしっかりドキュメントに文字起こしすることも大切だと思います。
タスクにおけるプログラミングに関する活動を1つに限定する
プログラミングの活動一覧
| 活動 | オンボード時の活用方法 |
|---|---|
| 探索 | コードベースを見渡して、その全体像を把握する |
| 検索 | 特定のインターフェイスを実装しているクラスを探す |
| 転写 | 新人に作業の具体的な手順について明確な計画を与える |
| 理解 | 特定のメソッドを自然言語で要約するなど、コードの内容を理解する |
| 増強 | 既存クラスへの機能追加（計画の作成も含む） |
上記の活動の中から1つ選び、新人には1つずつやってもらうことが良いとされています。
どのような順序で学んでほしいかを決定して、何から着手してもらうかを決定する必要があります。
新人の特性を理解した上で、タスクを選定しましょう。
何をさせるかを決定した上で、必要最小限のオンボーディング内容をまとめる
こちらは、一度に全部は説明しないための改善点になるかなと思います。
本当に必要最低限の内容でオンボーディングする必要があると思っています。
また、オンボーディングの説明では、「専門知識の呪い」にならないような説明が必要です。
どうして開発ルールが存在するのか、どうしてそのようにソースコードを追うのかなど、しっかり背景を説明しながらオンボーディングをするといいと思います。（どんなことに対しても「知ってて当たり前」をなくすことが重要）
1つずつ確実にタスクをこなしていき、タスクのレベルも上がってきたタイミングで次のオンボーディングを実施するような流れがいいかなと思います。
まとめ
オンボーディングに関する重要だなと思ったこと、今まで間違ってたなってことをまとめました。
皆さんの環境でもオンボーディングに対して同じ違和感をもっていた場合は、何かしらの助けになるかなと思っています。
オンボーディングが完了した後、実装を行う際はペアプロかバディプログラミングなどをするのもおすすめかなと思っています。
それも対象者の特性に応じて臨機応変に選んでいただければと思います。
最後まで読んでいただきありがとうございました。