何でも「チームワーク」のせいにするな――エースと新人を組ませた上司の誤算

※この記事は、私が実際に関わった複数の開発現場での出来事をもとに、守秘義務に配慮して登場人物・状況・時系列を再構成し、一つの物語として一部脚色しています。個別の事例をそのまま再現したものではありません。

「もういいよ。あとは俺がやるから」

Aさんは、Bさんが作った資料を見てそう言った。
責めるつもりはなかった。

提出期限は明日だった。このまま修正方法を説明するより、自分で直した方が早い。Aさんにとっては、それだけの判断だった。

Aさんが修正しようとした時、Bさんがつぶやいた。

「どうせ、僕が作ったものでは不満なんですよね」

Aさんは、一瞬、何を言われたのか分からなかった。
数秒の沈黙のあと、Bさんは席を立った。

その日の夕方、Aさんは課長に呼ばれた。

「A君、もう少し仲良くやってよ。チームワークが大事なんだから」

その言葉を聞いた瞬間、Aさんの中で何かが切れた。

二人が組むことになったのは、三か月前だった。

Aさんは入社してからすぐに頭角を現し、若くして課のエースになった。
頑張れば頑張るほど成績が伸び、仕事が面白くて仕方なかった。

一方、Bさんは未経験で入社したばかりだった。
そろそろAさんに人材育成の面でも成長してほしいと思っていた課長は、歳がそれほど離れていないAさんとBさんをペアにしようと考えた。

「B君を育ててやってくれないかな。A君ならいいお手本になるだろう」

課長はこの一言だけで、Bさんの育成をAさんに任せてしまった。

Aさんは、先輩から受け継いだ引継ぎ関連資料があったので、
「まず、ここのフォルダの資料を読んでおいて」
と依頼。

しかし、未経験で業界知識もないBさんにとって、日本語で書かれているにもかかわらず、英語を読んでいるような気分になった。

「Aさん、これはどういう意味ですか？」

最初は都度答えていたAさん。
しかし、だんだん面倒に感じてきて、ある時、こんなことを言った。

「基本的に、探せばそのフォルダの資料に書いてあるから、まずは一通り目を通してもらっていいかな。あと、できれば質問はまとめてほしいな。」

Bさんから見ると、「読んでも分からないから聞いている」、
Aさんから見ると、「ちゃんと読まずに質問してくる」
とお互いの感じ方が違っていた。

Bさんは、何もしていなかったわけではなく、ただ、未経験者で基礎知識がなさ過ぎて資料に出てくる言葉の意味が分からず、何を調べればよいのかも分からない状態だった。

聞けば迷惑そうにされる。聞かなければ仕事が進まない。そのうち、Bさんは質問すること自体にためらいを感じるようになった。

それから、少し時間が経って、AさんはBさんに
「これ、なんでこの結論になったの？」
と質問した。

「いろいろ調べて、こうなりました」

（きれいにまとまっているけど、やけに曖昧な回答だな。あまり、理解しないまま回答している？もしかして、AIの回答とか？）

そう思ったAさんは、
「結論を出す場合は、ちゃんと自分が納得した形で出した方がいいよ」
と伝え、

「はい、分かりました」
と回答。

（ちゃんと分かっているかな？）とAさんはそう思ったものの、なぜそれが大切かを説明するには若干空気が重く、そのまま会話は終了。

そして、翌日。
「もういいよ。あとは俺がやるから」

さて、この問題は、誰か一人の努力不足だったのでしょうか。

Aさんでしょうか。
もう少し丁寧に教えるべきだったのかもしれません。

Bさんでしょうか。
もっと自分で調べ、考える姿勢が必要だったのかもしれません。

課長でしょうか。
二人を組ませる前に、もっと準備しておくべきだったのかもしれません。

おそらく、どれも少しずつ正しいのだと思います。
ただ、この問題を「Aさんの教え方が悪い」「Bさんの努力が足りない」「二人のチームワークが悪い」とだけ見てしまうと、本質を見誤ります。

本当に見るべきだったのは、二人の相性ではなく、仕事の渡し方と役割の設計でした。育成のプロジェクトの仕事の一つだと思いますが、どのような育成の取り組み方がよかったのでしょうか？

「仕事ができる」と「初心者に教えられる」は別の能力

Aさんは、感覚的に「こうすればうまくいく」と分かっているため、初心者がどこでつまずくのかが分かりません。むしろ、「何が分からないかが、分からない」という状態です。

逆に少し前まで初心者だった人なら、

など、自分がつまずいたところを教えられる場合があります。

仕事ができる人は、何でもできると思われがちです。
Bさんも上手に教えてもらえるという淡い期待があったかもしれません。

しかし、本来は誰でも得意不得意があり、完璧な人はいません。
「何でもできる」という期待は、強すぎると「何でも押し付けられる」というプレッシャーに変質してしまいます。

課長が「人」だけを見て、「仕事の設計」をしていない

課長が決めるべきだったのは、単に「AとBを組ませる」ことではありません。

• Bさんは、1年で何ができるようになればいいのか

• Aさんが教える範囲はどこまででいいのか

• Aさんに育成をお願いする分、どれだけ仕事量を減らすか

• 育成をどう評価するのか

こういったことを決めずに、
「Aさんならうまくやってくれるだろう」
と考えた点が問題です。

もちろん、課長にも悪気はありませんでした。
Aさんを信頼していたし、Bさんにも早く戦力になってほしいと思っていた。
ただ、その信頼を「任せっぱなし」にしてしまった。

結果論ではありますが、課長とAさんで事前に育成範囲や進め方を話し合い、一緒に設計していれば、Aさんの納得度も違っていたはずです。

「チームワーク」という言葉で原因をぼかした

「仲良くやる」
「チームワークが大事」
どちらもその通りです。否定しようがありません。
この他にも、使う側にとって便利な言葉があります。

「お互いコミュニケーションを取ろう」
「もっと主体性を持って仕事してほしい」
「ちゃんと確認してね」

これらは、言葉そのものは間違っていないものの、具体的な行動に落とせないという落とし穴があります。

Aさんからすれば、
「それは分かっている。具体的にどうすればいいか、教えてください」
と感じたかもしれません。

何でもチームワークのせいにすると問題は解決しません。
それは表面的に見えているだけだからです。
そこを指摘するだけでなく、その原因を深掘りすることが大事です。

その後に課長とAさんが話し合って決めたこと

そこで課長は、Aさんに「もっと頑張ってくれ」と言うのをやめました。代わりに、二人の仕事の進め方そのものを見直すことにしました。

• 未経験で入社した先輩のCさんにもフォローしてもらう

• Aさんが教える範囲と時間を決める

• 完成後ではなく、途中段階で確認する

• Bさんの質問時に「調べたこと・分からない点」を整理する

• Aさんの通常業務を減らす

• 育成をAさんの評価対象にする

後日談

数か月後、BさんがAさんの必要な情報を先回りして集めてくれました。

「これ、調べてくれたんだ、ありがとう」

「前、Aさんが気にしていたので」

二人の性格が変わったわけではありませんし、
いまも特別仲がいいというわけでもありません。

変わったのは、役割と仕事の渡し方でした。

上司やPLの仕事は、「仲良くやって」と求めることではなく、それぞれが貢献できる役割と、安心して相談・確認できる流れを設計することです。

チームワークは、気合いで生まれるものではありません。
互いが貢献できる役割を持ち、安心して確認できる流れがあり、少しずつ信頼が積み重なった結果として生まれるものです。

だから、チームがうまくいかないときほど、安易に「チームワーク」のせいにしない。見るべきなのは、人の性格ではなく、そうならざるを得なかった仕事の構造です。

「自分でやった方が早い」は、その1回だけを見れば正しいことがあります。でも、マネジメントでは未来のチームがどうなるかまで考える必要があります。自分でやるか、人に任せるか。その判断基準を整理しています。