はじめに
ソフトウェア開発の現場では、しばしば「PM（プロダクトマネージャー）が仕様を完璧に決め、エンジニアはそれをコードに落とし込む」という分業体制が見られます。しかし、本当に優れたプロダクトを生み出すチームは、その境界線が曖昧です。
2018年、Atlassianの伝説的PMであるSherif Mansour氏が提唱した「Product Engineer（プロダクトエンジニア）」という概念は、今なお多くの開発チームにとっての北極星となっています。今回は、この記事がなぜ重要なのか、現代の視点も交えて解説します。
1. 著者はどんな人物か
まず、この記事の執筆者であるSherif Mansour（シェリフ・マンスール）氏について紹介します。
経歴のハイライト
Sherif氏は、世界的なコラボレーションツール企業 Atlassian（アトラシアン） における最重要人物の一人です。
20年以上のソフトウェア開発経験を持ち、元々はエンジニアとしてキャリアをスタートさせました。Atlassianでは15年以上にわたり、同社の主力製品である Confluence の責任者を務めたほか、StrideやTeam Calendarsといった新製品の立ち上げも主導。AtlassianのPM組織がまだ数名だった時代から、数百名規模に成長するまでの過程を支えてきた「PMの師」とも言える存在です。
現在の活動（2025年時点）
2025年現在も彼はAtlassianに在籍し、 Distinguished Product Manager というトップクラスの専門職位に就いています。さらに注目すべきは、彼が現在 Head of AI として、AtlassianのAIエージェント製品（Atlassian Rovoなど）の戦略をリードしている点です。かつて「人間同士のコラボレーション」を定義した彼が、今は「人間とAIのコラボレーション」を定義しています。
評価される理由
彼が世界中のPMから支持される理由は、「PMの役割」を権威的な司令塔としてではなく、 「チームの共通理解（Shared Understanding）を作る黒子」 と定義している点にあります。現場のリアリティに根ざした彼の実践論は、決して理想論だけで終わらない説得力があります。
2. なぜこのブログが執筆されたのか（背景の考察）
この記事が公開された2018年当時、アジャイル開発は普及していたものの、多くの組織ではまだ「ウォーターフォール的なアジャイル」が横行していました。「PMが詳細なチケットを書き、エンジニアがそれを消化する」という関係性です。
Sherif氏はこの記事を通じて、 「PMがボトルネックになる構造」への危機感 を表明しました。PMが細部まで指示を出さないと動かないチームはスケールしません。
彼は、 「PMがいなくても自律的に正しい意思決定ができるエンジニア（＝Product Engineer）」 の存在こそが、成功するプロダクト開発の鍵であると説きました。これは単なるエンジニアへの期待ではなく、 「PMよ、もっと権限を手放し、チームに文脈（Context）を渡せ」 という、PM自身の意識変革を促すメッセージでもあったのです。
3. 記事の要点解説
記事の中で、Sherif氏は「プロダクトエンジニア」をどう定義し、どう協働すべきかを説いています。
「プロダクトエンジニア」とは？
単に技術力が高いエンジニアではありません。 「『どう作るか（How）』だけでなく、『なぜ作るか（Why）』に積極的に関与し、テクノロジーを使ってユーザーの課題を一足飛びに解決しようとするエンジニア」 のことです。
プロダクトエンジニアの8つの特徴とPMの振る舞い
Sherif氏は、彼らを見分け、共に働くための8つの特徴を挙げています。
-
確固たる意見を持つ（Strong opinions, loosely held）
- 彼らは「仕様書待ち」をしません。「ここはどうあるべきか」という意見を持って議論に来ます。
- PMの対応: 納得させるために「なぜやるのか」をより丁寧に説明し、信頼関係を築く必要があります。
-
直感を素早く磨く
- 一つの学びから、プロダクト全体への影響を即座に推測します。
- PMの対応: エンジニアを直接顧客に会わせましょう。一次情報に触れさせるのが最強の育成法です。
-
健全な衝突をもたらす
- 「本当にこれをやるべきか？」と根本的な問いを投げかけます。
- PMの対応: これを攻撃と受け取らず、自分たちの考えの「穴」を見つけてくれたと感謝し、議論を深めましょう。
-
エッジケースを最小化する
- レアケースの対応に時間を浪費せず、大多数のユーザーが通る「王道（ハッピーパス）」に注力します。
- PMの対応: 労力対効果（ROI）の判断材料を提供し、彼らが重要な部分に集中できるようガイドします。
-
「クイックウィン」を見つける天才
- コードの中身を知っている彼らこそ、低コストで高い価値を出せる「お宝機能」を知っています。
- PMの対応: PMが解決策を考えるのではなく、「顧客が求める価値」を伝え、解決策は彼らに任せましょう。
-
早期フィードバックを求める
- 完璧なコードを書く前に、ショートカットしてでも仮説検証しようとします。
- PMの対応: フィードバックのトリアージ（優先順位付け）を彼らに任せ、学習サイクルを回しやすい環境を作ります。
-
優れたコミュニケーター
- 技術的な内容だけでなく、チームの学びを共有することに長けています。
- PMの対応: 彼らがステークホルダーにプレゼンしたり、ブログを書いたりする機会を作り、輝かせましょう。
-
意思決定を行い、バックログを所有する
- 自律性を求めます。
- PMの対応: バックログから手を引くこと。 PMがタスク管理係（Jiraのカードを動かす人）になっているなら、それはチームに十分なコンテキストを渡せていない証拠です。
さいごに
Sherif Mansour氏のメッセージは明確です。
「PMの究極の目標は、共通理解を作り上げ、自分自身を不要にすること」 。
2025年の現在、生成AIやCopilotの台頭により、「コードを書くこと」自体のハードルは劇的に下がりました。だからこそ、 「何を、なぜ作るのか」を理解し、実装に落とし込めるプロダクトエンジニア の価値は、2018年当時よりもさらに高まっています。
PMにとっては「権限を手放す勇気」を、エンジニアにとっては「ビジネスやユーザーへの好奇心」を。この記事は、双方が歩み寄るための最高のガイドラインと言えるでしょう。