Player Manager

理想のPMとはなんだろう。

大人数が関わる開発において、PMの仕事は多岐にわたる。プロパーと業務委託と外注の管理。コスト計算。チケット管理。品質管理。スケジュールの調整。障害が起きたら報告書を書いて、偉い人に説明して、再発防止策を出す。会社によってはEMやTLに権限が分散していることもあるが、最終的に「で、どうするの」と聞かれるのはPMだ。

小さいチームならプレイングマネージャーが成立する。自分でコードを書きながら、チームの方向を決められる。5人くらいまでなら、設計も実装もレビューもやりつつ、顧客と話して仕様を決めることもできる。

10人を超えたあたりから、それが壊れ始める。

コードを書いている時間に、Slackの未読が溜まる。レビューが滞る。ミーティングが増える。自分がボトルネックになっていることに気づく。コードを書く時間を削れば回るが、コードを書かなくなったPMは現場の温度感がわからなくなる。技術的な判断がずれ始める。かといってコードを書き続ければ、マネジメントが雑になる。

結局、ある規模を超えたらプレイヤーを降りるしかない。降りたくないのに降りるしかない。コードを書くことが好きでこの仕事を始めた人間にとって、それはなかなかつらい選択だ。

プレイヤーのままマネージャーになれるという幻想は、プレイヤーの傲慢かもしれない。わたしはその傲慢を捨てきれずに、結局辞めた。いまはAIがコードを書いてくれるので、プレイングマネージャーの定義自体が変わりつつある。あの葛藤が遠い過去になりつつある。