はじめに
2026年1月、3社目となる今の会社にエンジニアとして入社した。そして今回、育児休業からの復帰を機に、PdM(プロダクトマネージャー)という新しい役割に挑戦することになった。
これまでエンジニアとしてキャリアを歩んできたが、コードを書くことが嫌いになったわけでも、技術への興味を失ったわけでもない。むしろ、これまでの経験を通じて、プロダクト開発における自分の関心が少しずつ変わってきたことが大きな理由だ。
一言で表すなら、「ものを正しく作ること」よりも「正しいものを作ること」に興味を持つようになったということである。
この記事では、これまでのキャリアを振り返りながら、なぜPdMという役割を選んだのかを書いてみたい。
技術的な挑戦を求めていたエンジニア時代
1社目でエンジニアとして働いていた頃の自分は、どちらかというと技術志向の強いエンジニアだった。新しい技術に触れたい、技術的に難しい課題を解決したい、エンジニアとしてもっと成長したい。そうした思いが強く、技術的な挑戦ができる環境を求めて、2社目となるテック企業へ転職した。
2社目では新規事業部に所属し、プロダクトのローンチから、その後の運用改善まで携わった。新しいプロダクトをゼロから形にしていく経験は刺激的だったし、技術的にも多くの学びがあった。
一方で、プロダクトの開発から運用まで関わる中で、それまであまり意識していなかったことが気になるようになった。それは、「自分たちが作っているものは、本当に誰かの役に立っているのだろうか」ということだ。
作っているのに、使われない
新規事業としてプロダクトをローンチし、機能開発や改善を重ねていく。エンジニアとしては、日々やるべきことがある。しかし、開発を続けても、なかなか利用者が増えない。そんな状況の中で、次第に疑問を感じるようになった。
「この機能は、誰のために作っているのだろう」
「利用者が増えない中で、今ある機能を作り続け、メンテナンスし続けることにどれだけの価値があるのだろう」
「そもそも、このプロダクトは将来どこを目指しているのだろう」
特にもどかしかったのは、プロダクトの方向性が曖昧なまま開発が進んでいくことだった。市場の感覚や競合他社の動向をもとに、次に開発する機能が決まっていく。
もちろん、市場を理解することも、競合他社を分析することも重要だ。ただ、競合他社にある機能が、自分たちのユーザーにも必要とは限らない。その機能によって誰のどんな課題が解決されるのか。開発することで、どの指標がどう改善することを期待しているのか。そうした仮説やデータに基づいた判断が十分にないまま、機能開発が進んでいくことに歯痒さを感じていた。
技術的に優れた実装ができても、プロダクトが使われなければ、その価値を十分に届けることはできない。そして、使われない機能にも継続的なメンテナンスコストは発生する。
この経験から、開発の生産性を高めることだけでなく、そもそも何を作るべきなのかを見極めることの方が、プロダクトにとって重要なのではないかと考えるようになった。
個人開発で感じた、使われることの面白さ
一方で、個人開発では違った経験をしていた。
自分は個人で、あるWebサービスを開発・運営している。ありがたいことに、今では月間30万PVほどのアクセスがあるサービスに成長した。
個人開発なので、どの機能を作るか、何を優先するか、どう改善するかは、基本的にすべて自分で考えている。もちろん、自分が欲しいと思ったものを作ることもある。ただ、実際にサービスを運営していると、自分が作りたいものとユーザーが求めているものが必ずしも一致しないことに気づく。
どんな情報が求められているのか。どんな機能があれば便利なのか。どこを改善すればもっと使いやすくなるのか。そうしたことを考えながら開発し、実際にアクセスが増えたり、収益につながったりしたときには、違った喜びがあった。
自分が作ったものが誰かに使われ、その価値が数字として表れる。それが非常に大きなモチベーションになっていた。
振り返ると、この頃から自分の関心は、技術的に難しいものを作ることよりも、自分が考えたものがユーザーに受け入れられ、サービスとして成長していくことに移っていたのかもしれない。
個人開発では、自分でプロダクトの方向性を考え、開発し、結果を見ながら改善できる。もちろん、個人開発と企業でのプロダクトマネジメントは違うが、この経験がPdMという役割に興味を持つ大きなきっかけになった。
「正しく作る」と「正しいものを作る」は違う
これまでの経験から感じたのは、「ものを正しく作ること」と「正しいものを作ること」は別の問題だということだ。
エンジニアとして、品質の高いコードを書くこと、保守性の高い設計にすること、安定して動くシステムを構築することは重要だ。これらは今でも大切だと思っている。ただ、どれだけ正しく作られたものであっても、そもそもユーザーに必要とされていなければ、期待した成果にはつながらない。
例えば、ある機能の開発に1か月かかり、その機能がほとんど使われなかったとする。実装の品質が高く、予定通りリリースできたとしても、それだけでプロダクトとして成功したとは言えないはずだ。本来であれば、開発に着手する前に、その機能が本当に必要なのか、もっと小さな方法で仮説を検証できないか、を考える余地があったかもしれない。
もちろん、すべての施策が成功するわけではないし、失敗すること自体が悪いとも思わない。重要なのは、次の3つが明確になっていることだと思う。
- 何を期待して取り組んだのか
- 結果として何が起きたのか
- そこから何を学んだのか
ただ機能を作り続けるのではなく、仮説を立て、検証し、学習しながらプロダクトを成長させていく。次第に、そうした部分により深く関わりたいと思うようになった。
AIによって変わりつつある開発と、変わらない問い
もう一つ、今回のキャリア転向を考えるうえで意識しているのが、AIによるソフトウェア開発の変化だ。
生成AIの進化によって、コードを書くことや実装を進めることのあり方は大きく変わりつつある。これまで人間が多くの時間を費やしていた実装作業の一部を、AIが支援できるようになった。
もちろん、AIが生成したコードの品質を評価したり、設計の妥当性を判断したりするには、引き続き技術的な知識が必要だ。ただ、今後さらに実装の効率が高まっていくのであれば、別の部分がより重要になると考えている。
それは、「何を作るべきなのか」という問いだ。
AIによって開発速度が上がったとしても、ユーザーに必要とされない機能を大量に作ってしまえば、プロダクトが成長するとは限らない。むしろ、作れるものが増えるからこそ、何を作らないか、何にリソースを集中するかという判断が重要になるのではないか。
開発を効率よく進めることだけでなく、開発前にユーザーの課題や解決策の仮説を検証し、リリース後も成果を確かめていく。そうしたProduct Discoveryの考え方は、これまで自分が感じていた問題意識とも重なる部分がある。
AIによって「どう作るか」の選択肢が増えていく時代だからこそ、「何を、なぜ作るのか」を考える力を磨いていきたい。
なぜPdMという役割を選んだのか
こうした経験や考え方の変化があり、今回、PdMという役割に挑戦することを決めた。
PdMは、単に機能の仕様を決めたり、開発チームの進捗を管理したりする役割ではないと思っている。
- ユーザーの課題を理解し、事業の方向性を踏まえ、どの課題に取り組むべきかを判断する
- その判断が正しかったのかを、ユーザーの反応やデータから検証していく
そうしたプロダクトの成果に向き合う仕事をしてみたい。
もちろん、エンジニアという立場でもプロダクトの課題発見や意思決定に関わることはできる。PdMにならなければ、そうしたことができないわけではない。ただ、これからのキャリアでは、実装そのものだけでなく、プロダクトが提供する価値や事業としての成果に、より大きな責任を持ちたいと思った。
これまで培ってきた技術的な知識も、決して無駄になるわけではない。技術的な実現可能性や開発コスト、運用負荷を理解したうえで、ユーザーや事業にとって何が最適なのかを考えられることは、自分の強みとして活かしていきたい。
開発チームに対しても、単に仕様を渡すだけではなく、なぜその機能が必要なのか、どんな課題を解決したいのかという背景を共有することを大切にしたい。
エンジニアとして働いてきたからこそ、目的が明確でないまま開発を進めることの難しさも理解しているつもりだ。だからこそ、チーム全体が同じ目的に向かい、それぞれの専門性を活かしながら解決策を考えられる状態を作っていきたい。
おわりに
振り返ってみると、1社目では技術的な挑戦を求め、2社目では新規事業のプロダクト開発を経験し、個人開発では自分のサービスが成長する面白さを知った。それぞれの経験を通じて、自分が仕事に求めるものも少しずつ変わってきたのだと思う。
以前は、技術的に難しい課題を解決することに大きなやりがいを感じていた。今はそれに加えて、自分たちが作ったものが誰かの役に立ち、実際に使われ、プロダクトとして成長していくことに、より大きなやりがいを感じている。
エンジニアからPdMへの転向は、自分にとって新しい挑戦だ。これまでの技術的な経験を活かしながら、今度はプロダクトの成果に責任を持てる人になりたい。
「ものを正しく作る」から「正しいものを作る」へ。
そんな考え方を大切にしながら、これからPdMとして経験を積んでいきたい。