変更履歴
2021/9/23
プロジェクトリードにおける考察について取り入れた
2021/10/11
職種の人数が多い、アプリケーションエンジニアを対象として、まずは内容を詳細化してアップデート
2021/12/10
プロフェッショナルの年収を520~550万を520~570万に変更
チーフプロフェッショナルの年収を550~600万を570~620万に変更
マルチリードエンジニア、チーフテックリード、リード・アーキテクト、チーフマイスターエンジニアの年収上限を950万から1000万に変更
アーキテクト、リードアーキテクトの職位ガイドラインの詳細（暫定）を追加
2022/4/11
リードエンジニアの年収レンジを650-700万についてを、650-720万に変更
チーフリードエンジニアの年収レンジを超える700-800万から、720-800万に変更
2023/3/13
プロフェッショナルのチームコラボレーション（主体性）に追加
プリセールスにおいて、チームの状況に応じて営業と共に商談に参加した上で、ヒアリング、提案対応を主体的に行うことができる。
2023/05/30
人材市場の状況を踏まえて、マルチスタックが一定期待される状況もあるので、一定職位以上（チーフプロフェッショナル）においてはマルチスタックが加点要素になることもあれば、マルチスタックでないことによる減点要素もあり得ることをキャリアパスの図に反映
2024/06/23
職位ガイドラインの給与レンジの変更
変更前
サブリードエンジニア 600-650万
リードエンジニア. 650-720万
変更後
サブリードエンジニア 600-680万
リードエンジニア. 650-750万
2024/06/25
2024/7/10
サブリードの職位ガイドラインに追加
チーフ・プロフェッショナル職位の能力を持った上で、標準的な規模（同じ職能のエンジニアが数名程度参画）、難易度のプロジェクトで、リードエンジニア業務として以下を（リード・エンジニアからの支援をもらった上で）行うことができている
①テクニカルセールス
顧客要望を要件として整理し、実装や単体テストの作業工数を見積もることができる
②工数見積
システムの要件を仕様化し、各機能の課題、実装工数（設計、実装、単体テスト）、試験工数（結合）の見積もりを行うことができる
③スケジュール管理
作業メンバーの開発状況の整理、課題や問題の把握、遅延や巻き返しなどのサポートを行い、遅延の可能性があればリードエンジニアへの報告を行うことができる
④ドキュメント作成・管理
成果物の管理（ソースコード、納品物ドキュメント、機微情報）を適切に行える
⑤仕様調整
仕様の曖昧な点などについて、あるべき案の提案をすることができる
2024/7/26
サブ・アーキテクトの職位を追加
2024/727
リードエンジニアの職位ガイドラインに、プロダクトリードロール（ver0.5）を追加
プロダクトリードタイプの人のキャリアを用意するために、まずはプロダクトリードロールを追加
今後、給与プロリクのテンプレートに反映
チーフプロダクトリードエンジニアの職位ガイドラインに必要になったら作成する
2024/8/2
以下を削除。書籍よりも他の情報インプットの重要性が向上、およびアウトカムを目的した学習方針の変更により
積読の効用をポジティブに捉えた上で、目安として月間の読書量の５倍の積読を行うことができている
2024/9/1
アプリケーションエンジニアガイドラインをプロダクトエンジニアガイドラインに変更
機械学習エンジニアにおけるマルチスタックの記述は、生成AIエンジニアに修正
フロントエンドのキャリア６系統について修正
マイスターエンジニアを削除して、プロダクトリードに変更
テックリードの位置付けを生成AI時代に合わせて変更
プロダクトエンジニアの定義や役割や期待 を記載
2024/9/21
リード志向のベン図を追加
2024/10/31
アソシエイト職位の給与レンジの上限を530万から550万に変更
特に早期内定を出した後、期間を経て入社したアソシエイトは保有能力が向上して入社後速やかに給与改定プロリクを出して昇給するケースがあるため
職位ガイドライン大前提（特に社外の方へ）
ゆめみでは、 給与自己決定制度（公式ドキュメント） での給与決定が運用されています。下記ガイドラインに関わらず、人材市場評価・社内市場評価も勘案しながら、周囲からレビューをもらい最後は給与を自己決定をします。給与はえいやで決めるとしています。
また、「ガイドライン」とは、その定義から、それを参考にした上で本人が自己決定する手がかりでしかありません。チェックリストを満たしたら単純に給与が上がるというものではないですし、チェックリストを満たしていないから給与が上げられないわけでもありません。
細分化した役割、期待、能力を設定している理由としては、本人が自ら能力開発目標を立てるための助けになるとして設定もされています。
その上で、本ガイドラインを外部にオープンにする事により、業界においてエンジニアがより適正に評価され、能力開発が進む事を期待しますし、各社もオープングレードとして等級制度の内容をオープンにする流れが進むと良いと考えています。
給与自己決定制度（公式ドキュメント） での給与決定が運用されています。下記ガイドラインに関わらず、人材市場評価・社内市場評価も勘案しながら、周囲からレビューをもらい最後は給与を自己決定をします。給与はえいやで決めるとしています。
また、「ガイドライン」とは、その定義から、それを参考にした上で本人が自己決定する手がかりでしかありません。チェックリストを満たしたら単純に給与が上がるというものではないですし、チェックリストを満たしていないから給与が上げられないわけでもありません。
細分化した役割、期待、能力を設定している理由としては、本人が自ら能力開発目標を立てるための助けになるとして設定もされています。
その上で、本ガイドラインを外部にオープンにする事により、業界においてエンジニアがより適正に評価され、能力開発が進む事を期待しますし、各社もオープングレードとして等級制度の内容をオープンにする流れが進むと良いと考えています。
プロダクトエンジニアの定義と役割
以下の説明動画を参考にしてください
プロダクトエンジニアの定義
プロダクトエンジニアの役割は、特定領域の「技術力」と周辺領域への「越境力」でプロダクトの成長を達成することと定義します
越境力の定義
越境力とは、アプリケーション（DevOps）エンジニアの主担当領域である「設計・開発・運用」の領域の周辺・隣接領域へ役割を拡張することができる力を指します
越境する対象領域は以下となります
越境対象となる周辺・隣接領域
ビジネス・ドメイン習熟
顧客・ユーザー体験設計
UIデザイン
アーキテクチャ設計
データ分析
プロジェクトリード
組織プロセスマネジメント
役割や期待
越境性について
「越境性」とは、自分の専門分野や主要な責任領域を超えて、他の関連分野や領域にも積極的に関わり、貢献する能力や姿勢のことです。
具体例
フロントエンドエンジニアがUIデザインの提案をする
バックエンドエンジニアがユーザー体験の改善に関与する
モバイルアプリエンジニアがデータ分析に携わる
他との違い
フルスタックとの違い
特定の技術スタックに専念することもある（例：フロントエンドプロダクトエンジニア、iOSプロダクトエンジニア）
フルサイクルとの違い
工程としては全て（例：企画から分析まで）を一貫して主担当するわけではない
プロダクトエンジニアならではの越境対象（１〜３の領域）
これまでも、アプリケーションエンジニアとして職位が上がる中では、「4〜6の領域」を主担当として担当することはあった
一方で、プロダクトエンジニアについては、「1〜3の領域」にも越境していく事が期待される
特に、2, 3については、最低限のドメイン理解はあった上で、1のドメイン習熟に可能な限り踏み込みながら、こうあるべきという要求定義も一部責務として担うことが期待される（どこまでいっても、1の領域の専門家であるドメインエキスパートレベルでのドメイン習熟には至らないが、そこに踏み込み、近づくことが必要）
いずれの越境先の領域においても、その領域を責任もって遂行する専門家は別にいることが前提
その場合は、お互いに重なる領域の中で協働していく連携性において能動性を発揮するリーダーシップこそがプロダクトエンジニアへの期待になる
ゆめみならではの越境対象（７の領域）
ゆめみは会社をプロダクトとして規定しているので「７の領域」組織プロセスマネジメント（ナーチャリング、採用、委員会など含めて）にも越境するというのが他社との違いになっています
一方で、このプロセスマネジメントへの越境性は、顧客とのプロダクトチームにおけるプロセスマネジメントの改善などにも役立つことがありますが、プロダクトによっては関与が難しい場合もあるので、案件においては任意対象としています
リードエンジニアの２種類のロールとの関連性
プロジェクトリードロール
プロダクトリードロール
の2種類の役割が、ゆめみのリードエンジニアには期待されます。
プロジェクトリードロールは「6の領域」を主な領域として担当する役割となります。
一方で、プロダクトリードロールでは、「1〜7の領域」の特定の領域の責務を担うというよりは、「1〜7の領域」に関わらず、プロダクト成長を目的こから逆算して必要な領域に越境することが期待されます。
背景
ゆめみのアプリケーションエンジニアは、プロダクトエンジニアであるべきとして規定した背景には以下が挙げられます
分業の弊害
規模が大きいプロダクトや企業で分業化が進む中で、プロダクト志向が失われる弊害がある、特にゆめみはテック志向が強い人を採用する中で、プロダクト志向が顧客への価値提供において重要になっています
PdM支援の重要性が業界として高まる
プロダクトの規模や複雑性が高まる中で、どこまでいっても最後には、個の意思決定に委ねるべき役割のPdMに責任が集中することで、PdM大変問題が起きているが、それを解決するためには、エンジニアもプロダクト志向としてPO・PdMを支援する必要が業界的には高まっています
ゆめみの顧客からのニーズ
内製化支援を進める中で、プロダクト志向がより求められており、そこに対応していく必要があります
生成AIによる影響
生成AIによって実装者（How）が仕様（What）を決める役割を担う No access が、これから数年後に浸透する（と予想される）中で、顧客体験やビジネス（Why）を理解する必要が出てきました
採用との関連性
ゆめみでは特定領域の技術志向が高い人を採用してきました
今後も、特定の技術領域の強みを大切にすることは変わりません
一方で、その強みを軸にしながらも、越境できる事が、エンジニアに限らず、ほぼ全ての職種に求められると予想されます
参考
アソシエイト職位
アソシエイト []
480-550万
以下のリンクトデータベースは、給与プロリクのテンプレートで呼び出されているマスターDBなので決して修正しないでください
アソシエイトエンジニア推奨図書
Clean Architecture - 達人に学ぶソフトウェアの構造と設計（アソシエイトには少しレベルが高いかもしれませんが，あえてアソシエイトの段階で一読することは勧めたい）
SOFT SKILLS（技術ではなく，処世術や技術者としての生存戦略として）
アソシエイトからプロフェッショナル職位の昇進必須条件
下記の条件が満たせなければ、いくらプロフェッショナル職位のチェック項目が付いていても、プロフェッショナル職位にはなれないでアソシエイト職位のままとなる。その場合、アソシエイト職位の給与上限が550万のため、昇給の上限も550万となる
ZAC「プロジェクト学習」の調整係数が必要なくなった段階、ハンズオンでの育成担当も外れて自走できる状態になり、必要に応じて自ら相談しにいくだけで業務が進む段階になっている
過去3ヶ月の平均案件稼働率が87%以上となっている
セルフオンボーディング プログラム が2000点以上となっているなお、新卒は入社後平均７ヶ月（標準偏差３ヶ月）には、アソシエイトのガイドラインを満たす事が期待されます
ただし、ゆめみの新卒エンジニアについては、800-1000時間以上の実践的なプログラミング歴が入社前にあることが標準的な想定となっている前提。
プロフェッショナル職位
セルフマネジメントを基盤とした上で、チームとの協働力、ビジネスコミュニケーションを身につけ、技術的な専門性を持った上でエンジニアとしてDevOpsの実現が期待された上で、プロダクト志向を常に意識しながら、越境力を持って行動できることが期待されます
プロフェッショナル []
520〜570万
プロフェッショナル職位推薦図書
ソフトウェアテストの教科書 （こちらの書籍は異論があると思います）
なお、新卒は入社後平均１２ヶ月（標準偏差３ヶ月）には、プロフェッショナルのガイドラインを満たす事が期待されます
チーフ・プロフェッショナル []
570〜620万
プロフェッショナルからリード職位への昇進必須条件
（重要）プロダクトのロードマップや開発ロードマップを理解した上で、ビジネス価値やユーザー体験の向上の観点であるべき仕様を提示することができる（2025/1/1以降昇進条件適用）
（重要）生成AIを活用して仕様書の作成・変更からコードの生成・変更を行う No access を理解している。その上で、現時点ででできる範囲（ツールの制約や案件の制約があることは仕方がない前提）での生成AI活用を行い、自分なりに開発生産性向上の工夫を日常的に行っている（なお、開発生産性向上の手段としては生成AIに限定はしていないことと、生成AIの効用を鵜呑みにすること、とりあえず生成AIを使えば良いという発想も推奨はしていない。加えて言えば、生成AIを活用しやすくするための独自ツールを開発することも手段には含まれる）（2025/1/1以降適用）
プロフェッショナルランクのコードレビューやペアプロ・ペアワークなどを通じて開発についての指導ができる
実際に、プロフェッショナルランクのエンジニアのコード・仕様書のレビューを行っている
なお、新卒は入社後平均１８ヶ月（標準偏差６ヶ月）には、チーフプロフェッショナルのガイドラインを満たす事が期待されます
リード職位
リード職位の４系統
リードエンジニア
プロジェクトリード（PL）ロール
プロダクトリード（PdL）ロール
テックリード
アーキテクト
マイスターエンジニア
４つの系統から自身にあった軸を選び（兼務でも良いですが、自分の資質、志向性にあった主軸は決めておいてください）キャリアプランに記載してもらいます。
リード志向性ベン図
ゆめみのエンジニアは、プロダクトエンジニアとして定義されているため、テック志向ではないと思われる可能性がありますが、そうではないです。テック志向のエンジニアが集まった上で、職位がプロフェッショナルからリードになる中で、自身の志向性に合わせてマッチしたリードロールの役割を担ってもらいます。
上記の図にあるように、ゆめみが求めるプロダクトエンジニアは色がついた領域、つまりテック志向がある人を採用で求める要件としています。つまり技術的な専門性の探求に関心がないと判断される色が付いていないグレーの領域は採用の対象外となります。（中途のプロダクトマネージャー、プロダクトデザイナー採用ではグレーにやや近い領域も対象となり得ます）
リード職位の中でも、プロジェクトリード志向やプロダクトリード志向が全くない人は、４系統の中では「テックリード（緑色の領域）」のキャリアがマッチすることになります。 これは、プロダクトエンジニアとしての定義にある「越境力」が無いことを意味はしないです。隣接領域への越境をリードする志向性が強くはないだけであり、越境する役割は全てに求められます。
一方で、プロジェクトリード志向とテックリード志向の重なりである「赤色の領域」は、プロジェクトリード（PL）ロールがマッチします。また、プロダクトリード志向とテックリード志向の重なりであるが、プロジェクトリード志向との重なりはない「ピンクの領域」は、プロダクトリード（PdL）ロールがマッチします。
これは後述しますが、リードエンジニアでPdLロールにマッチする人が役割としてPLロールを担わないことを意味はしません。
加えて、このベン図は自分の志向性にあったキャリアに迷った時の考え方の目安であり、必ずしも厳密にベン図の分類が成立するわけではないことに注意してください。
その他、全ての３つの志向をバランス良くもつタイプが「青色の領域」のアーキテクトとなります。
また、TL志向に偏る中でもプロセス志向が強い「黄色の領域」をマイスターエンジニアとしています。
リード職位：⑴ リードエンジニア
ゆめみでのリードエンジニアには、プロジェクトリードとプロダクトリードの２つの役割が期待されます。
PLロール、PdLロールは、あくまでリードエンジニアのロールであり、プロジェクトリードエンジニア、プロダクトリードエンジニアとして、リードエンジニアの職種が２つに分かれる訳ではありません
両方の役割を実施できることが期待されますが、人の資質や得意領域によってはいずれかの一方に偏ることも可能とします。
プロダクトリード（PdL）ロールに期待される役割
３つのコアバリュー
プロダクトリードエンジニアには、技術的な専門性をを持った上で、３つのコアバリューを発揮するプロダクトリードとしての役割が期待されます
幅広い技術スキルとビジネス理解
プロダクトの方向性に関する意思決定支援力
チームにおける課題解決、タスクマネジメント
PL・PdLロールの違い（詳細）
プロダクトリード（PdL）に求められる意思決定力
特に、PdLロールにおいては、プロダクトの成功、顧客体験を優先するため、納期・品質・予算を変更する意思決定が迫られる
つまり、ゆめみであれば、顧客への予算追加や納期変更を交渉したり、開発メンバーに対しては技術的負債を敢えて負うという意思決定もする必要がある
もちろん、大前提としてビジネスの成功の主要因がプロダクトの成功にある場合の話であり、ビジネスの成功の主要因が納期という場合は、納期を優先したプロジェクトリード（PL）ロールが求められる
つまりは、顧客のビジネスの成功の観点でどの変数を制約として最適解を導くかという判断が最終的には重要になるが、時代の変化としてはPdLロールがより重要になってきているとともに、ゆめみとしてはPdLロールを強化していく
サブ・リードエンジニア []
600〜680万
サブ・リードエンジニアからリード・エンジニアへの昇格必須条件
チーフ・プロフェッショナル職位の能力を持った上で、標準的な規模（同じ職能のエンジニアが数名程度参画）、難易度のプロジェクトで、リードエンジニア業務として以下を（リード・エンジニアからの支援をもらった上で）行うことができている
①テクニカルセールス
顧客要望を要件として整理し、実装や単体テストの作業工数を見積もることができる
②工数見積
システムの要件を仕様化し、各機能の課題、実装工数（設計、実装、単体テスト）、試験工数（結合）の見積もりを行うことができる
③スケジュール管理
作業メンバーの開発状況の整理、課題や問題の把握、遅延や巻き返しなどのサポートを行い、遅延の可能性があればリードエンジニアへの報告を行うことができる
④ドキュメント作成・管理
成果物の管理（ソースコード、納品物ドキュメント、機微情報）を適切に行える
⑤仕様調整
仕様の曖昧な点などについて、あるべき案の提案をすることができる
なお、新卒は入社後平均３０ヶ月（標準偏差６ヶ月、つまり約７割の新卒）には、サブ・リードエンジニアのガイドラインを満たす事が期待されます。
サブ・エンジニアからリードエンジニアへの昇格必須条件
リード・エンジニア []
650〜750万
プロジェクトリードロール（PL）
エンジニアとしての技術的な専門性に加えて、プロジェクトリードとして成果を出している
プロダクトリードロール（PdL）
エンジニアとしての幅広い技術的な専門性やビジネス理解を持った上で、プロダクトの価値向上やユーザー体験の向上を目的にプロダクトリードとして成果を出せている
リードエンジニアからチーフリードエンジニアへの昇格必須条件
技術的な高い専門性を持っていて、特定のチームやプロジェクトに依存せず、リードエンジニア業務を独力で行うことができている（チーフリードへの昇格必須条件）
実際に複数のプロジェクトや異なるチームメンバーとの組み合わせでリードエンジニアとして業務を独力で行った実績がある
顧客企業のエンジニアチームと共同開発を行う内製化支援業務においても、顧客からリードエンジニアとして技術的に評価されるレベル
チーフ・リードエンジニア []
700〜800万
難易度が高いプロジェクトにおけるプロジェクトリードとしての成果や、複数チームを横断したチームマネジメント、リードエンジニアの育成実績が求められる
マルチ・リードエンジニア []
800万〜1000万
チーフ・リードエンジニアが、マルチハット、マルチスタックなど幅広く役割範囲を広げていく場合にマルチ・リードエンジニアと位置付ける
マルチスタックの例
iOS、Androidの両方の技術の専門性を持った上で、iOS、 Android両方のプロダクトの設計理解、コード理解があるため、モバイルアプリに関する仕様調整を手戻りなく、実装容易性も考慮した上で、統合的にリードできる場合となります
マルチハットの例
アーキテクトあるいはプロジェクトマネージャー（チームビルディング・テクニカルセールス・顧客折衝・リスク管理など）の役割も兼務して担うことで、プロジェクトの高い品質や生産性に貢献できる
社内のグループ全体の委員会活動、あるいはグループを横断した委員会活動をリードできるレベルでのプロセスマネジメントを兼務して担い、組織に貢献できる
リード職位：⑵ テックリード
テックリード []
No access
You don’t have access to the database referenced by this view
Request access
700〜900万
サブ・リードエンジニアとしての職位ガイドラインを満たした上で、高い専門性と設計・実装力があり、複数のプロジェクト・プロダクトに対して技術的な課題解決を行うことができる
行動指針の参考
チーフ・テックリード []
900〜1000万
リード職位：⑶ アーキテクト
サブ・アーキテクト
650〜720万
リードエンジニアの職位とアーキテクトの職位ガイドラインの一部を満たした上でアーキテクトの補佐を行うことができる
アーキテクト []
700〜800万
リードエンジニアの職位ガイドラインを満たした上でシステム全体の設計やコアな部分の実装も行うことができる
リードアーキテクト []
800〜1000万
規模が大きかったり、複雑性が高いサービスにおいてシステム全体の設計だけでなく、クリティカルな部分の実装も行うことができる
リード職位：⑷ マイスターエンジニア
プロジェクトリードやテックリードというチームにおける役割を担わなくても、標準的なエンジニアの２倍以上の生産性が高いエンジニアはマイスター認定され、生産性にあわせて年収想定も高く設定され得る
マイスターエンジニア []
650〜720万
チーフ・マイスターエンジニア []
700万〜1000万
リーダー職位の年収加算・減算要素
マイスターエンジニア兼リードエンジニア
マイスターエンジニアがリードエンジニアの役割も担う場合
但し、マイスターエンジニアとして重要なチェック項目である上位１５%の生産性を誇る部分は必須項目とすること
逆に生産性が低いリードエンジニアについては減算要素になり得る
テックリード兼リードエンジニア
緊急的な状況ではリードエンジニアを自身で行いながらも、リードエンジニアの育成対象がいる場合は、リードエンジニアの支援的、教育的な役割にシフトして、技術的な支援に専念するなど、柔軟にリードエンジニアからテックリードの役割を変化させることができる
ただし、単に兼務しているだけではなく相乗効果が発揮できることも必要
マルチスタックエンジニア
ただし、マルチスタックが成果に貢献しており役割を継続的に実施している、将来も実施される想定が必要。昇給した後、役割がなくなった場合には一定猶予期間経過後、減給する可能性もある
サーバーサイド、フロントエンドなど連携性が高い２つ以上の技術領域において専門的な知識、経験を保有するチーフ・プロフェッショナル以上のエンジニアを指す
特に技術領域として連携性が高く、例え疎結合に設計されていたとしても、責務範囲を切り分ける際には、実装容易性などを考慮した詳細設計が必要であるため、複数分野について精通している事が将来的な保守性やコードの複雑化の回避に影響する
リードエンジニアのようにチームをリードする役割でなくても、詳細設計、高い品質をリードしていくという役割としてフルスタックエンジニアの役割が期待される場合がある
サーバーサイド、フロントエンド、インフラの３領域に渡って、チーフ・プロフェッショナルであるマルチスタック・エンジニアをフルスタック・エンジニアと呼ぶ。Netflixのような大規模なマイクロサービスアーキテクチャを採用する中で、フィーチャーチームが確立されていれば有用な役割ではあるが、ゆめみではフルスタックが求められる場面は多くはなく、アーキテクトとしての役割として複数技術理解が必要となる場面の方が多い。一方で、アーキテクトであっても全ての技術領域を教えられるレベルになるには難易度が高く、サーバーサイド寄り、フロントエンド寄り、モバイルアプリ寄りに分かれる。
モバイルアプリエンジニアについては、iOSエンジニア、Androidエンジニア、Flutterエンジニアの3つの技術領域において2つ以上の理解を必要とする。
フロントエンドとUIデザインを２つの領域での専門性がある場合は、UXエンジニアと呼ぶ
コーポレートエンジニアリングにおいては高いレベルになると、フルスタックかつフルサイクルが求められる
マルチハット・エンジニア
ただし、マルチハットが成果に貢献しており、役割を継続的に実施している、将来も実施される想定が必要。昇給した後、役割がなくなった場合には一定猶予期間経過後、減給する可能性もある
プロダクトオーナーあるいはスクラムマスターというスクラム における役割を兼務（帽子の被りわけ）ができるエンジニア
チームビルディング初期ではなく、スクラムチームが安定してきた段階では、エンジニアがスクラムマスターを兼務したりすることも実施できるようになる
あるいは、プロダクトに一定期間関わることによって業務知識を深く理解することになり、プロダクトオーナーの役割の一部を担うこともできる（例：エピックプロダクトオーナー など）
兼務することによってチームとして、スクラムマスターが一人に依存してしまう問題を回避したり、プロダクトオーナー の負担を軽減することにつながる
フルサイクル・エンジニア
ただし、フルサイクルが成果に結びついており、役割を継続的に実施している、将来も実施される想定が必要。昇給した後、役割がなくなった場合には一定猶予期間経過後、減給する可能性もある
継続的なディリバリーフェーズのプロジェクトを担当する
リード・エンジニアとしての能力に加えて、ヒアリング、要件定義、DevOps、窓口対応も行う事ができ、プロジェクトの要件定義フェーズからリリースまでの全ての工程において、複数の役割を一連して行うことができ、通常では発揮できないプロジェクトのクオリティ、アジリティの両立と、一人何役もの高い生産性の発揮をすることができている
グロースハック、コーポレートエンジニアリング、プロトタイピングなどで活躍が期待される
シニア職位
900〜1300万
シニアリードエンジニア・シニアテックリード・シニアマイスターエンジニア・シニアアーキテクト[]
その他：キャリアのロードマップ
マルチスタック生成AIエンジニア
生成AIエンジニアとプロダクトエンジニアを兼務するマルチスタックの場合は、生成AIの専門性によって加算要素を加える
５０万の目安は新卒におけるサーバーサイドエンジニアと生成AIエンジニア平均年収想定の差から設定しています
８０万については生成AIエンジニアとしての専門性があった上で、マルチスタックとしての付加価値が出せている前提となります
８０万を超える場合については、高い生成AIの専門性、マルチスタックとしての極めて高い付加価値が出せている前提となります
一方で、マルチスタックとして価値が出せない場合には加算要素はないものの、少なくとも生成AIエンジニア単体としての市場相場を下まわらないようにする必要があります
アソシエイトからリード職位までのロードマップ例
STEP1
昇進条件を満たして アソシエイト 年収530万 → プロフェッショナル 年収530万
STEP2
プロフェッショナル 年収530万→ プロジェクト貢献評価でレンジ内（520〜570万）で給与アップ 年収550万
STEP3
プロフェッショナル 年収550万 → 能力・経験を積んで チーフプロフェッショナルにランクアップ年収580万
STEP4
チーフプロフェッショナル 年収580万 → プロジェクト貢献評価でレンジ内で給与アップ 年収600万
STEP5
昇進条件を満たして チーフプロフェッショナル年収600万 → サブリードエンジニア 昇進 年収600万
サブリードエンジニアの職位に早いタイミングで昇進することで、社内に宣言した上で、サブリード業務を実施しやすくする場合は、サブリードエンジニアの給与レンジの下限でも良いので早めに職位を上げるパターン
STEP6
サブリードエンジニア 年収600万 → プロジェクト貢献評価でレンジ内で給与アップ 年収670万
STEP7
サブリードエンジニア 年収670万 → リードエンジニア 年収710万 にランクアップ
実質リードエンジニアの役割を担っているが、敢えてサブリードエンジニアの職位のまま経験を積んだ上で、十分にリードエンジニアとしてプロジェクト貢献できるタイミングを待った上で、リードエンジニアにランクアップ
STEP5のように早めにサブリードを宣言するパターンもあれば、STEP7のように、職位はサブリードのままで、プロジェクト内での役割としては実態としてリードエンジニアを敢えてやるなど、自分にあった昇進のやり方を行うことができるが、いずれにしても早いタイミングでサブリードを宣言することが推奨されている
フロントエンドエンジニアのキャリア６系統
モダンなフロントエンド技術の成熟化が進む中で、複線でのキャリア戦略が必要な時代になりつつあります
プロジェクトリード
プロダクトリード
マルチスタック（サーバーサイド）
デザインエンジニア
テックリード
マイスターエンジニア
テクニカルリードロールの６系統
テクニカルリードロールのイニシアティブ６系統 にあるようにテクニカルリードロールを担うテックリード職のキャリアについては、特定のイニシアティブに傾倒することも可能です
