はじめに

エンジニア組織でよく聞く役割のひとつ、「プレイングマネージャー」。
つまり、自分でもコードを書きながら、チームのマネジメントもやる人です。

「技術もわかって、チームも回せる」って、理想的に聞こえます。
でも実際やってみると、思った以上にしんどいポジションだったりします。

この記事では、プレイングマネージャーのメリットとデメリットを、現場目線で整理してみます。

なんでプレイングマネージャーが生まれるのか

こんな理由で、「とりあえずプレイングマネージャーで！」という流れは珍しくありません。
特にスタートアップや小規模チームでは、現場を理解してる人が指揮を執るのが一番早いのだと思います。

タスクをメンバーに任せるより、自分でやったほうが早い。
そう思ってつい手を出しすぎて、全部抱え込んでしまう。
これ、ほとんどのプレイングマネージャーが通る道です。

結果、メンバーは育たず、自分は疲弊。
「結局、自分しかわからないコードばっかり」みたいな状態になりがちです。

（ここが一番大きなデメリットだと思ってます）

マネージャーは全体を見て、リスクを俯瞰して判断する広い視野が必要です。
でも、開発者モードでは逆に視野を狭めて目の前のコードに集中する必要があります。

この「広げたり狭めたり」の切り替えを頻繁にやってると、どこかで精度が落ちます。何かを見落とす確率が上がります。結果、どちらも中途半端に……というのが典型的な失敗パターン。

正直、筆者はプレイングマネージャーが長期的にうまく回ってる例をあまり見たことがありません。
短期的には勢いで進むんですが、チームが大きくなると途端に破綻するケースが多いです。

マネージャーが体調を崩したりした瞬間、チームも止まる。
この構造はけっこう危ないです。

もちろん、全部が悪いわけじゃないです。

手を動かしているからこそ、メンバーの苦労や技術的な課題をちゃんと理解できます。
マネジメントだけしていると見えない「現場の温度感」を肌で感じられるのは大きな強み。

「この人、ちゃんとコード書けるんだ」って思われるだけで、メンバーの信頼度は上がります。
口だけじゃなくて、一緒に戦ってくれるリーダーという存在は、やっぱり心強いです。

スタートアップの立ち上げ期や、チームがまだ3〜5人くらいの規模なら、
プレイングマネージャーがいた方が話が早いです。
決定から実装までが一気通貫なので、スピード感は抜群。

プレイングマネージャーを続けるなら、いくつかコツがあります。

プレイングマネージャーは、組織の成長過程で一時的に必要な存在です。
初期フェーズでは推進力になりますが、
中〜長期では「組織の成長を止める構造」になるリスクもあります。

最終的には、プレイヤーを卒業してマネージャーに専念する方向に移るのが理想。
逆に、ずっとプレイングマネージャーでいると、
どこかで「チームの成長＜自分のスキル維持」になってしまいがちです。

「プレイングマネージャー」という言葉に万能感を感じる時期もありましたが、
実際やってみると、万能どころか綱渡りです。

ただし、「現場を理解するマネージャー」や「手を動かせるリーダー」という姿勢自体は、
これからもエンジニア組織にとって大切な価値だと思います。

フェーズによってうまく使い分けること、また、時期が来たら自分が抱えていたものを手放すこと、そうすることで組織は強くなっていくと思います。