プロダクトマネージャーの3分類

Rebuild.fm #126 のTaro Minowa (@higepon)さんの回で語られたプロダクトマネージャーの分類の話について。

http://rebuild.fm/126/

個人的にhigeponさんのBlogもよく読んでいる。 http://higepon.hatenablog.com/


この回は内容が大きく2つから構成されている。

  1. エンジニアにとってのTech Leadというキャリアパスについて
  2. プロダクトマネージャーの分類と難しさについて

本題として扱いたいのは2についてなのだが、1のTech Leadという役割、キャリアパスが新鮮かつエンジニアの組織を考える上でとても有用だったので、簡単に触れたいなと思います。

なおTech Leadに関する @higapon さんの考察サマリはご自身がブログに書かれてあるので詳しくはこちらを見ると良い。

http://d.hatena.ne.jp/higepon/20150806/1438844046

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であるという。

付随して、

といった議論があるようで、現実味があり面白かった。

Product Managerの分類

プロダクトマネージャーの3分類

さて本題。

higeponさんが様々なProduct Managerと一緒に働いた経験から、「Product Manager勝手に3分類」を紹介している。それは以下の様なものだ。

  1. 戦略的なロジカルタイプ
  2. 直感的芸術家右脳派タイプ
  3. 経験に裏打ちされた直感タイプ

各タイプの特徴を僕の理解も含めて簡単に整理すると、こんな感じ。

タイプ 長所 短所
戦略的 数字に強く何にでもすぐ答えられるのでチームの納得感をうまくつくれる。MBAっぽさ 理論にこだわりすぎてつまらないプロダクトに収まってしまう
芸術家 理解できないけど「すごい仕様」をつくってしまう。Steve Jobsっぽさ だいたい理由がないのでチームの納得感を醸成しにくい
経験派 過去の成功体験をプロダクトに反映できるチート感 経験に引っ張られてゼロベースで考えられない

タイプによる適正

上述のProduct Managerのタイプは、突き詰めると以下の2点に大きな影響を与えてくるように思う。

データや数値を重視する戦略家タイプは、とくにチームの生産性の面で高い効果を発揮する。数値という共通言語での説明を行っていくので、PMの上司もまたその数値を上司に伝えれば良い、というような情報の整理と交通がスムーズになり、納得感が生まれやすい。

対象的な芸術家タイプは、「理由」を説明するのが難しい仕様を作ってくるが、誰もが信じられないようなproductほど成果をユーザーに受け入れられたりする。

ただどんなタイプのProduct Managerであれ、Productをローンチすると言う行為は誰にとっても”賭け”である。いずれにせよリリースしないとそのProductが実装する未来の機能は良いものなのか判断できないので、成功にこぎつけるにはリリース後の運用のセンスや泥臭さのほうが重要かもしれない

そういう意味では適正というのは合ってないようなものかもしれない。

一緒に働きたいProduct Manager

結局はどんなタイプであろうと、信念のあるProduct Managerと働きたい というのが偽らざる事実のようだ。

ある機能をリリースする際に、やってはいけないNGトークスクリプト

「でもこっちのほうが良いと思います」 「じゃあ設定でかえれるようにしよう」

→たしかに信念がない。こんなPMは嫌ですね。

僕の持論でもあるが、やっぱりPMに求められるのは偏執= 確固たる勘違い じゃないかと思います。

結局はセンスである

とはいえ、Productを創りだす際は大体にしてPM/LT/デザイナーの3人で全体の設計を進めていくことになる。が、この場合センスがない人が一人でもいると大変ですよね〜という話があった。

すると2つ問題が起きる

  1. センスの人が妥協した意見を形成するようになり、最終的に妥協の塊のようなプロダクトが出来る
  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は相当に内容が濃かったため、着想を得る箇所が多く、まとめていたら、まとまりがなくなっていてなんか申し訳ない。


本稿が参考になった方はコメント&Kyash投げ銭をお待ちしております。記事へのフィードバックとして糧にします。なお、Kyashは常用していて応援しているプロダクトです。

kyash_link
kyash_link