変更履歴
目次
職位ガイドライン大前提(特に社外の方へ)
ゆめみでは、
給与自己決定制度(公式ドキュメント) での給与決定が運用されています。下記ガイドラインに関わらず、人材市場評価・社内市場評価も勘案しながら、周囲からレビューをもらい最後は給与を自己決定をします。給与はえいやで決めるとしています。
また、「ガイドライン」とは、その定義から、それを参考にした上で本人が自己決定する手がかりでしかありません。チェックリストを満たしたら単純に給与が上がるというものではないですし、チェックリストを満たしていないから給与が上げられないわけでもありません。
細分化した役割、期待、能力を設定している理由としては、本人が自ら能力開発目標を立てるための助けになるとして設定もされています。
その上で、本ガイドラインを外部にオープンにする事により、業界においてエンジニアがより適正に評価され、能力開発が進む事を期待しますし、各社もオープングレードとして等級制度の内容をオープンにする流れが進むと良いと考えています。
プロダクトエンジニアの定義と役割
以下の説明動画を参考にしてください
プロダクトエンジニアの定義
プロダクトエンジニアの役割は、特定領域の「技術力」と周辺領域への「越境力」でプロダクトの成長を達成することと定義します
越境力の定義
越境力とは、アプリケーション(DevOps)エンジニアの主担当領域である「設計・開発・運用」の領域の周辺・隣接領域へ役割を拡張することができる力を指します
越境する対象領域は以下となります
越境対象となる周辺・隣接領域
ビジネス・ドメイン習熟
顧客・ユーザー体験設計
UIデザイン
アーキテクチャ設計
データ分析
プロジェクトリード
組織プロセスマネジメント
役割や期待
アソシエイト職位
アソシエイト [
]
アソシエイトからプロフェッショナル職位の昇進必須条件
下記の条件が満たせなければ、いくらプロフェッショナル職位のチェック項目が付いていても、プロフェッショナル職位にはなれないでアソシエイト職位のままとなる。その場合、アソシエイト職位の給与上限が550万のため、昇給の上限も550万となる
ZAC「プロジェクト学習」の調整係数が必要なくなった段階、ハンズオンでの育成担当も外れて自走できる状態になり、必要に応じて自ら相談しにいくだけで業務が進む段階になっている
過去3ヶ月の平均案件稼働率が87%以上となっている
なお、新卒は入社後平均7ヶ月(標準偏差3ヶ月)には、アソシエイトのガイドラインを満たす事が期待されます
ただし、ゆめみの新卒エンジニアについては、800-1000時間以上の実践的なプログラミング歴が入社前にあることが標準的な想定となっている前提。
プロフェッショナル職位
セルフマネジメントを基盤とした上で、チームとの協働力、ビジネスコミュニケーションを身につけ、技術的な専門性を持った上でエンジニアとしてDevOpsの実現が期待された上で、プロダクト志向を常に意識しながら、越境力を持って行動できることが期待されます
プロフェッショナル [
]
チーフ・プロフェッショナル [
]
プロフェッショナルからリード職位への昇進必須条件
(重要)プロダクトのロードマップや開発ロードマップを理解した上で、ビジネス価値やユーザー体験の向上の観点であるべき仕様を提示することができる(2025/1/1以降昇進条件適用)
(重要)生成AIを活用して仕様書の作成・変更からコードの生成・変更を行う No access を理解している。その上で、現時点ででできる範囲(ツールの制約や案件の制約があることは仕方がない前提)での生成AI活用を行い、自分なりに開発生産性向上の工夫を日常的に行っている(なお、開発生産性向上の手段としては生成AIに限定はしていないことと、生成AIの効用を鵜呑みにすること、とりあえず生成AIを使えば良いという発想も推奨はしていない。加えて言えば、生成AIを活用しやすくするための独自ツールを開発することも手段には含まれる)(2025/1/1以降適用)
プロフェッショナルランクのコードレビューやペアプロ・ペアワークなどを通じて開発についての指導ができる
実際に、プロフェッショナルランクのエンジニアのコード・仕様書のレビューを行っている
なお、新卒は入社後平均18ヶ月(標準偏差6ヶ月)には、チーフプロフェッショナルのガイドラインを満たす事が期待されます
リード職位
リード職位の4系統
リードエンジニア
プロジェクトリード(PL)ロール
プロダクトリード(PdL)ロール
テックリード
アーキテクト
マイスターエンジニア
4つの系統から自身にあった軸を選び(兼務でも良いですが、自分の資質、志向性にあった主軸は決めておいてください)キャリアプランに記載してもらいます。
リード志向性ベン図
ゆめみのエンジニアは、プロダクトエンジニアとして定義されているため、テック志向ではないと思われる可能性がありますが、そうではないです。テック志向のエンジニアが集まった上で、職位がプロフェッショナルからリードになる中で、自身の志向性に合わせてマッチしたリードロールの役割を担ってもらいます。
上記の図にあるように、ゆめみが求めるプロダクトエンジニアは色がついた領域、つまりテック志向がある人を採用で求める要件としています。つまり技術的な専門性の探求に関心がないと判断される色が付いていないグレーの領域は採用の対象外となります。(中途のプロダクトマネージャー、プロダクトデザイナー採用ではグレーにやや近い領域も対象となり得ます)
リード職位の中でも、プロジェクトリード志向やプロダクトリード志向が全くない人は、4系統の中では「テックリード(緑色の領域)」のキャリアがマッチすることになります。 これは、プロダクトエンジニアとしての定義にある「越境力」が無いことを意味はしないです。隣接領域への越境をリードする志向性が強くはないだけであり、越境する役割は全てに求められます。
一方で、プロジェクトリード志向とテックリード志向の重なりである「赤色の領域」は、プロジェクトリード(PL)ロールがマッチします。また、プロダクトリード志向とテックリード志向の重なりであるが、プロジェクトリード志向との重なりはない「ピンクの領域」は、プロダクトリード(PdL)ロールがマッチします。
これは後述しますが、リードエンジニアでPdLロールにマッチする人が役割としてPLロールを担わないことを意味はしません。
加えて、このベン図は自分の志向性にあったキャリアに迷った時の考え方の目安であり、必ずしも厳密にベン図の分類が成立するわけではないことに注意してください。
その他、全ての3つの志向をバランス良くもつタイプが「青色の領域」のアーキテクトとなります。
また、TL志向に偏る中でもプロセス志向が強い「黄色の領域」をマイスターエンジニアとしています。
リード職位:⑴ リードエンジニア
ゆめみでのリードエンジニアには、プロジェクトリードとプロダクトリードの2つの役割が期待されます。
PLロール、PdLロールは、あくまでリードエンジニアのロールであり、プロジェクトリードエンジニア、プロダクトリードエンジニアとして、リードエンジニアの職種が2つに分かれる訳ではありません
両方の役割を実施できることが期待されますが、人の資質や得意領域によってはいずれかの一方に偏ることも可能とします。
プロジェクトリード(PL)ロールに期待される役割
3つのコアバリュー
プロジェクトリードエンジニアには、技術的な専門性を持った上で、3つのコアバリューを発揮するプロジェクトリードとしての役割が期待されます
仕事の進め方・情報共有など方針策定
顧客や関係者との詳細仕様調整や、前工程におけるリスク洗い出し
チームにおける課題解決、タスクマネジメント
プロダクトリード(PdL)ロールに期待される役割
3つのコアバリュー
プロダクトリードエンジニアには、技術的な専門性をを持った上で、3つのコアバリューを発揮するプロダクトリードとしての役割が期待されます
幅広い技術スキルとビジネス理解
プロダクトの方向性に関する意思決定支援力
チームにおける課題解決、タスクマネジメント
PL・PdLロールの違い(詳細)
項目 | プロジェクトリード(PL) | プロダクトリード(PdL) |
主な焦点 | 特定のプロジェクトの完遂 | プロダクト全体の長期的な成功 |
時間枠 | プロジェクト期間(短期~中期) | プロダクトのライフサイクル全体(長期) |
主要な責任 | プロジェクトの技術的側面の管理 | プロダクトの技術戦略の策定と実行 |
チーム構成 | プロジェクトチーム | クロスファンクショナルなプロダクトチーム |
技術スキル | プロジェクト関連の専門技術 | 幅広い技術知識とアーキテクチャ設計能力 |
ビジネススキル | プロジェクト管理、予算管理 | プロダクト戦略、市場分析、ビジネスモデル理解 |
ステークホルダー管理 | プロジェクトの調整 | 社内外の幅広いステークホルダーとの協働 |
成功の指標 | プロジェクトの納期、品質、予算 | プロダクトの市場での成功、顧客満足度、収益 |
イノベーション | プロジェクト範囲内での改善 | プロダクト全体のイノベーションと競争力向上 |
リスク管理 | プロジェクト固有のリスク対応 | プロダクトに関する長期的リスクの予測と対策 |
意思決定 | プロジェクトスコープ内での決定 | プロダクトの方向性に関する戦略的決定 |
キャリアパス | PM、PMO、リードアーキテクト | PdM、VPoP、ビジネスアーキテクト、スタッフアーキテクト |
プロダクトリード(PdL)に求められる意思決定力
特に、PdLロールにおいては、プロダクトの成功、顧客体験を優先するため、納期・品質・予算を変更する意思決定が迫られる
つまり、ゆめみであれば、顧客への予算追加や納期変更を交渉したり、開発メンバーに対しては技術的負債を敢えて負うという意思決定もする必要がある
もちろん、大前提としてビジネスの成功の主要因がプロダクトの成功にある場合の話であり、ビジネスの成功の主要因が納期という場合は、納期を優先したプロジェクトリード(PL)ロールが求められる
つまりは、顧客のビジネスの成功の観点でどの変数を制約として最適解を導くかという判断が最終的には重要になるが、時代の変化としてはPdLロールがより重要になってきているとともに、ゆめみとしてはPdLロールを強化していく
サブ・リードエンジニア [
]
なお、新卒は入社後平均30ヶ月(標準偏差6ヶ月、つまり約7割の新卒)には、サブ・リードエンジニアのガイドラインを満たす事が期待されます。
サブ・エンジニアからリードエンジニアへの昇格必須条件
リード・エンジニア [
]
リードエンジニアからチーフリードエンジニアへの昇格必須条件
技術的な高い専門性を持っていて、特定のチームやプロジェクトに依存せず、リードエンジニア業務を独力で行うことができている(チーフリードへの昇格必須条件)
実際に複数のプロジェクトや異なるチームメンバーとの組み合わせでリードエンジニアとして業務を独力で行った実績がある
顧客企業のエンジニアチームと共同開発を行う内製化支援業務においても、顧客からリードエンジニアとして技術的に評価されるレベル
チーフ・リードエンジニア [
]
マルチ・リードエンジニア [
]
マルチスタックの例
iOS、Androidの両方の技術の専門性を持った上で、iOS、 Android両方のプロダクトの設計理解、コード理解があるため、モバイルアプリに関する仕様調整を手戻りなく、実装容易性も考慮した上で、統合的にリードできる場合となります
マルチハットの例
アーキテクトあるいはプロジェクトマネージャー(チームビルディング・テクニカルセールス・顧客折衝・リスク管理など)の役割も兼務して担うことで、プロジェクトの高い品質や生産性に貢献できる
社内のグループ全体の委員会活動、あるいはグループを横断した委員会活動をリードできるレベルでのプロセスマネジメントを兼務して担い、組織に貢献できる
リード職位:⑵ テックリード
テックリード [
]
700〜900万
サブ・リードエンジニアとしての職位ガイドラインを満たした上で、高い専門性と設計・実装力があり、複数のプロジェクト・プロダクトに対して技術的な課題解決を行うことができる
行動指針の参考
チーフ・テックリード [
]
900〜1000万
リード職位:⑶ アーキテクト
サブ・アーキテクト
650〜720万
リードエンジニアの職位とアーキテクトの職位ガイドラインの一部を満たした上でアーキテクトの補佐を行うことができる
アーキテクト [
]
700〜800万
リードエンジニアの職位ガイドラインを満たした上でシステム全体の設計やコアな部分の実装も行うことができる
リードアーキテクト [
]
800〜1000万
規模が大きかったり、複雑性が高いサービスにおいてシステム全体の設計だけでなく、クリティカルな部分の実装も行うことができる
リード職位:⑷ マイスターエンジニア
プロジェクトリードやテックリードというチームにおける役割を担わなくても、標準的なエンジニアの2倍以上の生産性が高いエンジニアはマイスター認定され、生産性にあわせて年収想定も高く設定され得る
マイスターエンジニア [
]
チーフ・マイスターエンジニア [
]
リーダー職位の年収加算・減算要素
マイスターエンジニア兼リードエンジニア
テックリード兼リードエンジニア
マルチスタックエンジニア
マルチハット・エンジニア
フルサイクル・エンジニア
シニア職位
900〜1300万