【EMConf 2025】プレイングマネージャーのアンチパターンを回避するための、3つの条件｜カミナシ EM すずけん

2月27日に開催された、EM（エンジニアリングマネージャー）関連の3コミュニティが共同運営する大型カンファレンス「Engineering Manager Conference Japan 2025」。

本レポートでは、株式会社カミナシでEMを務める、すずけん（鈴木健太郎）氏のセッション「プレイングマネージャーは本当に悪なのか？　令和時代のプレイングマネージャーを戦略的にハックする」をご紹介します。

ネガティブな側面から語られがちな「プレイングマネージャー」に有効性を見出し、自ら「やりたい」と名乗りを上げて挑戦したというすずけんさん。登壇では、プレイングマネージャーというロールを検討し始めたきっかけや、実践から気づいた、アンチパターンに陥らないための条件を紹介。内容を一部再編成してレポートします。

• keyboard_arrow_down プレイングマネージャーは本当に悪なのか？
• keyboard_arrow_down AI時代の今こそ、「プレイングマネージャー」は機能するはず
• keyboard_arrow_down 価値提供のアジリティを高めるために、プレイングマネージャーになる
• keyboard_arrow_down アンチパターンをなぞらないための、3つの条件
• keyboard_arrow_down プレイングマネージャーは「制約」と「誓約」ありき
• keyboard_arrow_down 「プレイングマネージャー」を経ることで、段階的に「EM」に近づいていける
• keyboard_arrow_down 発生しやすいリスクへの対策は必須
• keyboard_arrow_down 「プレイングマネージャー」は、EMの1つの型

今日は「プレイングマネージャーは本当に悪なのか」というお話をします。僕はカミナシでEMをやっています、すずけんです。ICとして入社し、技術負債の解消やプロダクト開発に携わり、昨年5月の新規事業の立ち上げに際し、プレイングマネージャーをやりたいと言って以来約半年ほどやっています。

今日は
・プレイングマネージャーに挑戦することになった背景
・プレイングマネージャーというロールを機能させるために考えたことや行動したこと
・実践の中から得た気づきや学び
を共有します。逆に、技術的な判断や振る舞いの具体的なエピソードに関しては触れないので、ご了承ください。

では、早速ですが質問です。皆様は「プレイングマネージャー」と聞いてどんな印象を持ちますか？　僕の印象では「プレイングマネージャー＝アンチパターン」です。同じように思った方もいるのではないでしょうか？　プレイングマネージャーの一般的な印象は、やはり「プレイングに気を取られちゃって、マネジメントが疎かになるのではないか」というものだと思います。リスクとしては特に、組織課題を見失ったり、マネジメントの質が低下したり、意思決定がプレイヤー寄りになっちゃうんじゃないか、といった点が挙げられます。

でも、ちょっと待って欲しいんですよね。世の中のCTO、VPoE、EMの中には、自身で手を動かしてらっしゃる方っていません？

弊社のCTOが原トリっていうんですけど、彼もそのうちの1人です。でも、マネジメントがおろそかになっているという印象はそんなにありません。じゃあこういう人たちは、プレイングマネージャーって言わないんでしょうか？

プレイングマネージャーについて語られるとき、「できない理由」や「リスク」などマイナス面からスタートしがちです。でも実際には、何かしら理由やメリットがあるからプレイングマネージャーをやっているはずです。今日は、プレイングマネージャーの必要性や背景、有益性といったプラスの面を検討してみたいと思います。

では、「プレイングマネージャーは本当に悪なのか」という疑問に対して、僕自身が実際にプレイングマネージャーに挑戦するまでの経緯を説明します。

カミナシに入社して約半年が経った頃。当時僕はICでしたが、「スタートアップにもかかわらず、プロダクト開発の進みが遅いな」「チームのアジリティがなかなか上がらないな」という疑問を持っていました。

その原因のひとつに「EMの不足」がありました。しかしEM採用の難易度は非常に高く、すぐに増員できるわけじゃありません。そこで、EMの不足を社内で補うために、社内のICをEMにトランジションすることになりました。

カミナシにおけるEMの主な責務はピープルマネジメントです。実装タスクをやらないで、と言っているわけではないものの、実際にICからEMになると、そうした機会はほとんどなくなります。ICの僕から見ると、実質的に現場で手を動かすメンバーが減っているように見えていました。

とはいえ外部環境の変化は待ってくれない。組織として沢山あるやりたいことが、減るわけではありません。じゃあどうすればいいのか？と考えたとき、ひとつの仮説にたどり着きました。「AIを使ってプレイヤー業務を効率化できる現代であれば、“プレイングマネージャー型のEM”というアプローチが有効なんじゃないか」と考えたのです。

この仮説への期待は2つ。

1つ目は「意思決定と実行の一体化」。ピープルマネジメントはすごく大事だと理解している一方で、スタートアップとしてはプロダクト開発のスピード感も重要です。プレイングマネージャーとしてのEMがいることで、プロダクトの最前線で意思決定と実行をセットで推進でき、開発のスピードをより高められるのではないかと考えました。

もう1つは「AIによる業務効率化」。AIサービスによって、プレイングマネージャーのプレイヤー業務はかなり圧縮でき、マネジメント業務のための可処分時間を確保できるのではと考えました。

この仮説をもって、当時のEMに「プレイングマネージャー型のEMをやれないか」と提案したんですが、却下されました。これはすごく真っ当だったし、僕の伝え方が良くなかった部分もありました。

既存のプロダクトに対しては、プレイングマネージャーはなかなかワークしなさそうだというイメージがありました。これは今から振り返っても、僕もそう思います。それと、僕はICとして入社しているので、ICとしての成果をきちんと追求してほしいという要望がありました。これもすごく納得のいく理由ですね。

振り返ると当時は、僕の「価値提供のアジリティを高くしたい」という気持ちと、組織の「今はチームでのプロダクト開発を安定させていきたい」という要件が、うまく整合していなかったんだろうなと思っています。

そして月日は流れます。約半年後、仮説検証をしていたひとつのビジネス案が、新規事業として立ち上がることになりました。このタイミングで、CTOの原トリから、「プレイングマネージャー型のEM」としてのオファーを正式にもらいました。

ここでようやく、僕の「価値提供のアジリティを高くしたい」という思いと、組織の「マルチプロダクト化をより早くスピード感を持って実現していく」という要件が整合したのかなと実感しています。

次に、プレイングマネージャーとして工夫したことを話すまえに、まずは結果を伝えます。手前味噌なんですが、チームにとってすごくいい影響が出て、めっちゃいい感じになりました。CTOの原トリからも「カミナシらしさの一例」として評価されるぐらいうまくいきました。

めでたくプレイングマネージャーのオファーをもらったとはいえ、何も考えずにやっていれば冒頭にあったアンチパターンをなぞることになるだろうと予測していました。そのため、プレイングマネージャーをしっかり機能させるためにしたことを3つ、紹介しようと思います。

1つ目は、組織的なサポートへの期待を伝えること。僕ではコントロールできないことを、組織的にサポートしてくださいというお願いをしたのです。

もちろん全て叶うわけではないし、そうした期待はしていない。でも、僕がプレイングマネージャーとしてチームを率いるうえで、将来リスクになりそうな点の不確実性を極力減らしていきたかった。

なので、僕がプレイングマネージャーを務めるうえでの不安を包み隠さず正直に伝え、「組織的にサポートできませんか」と頼みました。ひょっとするとEMとしてあるまじきことかもしれませんが「自立、自走できるメンバー構成だと嬉しい」とか、「評価対象の人数は最小限にしたい」といったこと。また、僕はフロントエンドがさほど得意ではないので、フロントに強いメンバーを入れて、チーム全体で技術力のカバレッジを保てるようにしたい、とも相談していました。

2つ目は、僕が担う「プレイヤー業務」を、ただコードを書くとか手を動かすことと捉えるのではなく、「アカウンタビリティ（責務）」として捉えることです。

EMの責務には、ピープルマネジメント、テクノロジーマネジメント、プロジェクトマネジメント、プロダクトマネジメントという4つのカテゴリがあります。その中で僕が今回のタイミングで、何に重点的にコミットするのかを明確にしたのです。こうして「プレイヤー業務」を「責務」として捉えることで、行動に対する迷いが減り、今のプロダクト開発に必要な振る舞いだけに集中することができました。

3つ目は「テックリードではなく、あくまでもEMである」ということを忘れないようにしていました。

「プレイングマネージャー」は、あくまでもEMの型の1つだと思っています。なので、採用や評価、メンバーの成長支援など、これまであまりやったことがない業務への学習や、仕事を通じての実践にも取り組んでいました。

やってみてぶっちゃけどうだったのか？　生々しい話をすると、メンバーには「あまりハードワークしないでね」と言いながらも、僕はめっちゃハードワークしてました。ごめんなさい。

とはいえ、僕自身のキャリアにおいて、この経験は次へのステップに繋がると感じていたし、つらさより楽しさが上回っていたので、全く苦ではなかったです。

ここにいる皆さんもわかって頂けると思うのですが、手を動かすの、めっちゃ楽しくないですか？　自分本位な観点ですが、何かつくるのはやっぱり楽しい。それに、自分も実装に関わっているから、メンバーの見積もりの妥当性も判断しやすい。チームがうまくワークし結果が出てくると、マネジメント自体が楽しくなってくる。意思決定と実行を一致させながら、アジリティ高くどんどん価値提供していける状態になっていきました。

ここからは、「プレイングマネージャー」を実践する中で、どんな学びを得たのかをお話します。

実際にやってみて、プレイングマネージャーは「制約」と「誓約」ありきだと実感しました。「制約」とは「組織的なサポート」、「誓約」とは「責務への当事者意識」です。

組織的なサポートによって、制約を満たすチームをつくってもらわないと、なかなかワークしない。つまり、自分1人でプレイングマネージャーをやりたいといってワークできるわけではなく、環境をつくってもらう必要があるわけです。

その上で、プレイングマネージャーをするからには「スピード感のあるプロダクト開発を行うこと」「チームにインクリメントをもたらし、モメンタムをつくること」へコミットするという誓約が必要だと思っています。

そして不思議なことに「プレイングマネージャーです」と表明すると、僕の役割が明確になることで、周りの期待が自然と整っていく実感がありました。

やっぱりEMって、ICやメンバーから見たときに、何をやってるか分かりにくいんですよね。でもプレイングマネージャーをやっていると、プレイヤー業務での貢献が周囲に見えることによって、僕が何をやっているのか知ってもらいやすくなっているように感じました。

逆に自分にとっては、EMとしての光景も、プレイヤーとしての光景も見えるようになります。そのおかげで、メンバーの評価もしやすくなります。実装レベルでメンバーと一緒に働くので、メンバーがどれぐらい難しいことにチャレンジしているのか、頑張ってくれているのかを、より正確に把握できます。メンバーにとっても、評価に妥当性や納得感が自然と生まれているように思いました。

また、プレイングマネージャーをやってみるのは、EMキャリアの試金石に使えるのではないかとも感じています。

EMという役割に、ICとは別の楽しさを見いだせるのかどうかは、やってみないと分からない。とはいえ一度マネジメント方面に進んだら戻れない、というイメージはあるから一歩踏み出しづらい。その場合、一度プレイングマネージャーをやってみるのがいいのかなと思います。やってみて、向いていなかったとしたら、ICに戻ればいいのです。その経験は無駄にならないし、ICに戻ったときにも「EMが困っているようだ、僕も困っていたから助けてあげよう」という気持ちにつながると思います。

また、プレイングマネージャーを務めることで、ピープルマネジメントに段階的に挑戦することもできます。

右側の図は「エンジニアリングマネージャーのロードマップ」という、海外のサイトにあったものです。このロードマップでは、最初はテクニカルリーダーシップから始まり、徐々にピープルマネジメントに向かっています。

一般的にはEMをやることになってから、いきなりピープルマネジメントにパラシュートすることになります。それでもいいけれど、プレイングマネージャーを務めることで、このジャンプを少し小さくすることができます。プレイヤー業務の中でテクニカルリーダーシップをとってチームに貢献したうえで、マネジメント業務としてピープルマネジメントに少しずつ取り組むことで、ピープルマネジメントの帽子をかぶっている時間を少しずつ長くしていけるのです。

それに、プレイングマネージャーをやることで視座が上がる、とも感じました。

プレイングマネージャー型のEMになると大量の情報が集まってくるので、それらを使い、今までより1つ高い視座から、未来を想像して意思決定する機会が増えます。こうした、正解がない判断を積み重ねる経験が、僕の視座を高くしてくれた実感があります。

最後に、プレイングマネージャーをやるうえで発生しやすいリスクとその対応策を紹介します。

プレイングマネージャーって、やっぱりハードワークにはなっちゃうんですよね。そのため、気づかないうちに自分自身がリスクになっている可能性があります。例えばワーカーホリックになるリスクや、単一障害点になったりするリスク。

これらを回避するには、取り組むことの優先順位を決めたり人に頼る練習をしたり、またはチームメンバーにしっかり右腕になってもらって、自分がいなくても回るような組織にしていくことが大事だと思っています。

まとめです。プレイングマネージャーをやってみた僕なりの解釈では、プレイングマネージャーとは、責務に対してオーナーシップを体現するひとつの型だと考えています。

分解すると「プレイング」＋「エンジニアリングマネージャー」となり、「プレイング」は成果責任に対する行動、「エンジニアリングマネージャー」は実行責任に対する役割を指します。

プレイングマネージャーは「制約」と「誓約」の上に成り立つものです。組織的なサポートという制約と、自分で責務を選択して果たすという誓約があってこそ機能すると思っています。これらの前提を理解した上で「プレイングマネージャー」という役割を活用できるのであれば、課題解決や組織設計、キャリア形成に大きなゲームチェンジングをもたらす選択肢となりえるんじゃないでしょうか。

最後に。僕がプレイングマネージャーをオファーされた時、CTOの原トリは言いました。「すずけんさん、僕はプレイングマネージャーというポジションを設けることには賛同できない。だけど、期待値をもって「プレイングマネージャー型のEM」としてオファーします。やるならばサポートするので、何があったら上手くいきそうか、対話していきましょう」。このアクションはまさに、プレイングマネージャーにおけるリスクの側面だけを見て思考を停止するのではなく、ワークした時の効果に期待して物事を推進するというリーダーシップの形だと思うんですよね。

ぜひ、今回共有した話をもとに、組織で改めて「プレイングマネージャー」について議論してもらえたらうれしいです。以上、「プレイングマネージャーは本当に悪なのか？」ご清聴ありがとうございました。

執筆・編集：光松 瞳