こんにちは、リーナーの id:yusuke-k です。 リーナーのプロダクト開発の現場では基本的にマネージャーと言われる人がいません。 なぜそうなっているか、という話を書いてます。
この記事は ながらRuby会議01 で登壇したスポンサーLTを元に加筆しています。
リーナーについて
リーナーは調達購買領域で、BtoB SaaSを開発提供しているスタートアップです。 調達購買とはいわゆる「企業の買い物」です。複雑なプロセスが絡み合う領域ですが、現在はその中でも、見積や購買（発注）における業務を中心に扱っています。
リーナー見積, リーナー購買 というプロダクトを主力にしています。
マネジメントは必要だが、マネージャーは必ずしも必要ではない
マネジメントは組織の機能であって、役割なのに、なぜマネージャーが必要なのでしょうか。よいプロダクト、よいチームをつくるのに、みんなでマネジメントできればマネージャーはいなくてよいのでは？
そういう疑問をずっと思っていました。
マネージャーをつくる弊害
- 責任とプレッシャーがマネージャーに全集中する
- → 楽観的な人しか持続できない
- マネージャー vs プレイヤーという対立構造ができる
- 枠をつくると、必ず対立構造も生まれる
- → 鈍感力のある人しか持続できない
- マネージャーにだけ情報が集約される
- 権威勾配、情報格差が生まれる
- → 社内政治の温床になる
マネージャー = チームの限界
マネージャーの能力限界がチームやプロダクトの限界になります。どれだけ有能なメンバーが集まっても、マネージャーとの相性次第で生死が決まります。その結果、万能スーパーマンしかマネージャーになれない、もしくはマネージャーになったとしても成果を発揮できません。
せっかく優秀なメンバーが集まっても、マネージャーとなる一人のせいでチームがポテンシャルを発揮できないのは大きなリスクです。
個人的な疑問
よくマネージャーの説明として「成果の最大化」を上げる人が多いです。
- ex. "PdM はプロダクトの成果に責任を持つ"
- ex. "EM はチームの成果を最大化させるのが責任だ"
しかし成果の責任は、マネージャーに限らずすべてのメンバーが持つべきではないでしょうか？ それを切り離してしまったら、何のためにチームに人が集まっているのかわからなくなります。
ここからリーナーの話に入ります。
リーナーのマネジメント
- 5 年前（2020年9月）に一人目エンジニアが入社
- 社員総数 100 名ちょっと（2025 年 10月現在）
- そのうちのエンジニア・デザイナー総数
- 社員 27 名（内定者含む）
- 業務委託 5名前後
リーナーのプロダクトマネジメント
- 特徴
- リーナーは エンプラ toB SaaS（一社の単価が大きい）
- 顧客要望を深掘りする重要度が高い
- 意思決定
- 顧客フロントの セールス・CS と開発担当 Dev が議論して決める
- リードするメンバー、フォローするメンバーが開発のテーマごとによって入れ替わる
エンプラ toB SaaSなので、toCよりも利用するユーザーの層が絞られます。 顧客要望を考慮するときも、質を重視して深掘りしています。 そこで大事なのは、顧客フロントに立っている現場のセールス・CSメンバーとの協力です。
CSが顧客との関係性をグッと握ってくれているので、Devも「どんな問題をプロダクトでどう解くべきか」を深く掘り下げて考えることができます。
〇〇マネージャが介在することなく、現場のセールス・CSとDevが同じ目線で顧客が抱える問題と、プロダクト課題について議論する のを重視してます。（社内では "BizDevMix" と呼んでいます）
（詳しく知りたい方はカジュアル面談で聞いてください）
リーナーのピープルマネジメント
- リーナーのロール
- Ace, Captain
- Captain によるピープルマネジメント
- チーム内での「期待合わせ」
- チーム内外での「よもやま」,「相棒」
リーナーではCaptainと呼ばれるロールを持ってる人が主にピープルマネジメントを期待されてます。 とはいえAce, Captainというロールはあくまで便宜的なものであり、どちらかにパキッと分かれているものでもありません。
事業を成長させるために必要ないろんな役割を、各自が自己判断で汲み取って、自分が今できる最善を探せる ことを重視してます。
その自己判断をするための補助として、チーム内で期待をすり合わせる「期待合わせ」、チーム内外でコミュニケーションを深める「よもやま」「相棒」という取り組みをしています。
（詳しく知りたい方はカジュアル面談で聞いてください）
マネージャーをつくらないことによる問題
理解できる人が限られる
おそらくマネージャー経験者や、社会人としてのキャリアがある程度ある人からすると理解できることが多いと思いますが、キャリアの浅い人からすると、理解がしにくいと思います。
リーナーのやり方は、一人ひとりが自律して、周りと協調しながら自己判断でチームワークができることを前提に考えられています。
将来的にはジュニアメンバーにどうこの考え方をオンボーディングしていくかが課題になりそうです。
採用難易度が高い
シニアな人でも、リーナーの自己判断を重視するチームワークが合わない人はいます。 特に自分のキャリアに強いこだわりがある人は合わない可能性が高いです。
採用時には、この考え方に合うカルチャーマッチを考慮しないといけないので、採用難易度は高いです。 （逆に採用のミスマッチを防ぐ防波堤にもなっているのでメリットでもあります）
マネージャーをつくらないことにこだわってるわけではない
こだわりたいのは必要性の言語化です。
- なぜプロダクトマネジャーが必要なのか？
- なぜエンジニアリングマネージャーが必要なのか？
- なぜCTO, VPoE が必要なのか？
それはマネージャーにだけ任せるべき責任なのか？ を常に考えたいです。
「マネージャー」と呼ばずに役割を作ることもできるはずです。
- 新規メンバーのオンボーディングを担当する人
- （ジュニアメンバー含めて）チームのスキルアップを担当する人
- （ジュニアメンバー含めて）メンバーのキャリアについて相談に乗る人
- チームメンバーのアサインを調整する人
- プロダクトのロードマップを決める人
- エンジニアリングの技術方針を決める人
- ...
一般的な「⚪︎⚪︎マネジメント」と呼ばれている役割にはいろんな意味や期待が雑多に含まれています。 一つの役割に詰め込みすぎてるのが全ての元凶だと思っているので、それを丁寧に分解していく作業が必要です。
それをせずに、思考停止して「⚪︎⚪︎マネージャー」をつくるのは良くないよね、という思想を持って、リーナーでは組織づくりをしています。
