プレイングマネージャーなんちゃら
概要
プレイングマネージャーになった際はどうすべきか気になったので調べた。
経緯
プロジェクト管理的な諸々をやったりしているが、会社の状況的に実装も往々にして持つことがある。
会社の状況的に仕方ないし、実装をすること自体はめっちゃ好きなので苦ではないのだが、困ったりすることが往々にしてあるので、どうすべきか自分の中で整理したいと思って調べてみた。
前提
定義
プレイングマネージャとは
以下のサイトである通り、現場での仕事と、マネージャー業務の兼任のことを言うらしいです。
ソフトウェア的に変換すると、実装業務とマネージャー及びプロジェクト管理の兼任といったところでしょうか。
プレイングマネジャーとは、現場の業務を担当するプレーヤーと、部下をまとめるマネジャーの両方の役割を担う人のことです。主に課長層に多く、近年、プレイングマネジャーとして職場に貢献している人が増加しています。
どれくらいの人が対象？
以下の記事によると国内のプレイングマネージャーの割合は87.4%となっており、相当高い割合となっています。
物理的に人員が用意できないが、定期的に動くものをリリースし、早い開発スピードを保っていくことが求められる風潮は加速するので、この割合は今後も増える可能性があると考えられます。（知らんけど）
プレイングマネージャー否定派
プレイングマネージャを否定する派に関してはおおよそデメリットにフォーカスがいくと思います。
諸々探しましたが以下の記事の意見が否定派に関しては一番しっくりきました。
マネージャーという立場上、プレイヤーの仕事を持つならば成果を出すことが前提となり、マネージャーの仕事をおろそかにしてしまいがちなのです。(あと、人をどうにかする必要のあるマネジメントより、自分をどうにかすれば良い実装の方が没頭しやすく、選択しやすい)
プレイヤーとマネジャーの両方をやろうとすると、ほとんどの場合、プレイヤーとしての仕事を優先してしまいます。
なぜなら、自分のプレイヤーとしての仕事で成果を出さなければ、マネジャーとして部下に示しがつかないと考えるからです。ここにプレイングマネジャーの悩みが集約されています。
ただ、プレイヤーの仕事を優先しすぎると、マネージャーの仕事がおろそかになり、通常のパワー以上を使っているのに、両方が中途半端になり、マネージャーの立場から迷惑をかけたり、プレイヤーとして満足いかない成果しか出せない状態になりやすいのではないかと思います。
プレイングマネージャー肯定派
肯定派に関しては、対象となる割合を出していた元pdfから参照するのですが、そちらのpdfではプレイングマネージャーを推奨しております。
プレイング業務の割合とチーム成果の関係という非常に興味深い内容の図が記載しており、以下のような結果になっております。
- 行っていない:
3.08 - 20~30%:
3.27 - 80%以上:
2.86
こちらの結果になっている元pdfで要因分析し、結論を以下のように出してくれています。
「プレイング業務比率は30％未満におさえる」
「マネジャーであることで付加価値が高まるプレイング業務を担う」
「プレイング業務を戦略的に活用する」
マネジメントがおろそかにならない程度に、マネージャーとして行うべき、改善レベルと変革レベルの業務を持つべきだという見解らしいですね。
個人の意見
否定派も肯定派の意見も両方読んだ上で、個人的にはマネージャの仕事が主であるので基本的に否定派の方が腑に落ちました。
プレイング業務比率を20~30%に保ち、チームとして最大の成果を出し続けるのは、バランス感覚としてかなり繊細なのかと思っており、50%以上になった際のマネジメントが機能しなくなった状態の危険性の方が避けたいからです。
後これマネージャーが20~30%実施しているから成果上がっているだけで、チームメンバーの成果上がってる？って疑問も少々あります。(その実施率ずっと上下せずキープできるかも疑問)
働いている会社が自社開発であることもあるかもですが、プレイング業務には必ず運用・監視業務がセットでつきます。実際、マネジメントが重要な時期に、かなり重めのプレイング及び運用のタスクが過去に自分がプレイング業務を近しい行っていたことから担当になったことがありました。
主担当で担当していた箇所ではなかったので、キャッチアップから始まるし、相談できる状況でもないし、マネジメントどころではないのに、マネジメントの方はマネジメントの方でしないと各種関係者からご指摘いただくし...という状況でした。
もちろんプレイング業務を行い続けるメリットもあると思っていて、常に開発者と同じ状況にいるから、決断もしやすいし、同じ立場で悩みに寄り添うことができるのかなとは思っております。
そのメリットも考慮した上で、実施するならば以下の条件を満たしている状況のプレイング業務を行うべきなのかなと...
- 他チーム間とやりとりを頻繁に行う必要がある事象、マネジメント観点での調整がつきまとう事象
- 終了後に引き継ぎができる
- 一度も経験したことがなく、経験しないとマネジメント観点での管理に支障をきたす
- マネジメント業務が複雑になった際には受け渡すことができる
- どのメンバーに担当させても苦手分野で、チーム全体としての成果量を著しく下げる恐れがあるタスク
これができない状況ならば、稼働時間は同じの前提で、
チーム合計34タスク/2週間：マネジメントのプレイング9/Aさん10/Bさん10/Cさん5 より
チーム合計30タスク/2週間：マネジメントのプレイング1/Aさん12/Bさん11/Cさん6 のように全体成果量が局所的には減ったとしても、マネジメントの時間を確保しつつ、他チームメンバーのパフォーマンスが上がるような役回り、方法を考えるべきなのかなという結論に至りました。
前者の34はマネジメントが崩れる可能性が高く、プレイング業務ができなかった際に一気に成果量が減るのに対し、チームメンバーのパフォーマンスが上がることに注力している後者の方が長期的に見れば、チームとしての成長性と安定性を保ちつつ、マネジメントもできると思うからです。
前者は自分でやった方が早い病になりやすい気もします。
その上で、業務外は常に技術を学び続けるべきだし、副業とかでは管理とは全く違うプレイング業務のみもやってみたいと思っております。(副業はまだだが)
結論
自分なりの結論としては
- 複数条件が揃っているタスク以外はマネジメント職は持たない。
- 長期的な視点でチーム全体のパフォーマンスが上がりやすく,成果量が安定するような環境づくりに注力すべき
なのかなという結論まで整理しました。
その一方で趣味とか副業とかでコードはマネジメント職も一生書き続けるべきなのかなと。
顧客と同じ視点に立って開発することが最重要であることと同じように、
開発者と同じ視点に立てなくなった時点でそれはマネジメントと言えない気がしており。
（知らんけど橋田さんも言ってた）
備考
川島さんもm1で漫才師としても結果を出して、今も劇場では別の立場として漫才をやっているけどラヴィットでは 回しに徹してメンバーの良さを引き出すことに注力しているからこそあの鬼回しがある。
参考文献
Discussion