かつては、ソフトウェアエンジニア、プロダクトマネージャー、デザイナーという役割が明確に分かれていました。しかし今、これらの役割は融合しつつあります。プロダクトとコードの両方を担い、ユーザーを理解し、成果に責任を持つ人材が求められています。
しかし、約1年前まで、組織図と職種名は変わらないままでした。昨年の夏に転換点が訪れ、企業は新しいタイプのロールを採用し始めました。それがプロダクトエンジニアです。
現在、「プロダクトエンジニア」という言葉は週100回言及されています。これは2020年6月比で約335%の増加ですが、この成長が本格的に始まったのは2025年5月以降です。
では、この新しい役割とは何でしょうか？
プロダクトエンジニアとは？
今日の企業において、プロダクトエンジニアはその名の通り、プロダクトに関する判断力と技術的なノウハウを組み合わせて、素早くプロトタイプを作り、構築し、反復できる人材です。
当社のChief AI Officer、Zain Lakhaniはこう述べています：
「従来は、エンジニアが何かをリリースし、プロダクトマネージャーがユーザーに話を聞いてそれが有効かどうかを確認し、そのループが続いていました。しかし、スペクトルの中心に近づくにつれて——私が「プロダクトエンジニア」と呼ぶもの——それは一人でこなすようになります。リリース、反復、ユーザーフィードバックの収集、そして再び反復を、エンジニアリング・プロダクト・デザインに分散させるのではなく、一人でこなすのです。」
Codex、Claude Code、または好みのエージェントのおかげでコードを書く時間を減らせるため、この役割はより高い価値のある仕事に集中できます：創造的な問題解決、ユーザーとの対話、そして頭の片隅でぐるぐると回っている「もし〜だったら」という問いへの回答です。
これはデザイナーやPMへの脅威のように見えるかもしれませんが、実際には協力して働くことへの約束です。Productengineer.orgがプロダクトデザイナーへの公開書簡でこう述べています：
「「プロダクトエンジニアリング」という言葉を見て、あなたの領域を侵そうとしているのではないかと思うかもしれません……しかし実際のところ、それは主に私たち自身に向けて書かれたものです。コーディングをやめて考え始めること。Jiraチケットの先を見て、「これは正しい感じがするか？直感的か？これをリリースすることを誇りに思えるか？」と問うことへの自戒です。」
プロダクトエンジニアに求められること
プロダクトエンジニアは単なるコーダーではありません。むしろ、判断力とセンス、データ志向、そして技術的な実行力を融合させて、根本的な問題に到達し、ユーザーを理解し、解決策を実現します。
このプロダクトエンジニアの求人票では、LLMを活用したツールの構築や機能のリリースを行いながら、ターゲットオーディエンスと対話し、プラットフォームの方向性を形成し、優れたプロダクトセンスを維持するという、技術的なエンジニアリングとプロダクトセンスのバランスが求められています。
この役割はエンジニアリングに根ざしたままであり、プロダクト主導の開発者向け企業がこのコンセプトを推進しています。
これは数十年前から存在するPMの役割とどう違うのでしょうか？
プロダクトエンジニア vs. プロダクトマネージャー：違いと共通点
PMとプロダクトエンジニアの役割分担について、別の考え方もあります。PMは「なぜ」と「何を」を担い、プロダクトエンジニアはフィードバックに自ら対応しながら、全サイクルを担当します。
私たちが考える役割分担は次のとおりです：
| Product Managers | Product Engineers | |
|---|---|---|
| Primary focus | What to build, and why | What to build, how to build it, and if it worked |
| Feedback ownership | Partial. Collects feedback and hands it off to developers | End-to-end. Ships and learns themselves |
| Code ownership | None | Writes and ships it |
| User relationship | Interviews, research, and synthesis | Direct: reads product data and iterates in real-time |
| Works through | Backlogs, PRDs, and handoffs | Coding agents Analytics and product agents Judgement |
両者が重なる点はここです：ユーザーの課題を定義し、製品の方向性を形成し、何を作るかを優先順位付けすること。しかし、このループ全体を担うことには、それ自体のトレードオフが伴います。
プロダクトエンジニアが直面する3つの核心的な課題
この役割が組織の中で形成されるにつれ、プロダクトエンジニアが直面する主要な課題をいくつか挙げます：
- ガードレールの少なさ。スピードが最優先事項（かつ目的）です。しかし、テストや戦略の検討、反復に費やす時間を減らしてプロトタイプから本番環境へ移行することは、リリースするものの背後にあるリスクが増大することを意味します。
- リアクティブな分析。まったく新しいペースでリリースしているため、従来のプロダクト分析・計測プラットフォームはついていくのに苦労します。以前はPMが何を計測するかを定義していましたが、今やプロダクトエンジニアはプロアクティブなインサイトを必要としています：行動シグナルを表面化し、次に何を作るべきか、そしてすでにうまく機能している箇所（Slackのような）を教えてくれるツールが必要です。
- 後回しにされるインストルメンテーション。オブザーバビリティ、リサーチ、テストは地味に見えるかもしれませんが、それこそが普通の製品と優れた製品を分けるものです。昨今の市場では、これは一般的に第二ステップとして扱われていますが、本来は最初のステップであるべきです。私たちもNovusを構築する際に同じ過ちを犯しました。
これがあなたにとって意味すること
これらすべては、より大きな変化を示しています：ジェネラリストが勝利しています。従来の3回の引き継ぎミーティングなしに、プロダクト担当者のように考え、ユーザーと話し、データを見て、コードをリリースできる必要があります。
今問うべき問いは「プロダクトエンジニアを採用すべきか？」ではありません。これを読んでいるなら、答えは圧倒的にイエスだとすでにわかっているでしょう。代わりに、考え続けるべき問いは：このように動くための適切な基盤をどのように整えるか？ということです。
今最も難しいのは、次に何を作るべきかを知ること、そしてリリースしたものが実際に機能しているかどうかを把握することです。
それには、ユーザーとデータに常に近い状態を保つことが必要であり、それこそがプロダクトエンジニアと質の低いものをリリースしているだけの人を分けるものです。
朗報：それがまさに私たちがNovusを構築した目的です。無料なので、今日から始めることができます。
