プロダクトマネージャー、1950年代の日本でトヨタのチーフエンジニア制度が形作られる

肩書きから連想されるほど「作る」仕事はしていない。典型的な一日は、利用データの確認、顧客や営業チームとのニーズに関する会話、エンジニア向けの仕様書の作成や改訂、そして次に何を作り何を削るかを決める計画会議への出席が中心となる。自らコードを書いたり、画面を描いたり、何かを出荷したりする時間はごくわずかしかない。 プロダクトマネージャーになるにはエンジニアリングや技術のバックグラウンドが必要か? 必須ではないが、ソフトウェア色の強い役割では役立つ。エンジニア出身のプロダクトマネージャーは多いが、デザイン、マーケティング、コンサルティング、カスタマーサポートから移ってくる人も少なくない。特定の学位よりも重要なのは、データを読み解き、明確に文章を書き、自分でコードを書かなくてもエンジニアと対等に議論できることだ。

違う。プロダクトマネージャーがエンジニアやデザイナーなど誰かを直属の部下として持つことはほぼない――この仕事はしばしば「権限ではなく影響力で導く」役割だと説明される。プロダクトマネージャーは優先順位とその根拠を定めるが、実際の作業をどう進め誰が担当するかは通常エンジニアリングマネージャーやチームリーダーが決める。 国や企業によって大きく異なる。米国の大手テクノロジー企業では、ボーナスと株式を含めた総報酬が優に六桁ドル台(日本円で数千万円規模)に達することも珍しくない一方、インドやラテンアメリカの多くでは同等の役職でもその何分の一かにとどまる。株式を除く基本給だけで見れば、同じ会社のシニアエンジニアの給与に近い水準であることが多い。

データの要約、仕様書の初稿作成、顧客フィードバックの統合といった業務は、すでにAIツールによって高速化されている。自動化が難しいまま残るのは、そもそもどのアイデアに取り組む価値があるかを決めること、意見の異なる人々の間で妥協点を交渉すること、そして賭けが失敗したときに責任を負うことだ――これらはモデルに責任を負わせられない判断である。 「プロダクトオーナー」は1990年代にスクラムのフレームワークで定義された具体的な役割で、チームの作業バックログの優先順位付けを担当する。「プロダクトマネージャー」はより広範で歴史の長いビジネス上の肩書きで、戦略、市場調査、チーム横断の調整をカバーする。今日では両者を同義に使う企業も多いが、両方が併存する場合、プロダクトオーナーは通常プロダクトマネージャーの下、あるいはその隣で働く。