1. はじめに

ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。
以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。
今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。
(エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います)
会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。
本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。

2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する

中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあります。チームのマネージャーがその困難さを理解しておくことは重要です。

甲南大学 経営学部 教授の尾形 真実哉さんの研究によると、中途入社者が組織適応するためには、以下の6つの課題があると記されています。
「スキルや知識の習得」「暗黙のルールの理解」「アンラーニング」「中途意識の排除」「信頼関係の構築」「社内における人的ネットワークの構築」
(これらの課題のほとんどは、部署異動で来た新メンバーも同様だと思います)

詳しくは以下のPDFのP71～P90に詳しく書かれています。
中途採用者の組織適応課題に関する質的分析(PDF)

もう少し短い文章で噛み砕いた記事が以下にあります。
『よそ者』を「活かす組織」と「殺す組織」「中途入社者」が活躍する会社の秘密

上記の記事で特に重要なポイントを以下に引用します。

中途入社者は早期に「成果」を出したいと考えています。周りからもそのプレッシャーを感じています。成果を上げるにはどうすればいいか。前述したとおり、既存社員との信頼関係や人的ネットワークが鍵を握ります。しかし、それらを構築するためには「成果」が前提となります。ここに「因果関係のねじれ」が生じています。まさにジレンマです。

成果を出すためにも、ゆっくりと時間をかけて信頼関係と人的ネットワークを築きたい。しかし、その時間的余裕がない。この極めて窮屈な状態が中途入社者のパフォーマンスにネガティブな影響を与えているのです。』

つまり、6つの課題のうち、「信頼関係の構築」と「社内における人的ネットワークの構築」の2つは、新メンバーが自分だけで解決することが難しい課題なのです。
だからこそ、新メンバーを受け入れるチームが、それを意識した対応をする必要があります。

3. 過去の私はアンチパターンをやっていた

とても恥ずかしい話ですが、過去(10年前)の私は、以降で紹介するアンチパターンをやりまくっていました。スタンスとしては、以下のように思ってました。
「新卒社員じゃないんだから、いちいち丁寧に教える余裕はない」
「分からないことがあったら自分で聞くのが当然」
「仕事のやり方の基本は、組織によってそんなに変わらない」

新メンバーが新しいチームに適応することの困難さを全然わかっていませんでした。
苦労をかけてしまったと本当に申し訳なく思います。

そういう過去の反省から、現在は可能な限り、新メンバーに早く活躍してもらえるように以降のアンチパターンに陥らないように対策しています。

4. 中途入社や部署異動の新メンバーを活躍しづらくするアンチパターン

以下に8つのアンチパターンを紹介します。
なお、本当に凄くできる人材に対しては、このアンチパターンを全部やっていても問題なく活躍してくれるかもしれません。ただ、そこまで凄くない一般的な新メンバーに活躍してもらいたい場合は、このアンチパターンを回避した方が良いと思います。

①お手並み拝見してしまう

これは有名なアンチパターンで、中途入社して入ってきた新メンバーに対してチームが「お手並み拝見」してしまうことがあるというものです。
(部署異動で入ってきた新メンバーにも同じことが起きます）

以下の記事に書いてある内容を引用します。
中途社員がすぐ転職してしまうのはなぜ？定着率が低い企業が見直すべきこと

新卒社員であれば、フロアを連れ歩いて他部署のキーパーソンを紹介するなど、先輩社員が自然とインフォーマル（非公式）なネットワークを教えることもあると思います。中途社員の場合、一般的にはそこまで手厚いフォローを行いません。それは、迎え入れる側がそこまでやるのは、中途社員を子ども扱いしているようで失礼にあたるのではないかという思いがあるからでしょう。

中途社員はキャリアや経験もあり、新卒と比べて高い給料をもらうため、ほとんどの場合は仕事のやり方を含め「お任せします！」というケースが多いと思います。私は、これを「お手並み拝見」現象と呼んでいます。この結果、中途社員は「組織に受け入れられていない」という感覚に陥り、会社の文化に馴染めず、辞めてしまうのです。

つまり、新卒社員ではない中途や部署異動の新メンバーは「新卒社員と違って、それなりにできる人材のはず」というまわりの思い込みで、チームに馴染むためのサポートがあまり受けられないという現象が発生します。
その結果、本来は優秀な人材にもかかわらず、その組織の慣習や文化などの明文化されていないものがつかめず、組織に受け入れられていないと感じ、その実力を発揮できないまま辞めてしまうという現象が発生します。

＜対策＞
チームのマネージャーはこのアンチパターンに陥らないように、新メンバーのサポートをしっかり行うことを心がけて、チームでサポートする体制を作った方が良いです。
新卒社員ではない新メンバーに対して、手取り足取りサポートするのは、プライドを傷つけて失礼ではないかという考え方をする人もいるかもしれませんが、新メンバーとしては、早くチームのことを理解をしたいので教えてもらうことは大歓迎のはずです。むしろ手取り足取りサポートするくらいの気持ちで対応した方が良いと思います。

また、新メンバーが若手であり、利用する言語も開発手法も異なるような場合は、新卒社員と同じ教育でじっくり成長してもらうことも有効です。
新卒社員の育成方法については、以下の記事に詳しく記していますので、そちらを参照ください。

②自分のやり方で自由にやってください

上記のお手並み拝見の話に包含されるものですが、重要なので別の項目として取り上げます。
実力や実績があると思われる新メンバーに対して、自分のやり方で自由にやってくださいというパターンです。
新メンバーのロールが、マネージャーやテックリードやそれより上のロールであれば、裁量が広いので、自分のやり方でやってもらっても良いかもしれませんが、開発メンバーの一人として入ってきた場合は、アンチパターンになりえます。

まず前提として、中途入社の新メンバーは最初の頃は自分から「前職でのやり方」の方が良いやり方だという提案を控えることがあります。
入ったチームがなぜそのやり方をしているのか理解した上で人間関係を構築するまでは「そのやり方よりも前職でのやり方の方が良いやり方なので・・・」という「前職マウント」の発言は控えた方が良いというのは、中途入社時の注意点としてよく記事にも紹介されていて認知されている(と思う)からです。

その前提の場合、新メンバーとしては、早くそのチームのやり方やお作法を知って、それに合わせて活躍したいと思います。だから、自由にやってと言われるより、まずチームのやり方を知りたいということです。
特に気をつける点は、「自由にやってと伝えて新メンバーに作成してもらった成果に対して、後出しでダメ出しする」ことにより心にダメージを与えてしまうことです。それだけはやらないように気をつけた方がいいです。

＜対策＞
最初はチームのやり方を伝えます。
新メンバーが前職でやっていたやり方で改善提案して欲しい場合は、現状のチームのやり方を伝えた上で、どういうやり方が良いか相談すればOKです。
なお、最初はチームのやり方でやってもらったとしても、新メンバーがよりよいやり方を知っていれば、タイミングを見計らって、よりよいやり方を提案してくれます(チームの皆が活発に提案してくれる風土を作ることが前提ですが)。

③即戦力として取り扱う

新メンバーは、自分の実力が新しいチームの中で通用するか不安を持っています。
その組織の慣習や文化やチームの実力が分かるまでは、不安の状態なのに、即戦力として期待されるのは、プレッシャーになります。
特に、チームの既存メンバー全員に、即戦力として期待していることを認知させてしまうのはリスクがあります。
そういう認知があると、「即戦力として活躍できる人材のはず」というまわりの思い込みによって、新メンバーは十分なサポートが受けられない可能性が高くなるからです。
そして、まわりがそういうスタンスを取ると、それが新メンバーにとっても強いプレッシャーになり、実力が発揮できない要因になります。

＜対策＞
一番最初は、即戦力として扱わず、チームでサポートする姿勢を見せます。

④十分な教育期間がない

そのチームでの開発に貢献するためには、ドメイン知識、開発プロセス、必要なスキルの学習のために、教育期間が必要になります。
また、インセプションデッキ(メンバーみんなで議論して決めたプロダクトづくりにおける共通認識)を説明するなどで、どんなことを目指してプロダクトを開発しているのかを理解してもらうことも重要です。
(私のチームの場合は、プロジェクトの成果を出すことと同じくらい、「発信活動を継続しながら成長したい」「失敗しても良いからチームで新しいことにチャレンジしたい」ということに価値観を持っているという特徴があるので、それを説明します)

それらを理解していないままだと、チームのことがよく分からない状態で開発することになり、心情的にモヤモヤを抱えたままになります。
教育が不十分でも仕事は進められますが、全体像がよくわからないままで「いつか説明されるのだろうか」という不満を抱えたままで仕事をしてもらうのは、パフォーマンスを発揮してもらう上でよくないと思います。

＜対策＞
シンプルな対策は、新卒社員と同様の教育のうち、必要なものをピックアップして行うことです。
また、本件は新メンバーが納得していれば大きな問題がなくなるため、新メンバーに納得してもらえば教育期間を短くするのも有りです。
過去の私のチームの例として、新メンバーに対して、プロジェクトの現状として早く開発に入ってもらいたい状況であることと、新メンバーが行うべき教育カリキュラムとして何があるかを最初に説明しました。その上で、新メンバー自身にどうしたいか意向を聞いて、その意向通りに最初の教育期間を短くしたことがあります(後々に教育を追加実施)。

⑤ペアプロ・モブプロを一切やらない

最初の頃は、そのチームのやり方や考え方と、新メンバーの考え方に、どういう違いがあるのかを相互理解し、納得した上で進める方が効率的です。その中で、新メンバーは、チームの暗黙知を多く学ぶことができ、既存メンバーも新メンバーが持っている知見を得られます。
それを行うためには、最初の期間はペアプログラミング・モブプログラミング(以下、ペアプロ・モブプロ)中心の方が効率が良いです。ここで言うペアプロ・モブプロの範囲は、プログラミングのタスクに限らず、仕様書や設計書を作成するタスクなど、あらゆる工程を含めています。
にもかかわらず、ペアプロ・モブプロを一切やらずに、ソロで仕事をさせてしまうのは非効率です。
また、最初からソロで仕事をさせることによって、孤独感を感じさせてしまう場合もあります。孤独感を感じる状態では、楽しく仕事ができずパフォーマンスも発揮できないです。

＜対策＞
最初の期間は、ペアプロ・モブプロ中心でやってもらいます。
また、チームの考え方を学ぶために、モブレビューに参加してもらうことも有効です。モブレビューに参加していれば、自分がレビューされる場合の想定もできます

なお、ペアプロ・モブプロのやり方については以下を参照ください。

⑥チームメンバーとの会話が少ない

先に記載した通り、新メンバーは、チームのお作法や文化などの暗黙知に加えて、チームのメンバーの実力や人となりを早く理解したいと考えます。
そのためには、チームのメンバーとたくさんの会話が有効です。
それなのに、ソロで仕事をこなし、朝会などのチーム全体の会議以外で、あまり会話する機会がないと、それらの理解が進みづらいです。

＜対策＞
先に紹介した 甲南大学 経営学部 教授の尾形 真実哉さんの記事によると以下が紹介されています。

新入社員にはメンター制度などがありますが、中途入社者にも必要です。わからないことがあった時にすぐに聞ける存在は非常に重要です。この役目をつけてあげることが適応を促します。

ただ、上記だけでは特定のメンバーとの会話になってしまうため、新メンバーが仕事の中で色々なメンバーと会話する機会を作ることも重要です。
具体的には、チームの色んなメンバーとペアプロ・モブプロをするのが手っ取り早いです。

⑦チームの貢献になっていることを実感させない

新メンバーは、自分がチームに貢献できる実感を得ることで不安が少しずつ解消していくと思います。
チームに貢献になっていると感じられないと不安をかかえたまま仕事を続けることになります。

＜対策＞
新メンバーがやってくれたことや発言がチームの貢献になっていることを毎日のようにポジティブフィードバックすれば、不安は解消されていくと思います。

⑧最初から難しいタスクを任せる

新メンバーは、チームに貢献する実感を得ていく中で、不安が徐々に解消されていきます。
そのため、最初から難しいタスクを任せることはリスクがあります。
もし最初に任せたタスクがうまくいかなかった場合、自分の実力ではチームに貢献できないと感じてしまう可能性があります。

＜対策＞
最初は、難易度が高くなく、チームへの貢献を実感しやすいタスクを任せます。

5. まとめ

中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターンを紹介しました。
新メンバーが早く活躍できるようにするための参考にしていただければ幸いです。
また、本稿のアンチパターンに遭遇した結果どうだったのか、いただいた声を以下の記事にまとめましたので、そちらも参考にしていただければと思います。
アンチパターンが起きるとどうなるか

ちなみに私はITエンジニア向け情報誌「Software Design」の2022年5月号から「ハピネスチームビルディング」を題材に連載記事を書いています。以下で公開していますので、よろしければ、そちらも参照ください。

Twitterでも役立つ情報を発信しますのでフォローしてもらえると嬉しいです → @kojimadev