職位ガイドライン大前提（特に社外の方へ）

プロダクトエンジニアの定義と役割

#5 プロダクトエンジニアの定義 by Ray Wow FM

2024/9/1にゆめみの職位ガイドラインが大きく変更されました。アプリケーションエンジニア職位ガイドラインがプロダクトエンジニア職位ガイドラインに変更になった背景やプロダクトエンジニアの定義などについて詳しく説明します。

spotifyanchor-web.app.link

プロダクトエンジニアの定義

プロダクトエンジニアの役割は、特定領域の「技術力」と周辺領域への「越境力」でプロダクトの成長を達成することと定義します

越境力の定義

• 越境力とは、アプリケーション（DevOps）エンジニアの主担当領域である「設計・開発・運用」の領域の周辺・隣接領域へ役割を拡張することができる力を指します
• 越境する対象領域は以下となります

越境対象となる周辺・隣接領域

1. ビジネス・ドメイン習熟
2. 顧客・ユーザー体験設計
3. UIデザイン
4. アーキテクチャ設計
5. データ分析
6. プロジェクトリード
7. 組織プロセスマネジメント

アソシエイト職位

アソシエイトからプロフェッショナル職位の昇進必須条件

プロフェッショナル職位

セルフマネジメントを基盤とした上で、チームとの協働力、ビジネスコミュニケーションを身につけ、技術的な専門性を持った上でエンジニアとしてDevOpsの実現が期待された上で、プロダクト志向を常に意識しながら、越境力を持って行動できることが期待されます

プロフェッショナルからリード職位への昇進必須条件

• （重要）プロダクトのロードマップや開発ロードマップを理解した上で、ビジネス価値やユーザー体験の向上の観点であるべき仕様を提示することができる（2025/1/1以降昇進条件適用）

• （重要）生成AIを活用して仕様書の作成・変更からコードの生成・変更を行う を理解している。その上で、現時点ででできる範囲（ツールの制約や案件の制約があることは仕方がない前提）での生成AI活用を行い、自分なりに開発生産性向上の工夫を日常的に行っている（なお、開発生産性向上の手段としては生成AIに限定はしていないことと、生成AIの効用を鵜呑みにすること、とりあえず生成AIを使えば良いという発想も推奨はしていない。加えて言えば、生成AIを活用しやすくするための独自ツールを開発することも手段には含まれる）（2025/1/1以降適用）

• プロフェッショナルランクのコードレビューやペアプロ・ペアワークなどを通じて開発についての指導ができる
• 実際に、プロフェッショナルランクのエンジニアのコード・仕様書のレビューを行っている

リード職位

リード職位の４系統

1. リードエンジニア
1. プロジェクトリード（PL）ロール
2. プロダクトリード（PdL）ロール
2. テックリード
3. アーキテクト
4. マイスターエンジニア

４つの系統から自身にあった軸を選び（兼務でも良いですが、自分の資質、志向性にあった主軸は決めておいてください）キャリアプランに記載してもらいます。

リード志向性ベン図

上記の図にあるように、ゆめみが求めるプロダクトエンジニアは色がついた領域、つまりテック志向がある人を採用で求める要件としています。つまり技術的な専門性の探求に関心がないと判断される色が付いていないグレーの領域は採用の対象外となります。（中途のプロダクトマネージャー、プロダクトデザイナー採用ではグレーにやや近い領域も対象となり得ます）

リード職位の中でも、プロジェクトリード志向やプロダクトリード志向が全くない人は、４系統の中では「テックリード（緑色の領域）」のキャリアがマッチすることになります。 これは、プロダクトエンジニアとしての定義にある「越境力」が無いことを意味はしないです。隣接領域への越境をリードする志向性が強くはないだけであり、越境する役割は全てに求められます。

一方で、プロジェクトリード志向とテックリード志向の重なりである「赤色の領域」は、プロジェクトリード（PL）ロールがマッチします。また、プロダクトリード志向とテックリード志向の重なりであるが、プロジェクトリード志向との重なりはない「ピンクの領域」は、プロダクトリード（PdL）ロールがマッチします。

これは後述しますが、リードエンジニアでPdLロールにマッチする人が役割としてPLロールを担わないことを意味はしません。

加えて、このベン図は自分の志向性にあったキャリアに迷った時の考え方の目安であり、必ずしも厳密にベン図の分類が成立するわけではないことに注意してください。

その他、全ての３つの志向をバランス良くもつタイプが「青色の領域」のアーキテクトとなります。

また、TL志向に偏る中でもプロセス志向が強い「黄色の領域」をマイスターエンジニアとしています。

リード職位：⑴ リードエンジニア

PL・PdLロールの違い（詳細）

プロダクトリード（PdL）に求められる意思決定力

• 特に、PdLロールにおいては、プロダクトの成功、顧客体験を優先するため、納期・品質・予算を変更する意思決定が迫られる
• つまり、ゆめみであれば、顧客への予算追加や納期変更を交渉したり、開発メンバーに対しては技術的負債を敢えて負うという意思決定もする必要がある
• もちろん、大前提としてビジネスの成功の主要因がプロダクトの成功にある場合の話であり、ビジネスの成功の主要因が納期という場合は、納期を優先したプロジェクトリード（PL）ロールが求められる
• つまりは、顧客のビジネスの成功の観点でどの変数を制約として最適解を導くかという判断が最終的には重要になるが、時代の変化としてはPdLロールがより重要になってきているとともに、ゆめみとしてはPdLロールを強化していく

サブ・エンジニアからリードエンジニアへの昇格必須条件

リードエンジニアからチーフリードエンジニアへの昇格必須条件

マルチスタックの例

• iOS、Androidの両方の技術の専門性を持った上で、iOS、 Android両方のプロダクトの設計理解、コード理解があるため、モバイルアプリに関する仕様調整を手戻りなく、実装容易性も考慮した上で、統合的にリードできる場合となります

マルチハットの例

• アーキテクトあるいはプロジェクトマネージャー（チームビルディング・テクニカルセールス・顧客折衝・リスク管理など）の役割も兼務して担うことで、プロジェクトの高い品質や生産性に貢献できる
• 社内のグループ全体の委員会活動、あるいはグループを横断した委員会活動をリードできるレベルでのプロセスマネジメントを兼務して担い、組織に貢献できる

リード職位：⑵ テックリード

700〜900万

行動指針の参考

良いテックリード、悪いテックリード - 小さなごちそう

本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。ベン・ホロウィッツの「 良いプロダクトマージャー、悪いプロダクトマージャー 」からインスピレーションを得ている。 ...

tannomizuki.hatenablog.com

900〜1000万

リード職位：⑶ アーキテクト

サブ・アーキテクト

650〜720万

700〜800万

800〜1000万

リード職位：⑷ マイスターエンジニア

プロジェクトリードやテックリードというチームにおける役割を担わなくても、標準的なエンジニアの２倍以上の生産性が高いエンジニアはマイスター認定され、生産性にあわせて年収想定も高く設定され得る

リーダー職位の年収加算・減算要素

シニア職位

900〜1300万

その他：キャリアのロードマップ

その他情報

制度の背景についての記事

給与は自分で決める？！話題の職位ガイドラインを作ったCEOがエンジニアの評価システムを完全公開。その真意とは？

エンジニアなら一度や二度、「自分は正当に評価されているのか？」と疑問を抱いたことがあるはず。10月、株式会社ゆめみが職位ごとの年収目安と必要なスキルを細かく明文化した「アプリケーション・エンジニア職位ガイドライン詳細」を公開し話題となった。「徹底的な透明性」を追求する代表取締役の片岡氏に、ガイドライン作成の顛末と狙いを聞いた。

levtech.jp