PMのジョブディスクリプションの在り方とは 〜NewsPicksアカデミア 及川ゼミより〜
久津（@Nunerm）です。
前回記事に引き続き、今回もNewsPicksアカデミアの及川ゼミの講義や懇親会からの学びをアウトプットします。
今回のテーマは
「PM（プロダクトマネージャー）のジョブディスクリプションの在り方」
です。
ジョブディスクリプションとは
ジョブディスクリプションの説明は及川さんのスライドをそのまま記載させていただきます。
サンプルとして、Incrementsが公開しているPMのジョブディスクリプションを貼っておきます。
日本はメンバーシップ型雇用の企業が多いので、ジョブディスクリプション（≒募集要項）はあくまで採用時にのみ意識するものであり、採用後の組織内で意識することはほとんど無いのではないかと思います。役割や業務内容はその都度「良い感じに」決めていくことが多いでしょう。
この「良い感じに」の風習のせいで、プロダクトマネージャーのみならずエンジニアリングマネージャーやプロジェクトマネージャーを一括りに「マネージャー」として扱い、マネージメントする対象と責任を明確にしないが故に仕事がどんどん増え、ただただマネージャーが疲弊していく現場が多くなっている、と勝手に思っています。よろしくない。
海外のジョブ型雇用では、採用時だけでなく採用後も組織内で評価基準や成長の方針としてジョブディスクリプションが使われます。しっかりと定められた（＝組織に求められている）役割や責任が言語化されているため、責任範囲でない仕事が降ってくることは起こりにくくなります。（海外経験がないので受け売りですが）
少し余談ですが、別の場で元Microsoftの方から聞いた話で、MSではPMのパフォーマンスが出なかった場合、上司が２つの選択肢を出すそうです。１つ目は辞めるか、２つ目は３ヶ月以内に別のジョブに移るか。
ここには「左遷」的なニュアンスは全く無く「たまたまジョブが合っていないから、合うものに変えるだけ」とみなされるそうで、個人にとっても組織にとってもWin-Winな出来事だそうです。
これも結局ジョブディスクリプションによって明確な役割や責任があるからこそ実現できるものだと思います。
各企業のPMのジョブディスクリプションの違い
次に及川さんにGAFA＋MSのPMのジョブディスクリプションを紹介していただきました。
共通する部分もありましたが、重視している点や定義の粒度などが異なりました。それをまとめた図がこちら。
Facebookは基本的にコンピューター・サイエンス寄りの人材を求めており、アーキテクチャ設計や分析スキルをRequirementsに定義しています。
一方Amazonは"Product Management-- Non-Tech”のようなTechnologyを求めないPMと"Product Management-- Technical"の２つの職種があり、さらにその中には"IoT”とか"New Product”など担当するプロダクトの種類ごとに細かくジョブディスクリプションが定義されています。
ここで探してみると面白いです。
Amazon.jobs: Help us build Earth’s most customer-centric company.
そしてAppleとGoogleのPMのスタンス違いも面白かったです。
Appleは「ユーザーが求めているものを正確に把握している」、Googleは「ユーザーが求めているものはわからない」というスタンスです。確かに実際に世に出てきているプロダクトを見ると、そのスタンスが反映されているように思えます。
そして度々このブログで引用させていただいているBaiduのPMのChenさんのプロダクトマネージャーカンファレンス2018の登壇でも、「アメリカと中国で求められるPMのスキルが違う」というお話がありました。アメリカはニーズがある程度一様化しているため、そのニーズを技術力で解決できるPMが求められる。中国ではニーズが極端に多様化しているため、解決されていない新たなニーズを探すことができるPMが求められるとのことでした。
また講義内のグループワークでも５人のPMの方々と、各社のPMのジョブディスクリプションを比較し合いましたが、やはり多種多様でした。
つまり及川さんのスライドにも記載されている通り「組織によってプロダクトマネージャーは役割も必要とされるスキルも異なるため、組織が定義するプロダクトマネージャーを明確にすることが必要」なのです。
PMには多くのことが求められるのは事実ですが、「全部載せ」にしてしまうと責任の抽象度が上がってしまうし、そもそも全部満たすことは不可能なので募集要項としても評価基準としても機能しなくなります。
スタートアップの立ち上げ期でまだ役員とエンジニアしかいないような組織では、ビジョナリーで意思決定力が強い人が求められます。ある程度組織もプロダクトも成熟している組織では、オーナーシップや顧客ニーズの分析スキルなどが求められます。
つまり求める責任やスキルは、組織に合わせて厳選する必要があるのです。
PMのジョブディスクリプションをどうやって決めるのか
自分なりの答えとしては「自組織やプロダクトの状況を可視化して決める」です。
現状のプロダクトをどう成長させるのか、そのために現状の組織にはどういうスキルや役割が足りていないのかを理解した上で、そこを埋めるためのジョブディスクリプションを定義する必要があります。また必ずしも足りていないところを埋める必要もなく、優先度が低いのであればジョブディスクリプションには記載する必要はありません。
これは何もPMに限ったことでは無く、あらゆる職種でも同じことが言えると思います。
このように自組織とプロダクトの状況を可視化するためには、プロダクトマネジメントトライアングルを使ったり、以前このブログで書いた「組織の視力」を測定することが求められます。詳細は下記記事を参照してください。（個人的にはプロダクトマネジメントトライアングルは若干使いづらい派なので、自分なりにわかりやすいやり方で可視化すれば良いと思います）
productmanager55.hatenablog.com
まとめ
この手の「PMとは何ぞや？」的なテーマではいつも「組織やプロダクトによって違うから、現状を可視化して求めれられているPMを定義しよう」という結論に落ち着いています。
でもそれが本質なんだと思います。
各社の優秀なPMのジョブディスクリプションや"How To"をそのまま装着したからといってうまくいきません。それらの情報を要素分解して、自分の環境に合うものを選んで採用していくしかありません。そのためには常に自分たちの組織やプロダクトを客観視して状況を可視化することが求められます。
組織とプロダクトに真摯に向き合うことが大事なのです。
