『Product Engineers』解説と考察

プロダクト開発の現場において、「エンジニアは仕様通りに作る人」「PM は仕様を決める人」という分断が起きることは珍しくありません。しかし、世界的に成功しているプロダクトチームでは、その境界線はもっと曖昧で、より有機的です。

今回は、Atlassian で長年プロダクトマネジメントを牽引してきた Sherif Mansour 氏による記事『Product Engineers』を題材に、「 プロダクトエンジニア 」という概念について深掘りします。

Deep Research など生成 AI を利用した内容を元にしています。

1. 著者はどんな人物か：Sherif Mansour（シェリフ・マンスール） 氏

経歴のハイライト

Sherif Mansour氏は、Jira や Confluence で知られる Atlassian（アトラシアン） に 10 年以上在籍したベテランのプロダクトマネージャー（PM）です。「Distinguished Product Manager」として、同社のプロダクトマネジメント文化の形成に大きく貢献しました。

現在の活動

現在は Atlassian を離れ、プロダクトアドバイザーやスピーカーとして活動しているほか、自身の経験に基づいた実践的な知見を Medium や講演を通じて発信し続けています。

評価される理由

彼が多くの PM やエンジニアから支持される理由は、「 脱・機能工場（Feature Factory） 」を提唱するなど、単に機能を作るのではなく「顧客価値」をどう生み出すかという本質的な議論を主導してきた点にあります。

教科書的な理論ではなく、急成長する組織（Atlassian）の中での泥臭い経験に基づいた、「現場で使えるマインドセット」を言語化する能力が極めて高く評価されています。

2. なぜこのブログが執筆されたのか（背景の考察）

この記事が書かれた背景には、著者と当時の Atlassian エンジニアリング責任者（後に Shopify の SVP of Engineering、後に CTO となる）Jean-Michel Lemieux 氏との対話があります。

「成功するプロジェクト」の共通項

彼らが成功したプロジェクトを振り返った際、そこには特定の職種（PM やデザイナー）が揃っているかどうかではなく、「ある種のタイプのエンジニア」が存在したことが共通点だと気づきました。

「How」から「Why」へのシフト

ソフトウェア産業が成熟するにつれ、「どう作るか（How）」の技術的な難易度は相対的に下がってきています（フレームワークやインフラの進化による）。その中で、「 なぜ作るのか（Why） 」、つまり「技術を使ってどうユーザーの課題を一足飛びに解決するか」を考えられるエンジニアの価値が急上昇しているのです。

この記事は、単なるエンジニアのスキル定義ではなく、「 PM がマイクロマネジメントをやめ、チームに自律性を持たせるためには、どのようなエンジニア像が必要か 」という、組織論へのアンチテーゼとして執筆されたと言えます。

3. 記事の要点解説

Sherif 氏は、「プロダクトエンジニア」を単に技術力が高い人ではなく、「 プロダクトマネージャーのような動きができるエンジニア 」と定義しています。

PM が目指すべきゴール

PM の究極の仕事は、自分自身を 「 不要（Redundant） 」にすることです。これは職務放棄ではなく、チーム全員に十分なコンテキスト（背景情報）を与え、権限委譲することで、自分がいなくても正しい意思決定ができる状態を作ることを意味します。

プロダクトエンジニアの 8 つの特徴

記事では、プロダクトエンジニアの特徴と、それに対して PM がどう振る舞うべきかが解説されています。

1. 確固たる意見を持つ（が、固執しない）
   • 仕様待ちをせず、「もっとこうすべきでは？」と意見を持ってくる。
   • PM の役割： なぜそれをやるのか、説明責任を果たすことで信頼を得る。
2. 直感と共感力が高い
   • 顧客の課題を「自分ごと」として捉え、抽象的な課題から解決策を導き出す。
   • PM の役割： エンジニアを顧客に直接会わせる。間に割って入らない。
3. 健全な対立をもたらす
   • 「本当にこれを作る必要がある？」と現状に異議を唱える。
   • PM の役割： 批判を歓迎する。それがより良いプロダクトにつながることを理解する。
4. エッジケースを最小化し、本筋に集中する
   • 全てのバグを潰すことより、大多数のユーザーが通る「理想的な体験」に注力する。
   • PM の役割： トレードオフの判断材料（価値と頻度）を提供する。
5. 「クイックウィン」を見つける天才
   • コードの中身を知っているからこそ、低コストで高価値な実装（Low hanging fruit）を見抜ける。
   • PM の役割： PM が解決策を指定せず、課題と価値の定義に徹する。
6. 早期フィードバックを求める
   • 完璧なコードを書く前に、ショートカットしてでも仮説検証を優先する。
   • PM の役割： フィードバックループ（定性・定量）へのアクセス権限を与える。
7. 優れたコミュニケーター
   • 自分の仕事を周囲に伝え、学習を共有する能力がある。
   • PM の役割： 彼らが発信し、輝ける場を用意する。
8. バックログのオーナーになる
   • 自律的に意思決定し、タスク管理を PM に依存しない。
   • PM の役割： バックログに触らない。 チームが自走できるだけのコンテキストを提供する。

さいごに

PM の視点を得られる貴重なブログでした。

「エンジニアにもっとコードを書いてほしい」ではなく、「エンジニアにもっと課題を理解してほしい」と願うのであれば、PM がすべきことは仕様書を細かく書くことではなく、顧客の痛みやビジネスの背景という「共通認識（Shared Understanding）」を徹底的に共有し、あとは彼らを信じて任せること（Get out of the way）なのだと学びました。