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