🗺️実務とノウハウ

肩書きから連想されるほど「作る」仕事はしていない。典型的な一日は、利用データの確認、顧客や営業チームとのニーズに関する会話、エンジニア向けの仕様書の作成や改訂、そして次に何を作り何を削るかを決める計画会議への出席が中心となる。自らコードを書いたり、画面を描いたり、何かを出荷したりする時間はごくわずかしかない。

必須ではないが、ソフトウェア色の強い役割では役立つ。エンジニア出身のプロダクトマネージャーは多いが、デザイン、マーケティング、コンサルティング、カスタマーサポートから移ってくる人も少なくない。特定の学位よりも重要なのは、データを読み解き、明確に文章を書き、自分でコードを書かなくてもエンジニアと対等に議論できることだ。

肩書きは似ているが違う。プロジェクトマネージャーは、チーム全体のスケジュールを調整しながら作業が予定通り予算内で進んでいるかを追跡する。プロダクトマネージャーは、そもそも何を作るべきかとその理由を決め、根底にあるビジネスと顧客の論理を所有する。特に小規模な組織では両者の境界が実務上あいまいになることも多いが、それぞれが答える中心的な問いは異なる。

違う。プロダクトマネージャーがエンジニアやデザイナーなど誰かを直属の部下として持つことはほぼない――この仕事はしばしば「権限ではなく影響力で導く」役割だと説明される。プロダクトマネージャーは優先順位とその根拠を定めるが、実際の作業をどう進め誰が担当するかは通常エンジニアリングマネージャーやチームリーダーが決める。

国や企業によって大きく異なる。米国の大手テクノロジー企業では、ボーナスと株式を含めた総報酬が優に六桁ドル台(日本円で数千万円規模)に達することも珍しくない一方、インドやラテンアメリカの多くでは同等の役職でもその何分の一かにとどまる。株式を除く基本給だけで見れば、同じ会社のシニアエンジニアの給与に近い水準であることが多い。

データの要約、仕様書の初稿作成、顧客フィードバックの統合といった業務は、すでにAIツールによって高速化されている。自動化が難しいまま残るのは、そもそもどのアイデアに取り組む価値があるかを決めること、意見の異なる人々の間で妥協点を交渉すること、そして賭けが失敗したときに責任を負うことだ――これらはモデルに責任を負わせられない判断である。