タケハタのブログスマートフォン用の表示で見るタケハタのブログプログラマの生き方、働き方、技術について雑多に書いていくブログです。2018-12-07プレイングマネージャーとは?この前この記事がバズっていましたね。blog.manabusakai.com僕も明確に謳ってたわけではありませんが、ちょっと前まで実質プレイングマネージャー的な動きを何年かやっていたので、その体験を元に色々と書いてみようかと思います。(ちなみに今はほぼプレイヤーのポジションに戻っています)ちなみにやってきたマネジメント的な経験で言うと、まず所属していたプロジェクトのサーバーエンジニアリーダー(最大7人いたチーム)から始まり、途中から社内2プロジェクトのエンジニアの責任者(合計で大体20人前後)もやるようになったという感じです。各メンバーのスケジュール、コンディションの担保プロジェクトをまたいでのノウハウの共有、各種連携とかをやっていました。)、プレイングマネージャーと言われていましたが、エンジニアでいうプレイングマネージャーは「手を動かす(実装する)マネージャー、リーダー」といったところですかね。昔SIerとかでの仕事が主だった時代には、プログラマの最終的なキャリアパスとしてPM(プロジェクトマネージャー)があって、そこまで行くと自分でコード書いたりは全くせず、スケジュールや人の管理、いわゆるマネジメントをする仕事のイメージでした。それに対していわゆるベンチャー企業とかでは人も少ないことが多かったのでリーダーであろうとマネージャーであろうと自分でゴリゴリ実装してる人が多かったです(というよりしないと回らない)。やって自分でバリバリ手を動かしたくて、SIerとかでマネジメントやってる人がWeb系のベンチャー企業に転職するのは一時よくありましたね。最近ではWeb系ベンチャーとかでもプロジェクトが大規模化してきているところも多く、割とマネジメント業務をガッツリやる人を置く会社も増えてきた気がします。それでも手を動かす割合をある程度保ちつつマネジメントをする「プレイングマネージャー」みたいな言葉が使われるようになってきたのかなと、なんとなく思います。プレイングとマネージャーの割合のパターンなんとなく5:5というふわっとしたイメージですが、これは人によりけりですかね(そもそも割いてる時間とか厳密に考えてないけど・・・)。僕の知っている&体験したいくつかのパターンを上げてみます。小さいチームとかでよくありますが、本当に簡易的な進捗の確認と、メンバーが相談事あれば聞いて解決したりとかだけで、基本的には自分の実装をしているパターンです。人数が多くないのでそもそもそんなに管理することが多くないエンジニアと別にPMがいて、マネジメントの一部だけをやっているプレイヤーの手も足りず、最低限の部分だけマネジメントしてあとは本人に任せているとかが多いのかなと思います。逆に実装は2割くらいでマネジメントを重視してる人それなりのチーム規模になってくると、前述の進捗確認とか相談事項の解決とかやってるだけでも人が多い分時間はかかるし、メンバー間の調整とかも色々発生してきます。なると大規模で期限の厳しい実装とかを自分で持つのは辛くなってきます。クリティカルパスにはならないタスクで余裕のある実装だけする重要だけど緊急じゃない実装(スケジュール的に余裕のあるタスク)をする突発的な対応のためのバッファとして残しておくという感じで実装する内容をある程度絞ってることが多いかなと思います。バランスが難しいパターン。5:5といいつつ8:8くらいの感覚でキャパオーバーになってしまうことも多いです笑それなりに人数のいるチームでマネジメントをちゃんとして、かつ自分も(多少の考慮はするものの)ガッツリ1人/月の工数感で実装するくらいの規模感でやっている時ですね。これを実現するには色々なタスクを人より早くこなすために工夫が必要になってきます。あと、その時々の状況によって割合を6:4とか3:7とか柔軟に変えて、最終的にトータル5:5だったかな、くらいの感覚ですね。なにができていることが大事?僕がプレイングマネージャー的にやっていた時は、前述のパターンでいうと5:5の割合が一番イメージ的には近いです。結局のところマネージャー(あるいはリーダー)としてなにができていることが一番大事かによって、割合がどうであろうと良いはずとは考えています。冒頭に書いていた何に責任を持っているかに近いですが、それを実現するために僕はプロダクトとしての品質の担保メンバーのスケジュール、状態把握、改善もちろん自分のアウトプットの品質も落とさないし、スケジュールも遅らせないということを、軸として意識してやっていました。当たり前のことだけですが、難しいのはいかに3をキープしながら1と2をちゃんとこなせるかだと思ってます。レビューとかしないといけなかったり、マネジメントでやることの多いタイミングは自分で持つ実装タスクを減らしたり、逆に自分も結構実装しないと間に合わないような時はマネジメントの粒度は荒くして、最低限のところだけ担保できるようにして凌いだりしていました。あとは人に任せられる部分は任せたり、若手を育てて人に振れるタスクを増やしたり。これが正解かはわからないですが、ある程度安定したチーム体制は作れていたし、周りからの評価も得られていたのでそれなりに良いやり方だったのかなとは思ってます。冒頭に貼ったブログでは、これまで貯金した技術力を取り崩している感じが拭えない貯金するペースが落ちているので、いずれは底をつく不安といったことが書いてありました。個人的にはプレイングマネージャーとしてやっていたからこそできた技術的成長はあったかなと思っています。基本的にはチームメンバーみんなのタスクを決める立場なので、自分のタスクもある意味自由に決められます。普通のタスクはメンバーに任せて、自分は難易度の高い箇所をやったりすることも多かったです。メンバーの成長も考えて難易度の高いタスクを人に振ることも、メンバーのレベル感に応じてやっていました。したらさらに難易度の高い部分のタスクを自分がやれば良いかなと。それでもある程度やり尽くすタイミングは出てくると思いますが、それはもうポジション関係なくそのプロジェクトで技術的成長できる部分がなくなったということなので、別の問題ですね。マネージャーのところには、なんだかんだ色んな話が舞い込んできます。難しい設計の相談だったり、障害対応の話だったり、外部チームとの連携だったり。それらを色々と対応していることで、知識の幅も広げられました。これらの経験のお蔭で僕は、色々な大きい開発の設計だったり、サーバーエンジニアに必要な負荷対応の知識だったり、インフラ関連の知識等々を色々と身に付けられました。プレイヤーとして同じ時間を過ごしていたら、業務だけでこんなに色々な経験をすることはできなかったんじゃないかなと思っています。プレイヤーに戻ったか?冒頭にさらっと書きましたが、今はほぼプレイヤーのポジションに戻っています。なんで戻ったかというと、プレイングマネージャーとかやってると不思議なもので、自然とマネジメントの割合が増えてきてしまうんですよね。そもそもマネジメントをやりたいエンジニアって結構貴重で、さらにちゃんとこなせる人となるともっと少なくなります。なんで仮に最初プレイングの割合を多めにやってても、徐々にマネジメントの需要が高まってきて、そちらに割く時間も増えてきたりします。なってしまうとやっぱりエンジニアとして自分のやりたいこととはズレてきてしまいます。マネジメントの方が明らかに多くなってしまうと、技術的なアウトプットも出せなくなってしまうので・・・といったタイミングで異動したプロジェクトもたまたまエンジニアが2人しかいないプロジェクトだったので、奇しくもマネジメントの必要もなく、バリバリのプレイヤーになりました。要はバランスが大事ですね。前提としてマネジメントだけやるというのは嫌なので。プレイングマネージャーやって良かった?ここまでで既に書いてますが、やって良かったと思っています。確実にプレイヤーとしてやっているだけでは得られない経験をできたし、その経験がプレイヤーに戻った今も確実に生きています。必要とあらばやろうとは思っているし、やる機会は今後また来るんじゃないかなとも思っています。はてなブログProプログラマとしての生き方とか、働き方とか、技術のことを雑多に書いていきます。CODE-セブンスコード-」のバックエンド技術DockerでMySQLを起動した時はバージョン差異に注意ブログの技術記事で書く内容をパターン分けしてみた2019年を雑に振り返る月別アーカイブはてなブログをはじめよう!take7010さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。