プロダクトマネジメントトライアングルと各社の PM の職責と JD
Product Manager Conference 2017 (#pmconfjp) の最後のセッションで登壇させていただきました。セッション中にはあまり時間がなかったので、セッションでいくつか触れたことについて補足しておきたいと思います。
プロダクトマネジメントトライアングル
セッションで挙手をお願いしたとき、意外と多くの方がご存じなかったので PM Triangle について私の方でも取り上げておきます。
プロダクトマネージャの職責は比較的曖昧で、そのため「プロダクトマネージャーとは何か」という議論は混迷を極めます（その曖昧さが PM の本質だ、という話もあります）。
そんなとき一つ参考になるのが、The Product Management Triangle (by Dan Schmidt) という記事にあるプロダクトマネジメントトライアングルです。
この記事についてはにんじんくんさんの翻訳が素晴らしいです。
ただ、原案のトライアングルは網羅的であるがゆえにちょっと細かすぎて、話し合うときには使いづらいという話を聞いたので、極力内容を変えずに、少し抽象化してそれぞれ 3 つずつに変更してみたのが以下のトライアングルです。
記事によれば、プロダクトマネージャーはこれらの領域を健全に機能させることが役割であり、
- 機能がなければ自分で役割を演じたり、補う方法を見つける
（たとえばデザイナーがいなければ、自分でデザインを行ったりデザイナーを雇う） - 「開発者-ビジネス」「ビジネス-顧客」「顧客-開発者」の融合領域における、各種の複雑さや衝突、トレードオフの統合を行う
といったことが PM の職責であると理解しています。
逆に言えば、これらを俯瞰して見ることができる能力が PM には求められています。そうした意味で、PM は様々なことを広く学び、組織やビジネスの変化に柔軟に対応できる必要があるとも言えます（今回の PM Conference はそうした視野を『広げる』部分が一つの目的だったと伺っています）。
また「PM にはコミュニケーション能力が必要になる」というのは、それぞれの機能が組織的に分かれている場合、それぞれ違うゴールや言語を持つ人たちを滑らかに機能させたり、衝突を統合しながらプロダクトを前に進めるためにコミュ力が必要だと言われるのだと思います。
PM は会社や製品ごとに違う
トライアングルから見えてくるもう一つのことは、「PM に求められる能力は会社や組織、製品によって異なる」ということです。
なぜなら、現状の組織でトライアングルのどの部分が機能していないかは、時と組織によって異なるからです。
組織のリソースが豊富な場合はプロダクトの仕様を策定するだけの PM なのかもしれません。スタートアップのようにまったくリソースのない組織の場合は、全部の機能を一人がやらなければいけないのかもしれません。人を採用して少しリソースが増えたら、また PM に求められるバランス感が変わってきます。
組織の今の状況に応じて PM はその役割を変えますし、同じ組織においても時間が過ぎれば役割が変わっていくと認識しておくほうがよいのでしょう。
また、McKinsey の今年の『デジタル世界のプロダクトマネージャー』という記事には、以下のように会社ごとに異なる PM のあり方が描かれていました。それは
- テクノロジスト
- ジェネラリスト
- ビジネス志向
の３つです。
自社の PM が、どういう位置付けの PM を求めているかを考える際に、この分類は一つ参考になるのではないかと思います。
またこうした背景があるから、異なる会社の PM 間のノウハウ共有の際に大きな違いが出てくるのではないかと思います。
ビジネスモデルで変わる PM の立ち位置
こうした会社間での違いは企業文化的なものも影響しているのだと思いますが、そもそもはビジネスモデルに依る部署間のパワーバランスが PM の役割にも影響していると考えられそうです（黒田さんの指摘によるもの）。それは主に以下の二つの極のグラデーションではないかと思います。
- 主にエンジニアのコードで利益の成長が加速するビジネスモデルか
→テクノロジ寄りになりがち - 主に営業の頑張りによって利益の成長が加速するビジネスモデルか
→ビジネス寄りになりがち
つまりプロダクトの Engine of Growth が組織のどこにあるのか、というのによってビジネスモデルや組織のパワーバランスが左右され、さらに PM の立ち位置も左右されるのだと思います。
（とある営業組織が強い会社の PM の人と話したときは、ほとんど営業さんの御用聞きになってるみたいで大変そうでした…）
製品ごとの PM の違い
またスタートアップにおいては、一会社＝一製品ですが、大きくなってくると一つの会社が複数の製品を持つことになります。そして同じ会社でも、製品によっても PM の職責は異なるようです。それは上述の通り、製品ごとにビジネスモデルが違う、という理由が挙げられます。
たとえば、Google というひとつの会社を見てみても、Google Ads のプロダクトマネージャーは基本的にトライアングルのすべてを見るように言われるそうですが、その他の多くのプロダクトについてはビジネス（利益）の部分はほとんど何も言われず、ユーザー体験の向上を中心に PM が動くことになるそうです（つまり開発者と顧客のネットワークを機能させる部分のみ）。
なので、会社によって PM の役割が異なるだけではなく、組織やビジネスモデルによっても PM の役割は異なる（べき）、ということになりそうです。
メンターなどを探すときには、こうした各会社や製品による PM の機能の違いを意識しつつ、職責が似ている PM や逆に異なっている PM にメンターとして就いてもらうのがいいかもしれません（そんなとき改案のトライアングルは「お互い何をやっているのか」を整理するときに役立つのではないかと思います）。
スループットの最大化
こうした様々な違いを認識した上で、プロダクトマネジメントトライアングルを見てみると、自分たち独自の気付きが生まれるのではないかと思います。
その上で、プロダクトマネジメントトライアングルは比較的静的な機能の見方です。PM は「今どこが足りないか」「今はどこがボトルネックか」を考える必要があるため、『スループット』を意識しておくのも良いのではと思い、壇上で少し紹介させていただきました。
プロダクトマネジメントトライアングルの記事を考えてみると、いまプロダクトのスループットを出す上で、ボトルネックになっている部分を見つけるのがある意味 PM の仕事とも言えそうだからです。
そしてプロダクトマネージャーは素晴らしい価値を持つプロダクトを生み出し続けるファクトリーを社内に作ることとも言えます。そう考えたときに、スループット（利益）を上げるという部分で『図解リーンスタートアップ成長戦略』は参考になる書籍だと思います。
本書は特に既にプロダクトがあって改善していくフェーズの皆さんにお勧めします。
ちなみに『図解リーンスタートアップ成長戦略』の翻訳者である角さんと、先ほど上に引用したスライドの黒田さんと一緒に 12 月にイベントをするので是非ご参加ください。
ここまでのまとめ
つまり、
- PM の機能
- PM の機能は組織によって異なる
- 自社や製品のビジネスモデル
- スループット
を把握することで、今 PM の人は、自分がどの部分に期待されているかの整理が少しだけ簡単にできるのではないでしょうか。
そうすると、自社で PM がどうあるべきか（あるいは何が足りないか）を考えていく土台が出来上がっていくのではないかと思います。
その上での Job Description (JD)
さて、どの企業も PM が採用できないことを課題に感じていると聞いています（Google も中途で良い PM が採用できないから APM 制度を作って育成することにした、とも聞きました）。
及川さんが何度かご指摘されていますが、そんなときは PM のジョブディスクリプション (JD) をきちんと書いてみると、今の組織にどういう PM がほしいのかが明確になります。
その際に、上記のプロダクトマネジメントトライアングルや、PM の会社ごとの違い、ビジネスモデルの違いの知識が活きてくるのではないかと思います。
Job Description の例としては、LinkedIn などを見るのもいいと思いますが、Increments さんが PM の JD をアップしているので参考にすると良いと思います。
また、JD を書く前に、チームでトレードオフスライダーを書いてみるのもいいかもしれません。
こういうスライダーを書くときには、プロダクトマネジメントトライアングル（原案）の、細かいスキルがスライダーの軸として使えるのではないかと思います。ぜひこうした過去のドキュメントにあたってみて下さい。
