この記事は プロダクトマネージャー Advent Calendar 2024 6日目の記事です。
前日は Taro Yoshioka さんによる PdMの介在価値ってなんだろう？ のお話でした。
プロダクトマネージャー（PdM）がいなくてもプロダクト開発は進むよね、私たちPdMの存在意義は何だろう、と考えることがしばしばあります。この記事では、プロダクトやチームにとってのPdMの価値が分かりやすくまとめられていて、とても参考になりました。
はじめに
@oyngtmhr です。
ECサービスのプロダクトマネージャーをしています。
キャリアとしては金融系システムの開発からスタートし、クラウドインフラ構築のエンジニアやプロジェクトマネージャーを経験。現在はプロダクトマネージャーとして、プロダクトマネジメント業務を4割、プロジェクトマネジメント業務を6割程度の割合で担当しています。
私のようにエンジニアやプロジェクトマネージャーからプロダクトマネージャーへキャリアチェンジするケースは多いと思います。
この記事では、私自身の経験から、エンジニアやプロジェクトマネージャーがプロダクトマネージャーになって直面した課題とあるべき姿と思うものについて共有します。自分自身の振り返りでもあり、同じようなキャリアチェンジを考えている方の参考にもなればと思います。
なお、ここでいう「エンジニア」とは、Webシステムやエンタープライズ基幹システムの上流から下流工程まで携わるシステム開発者およびプロジェクトマネージャーを含む、広義の意味で使用しています。
エンジニア意識が引き起こすやらかし
エンジニアとしての知識や経験があるがゆえに、ついエンジニアの領域に踏み込んでしまいます。
- プログラムロジックの細部にまで質問する。なんなら修正案まで提案してしまう
- システムのバグ解消について具体的なログの確認方法を提案する。なんなら自ら調査まで始めてしまう
- 過去の現場での開発手法にこだわる。なんならチームに押しつけようとしてしまう
これらの行動は、前職や現職の初期に経験した失敗です。結果として、エンジニアとの関係を悪化し、本来注力すべきプロダクトマネジメントやプロジェクトマネジメントの時間も削られてしまいました。これは明らかなやらかしでした。
あるべき姿だと思うもの
これらのやらかしを経て、現在はエンジニア領域はエンジニアに任せ、ビジネスとエンジニアの橋渡し役に徹すること、そしてエンジニアリングが円滑に進むよう、黒子として支援することを意識しています。
- ビジネス側とのコミュニケーションに注力する。ミーティングやチャットを通じて要件を文書化し、システムの実現可能性やコストの検討ができるレベルまで具体化する。
- システム開発で生じる課題について、ユーザーとビジネスの視点から想定される影響を整理し、ビジネス側への説明と交渉を行う。
- ビジネスとエンジニアの間で責任範囲があいまいなボールを拾い上げ、整理した上で適切な担当者に投げる。
とはいえ、エンジニアとしての知識や視点が必要なシーンも多くあるため、そのバランスを意識しながら日々の業務に取り組んでいます。
エンジニアがプロダクトマネージャーになるメリット
もちろんエンジニア出身でプロダクトマネジメントを実践する際には、数多くのメリットがあります。これらの強みを意識的に活用することで、プロダクトの品質向上とプロジェクトの円滑な進行に貢献できます。
- ソフトウェアの品質に関する理解がある。品質の問題発生時には適切な対策を講じることができる
- 企画段階からセキュリティなどの非機能要件を考慮した要件策定ができる
- データへの理解が深く、データの保管場所や処理フローを把握し、効果的な収集・分析を行える
最後に
エンジニアからプロダクトマネージャーになると、エンジニアとしての知識や経験が強みとなる一方で、エンジニアとしてのバックグラウンドをどこまで出していくかのバランスが難しいです。
まだまだ学ぶべきこと、実践すべきことはたくさんありますが、プロダクトを成功に導き、収益を上げること、そしてビジネスとエンジニアを含めたチーム全体が良好な関係を保ちながらやっていけるよう、2025年も挑戦していきたいと思います。