この前この記事がバズっていましたね。 blog.manabusakai.com

僕も明確に謳ってたわけではありませんが、ちょっと前まで実質プレイングマネージャー的な動きを何年かやっていたので、その体験を元に色々と書いてみようかと思います。 (ちなみに今はほぼプレイヤーのポジションに戻っています)

ちなみにやってきたマネジメント的な経験で言うと、まず所属していたプロジェクトのサーバーエンジニアリーダー(最大7人いたチーム)から始まり、途中から社内2プロジェクトのエンジニアの責任者(合計で大体20人前後)もやるようになったという感じです。
そんなに具体的な話はしてないですが、昔に受けた下記のインタビューを参考に笑

https://career.levtech.jp/guide/pickup/column/54/

その時実際に何に責任を持っていたかでいうと、

それぞれのプロジェクトの技術的な品質の担保
各メンバーのスケジュール、コンディションの担保
プロジェクトをまたいでのノウハウの共有、各種連携

とかをやっていました。

そもそもプレイングマネージャーとは？

プロ野球で過去に何人か「選手兼監督」という人がいて(野村克也、古田敦也とか)、プレイングマネージャーと言われていましたが、エンジニアでいうプレイングマネージャーは「手を動かす(実装する)マネージャー、リーダー」といったところですかね。

昔SIerとかでの仕事が主だった時代には、プログラマの最終的なキャリアパスとしてPM(プロジェクトマネージャー)があって、そこまで行くと自分でコード書いたりは全くせず、スケジュールや人の管理、いわゆるマネジメントをする仕事のイメージでした。

それに対していわゆるベンチャー企業とかでは人も少ないことが多かったのでリーダーであろうとマネージャーであろうと自分でゴリゴリ実装してる人が多かったです(というよりしないと回らない)。
そうやって自分でバリバリ手を動かしたくて、SIerとかでマネジメントやってる人がWeb系のベンチャー企業に転職するのは一時よくありましたね。

ただ、最近ではWeb系ベンチャーとかでもプロジェクトが大規模化してきているところも多く、割とマネジメント業務をガッツリやる人を置く会社も増えてきた気がします。
だからこそ、それでも手を動かす割合をある程度保ちつつマネジメントをする「プレイングマネージャー」みたいな言葉が使われるようになってきたのかなと、なんとなく思います。

プレイングとマネージャーの割合のパターン

なんとなく5:5というふわっとしたイメージですが、これは人によりけりですかね(そもそも割いてる時間とか厳密に考えてないけど・・・)。
僕の知っている&体験したいくつかのパターンを上げてみます。

マネジメント2割くらいで、基本的にプレイヤーとしてもほぼ1人分の工数を割いてる人

主に小さいチームとかでよくありますが、本当に簡易的な進捗の確認と、メンバーが相談事あれば聞いて解決したりとかだけで、基本的には自分の実装をしているパターンです。

人数が多くないのでそもそもそんなに管理することが多くない
エンジニアと別にPMがいて、マネジメントの一部だけをやっている
プレイヤーの手も足りず、最低限の部分だけマネジメントしてあとは本人に任せている

とかが多いのかなと思います。

逆に実装は2割くらいでマネジメントを重視してる人

それなりのチーム規模になってくると、前述の進捗確認とか相談事項の解決とかやってるだけでも人が多い分時間はかかるし、メンバー間の調整とかも色々発生してきます。
こうなると大規模で期限の厳しい実装とかを自分で持つのは辛くなってきます。

クリティカルパスにはならないタスクで余裕のある実装だけする
重要だけど緊急じゃない実装(スケジュール的に余裕のあるタスク)をする
突発的な対応のためのバッファとして残しておく

という感じで実装する内容をある程度絞ってることが多いかなと思います。
逆にこのスタイルで普通に自分でも実装タスク持っちゃって破綻するパターンはよくありますｗ

5割ずつくらいの人

一番バランスが難しいパターン。
5:5といいつつ8:8くらいの感覚でキャパオーバーになってしまうことも多いです笑

それなりに人数のいるチームでマネジメントをちゃんとして、かつ自分も(多少の考慮はするものの)ガッツリ1人/月の工数感で実装するくらいの規模感でやっている時ですね。

これを実現するには色々なタスクを人より早くこなすために工夫が必要になってきます。
あと、その時々の状況によって割合を6:4とか3:7とか柔軟に変えて、最終的にトータル5:5だったかな、くらいの感覚ですね。

なにができていることが大事？

僕がプレイングマネージャー的にやっていた時は、前述のパターンでいうと5:5の割合が一番イメージ的には近いです。
が、結局のところマネージャー(あるいはリーダー)としてなにができていることが一番大事かによって、割合がどうであろうと良いはずとは考えています。
冒頭に書いていた何に責任を持っているかに近いですが、それを実現するために僕は

プロダクトとしての品質の担保
メンバーのスケジュール、状態把握、改善
もちろん自分のアウトプットの品質も落とさないし、スケジュールも遅らせない

ということを、軸として意識してやっていました。
至極当たり前のことだけですが、難しいのはいかに3をキープしながら1と2をちゃんとこなせるかだと思ってます。

なので例えば色々レビューとかしないといけなかったり、マネジメントでやることの多いタイミングは自分で持つ実装タスクを減らしたり、逆に自分も結構実装しないと間に合わないような時はマネジメントの粒度は荒くして、最低限のところだけ担保できるようにして凌いだりしていました。
あとは人に任せられる部分は任せたり、若手を育てて人に振れるタスクを増やしたり。

これが正解かはわからないですが、ある程度安定したチーム体制は作れていたし、周りからの評価も得られていたのでそれなりに良いやり方だったのかなとは思ってます。

プレイングマネージャーの技術的成長

冒頭に貼ったブログでは、

これまで貯金した技術力を取り崩している感じが拭えない

貯金するペースが落ちているので、いずれは底をつく不安

といったことが書いてありました。
ただ、個人的にはプレイングマネージャーとしてやっていたからこそできた技術的成長はあったかなと思っています。

基本的にはチームメンバーみんなのタスクを決める立場なので、自分のタスクもある意味自由に決められます。
なので普通のタスクはメンバーに任せて、自分は難易度の高い箇所をやったりすることも多かったです。

もちろんメンバーの成長も考えて難易度の高いタスクを人に振ることも、メンバーのレベル感に応じてやっていました。
が、そしたらさらに難易度の高い部分のタスクを自分がやれば良いかなと。

もちろんそれでもある程度やり尽くすタイミングは出てくると思いますが、それはもうポジション関係なくそのプロジェクトで技術的成長できる部分がなくなったということなので、別の問題ですね。

また、マネージャーのところには、なんだかんだ色んな話が舞い込んできます。
難しい設計の相談だったり、障害対応の話だったり、外部チームとの連携だったり。
それらを色々と対応していることで、知識の幅も広げられました。

これらの経験のお蔭で僕は、色々な大きい開発の設計だったり、サーバーエンジニアに必要な負荷対応の知識だったり、インフラ関連の知識等々を色々と身に付けられました。
もしプレイヤーとして同じ時間を過ごしていたら、業務だけでこんなに色々な経験をすることはできなかったんじゃないかなと思っています。

なぜプレイヤーに戻ったか？

冒頭にさらっと書きましたが、今はほぼプレイヤーのポジションに戻っています。

で、なんで戻ったかというと、プレイングマネージャーとかやってると不思議なもので、自然とマネジメントの割合が増えてきてしまうんですよね。
そもそもマネジメントをやりたいエンジニアって結構貴重で、さらにちゃんとこなせる人となるともっと少なくなります。

なんで仮に最初プレイングの割合を多めにやってても、徐々にマネジメントの需要が高まってきて、そちらに割く時間も増えてきたりします。
ただ、そうなってしまうとやっぱりエンジニアとして自分のやりたいこととはズレてきてしまいます。
さすがにマネジメントの方が明らかに多くなってしまうと、技術的なアウトプットも出せなくなってしまうので・・・

といったタイミングで異動したプロジェクトもたまたまエンジニアが2人しかいないプロジェクトだったので、奇しくもマネジメントの必要もなく、バリバリのプレイヤーになりました。
まあ要はバランスが大事ですね。
前提としてマネジメントだけやるというのは嫌なので。