chomeブログ

エンジニアリングマネージャーの備忘録です

プレイングマネージャーは悪手か?

■背景

いくつかのチームでマネージャーを経験する中で得た、プレイングマネージャーについての考えを整理してみました。以前は、マネージャーはマネジメントに専念すべきでプレイングマネージャーは人手不足を補う次善の策でしかないという考えを持っていました。ただ、いくつかのチームでマネジメント業務を経験する中で、プレイングマネージャーにもメリットがあり組織設計次第で取りうる選択肢になるという考えに変わりました。

プレイングマネージャーは悪手か?

◎成果が最大化できるかで考える

マネージャーの仕事はチームの成果を最大化させることです。そう考えると、必ずしもメンバーに任せるだけが正解ではなく、自分が動いた方が成果が出せる場合は動いても良いことになります。マネージャー自身のリソースは有限であるため、自分がプレイする割合とマネジメントにまわりメンバーに任せる割合を調整し、成果が最大化される塩梅を見つける必要があります。その時々で以下の方程式を解くようなイメージです。

成果を求める方程式

ただし、この方程式には時間軸は考慮されていません。眼の前の成果を優先しマネージャーがプレイし続けていると権限委譲が進まずメンバーの成長が阻害されてしまいうことがあります。上の方程式で言うと「メンバーのプレイスキル(定数)」がずっと変わらないことになり、そうなると長期的には成果が頭打ちすることになります。マネージャーがプレイングを担うことは短期的にはありですが、長期的な成果を考えると成長につながるようなタスクは極力マネージャーから手放していくべきだろうと考えます。

プレイングマネージャーはなぜ忙しいのか?

◎相反する動きが求められる

プレイングマネージャーは業務過多になりがちです。単純にやることが多いからといえばそれまでですが、私の経験上、相反する性質の動きが求められることで、物理的にも体感的にも忙しさが増していると考えます。

マネージャーに求められる動きは環境によって変わるのであくまで私の場合の話ですが、当時私がマネージャーとして求められていたのは、他のメンバーが成果を出しやすい状況を作ることでした。それには全体を俯瞰して見ながら社内調整などの細かいタスクをマルチに素早く打ち返すといった動きが必要でした。一方で、リードプレイヤーであることも求められており、他の人にはできない難易度の高い仕事を担当し、まとまった時間と集中を要する仕事をしていました。

前者と後者は真逆の性質の動きになっていたため、タスクの優先度付けも時間の確保もめちゃくちゃ難しくなり、結果、プレイヤー業務は残業時間に集中してやることでなんとかカバーしていました。くわえて、業務によってマインドを切り替えることのオーバーヘッドは大きく、体感的な忙しさも飛躍的に上がっていたと思います。まるで、ボクシング選手とセコンドとの両方を一人で担っているような感覚がありました。

前述の「成果を求める方程式」のところでメンバーの育成観点で長期的にはプレイングマネージャーは脱するべきと書きましたが、マネージャー自身の負担的にも、過度な疲弊を生むため長続きするものではないと考えます。

■専任マネージャーのジレンマ

◎現場感の喪失

ではマネージャーに専任できることは幸せでしょうか?

私もずっとプレイングマネージャーをしていたわけではなく、マネジメントに集中できていた時期もあります。その時はメンバーが成長し権限委譲も進んでいたこともあり、私自身はメンバーをサポートすることに集中でき、チームとしても成果が出ていたと思います。ただ悩みがなかったわけではありません。

しばらく自分で手を動かす業務から離れることで、メンバーの方が今のシステムに詳しいことが多くなっていくことに、淋しさと焦りを感じるようになりました。気持ちの問題だけであればまだ良いですが、現場の感覚が薄れることで技術的な判断やメンバーの評価がだんだんと難しくなっていきました。まるで技術の貯金が切り崩されていくような感覚がありました。

マネージャーであり続けるためには、現場感を失わないためのキャッチアップが必要となり、定期的にプレイヤーよりの動きに戻らねばならないというジレンマのようなものを感じました。 (最近マネージャーからICに戻る人の話をよく耳にしますが、あれはここに起因するところがあるのかなと想像します)

■一つの理想形

◎小さく優先度の低い「ささやかな作業」を担当する

プレイングマネージャーであることは、現場感を維持するのに良い方法のように見えます。ただ前述のようなリードプレイヤーの動きも求められるマネージャーだと、疲弊を生み長続きしません。

書籍「エンジニアのためのマネジメントキャリアパス」によると、管理者は管理業務のかたわら「バグの処理やちょっとした機能の作成」といったささやかな作業をするとよいとあります。ITスキルを維持し、現場の問題を察知することにつながるためです。また、ささやかな作業であれば、いざというときは優先度を下げ、管理者がボトルネックになることを避けることもできます。

前述のリードプレイヤーは、マネージャー自身が直接成果に貢献するアプローチでしたが、こちらの「ささやかな作業」を担当する方法は現場感を維持することで「マネージャーのマネジメントスキル」を保ち、長期的に高い成果を上げるアプローチだと言えます。

マネージャーは現場感・マネジメント力を維持する目的で小さく優先度の低い「ささやかな作業」を担当する、成長につながる難易度の高いタスクはメンバーに渡しチーム全体の成長を促す、という在り方が、長期的に安定して高い成果を出せる形であると考えます。

◎マネージャーオブマネージャー

では専任のマネージャーは必ず成り立たないものでしょうか?一つありうるのは、プレイングマネージャーをマネージするマネージャーオブマネージャーであれば持続可能なのかなと考えます。

専任マネージャーの問題は現場感の喪失にあると述べました。ただ、マネージする対象がマネージャーであれば、その接点は自分が専門とするマネジメントに関する判断や評価、壁打ちになることが主となるため、相手の方がいつの間にか詳しくなっているということが起きにくいのかなと思います。少なくとも全く話についていけなくなるということは無いはずです。プレイヤーをマネージする専任マネージャーよりも、ジレンマにはおちいらず長続きするのではないかと考えます。

採用難易度を踏まえるとそんなにマネージャー集められるのかという疑問もあるのであくまで理想形の話として、プレイングマネージャーをマネージするマネージャーオブマネージャー(長い!)はありではないでしょうか。

■おわりに

プレイングマネージャーについて考察してみました。コア業務を担うようなプレイングマネージャーは、短期的にはありだが、育成観点と難易度の高さから、長期的には脱するべきであるという考えを述べました。一つの理想形として、「ささやかな作業」をするプレイングマネージャー、およびマネージャーオブマネージャーの形を提示しました。

理想の形を書いたものの、昨今のエンジニア不足を考えると、チーム内のできるエンジニアがマネージャーに選ばれ、なし崩し的にマネジメントとプレイングを両立せざる得なくなることはあるあるだろうなと思います。採用や育成、長期的な組織設計で、プレイングマネージャーが無理を被らないチームにしたいものです。