はじめに
近年、テック業界、特にシリコンバレーのスタートアップ界隈で「プロダクトエンジニア（Product Engineer）」という職種が注目を集めています。「ただコードを書くだけのエンジニア」ではなく、「プロダクトマネージャー（PM）のような視点を持つエンジニア」です。
今回取り上げるのは、急成長中のプロダクト分析プラットフォーム「PostHog」のブログ記事『Product engineer vs product manager: What's the difference?』です。この記事は、プロダクトエンジニアと PM の違いを明確にし、現代のプロダクト開発においてエンジニアがどのように振る舞うべきかを説いた良記事です。本稿では、その内容を紐解きながら、なぜ今この役割が重要視されているのかを考察します。
1. 著者はどんな人物か：Ian Vanagas
経歴のハイライト
記事の著者である Ian Vanagas 氏は、プロダクト分析ツールを提供する企業 PostHog の主要メンバー（Growth/Content 担当）です。彼は PostHog において、単なるマーケティング活動にとどまらず、エンジニアリング文化やプロダクト開発の知見を広める役割を担っています。
現在の活動
現在は、PostHog のブログやニュースレターを通じて、スタートアップの成長戦略、エンジニアリング文化、プロダクトマネジメントに関する質の高いコンテンツを発信し続けています。特に、開発者や創業者が直面するリアルな課題に対する実践的なアドバイスが特徴です。
評価される理由
彼、そして彼が所属する PostHog が評価される最大の理由は、 「透明性」と「エンジニアファースト」の徹底 にあります。PostHog は自社のハンドブック（社内規定や文化）を完全公開しており、その「エンジニアが主導権を持つ（Engineering-led）」文化は多くのスタートアップの模範となっています。Ian 氏はその文化を言語化し、業界のトレンド（今回の場合はプロダクトエンジニアの台頭）を的確に捉えて発信しているため、多くの開発者や PM から信頼を得ています。
2. なぜこのブログが執筆されたのか（背景の考察）
この記事が執筆された背景には、以下の 2 つの大きな意図があると考えられます。
① 「分業体制」へのアンチテーゼと PMF の追求
従来の開発体制では、「PM が仕様を決め、エンジニアがそれを作る」という分業が一般的でした。しかし、変化の激しい初期スタートアップにおいて、この伝言ゲームはスピードを殺し、プロダクトマーケットフィット（PMF）を遠ざけます。PostHog 自身がエンジニア主導で成功した企業であるため、「エンジニア自身が仕様を決め、作り、顧客と話す方が早い」という実体験に基づき、このスタイルを業界標準として提唱する意図があります。
② 「プロダクトエンジニア」というキャリアの確立
「指示待ちではなく、事業に貢献したい」と考える優秀なエンジニアに対し、「プロダクトエンジニア」という明確なラベルとキャリアパスを提示しています。これは PostHog 自身の採用戦略（優秀なプロダクトエンジニアを惹きつける）でもあり、同時に「コードを書く PM」や「ビジネスのわかるエンジニア」という曖昧だった存在を定義づけることで、業界全体のレベルアップを図ろうとしています。
3. 記事の要点解説
記事では、プロダクトエンジニア（PE）とプロダクトマネージャー（PM）の違いを「開発の旅」に例えて比較しています。
A. 定義：PE は「エンジニアと PM のハイブリッド」
プロダクトエンジニアを一言で言えば、 「PM と同じゴール（顧客の課題解決）を持ちながら、コードを書いて直接的に解決する人」 です。
B. フェーズごとの違い
| フェーズ | プロダクトマネージャー (PM) | プロダクトエンジニア (PE) |
|---|---|---|
| 1. 着手・発見 | ユーザー調査、データ分析、レポート作成を行い、論理的に優先順位を決める。 | Issue を書き出し、即座にプロトタイプを作り始める。「議論より動くもの」で検証する。 |
| 2. 構築 (Build) | ステークホルダー（他部署）との調整、詳細な仕様策定、チーム間の合意形成を重視。 | 自分で仕様を決め、設計し、実装する。他者への説明コストを省き、PMF を求めて高速で反復開発する。 |
| 3. ローンチ | 大規模なリリースイベントとして扱い、全方位的な調整を行う。 | 日常的なデプロイの一部。フィーチャーフラグ等を使い、静かに、かつ頻繁にリリースする。 |
C. 両者の共存関係
記事の結論として、 PM は不要になるわけではありません 。
PE の台頭により、初期ステージの PM 業務（仕様策定など）はエンジニアが担うようになります。その代わり、PM は「組織が大きくなり複雑化したフェーズ」で、より高度なステークホルダー管理や、エンジニアが深入りできない市場調査などに特化していきます。
PostHog の例では、PM はエンジニアに「何を作るか」を指示するのではなく、エンジニアが正しい意思決定を行えるよう「コンテキスト（文脈や情報）」を与えるサポーターとしての役割を果たしているとのことです。
さいごに
Ian Vanagas 氏の記事は、エンジニアに対して「コードを書くだけでなく、プロダクトのオーナーになれ」と鼓舞するものでした。
日本でも、エンジニア採用において「事業への興味」が問われることが増えています。この記事が示すように、これからのエンジニアは技術力に加え、「プロダクトの成功」にコミットする姿勢――すなわちプロダクトエンジニアとしてのマインドセットが、より一層求められるようになるでしょう。また、PM にとっては、エンジニアを「実装者」としてではなく「共同創業者」のように扱い、権限を移譲していくことが、チームの速度を上げる鍵となりそうです。