はじめに
エンジニア組織でよく聞く役割のひとつ、「プレイングマネージャー」。
つまり、自分でもコードを書きながら、チームのマネジメントもやる人です。
「技術もわかって、チームも回せる」って、理想的に聞こえます。
でも実際やってみると、思った以上にしんどいポジションだったりします。
この記事では、プレイングマネージャーのメリットとデメリットを、現場目線で整理してみます。
なんでプレイングマネージャーが生まれるのか
- チームが小さいから専任マネージャーを置けない
- 現場感のあるリーダーが求められる
- 手を動かさないと「古い人」扱いされる（エンジニアあるある）
こんな理由で、「とりあえずプレイングマネージャーで！」という流れは珍しくありません。
特にスタートアップや小規模チームでは、現場を理解してる人が指揮を執るのが一番早いのだと思います。
デメリット：二兎を追う者はなんとやら
1. 「自分でやったほうが早い」病
タスクをメンバーに任せるより、自分でやったほうが早い。
そう思ってつい手を出しすぎて、全部抱え込んでしまう。
これ、ほとんどのプレイングマネージャーが通る道です。
結果、メンバーは育たず、自分は疲弊。
「結局、自分しかわからないコードばっかり」みたいな状態になりがちです。
2. 視野の切り替えがムズすぎる問題
（ここが一番大きなデメリットだと思ってます）
マネージャーは全体を見て、リスクを俯瞰して判断する広い視野が必要です。
でも、開発者モードでは逆に視野を狭めて目の前のコードに集中する必要があります。
この「広げたり狭めたり」の切り替えを頻繁にやってると、どこかで精度が落ちます。何かを見落とす確率が上がります。結果、どちらも中途半端に……というのが典型的な失敗パターン。
3. 成功事例が意外と少ない
正直、筆者はプレイングマネージャーが長期的にうまく回ってる例をあまり見たことがありません。
短期的には勢いで進むんですが、チームが大きくなると途端に破綻するケースが多いです。
マネージャーが体調を崩したりした瞬間、チームも止まる。
この構造はけっこう危ないです。
それでもメリットはある
もちろん、全部が悪いわけじゃないです。
1. 現場のリアルを理解できる
手を動かしているからこそ、メンバーの苦労や技術的な課題をちゃんと理解できます。
マネジメントだけしていると見えない「現場の温度感」を肌で感じられるのは大きな強み。
2. 信頼されやすい
「この人、ちゃんとコード書けるんだ」って思われるだけで、メンバーの信頼度は上がります。
口だけじゃなくて、一緒に戦ってくれるリーダーという存在は、やっぱり心強いです。
3. 初期フェーズでは即効性がある
スタートアップの立ち上げ期や、チームがまだ3〜5人くらいの規模なら、
プレイングマネージャーがいた方が話が早いです。
決定から実装までが一気通貫なので、スピード感は抜群。
どうすればうまくいくのか？
プレイングマネージャーを続けるなら、いくつかコツがあります。
-
自分の時間を見える化する
「開発○％、マネジメント○％」を明確に。いつの間にか100%開発してるなんてよくある話。 -
任せることを恐れない
手放すのもスキル。自分が全部やらない仕組みをつくる。 -
定期的に“手を動かす量”を見直す
チームが育ってきたら、プレイ比率を下げる勇気を。
結論：プレイングマネージャーは「過渡期の形」
プレイングマネージャーは、組織の成長過程で一時的に必要な存在です。
初期フェーズでは推進力になりますが、
中〜長期では「組織の成長を止める構造」になるリスクもあります。
最終的には、プレイヤーを卒業してマネージャーに専念する方向に移るのが理想。
逆に、ずっとプレイングマネージャーでいると、
どこかで「チームの成長＜自分のスキル維持」になってしまいがちです。
おわりに
「プレイングマネージャー」という言葉に万能感を感じる時期もありましたが、
実際やってみると、万能どころか綱渡りです。
ただし、「現場を理解するマネージャー」や「手を動かせるリーダー」という姿勢自体は、
これからもエンジニア組織にとって大切な価値だと思います。
フェーズによってうまく使い分けること、また、時期が来たら自分が抱えていたものを手放すこと、そうすることで組織は強くなっていくと思います。