はじめに
近年のweb市場では、DXの必要性に合わせてPdM人材が求められています。 採用でもPdMをやってきた人、これから目指したい人が増えてきている印象で、私自身もPdMを名乗っているときもあります。
一方で、エンジニア畑の人たちがPdMを目指したいというときに 「エンジニアリングから離れないといけないのではないか？」と考えていて キャリアを閉ざす人がいると思います。
これらに関する雑感を書きます。
PdMってなんだ？PjMとの違いは？
私が人に説明する際に話すのは下記です。
- PjM(プロジェクトマネージャー)はプロジェクトを終わらせるように進める管理者
- PdM(プロダクトマネージャー)はプロダクトを終わらせないように進める管理者
PdMの一般的な業務は以下だと認識しています。
- 企画立案・要件定義
- 進捗管理
- KGI・KPI設計
- ロードマップ策定
- データ分析 corp.tech.hipro-job.jp
よく「何を作るか(what)」「なぜ作るのか(why)」を追求していく人と言われますね。
ミニCEOだと言われたり、言われなかったり。
ここで重要なのが、PdMの業務には基本設計するとか、コーディングするとかいった「エンジニアリングの要素」が1ミリも入ってないというところ。
異なる畑へのステップアップに見えるため、「エンジニアリングを捨てて学ばなければならない？」と思われる方が多い印象です。
エンジニアリングの本質は課題解決
「コーディングだけやれば良いという時代は終わった」と私は考えています。
何をつくっているか、なぜつくっているかまでを知っておかないと、不要なシステムを作り込んだり、作ったものの評価を正当に受けられない可能性があります。
それは事業貢献だけでなく、自信のエンジニアスキルへのフィードバックもなくメリットは何もありません。
広義の意味で、エンジニアはPdMの領域に足を踏み込んでおかなければより良いものづくりはできないと思っています。
超曖昧なベン図ですが書いてみました。 エンジニアとPdMの間の定義というのが一般的なのかわからないですが、「企画エンジニア」とあったので追加しています。 みなさんはどの領域を目指していますか？
ちなみに私が目指している領域のベン図は下記です。エキスパート以外の領域は網羅したいと思っています。
「やること多いじゃん！」って思うかもしれませんが、はい。やることは広義ですがシンプルです。
やること * プロダクト開発 * 組織改善
やらないこと * 超難しいテックリードでないとできないような技術的挑戦 * デザイン * 一人で開発すること * 営業活動 * エンジニア以外の組織改善
組織改善の文脈を除外すれば、一般的に言う「ジェネラリスト」の領域かもしれないですね。
なぜこの領域を目指しているか
「開発現場で求められているから」です。 プロダクト開発においてQCDは非常に大切です。
このQCDという言葉は昔から使われており、WEBの成長速度は早いと言われていますが、近年だと更にDelivery(事業提供)が求められていると感じています。
開発生産性指標であるfour keysでも、サービス復旧時間が求められており、Deliveryの重要性を鑑みることができます。
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
最速のDeliveryとは
極端な例で、実際には定例じゃなくSlackやChatworkなどでやりとりもあるんでしょうが、コミュニケーション数としては正しい。
1次情報、2次情報と間に人が入れば入るほど伝書鳩役の人が増えて、作りたいものが間違うリスクはもちろん、スピードも遅くなります。
つまり「自分がつくれるが最強最速」である。
とはいえ
個人がPdMとエンジニア両立して学びながらは大変なため、チームとして支えて上げる必要があると思っています。
そのためにはチーム間で「その人の目指すキャリアを共有すること」が大切です。
テックリード、エンジニアリングマネージャー、PdMなどチームメンバーが目指していることに近しいタスクをアサインします。
余ったタスクは要相談です。今回のように「PdMがやるべきタスク」であればその人のために残してあげるべきですし、
「誰がやっても同じだよね」というタスクは譲歩してやってあげましょう。過多がないように。
往々にしてPdM=事業責任者=誰もやらないタスクをやる という誤解が生まれがちですが、チームみんなのタスクであることを認識しないといけません。
おわりに
今回PdMを例に上げていますが、これは別の職種でも同じ話かと思います。
私のチームではキャリアビジョンの共有・透明性を大切にしていて、プロジェクトのキックオフの際には各メンバーへ期待する役割を公開しています。
人一人が働ける時間は決まっていますが、メンバーと支え合うことでタスクを分担したり、より自分のなりたいキャリアを目指すことができるのもチームの良いところだと思ってます。
