IT 業界で追求できる可能性のあるキャリア トラックに関する優れた記事は多数ありますが、キャリア ラダーを上るための実際のガイドとして使用できる記事はあまり見かけません。 現在、私はエンジニアの昇進に関する非常に明確な要件と、それらの要件を満たしていることの十分な証拠として使用できるものを定めている会社で働いています。この 2 つの要因の組み合わせから、このトピックに関する追加情報が、そのような要件を定めていない会社に雇用されている他のエンジニアが次のレベルに到達するための戦略を立てるのに役立つかもしれないという考えが浮かびました。 成熟度が多少なりとも高い IT 企業では、ソフトウェア エンジニアの一般的なキャリア トラックは直線的で、ほぼ同じです。 アソシエイト ソフトウェア エンジニアはオプションであり、一般的な IT 部門構造に提示される場合と提示されない場合があります。その理由は非常に単純です。アソシエイト ソフトウェア エンジニアは多くのサポートを必要とするため、最初の 12 か月間は純益がマイナスであり、すべての企業がそのようなポジションを組織構造に組み込むためのリソースと時間を持っているわけではないからです。 今後のキャリアパスは、あなたの傾向、あなたが何を楽しんでいるか、そして仕事のやり方を変える準備ができているかどうかによって決まります。 コーディングにほとんどの時間を割り当てたいのであれば、シニア ソフトウェア エンジニアのままでいることに何の問題もありません。ただし、他の人に力を与え、リードする必要があると感じる場合は、それぞれの役割に対するすべての期待、自分の強み、自分の原動力などを検討し、自分に最も適した道を選ぶのが適切なタイミングです。 上記のトラックは見た目はシンプルですが、正しい端に近づく方法が明確ではありません。次の洞察は、次のような企業に当てはまります。 各雇用主に直属の上司がいる階層構造 従業員の育成に対する真の関心 上記のことはなぜ重要なのでしょうか? 。 答えは非常に簡単です。初日から、あなたには直属の上司という味方がいるからです 各直属上司の効率は、その直属上司に報告する各人の成果に基づいています。つまり、成長が速いほど、成果が大きいほど、直属上司の効率は高くなります。これらすべてを考慮すると、遅かれ早かれ、あなたが入社した後、直属上司はあなたに「一定期間後、あなたはどうなっていると思いますか？」と質問するでしょう。もし、そのような質問がされず、1対1の面談が定期的に行われている場合は、議題にこの質問を議題として追加してください。 自分の意図を表明し、目標を設定することは、道の第一歩にすぎません。次のステップは、より上位の役職に必要な要件のリストを集め、自分の資格の証拠として役立つ実績のリストをまとめることです。このリストは、A 地点から B 地点に到達するために従うべきガイドとして使用できます。昇進プロセスの透明性がある企業では、これはすでに実施されているはずです。 そうでない場合は、あなたと上司が作成することができます。このプロセスは双方にとって有益であることを忘れないでください。一定の成果を達成したら昇進で賞賛され、直属の上司はチームの成果を上げることができるという合意が得られるので、双方にとってメリットがあります。 企業によって特定の職種に対する要件は異なる場合があり、以下に挙げる要件が普遍的ですべての人に適していると主張するつもりはありません。主な目的は、あなたのニーズに合わせてさらに調整できるものが必要な場合、どのようなものになるかのアイデアを提供することです。 証拠のガイドラインは、目的の目的地に導くロードマップとして使用できます。共通トラックの次のステップは次のようになります。 チームのロードマップをチェックして、証拠の目的に合う可能性のある適切なプロジェクトまたは変更要求を探します。 直属の上司にあなたの意図を伝えてください。そうすれば、上司は適切なプロジェクトの割り当てを支援し、プロジェクトの優先度、ビジネス価値、いつ開発に取り掛かれるかに関する情報を提供できます。 コード、可観測性、拡張性、セキュリティの観点から改善の余地がある領域を特定し、所有権チケットとして提出します。 会社の現在の採用プロセスを理解し、採用セッション中にシャドーイングを依頼してください。役割の交代を依頼して、より上級の人物がシャドーイングしてフィードバックを求めてください。 以下は、証拠の観点からの要件/ガイドラインからカバーされる役割の短いリストです。 共通トラック ジュニアソフトウェアエンジニアの要件 ソフトウェアエンジニアの要件 シニアソフトウェアエンジニアの要件 工学コース リードエンジニアの要件 シニアエンジニアリングリーダーの要件 マネジメントコース エンジニアリングマネージャー エンジニアリングディレクター ジュニアソフトウェアエンジニアの要件 エリア 要件 証拠のガイドライン 配達 タスクを配信する · 明確な要件が必要（ビジネスとシステム） · 限定された範囲の技術ソリューションを設計/実装する · 限られた指導が必要 1. 完了したタスクのリスト o タスクは言及できるほど複雑である必要があります o 期限は守られる o 重大な品質問題なし o タスクは手助けなしで完了した 2. すべての要件が満たされていることを確認するラインマネージャーからの入力。 品質 ベストプラクティスを適用する · ベストプラクティスを学び、常に適用する · さまざまな開発ツールに精通している · 複雑な問題やバグを調査して修正する すべての要件が満たされていることを確認する直属の上司と同僚からのフィードバック。 ソフトウェアエンジニアの要件 エリア 要件 証拠のガイドライン 配達 変更要求（機能）を配信する · ビジネス要件を入力として取り込む · 解決策（何をいつ行う必要があるか）と実装（どのように行うべきか）について十分な詳細レベルで作業をタスクに分割します。 · タスク/ユーザーストーリーレベルで正確な見積もりを提供します · 他のエンジニアと連携してより早く成果を出す 以下の要件に準拠して配信された変更要求のリスト: 1. 変更要求は完全に配信され、期限が守られました。 2. 検出部分は従業員によって完了しました (チケット、見積もり)。 3. 変更要求は技術的な観点から見て十分に複雑です (1 人のエンジニアが実装するには 2 人週以上かかります)。 4. 変更要求はビジネスに意味のある影響をもたらします。 5. 変更要求はビジネス部門によって承認され、本番環境で実行されます。 6. 従業員は十分なレベルの自律性と品質を実証しています (技術リーダーとエンジニアリング マネージャーからのフィードバックに基づく)。 システム設計 デザインサービス · 非機能的な側面（拡張性、セキュリティ、可観測性など）をすべて考慮しながら、小規模なサービスを設計および実装します。 · エンジニアリングの実践と方法論を完全に採用して高品質のコードを作成します · ベストプラクティスを実施するためにコードレビューに参加する · 発生したバグや問題の根本原因を修正します 以下の要件に準拠して設計された少なくとも 2 つのサービス: 1. 新しいサービスでも、既存のサービスの完全な再設計でもかまいません。 2. スタンドアロン サービス、ライブラリ、または他のサービスによって使用されるコンポーネントにすることができます。 3. 設計の観点から、サービスは些細なものであってはなりません。 4. エンジニアは正式な設計プロセスに従うべきでした。 · ビジネス要件とシステム要件を取得する · 境界付けられたコンテキストを特定する · 非機能要件を特定する · コンテキストをサービスに分解する · ソリューションに関するフィードバックを得る · 実装する 5. サービスが実装され、本番環境で実行されます。 シニアソフトウェアエンジニア エリア 要件 証拠のガイドライン 配達 プロジェクトフェーズ（エピック）を提供する · 要件と高レベルのシステム設計を入力として取り込む · サービスまたはコンポーネントのシステム設計を作成し、使用する技術とエンジニアリング手法を決定します · 解決策（何をいつ行う必要があるか）と実装（どのように行うべきか）について十分な詳細レベルをもって、作業をタスクまたはユーザーストーリーに分割します。 · タスク/ユーザーストーリーレベルで正確な見積もりを提供します · 小規模チームを率いてスコープを達成 · チームの障害を取り除き、問題を解決し、障害を取り除く 次の要件に準拠して提供されるプロジェクト フェーズ/エピックのリスト: 1. エピック/プロジェクトフェーズは完全に完了し、期限も守られました。 2. 検出部分は従業員によって完了しました (チケット、見積もり)。 3. エピック/プロジェクト フェーズは、技術的な観点から見て十分に複雑です (少なくとも 2 人のエンジニアが 2 週間以上必要)。 4. エピック/プロジェクト フェーズはビジネスに意味のある影響をもたらします。 5. 機能はビジネスによって承認され、運用環境で実行されます。 6. 従業員は十分なレベルの自律性と品質を実証しています (技術リーダーとエンジニアリング マネージャーからのフィードバックに基づく)。 7. エンジニアは技術リーダーとして実装に参加しました。 システム設計 サブシステムを設計する · ソフトウェアエンジニアと同じですが、より複雑なサービスやサブシステムに焦点を当てています。 · クラウドおよび分散システムの設計と実装に精通している 以下の要件に準拠して設計された少なくとも 3 つのサービス: 1. 新しいサービスでも、既存のサービスの完全な再設計でもかまいません。 2. スタンドアロン サービス、ライブラリ、または他のサービスによって使用されるコンポーネントにすることができます。 3. 設計の観点から、サービスは些細なものであってはなりません。 4. エンジニアは正式な設計プロセスに従うべきでした。 a. ビジネス要件とシステム要件を取得する b. 境界付けられたコンテキストを特定する c. 非機能要件を特定する d. コンテキストをサービスに分解する e. 解決策に関するフィードバックを得る f. 実装する 5. サービスが実装され、本番環境で実行されます。 変化を推進する 変更を提案する · 現状と前提に疑問を投げかける · プラットフォーム、プロセス、作業環境、技術チーム全体を改善する方法を見つける 少なくとも 3 つの重要な変更が提案されました。これは次のいずれかです。 1. 機能性: 優先順位が付けられ、実装された変更要求を提案しました (変更要求は、表面的な変更ではなく、変更として考慮されるほど実質的なものである必要があります)。 2. 人材: 採用され、試用期間を通過したエンジニア (ジュニア ソフトウェア エンジニア以上、チームへの異動として考慮) にインタビューしました。 3. 所有権: 所有権プロジェクトを提案しました (所有権ロードマップに含まれ、CTO によって承認されました)。 リードエンジニアの要件 エリア 要件 証拠のガイドライン 配達 プロジェクトの技術リーダー（プロジェクト提案） · ビジネス要件を入力として取り込む · ビジネス上の問題に対する最も効果的なソリューションを見つける（代替案を調査し、ノーコード/ローコードアプローチを使用してソリューションを検証する） · 新しいサービスまたはサブシステムのシステム設計を作成し、使用する技術とエンジニアリング手法を決定します。 · 解決策（何をいつ行う必要があるか）と実装（どのように行うべきか）について十分な詳細レベルで作業をエピックに分割します。 · プロジェクトレベルで正確な見積もりを提供し、日付を約束します · プロジェクト全体の技術リーダーとして活動する · チームの障害を取り除き、問題を解決し、障害を取り除く · テクノロジー、実装、運用上のリスクを管理する 以下の要件に準拠して実施されたプロジェクトのリスト: 1. 問題の解決策は従業員によって提案され、効果的であると見なされます。つまり、複数の代替案が評価され、ローコード/ノーコードの検証に基づいて最適な代替案が選択されました。 2. 検出部分は従業員によって完了しました (チケット、見積もり)。 3. ソリューションは従業員によって設計されました。 4. プロジェクトは、プロジェクト提案を通じて開始される「機能」プロジェクトである必要があります。 5. エンジニアは技術リーダーとして実装に参加しました (詳細については要件の列を参照してください)。 変化を推進する 技術的な変更を推進する（チーム） · システム品質の向上と技術的負債の削減に向けた取り組みを提案し、実施する · 開発者のエクスペリエンスと生産性を向上させるための変更を提案し、実装する · クリーンなコードとクリーンなアーキテクチャを提唱し、実施する 次の要件に準拠する、導入された主要な変更のリスト (通常は少なくとも 4 つ)。 1. 変更により、システム品質 (例: プラットフォームの改善)、開発者エクスペリエンス、または開発者の生産性が大幅に向上します。変更はチーム全体に影響します。 2. エンジニアは変更を提案する人である必要はありません。エンジニアは変更の主な推進力である必要があります (設計、技術リーダーとしての活動、実装への参加など)。変更はエンジニアによって、またはチームの努力によって実行できます。 3. 変更はチーム/プラットフォームによって完全に実装され、使用される必要があります (変更は「固定」され、維持するのに十分な価値を提供する必要があります)。 4. 変更は言及できるほど重大なものである必要があります。 人々 メンター · 経験の浅いエンジニアを指導しサポートする · 技術面接を効果的に実施する · 採用時に優秀なエンジニアを引きつける「磁石」として機能します（優秀な人材をめぐって他社と競争する際の決定的な要因となります） 考えられる証拠: 1. 面接を受け、採用され、試用期間に合格したエンジニア。 2. スキルアップしたエンジニアからのフィードバック。 3. 技術チーム全体 (例: Tech Sync、Engineering Dojo) 向けにトレーニング セッションが企画/実施されます。 4. ワーキング グループを主導する場合、ワーキング グループの範囲内で提案/実装された変更のリストを証拠として使用できます。 シニアエンジニアリングリーダー エリア 要件 証拠のガイドライン 配達 複雑なプロジェクトの技術リーダー（プロジェクト提案） リードエンジニアと同じですが、技術的、組織的、またはビジネス的な観点から複雑な問題に焦点を当てます。 · プロジェクトでは複数のチーム間の調整が必要です · プロジェクトにはサードパーティの技術プロバイダーまたは利害関係者（パートナーシップなど）が関与している · 製品が発見モードにある間に新しい製品を構築する · 期限が決まっており、多くの不明点がある優先度の高い緊急プロジェクト 以下の要件に準拠して実施されたプロジェクトのリスト: 1. プロジェクトは複雑であると考えられます (左の例を参照)。 2. プロジェクトは完全に完了し（すべての成果物 + DoD）、期限も守られました。 3. 問題に対する解決策が従業員によって提案され、効果的であると見なされます (つまり、複数の代替案が評価され、ローコード/ノーコード検証に基づいて最適な代替案が選択されました)。 4. 検出部分は従業員によって完了しました (システム要件、チケット、見積もり)。 5. ソリューションは従業員によって設計されました。このプロジェクトは、システム設計の観点から見ると非常に複雑です。 6. エンジニアが技術リーダーとして実装に参加しました。 変化を推進する 技術的な変化を推進する（技術） · E5と同じですが、技術レベルは · 少なくとも 1 つの非機能的側面 (セキュリティ、可観測性など) のシステム所有者。 導入された主要な変更のリスト (通常は少なくとも 4 つ)。次の要件に準拠します。 1. 変更により、システム品質 (例: プラットフォームの改善)、開発者エクスペリエンス、開発者生産性が大幅に向上します。変更は複数のチームに影響します (例: テクノロジの採用)。 2. エンジニアは変更を提案する人である必要はありません。エンジニアは変更の主な推進力である必要があります (設計、技術リーダーとしての活動、実装への参加など)。変更自体は、エンジニアによって、またはチームの努力によって実行できます。 3. 変更は完全に実装され、複数のチームで使用される必要があります (変更は「固定」され、維持するのに十分な価値を提供する必要があります)。 4. 変更は言及するほど重要なものである必要があります。所有権プロジェクトとして「今後のプロジェクト」ページで追跡する必要があります (このコンテキストでの所有権とは、プラットフォーム関連の変更だけでなく、プラットフォーム、ツール、プロセスなどの変更を意味します)。 5. 少なくとも 2 つの変更は、個人が所有する非機能的な側面に関連している必要があります。 人々 認められた専門家 · 企業レベルで特定の専門分野の専門家として認められ、専門分野における技術連絡窓口として機能します。 · 専門分野内のトレンドや技術を監視し、最新情報や調査結果を伝える · 他のエンジニアと専門知識を積極的かつ定期的に共有する（ワークショップ、技術講演、トレーニング） · 複雑な問題の解決策を見つけるためのコラボレーションを促進する（ワーキンググループなど） · 技術面接を効果的に実施する · 経験の浅いエンジニアを指導・サポートし、専門的な開発の観点からキャリアを指導します。 · 採用時に優秀なエンジニアを引きつける「磁石」として機能します（優秀な人材をめぐって他社と競争する際の決定的な要因となります） 考えられる証拠: 1. 採用され、試用期間を通過したエンジニアに面接を行いました。 2. スキルアップしたエンジニアからのフィードバック。 3. 技術チーム全体 (例: Tech Sync、Engineering Dojo) 向けにトレーニング セッションが企画/実施されます。 4. ワーキング グループを主導する場合、ワーキング グループの範囲内で提案/実装された変更のリストを証拠として使用できます。 エンジニアリングマネージャー エリア 要件 証拠のガイドライン 配達 チームのロードマップを配信 · 3～6人のエンジニアの分隊を率いる · 複数の同時進行プロジェクトにおけるプロジェクトマネージャーとして活動 · ビジネス要件のみを入力として結果を提供できる（システム要件を作成して承認できる） · ビジネス価値に基づくビジネスへの影響に焦点を当てる · ビジネス関係者にコミットメント、ステータス、リスクを伝える · 部隊メンバー全員が必要な情報をすべて持っていることを確認する · イニシアチブ/所有権の範囲内で第三者に伝達する · 機能の提供とシステム品質の適切なバランスを見つける · シニアソフトウェアエンジニアに必要なすべての要件 チームによって提供される新しいプロジェクトは、次の要件に準拠しています。 1. プロジェクト提案を通じて開始されたプロジェクト。 2. プロジェクトは影響指標を達成し、公約を達成しました。 3. 前回のプロモーション サイクルで報告されたプロジェクトはリストに含めることができません。 生産性 マネジメントの変更を推進する（チーム） · チームのパフォーマンスを測定し、継続的に改善する · 生産性を重視してチーム内のベストプラクティスを特定し、確立する · 高い配信品質を維持 · 進捗、リスク、結果の透明性を確保する 1. チーム生産性（パフォーマンス）メトリック値。 2. 以下の要件に準拠する主要な変更（少なくとも 4 つ）が導入されました。 a. 所有するチームまたは部族に関連する問題を解決する場合、その問題はトップ 5 の問題に含まれ、ライン マネージャーと合意されている必要があります。 b. 変更はチームによって完全に実装され、使用される必要があります (変更は「定着」し、維持するのに十分な価値を提供する必要があります)。 c. 変更により、生産性、エンゲージメント、または配信品質が大幅に向上するはずです。 d. 変更を提案するのはマネージャである必要はありません。EM が変更の主な推進力となる必要があります。変更はエンジニアまたはチームの努力によって実現できます。 人々 ラインマネージャー（直属の部下が 3 人以上） · 3～6人の直属部下を管理する · エンジニアの指導とサポート · キャリアアップをサポートし、指導します · 意見の相違を調整し、対立の管理と解決を支援します · ポジティブなチーム文化とコラボレーションを奨励する 1. 分隊のエンゲージメントメトリック値。 2. 採用され、試用期間に合格したエンジニアのリスト（採用していない場合は省略できます。EM は採用マネージャーである必要があります）。 エンジニアリングディレクター エリア 要件 証拠のガイドライン 配達 複数の部隊にロードマップを提供する · 2～3チームにまたがる配送を確実に行う · いずれかのチームでエンジニアリングマネージャーの役割を果たす · 第三者とのパートナーシップを所有している · エンジニアリングマネージャーからのすべての要件 以下の要件に準拠するチームによって提供される新しいプロジェクト: 1. プロジェクト提案を通じて開始されたプロジェクト（BAU アクティビティではない）。 2. プロジェクトは影響指標を達成し、公約も達成されました。 3. プロジェクトの結果は、Tech Feature セッションとして発表されました。 4. 前回のプロモーション サイクルで報告されたプロジェクトはリストに含めることができません。 5. 少なくとも 2 つのプロジェクトが会社レベルの主要プロジェクトとして認識されている必要があります (例: 新製品など、CTO と確認可能)。 変化を推進する 管理の変更を推進する（複数のチーム/技術） · エンジニアリングからのすべての要件が複数のチームにまたがる · 少なくとも 1 つのプロセスのシステム所有者 (例: サポートなど) 1. 複数の分隊にわたる分隊の生産性（パフォーマンス）メトリック値。 2. 以下の要件に準拠する主要な変更（少なくとも 6 件）が導入されました。 a. 分隊または部族に関連する問題を解決する場合、その問題は上位 5 つの問題に含まれ、ライン マネージャーと合意する必要があります。 b. 変更は完全に実装され、チームによって使用される必要があります (変更は「定着」し、維持するのに十分な価値を提供する必要があります)。 c. 変更により、生産性、エンゲージメント、または配信品質が大幅に向上するはずです。 d. 変更を提案するのは必ずしもマネージャーである必要はありません。エンジニアリング ディレクターが変更の推進力となる必要があります。変更はエンジニア 1 人またはチームの協力で実行できます。 e. 少なくとも 2 つの変更は、ディレクターが所有するプロセスに関連している必要があります。 人々 ラインマネージャー（間接部下を含む 10 名以上の部下） · エンジニアリングマネージャーに必要なすべての要件 · エンジニアの指導とサポート · キャリアアップをサポートし、指導します · 解約を管理し、「残念な解約」を減らす 1. 複数の分隊にわたる分隊のエンゲージメント メトリック値。 2. 採用され、試用期間に合格したエンジニアのリスト（採用していない場合は省略できます）。 3. 昇進したエンジニアのリスト（昇進の業務上の必要性がない場合はスキップできます）。
