📒
プロダクトマネージャーの3分類
Rebuild.fm #126 のTaro Minowa (@higepon)さんの回で語られたプロダクトマネージャーの分類の話について。
個人的にhigeponさんのBlogもよく読んでいる。
この回は内容が大きく2つから構成されている。
- エンジニアにとってのTech Leadというキャリアパスについて
- プロダクトマネージャーの分類と難しさについて
本題として扱いたいのは2についてなのだが、1のTech Leadという役割、キャリアパスが新鮮かつエンジニアの組織を考える上でとても有用だったので、簡単に触れたいなと思います。
なおTech Leadに関する @higapon さんの考察サマリはご自身がブログに書かれてあるので詳しくはこちらを見ると良い。
Tech Leadとは
そもそもTech Lead(TL)とはどういう役割なのか。要約すると以下のとおりである。
- エンジニアチームの生産性にコミットする
- 技術的に最も詳しく、チームの技術的な決断（アーキテクトデザインなど）に責任を持つ
- チームのコード品質に責任を持つ
TLと対象的なロールとしてEngineering Manager(EM)が挙げられる。EMの主な役割はこうだ。
- チームのキャリアに責任を持つ
- チームの仕事を取ってくる
大きな違いとしてはPeople Managementをするかどうかの違いのようだ。
TLは技術に関してチームの中で最も長け、主にコードをマネジメントする。そのために、コードレビューにかなりの時間を割き、自身がコードを書く時間は50%未満。一方でEMはメンバーのやりたいこと、モチベーション、キャリアなどにコミットする。
Tech Leadが抱えがちなジレンマとして
- チームで使用する技術に最も詳しくなくてはいけない！
- しかし実際はコードレビューばかり
みたいなのがよくあるみたいだ。
Tech Leadのキャリアパス
Chief Architect(CA)のパスとしてLT、VP of Engineering(VPoE)のパスとしてEMというような整理がされていた。
VPoEはエンジニアチーム（組織づくり）に、CAは技術的な最上段のイシューであるアーキテクトにコミットする存在なので、その前のパスとしてそれぞれLT、VPoEが存在するという認識がUSでは一般的のようだった。
エンジニアの多くはマネジメント職には就かない。ではマネジメントを目指さない、技術で尖っていきたいエンジニアが何を目指すのか、という論点に対しての一つの答えがTLであるという。
付随して、
- 日本ではこういったラベルの定義が曖昧なため、LTなどの語句を使っても共通認識として捉えられない事が多い
- ただUSならLTとEMが綺麗に仕事が分かれるかというとやっぱりそんなこともなく、兼務だったり仕事の一部をなし崩し的に受けることも多い
- なし崩しで仕事を受けると言う意味だとProduct ManagerはUSでもボールを拾ってて大変そうだ
といった議論があるようで、現実味があり面白かった。
Product Managerの分類
本題。higeponさんが様々なProduct Managerと一緒に働いた経験から、「Product Manager勝手に3分類」を紹介している。それは以下の様なものだ。
- 戦略的なロジカルタイプ
- 直感的芸術家右脳派タイプ
- 経験に裏打ちされた直感タイプ
各タイプの特徴を僕の理解も含めて簡単に整理すると、こんな感じ。
タイプによる適正
上述のProduct Managerのタイプは、突き詰めると以下の2点に大きな影響を与えてくるように思う。
- 創りだす仕様の未来感
- チームの生産性 = 開発速度
データや数値を重視する戦略家タイプは、とくにチームの生産性の面で高い効果を発揮する。数値という共通言語での説明を行っていくので、PMの上司もまたその数値を上司に伝えれば良い、というような情報の整理と交通がスムーズになり、納得感が生まれやすい。
対象的な芸術家タイプは、「理由」を説明するのが難しい仕様を作ってくるが、誰もが信じられないようなproductほど成果をユーザーに受け入れられたりする。
ただどんなタイプのProduct Managerであれ、Productをローンチすると言う行為は誰にとっても”賭け”である。いずれにせよリリースしないとそのProductが実装する未来の機能は良いものなのか判断できないので、成功にこぎつけるにはリリース後の運用のセンスや泥臭さのほうが重要かもしれない。
そういう意味では適正というのは合ってないようなものかもしれない。
一緒に働きたいProduct Manager
結局はどんなタイプであろうと、信念のあるProduct Managerと働きたい というのが偽らざる事実のようだ。
ある機能をリリースする際に、やってはいけないNGトークスクリプト
「でもこっちのほうが良いと思います」 「じゃあ設定でかえれるようにしよう」
→たしかに信念がない。こんなPMは嫌ですね。
僕の持論でもあるが、やっぱりPMに求められるのは偏執= 確固たる勘違い じゃないかと思います。
結局はセンスである
とはいえ、Productを創りだす際は大体にしてPM/LT/デザイナーの3人で全体の設計を進めていくことになる。が、この場合センスがない人が一人でもいると大変ですよね〜という話があった。
- センスの有る人とそうでない人が議論すると、最終的にセンスある人が議論に勝って意見に採用される
- 回数を重ねると、やっぱり人と人なのでセンスある人がクソな意見だとしても全否定ができなくなる
- 「あなたの意見もよいと思うけど、こっちのほうが良いよね」というコミュニケーションになる
すると2つ問題が起きる
- センスの人が妥協した意見を形成するようになり、最終的に妥協の塊のようなプロダクトが出来る
- センスのない人が20%くらい承認されることで、センスの無さに非自覚になる、伸びなくなる
Product Managerのキャリアパス
Product Managerには、これといったキャリアパスがない。
higeponさんの経験則だとProduct Managerの50%はエンジニア出身だとのこと。 それ以外のキャリアパスとしては、プロジェクト/プログラム単位のマネジメントを行っていた人間がその過程で関係各所との信頼関係を築き、職種を転換してジュニアのProduct Managerへ転換してくるパスがあるそう。
プログラマであればコンピューターサイエンスを学ぶことで、キャリアをスタートできるように、「 これを大学で学んだからProduct Managerになれます」というような必修科目はProduct Managerにはない。
ただ、ないからこそPMのすべき仕事の定義は明確にし、その中で自分の強みを発揮していくほうが個性的なPMがたくさん生まれて良いんじゃないかなと思う。 僕自身はマーケター→PMというおそらく珍しいパスを進んでいて、Productの設計思想はマーケティングプランを包含したものになっていく。
うちは今ECなので、僕が創る仕様はpurchase funnelを改善していくかにすべて落としている。 たしかにプログラミングについての知識が乏しいのが僕の弱点なので、その点を補えるように
- この仕様はサービスに本当に効くのか？
- 事業は伸びるのか？
を丁寧にbreakdownして仕様を創り、コミュニケーションしていくことで、典型的なPMと違った価値が出せれば、と思ってます。
まとめ
今回のRebuildは相当に内容が濃かったため、着想を得る箇所が多く、まとめていたら、まとまりがなくなっていてなんか申し訳ない。
- プログラマーのパスとしてのTech Leadがあり、より技術的責任を負いながらキャリアを積んでいく道もあるよ。
- Product Managerはざっくり3つに分類できるけど、結局のところセンスと根性だと思うよ。
- Product Managerの多くはプログラマー経験者だけど、そうじゃないパスで強みを築くのも面白いと思うよ。