エンジニアラダー

← 職種一覧

ソフトウェアエンジニア

Software Engineer

Backend / Frontend / Full-Stack を横断する基盤職種。他職種のレベル換算の基準になる。

別名・近接タイトル: Backend Engineer / Frontend Engineer / Full-Stack Engineer / Product Engineer

セルフチェックをする →

レベル × 評価軸マトリクス

← 横にスクロールして各レベルを比較できます →
評価軸L1Associate / ジュニアL2Engineer / ミドルL3SeniorL4StaffL5Principal
技術力

設計・仕様を正しく理解し、AIツール等の補助も活かしつつ、テストコードとエラーハンドリングを含めて確実に実装・検証できる。

実運用ルーブリック
推奨行動 (Do)
  • 既存のコーディング規約や設計パターンに従い、可読性と保守性の高いコードを書く
  • 正常系だけでなく境界値や異常系のエラーハンドリングを考慮し、ユニットテストを記述する
  • AIコーディング支援ツールの出力を盲信せず、ロジックと動作を自分で検証・理解してからPRを出す
注意・アンチパターン (Don't)
  • テストを書かずに「動いたから大丈夫」とPRを作成する
  • AIが生成したコードの意味やエッジケースを理解しないままマージしようとする
  • エラーを空のcatchブロックやログなしで握りつぶす
成果物・エビデンス例
  • ユニットテストが含まれ、CIテストを通過しているプルリクエスト
  • テストカバレッジを維持・向上させているコミット履歴
  • バグ修正時に作成した再現テストコード

機能単位の設計から実装、自動テスト、オブザーバビリティ（ログ・メトリクス）までを考慮して本番品質で構築できる。

実運用ルーブリック
推奨行動 (Do)
  • 単一障害点やデータ整合性、クエリ性能を考慮したクリーンなAPI・データモデル設計を行う
  • 本番運用を見据え、構造化ログ、メトリクス、エラートラッキングを適切に組み込む
  • モジュール間の結合度を下げ、変更に強くリファクタリングしやすいコードベースを保つ
注意・アンチパターン (Don't)
  • デバッグ用ログだけを残し、本番でのアラート監視や障害調査に必要なログ・メトリクスを考慮しない
  • 将来の拡張性を過剰に意識して不要な抽象化やレイヤー（YAGNI違反）を増やす
成果物・エビデンス例
  • 適切なモジュール分割とテストが施された機能PR
  • 監視ダッシュボードや本番アラート設定の作成実績
  • 既存コードのリファクタリングにより保守性を向上させた実績

複数コンポーネントにまたがる設計（Design Doc等）を主導し、非機能要件（性能・可用性・セキュリティ）のトレードオフを言語化できる。

実運用ルーブリック
推奨行動 (Do)
  • Design Doc / RFCを起案し、複数代替案の比較、セキュリティ、スケーラビリティ、コストを明文化する
  • システムの構造的ボトルネックを特定し、キャッシュ戦略や非同期化、DB最適化で根本解決する
  • チーム全体のコードベースの一貫性と品質水準を保つための技術的基準を示す
注意・アンチパターン (Don't)
  • 事前の設計書や合意形成なしに大規模なコード変更を始め、手遅れになってから設計欠陥が発覚する
  • 特定の技術やパラダイムへの個人的な好みに固執し、要件やチームのスキルセットに合わない技術を無理に採用する
成果物・エビデンス例
  • チーム内外でレビュー・承認された Design Doc / RFC / ADR ドキュメント
  • システムの性能向上（レイテンシ半減、リソース消費抑制など）を実証したメトリクス
  • セキュリティや耐障害性を抜本的に高めたアーキテクチャ改善の実績

複数チームにまたがる複雑なアーキテクチャの一貫性を保ち、再利用可能なパターンやPaved Road（共通基盤・開発標準）を整備する。

実運用ルーブリック
推奨行動 (Do)
  • 各チームが車輪の再発明を避けるための共通ライブラリ、API設計標準、マイクロサービス設計指針（Paved Road）を策定する
  • 組織全体の耐障害性（DR計画、サーキットブレーカー、カオスエンジニアリング）の設計指針を主導する
  • システムの境界（ドメイン境界）を適切に再定義し、チーム間の認知負荷と結合度を下げるアーキテクチャ刷新を牽引する
注意・アンチパターン (Don't)
  • 現場の実態を無視した「象牙の塔」的な規約や標準を押し付け、各チームの開発速度を落とす
  • 全体の整合性を考えず、各チームがバラバラに異なる技術やインフラを無秩序に導入するのを放置する
成果物・エビデンス例
  • 全社エンジニアリングガイドラインやRFCプロセスの策定・運用実績
  • 複数チームで利用される共通基盤・フレームワークの設計と導入実績
  • 大規模障害耐性（DR）の設計書および全社アーキテクチャ刷新計画

事業の3〜5年後を見据えた技術ビジョンを描き、不可逆な大規模アーキテクチャ刷新や技術的賭けの成否に全社責任を持つ。

実運用ルーブリック
推奨行動 (Do)
  • 技術革新（生成AI、分散基盤、新アーキテクチャ）を見極め、自社の競争優位を決定づける技術戦略ロードマップを策定する
  • 全社の存亡に関わる構造的リスク（システム限界、大規模データ消失、セキュリティ脆弱性）を未然に防ぐ抜本設計を牽引する
  • 業界標準の策定や重要OSSへのコントリビューションを通じて、自社の技術的リーダーシップを業界に確立する
注意・アンチパターン (Don't)
  • 一過性のバズワードに飛びつき、事業の実態や収益性に合わない巨額の技術投資を会社に強いる
  • 技術的な美しさばかりを追求し、事業の収益性や市場投入スピードを無視した設計を強要する
成果物・エビデンス例
  • 3〜5年スパンの全社技術戦略ドキュメントおよび技術ビジョンステートメント
  • 会社の将来の成長を支えた大規模技術基盤刷新の成功実績
  • 著名OSSへのコミットや主要標準化団体・コミュニティでの活動実績
スコープと影響

チームのタスク（小さな機能追加やバグ修正）を、レビュアーのフィードバックを受けながら仕様通りに完遂できる。

実運用ルーブリック
推奨行動 (Do)
  • チケットやタスクの受け入れ基準（Definition of Done）を事前に確認し、漏れなく完了させる
  • 小さなPRに分割してレビュー負荷を下げ、手戻りを最小化する
注意・アンチパターン (Don't)
  • 仕様が曖昧なまま勝手な思い込みで実装を進め、後から大幅な手戻りを発生させる
  • 1つのPRに無関係な複数の変更を詰め込み、レビューを難航させる
成果物・エビデンス例
  • 受け入れ基準を満たしてリリースされた機能追加・不具合修正チケット
  • レビュアーからの「PRの粒度が適切でレビューしやすい」というフィードバック

1つの独立した機能や改善を、要件定義から本番リリース・初期稼働の確認まで自力でリード・完遂できる。

実運用ルーブリック
推奨行動 (Do)
  • スプリントやマイルストーンのスコープを責任を持って守り切る
  • リリース計画（フィーチャーフラグ、カナリアリリース、DBマイグレーション）を自ら策定・実行する
  • リリース後にメトリクスやユーザーの挙動を確認し、初期稼働の安定化まで見届ける
注意・アンチパターン (Don't)
  • 「PRがマージされたから完了」とし、本番デプロイや初期稼働の確認を他人に丸投げする
  • 予期せぬ不具合が起きた際、影響度の把握やロールバックの判断を先延ばしにする
成果物・エビデンス例
  • 計画通りに無事故でリリースされた中規模機能・改善の実績
  • フィーチャーフラグやカナリアデプロイを用いた段階的リリースの運用実績
  • DBマイグレーションを含むリリース手順書の作成と完遂

チームの四半期目標や重要プロジェクトをリードし、技術的障害や仕様の曖昧さを解消しながら期限内に品質高く完遂させる。

実運用ルーブリック
推奨行動 (Do)
  • 不確実性の高い大規模プロジェクトを明確なマイルストーンとタスクに分解し、チームで推進する
  • 予期せぬブロッカーが発生した際、スコープの再調整や技術的代替案を即座に判断してデリバリーを守る
注意・アンチパターン (Don't)
  • 一人で全ての実装を抱え込んでボトルネックになり、チーム全体の進捗を遅らせる
  • 納期を守るために自動テストやセキュリティを安易に切り捨て、後から深刻な障害を引き起こす
成果物・エビデンス例
  • 重要プロジェクトの期日通りの完遂とビジネスKPI達成への貢献実績
  • プロジェクトの技術ロードマップ、WBS、リスクマネジメント資料
  • ステークホルダーへの定期的かつ透明性の高い進捗・技術的リスク報告

部門・組織規模の重大な技術課題やボトルネック（スケーラビリティ、技術的負債）を定義し、複数チームを巻き込んで解決に導く。

実運用ルーブリック
推奨行動 (Do)
  • 「誰も課題の全貌を掴めていない組織的技術課題」を発見・言語化し、解決の技術ロードマップを描く
  • 複数チームにまたがる大型刷新プロジェクト（モジュラーモノリス化、DB分割等）を技術面で牽引し、完遂させる
注意・アンチパターン (Don't)
  • 自チームのスコープに安住し、組織全体のボトルネックや危機的状況に対して傍観者でいる
  • 影響範囲の大きいアーキテクチャ変更において、他チームへの移行支援や周知を怠る
成果物・エビデンス例
  • 複数チーム横断プロジェクトの技術ロードマップとデリバリー実績
  • 組織レベルの開発効率指標（デプロイ頻度、リードタイム等）の大幅改善実績
  • 全社規模の重要データベースやインフラの無停止マイグレーション完遂実績

会社全体の存続や成長を左右する最も困難な技術課題（壊滅的リスク、全社基盤の限界等）を解決し、事業競争力の基盤を築く。

実運用ルーブリック
推奨行動 (Do)
  • 会社で最も難度が高く、誰も解決できなかった技術的限界（全社コアDBのシャーディング、ゼロダウンタイム全面刷新等）に自らコミットする
  • 新規事業の立ち上げやM&Aに伴うシステム統合を技術面からリードし、事業価値を最大化する
注意・アンチパターン (Don't)
  • 抽象的な戦略や理念を語るだけで、現場の最も困難で泥臭い技術課題から逃避する
  • 短期的な売上数字だけにとらわれ、全社基盤の崩壊リスクを放置する
成果物・エビデンス例
  • 全社規模の重要基盤刷新プロジェクトの完遂実績
  • M&Aや大規模事業統合における技術デューデリジェンスおよび統合成績
  • インフラコストの劇的削減や、システム収容力の大幅向上（10倍スケール対応等）の成果
自律性

担当タスクの進捗と完了基準を把握し、詰まったら事実と試したことを整理して早めに相談・エスカレーションできる。

実運用ルーブリック
推奨行動 (Do)
  • 調査に一定時間（15〜30分程度）かけて解決しない場合、試したことと仮説をメモして相談する（タイムボックスの徹底）
  • タスクの遅延が見込まれる場合、締切前に行動しアラートを上げる
注意・アンチパターン (Don't)
  • 何も相談しないまま数日間同じ問題で立ち止まる（スタックの隠蔽）
  • 「どうすればいいですか？」とだけ聞き、自分が試した事実やエラーログを共有しない
成果物・エビデンス例
  • デイリースタンドアップでの事実ベースの正確な進捗・ブロッカー報告
  • Slackやチケットでの「試したこと」「エラー出力」を整理した質問ログ

担当領域の実装方針や技術的トレードオフを自分で判断し、リリース後の不具合やパフォーマンスにも責任を持つ。

実運用ルーブリック
推奨行動 (Do)
  • 開発速度と長期的な保守性のトレードオフを比較検討し、選択理由を周囲に論理的に説明する
  • 担当機能のエラー率やレスポンスタイムを継続的に監視し、劣化があれば主動的に調査・修正する
注意・アンチパターン (Don't)
  • 自分の書いたコードに起因するアラートや障害対応を、オンコール担当や他メンバーに丸投げする
  • 技術的負債や不具合の火種に気づきながら、チケット化も共有もせず放置する
成果物・エビデンス例
  • 技術選定や実装アプローチのトレードオフを比較検討した設計メモ
  • リリース後のパフォーマンス劣化やエラーを自主的に検知・修正したPR

チーム内の技術的負債やボトルネックを自ら見つけ出して優先順位をつけ、技術選定やアーキテクチャ方針の決定を主導する。

実運用ルーブリック
推奨行動 (Do)
  • チームの開発速度を低下させている負債（CI時間の長期化、Flaky Test、古いFW等）を定量化し、解消を主導する
  • チームの誰も拾っていないが重要な課題（潜在的な脆弱性、運用の非効率）を自ら拾い上げて解決する
注意・アンチパターン (Don't)
  • ビジネス機能の開発に追われることを言い訳に、破綻寸前の技術的負債を見て見ぬふりをする
  • ビジネス価値やチームの開発生産性に寄与しない自己満足的なリファクタリングを強行する
成果物・エビデンス例
  • 技術的負債の棚卸しと削減計画の立案・実行実績
  • CI/CDパイプラインの高速化（例: 20分→5分）やテスト安定化の成果

不確実性が高く正解のない技術的意思決定を主導し、その結果と長期的な保守性に対して組織的な説明責任を果たす。

実運用ルーブリック
推奨行動 (Do)
  • クラウド移行、コア言語の刷新、内製 vs SaaSなどの重大な決断において、メリット・デメリットとリスクを定量化して決定を下す
  • 下した技術的意思決定が意図した成果を出さなかった場合でも、迅速にピボットし全社に学びを共有する
注意・アンチパターン (Don't)
  • 失敗の批判を恐れて決断を先延ばしにし、組織全体を膠着状態に陥れる
  • 過去の自分の決定に固執し、状況が変化しても意固地に方針変更を拒む
成果物・エビデンス例
  • 重要技術選定に関する包括的な評価レポート・トレードオフ分析書
  • 全社アーキテクチャレビュー（Architecture Review Board等）での意思決定記録

組織の誰も責任を持っていない重大かつ曖昧な技術的空白を自ら引き受け、経営レベルのトレードオフ判断を下す。

実運用ルーブリック
推奨行動 (Do)
  • 経営陣すら気づいていない潜在的な全社技術リスク（規制対応、プライバシー、セキュリティ）を察知し、先回りして防御策を主導する
  • 数億円規模のクラウドインフラ費用やライセンス費用の構造改革を主導し、財務的なインパクトを創出する
注意・アンチパターン (Don't)
  • 「それは自分の管轄ではない」と組織の縦割りを理由に、全社的な危機を見て見ぬふりをする
  • 技術的判断の誤りによる結果責任を、経営陣や現場のチームに転嫁する
成果物・エビデンス例
  • 経営会議や取締役会に提出された技術リスク評価書および大型投資判断資料
  • 全社的なコンプライアンス・法規制対応を技術主導でクリアした実績
協働とコミュニケーション

レビューの指摘意図を正しく理解して修正に反映し、作業の状況や疑問点を明確にテキスト化して共有できる。

実運用ルーブリック
推奨行動 (Do)
  • レビュー指摘を学びの機会と捉え、指摘の背景にある設計思想や理由を理解して修正する
  • 非同期コミュニケーション（Slack / GitHubコメント）で、コンテキストと再現手順を分かりやすく記述する
注意・アンチパターン (Don't)
  • レビュー指摘を人格否定のように受け取って防衛的・感情的な態度をとる
  • コメントの意図が分からないのに質問せず、適当に修正して再提出する
成果物・エビデンス例
  • PR上での建設的で前向きなやり取りの履歴
  • チケットやIssueへの分かりやすい作業経緯・調査メモの記録

他者のPRを的確にレビュー（品質・可読性・エッジケース）し、PdMや他職種と仕様のすり合わせを行う。

実運用ルーブリック
推奨行動 (Do)
  • 他メンバーのPRを迅速にレビューし、単なる体裁だけでなく設計の意図やエッジケースの不備を指摘する
  • PdMやデザイナーの要件に対し、技術的難易度やコストを踏まえて建設的な代替案やフェーズ分けを提案する
注意・アンチパターン (Don't)
  • PRレビューを後回しにし、チームメンバーの作業を長期間ブロックする
  • PdMやビジネス側の要望に対して「技術的に不可能」とだけ突っぱね、代替案を考えない
成果物・エビデンス例
  • エッジケースや潜在リスクを未然に防いだ質の高いコードレビューコメント
  • PdMやデザイナーと仕様をすり合わせ、実現可能なスコープに落とし込んだ議事録やチケット

設計レビューで建設的なフィードバックを行い合意形成をリードするとともに、非エンジニアにも技術的制約を明快に説明できる。

実運用ルーブリック
推奨行動 (Do)
  • 設計レビューで「なぜその設計にすべきか」「将来どんなリスクがあるか」を論理的に示し、チームの合意を形成する
  • PdMや事業責任者に対して、技術的負債の解消や非機能要件の重要性をビジネスインパクト（障害損害額、離脱率等）に翻訳して伝える
注意・アンチパターン (Don't)
  • 意見が対立した際に感情的になったり、年次や経験を盾に権威主義的に押し通そうとする
  • 専門用語を多用して非エンジニアを煙に巻き、ビジネス側との対話を拒絶する
成果物・エビデンス例
  • 設計レビューやアーキテクチャ議論におけるファシリテーション実績
  • 非エンジニア向けに技術的トレードオフを分かりやすく解説した提案資料

異なるチームやステークホルダー間の利害・技術的対立を調整し、組織全体の最適解に向けた技術的合意を形成する。

実運用ルーブリック
推奨行動 (Do)
  • プラットフォームチームとプロダクト開発チームなど、異なる部門間の利害対立を構造と仕組みで解消する
  • EM（エンジニアリングマネージャー）やPdMリードと密に連携し、ビジネス戦略と技術ロードマップの整合をとる
注意・アンチパターン (Don't)
  • 対立するチームの一方に過度に偏り、他方の開発者体験や自律性を大きく損なう決定を下す
  • 社内政治や根回しだけに終始し、技術的な妥当性や現場の声を軽視する
成果物・エビデンス例
  • 組織間の技術的摩擦を解消した標準化・連携プロセスの確立実績
  • 全社技術委員会やワーキンググループ（WG）の設立とファシリテーション実績

経営陣（CTO/VPE/事業責任者）の技術的右腕として対話し、ビジネス目標を全社の技術ロードマップに接続する。

実運用ルーブリック
推奨行動 (Do)
  • 経営陣と対等に議論し、抽象的な事業戦略（グローバル展開、新規事業参入）を実行可能な技術ロードマップに翻訳する
  • 開発組織全体の士気を高めるビジョンを語り、優秀なエンジニアを引きつけるシンボルとなる
注意・アンチパターン (Don't)
  • 経営陣と対立した際に技術の側に引きこもり、ビジネス側との建設的な対話を拒絶する
  • 自身の権威をかざして現場のボトムアップなイノベーションを握りつぶす
成果物・エビデンス例
  • 経営陣と共同策定した全社年間技術方針およびOKR
  • 全社エンジニア総会（All Hands）での基調メッセージ発信と組織エンゲージメント向上実績
人を伸ばす

自分の学習と成長に責任を持ち、質問やドキュメント読み込みを通じてコードベースの理解を継続的に深める。

実運用ルーブリック
推奨行動 (Do)
  • チームのREADMEやオンボーディングドキュメントを読み込み、古い記述を見つけたら自ら修正PRを出す
  • 自分が解決したトラブルや学んだTipsをチームのナレッジ共有スペースに還元する
注意・アンチパターン (Don't)
  • 同じ質問を何度も繰り返し、教えてもらった内容をメモ・ドキュメント化しない
  • 自分の担当タスク以外のシステムの仕組みやチームの動向に関心を持たない
成果物・エビデンス例
  • 開発環境構築手順やドキュメントの改善PR
  • 社内WikiやTimesチャンネルでのナレッジ共有・学びのアウトプット

新しいメンバーのオンボーディングを支援し、自分が得た知見やトラブルシュート手順をチームのドキュメントに還元する。

実運用ルーブリック
推奨行動 (Do)
  • 新メンバーのメンター/バディを担当し、開発環境のセットアップから初PRマージまで伴走する
  • 障害対応やトラブルシュートで得た知見をRunbookやポストモーテムとしてドキュメント化する
注意・アンチパターン (Don't)
  • 自分だけが知っている手順や知識を抱え込み、チームの属人化を助長する
  • 新メンバーからの質問に対して不親切な対応をしたり、放置したりする
成果物・エビデンス例
  • オンボーディングバディとしての支援実績と新メンバーの立ち上がり成果
  • 更新・拡充したRunbook（運用手順書）やFAQドキュメント

ジュニア〜ミドルのメンバーを継続的にメンタリングし、AI活用やレビュー文化を通じてチーム全体のエンジニアリング水準を引き上げる。

実運用ルーブリック
推奨行動 (Do)
  • メンバーの自立を促すメンタリング（安易に答えを与えず思考を深める問いかけ）を行い、メンバーの昇格を後押しする
  • ペアプロや勉強会を企画し、モダンなプラクティスやAIコーディングツールの効果的な活用法をチームに普及させる
  • 障害発生時に個人を責めず、仕組みで防ぐ Blameless Post-Mortem 文化を牽引する
注意・アンチパターン (Don't)
  • 忙しさを理由にメンバーからの相談やレビュー依頼を後回しにし続ける
  • 「自分でやった方が早い」とタスクを独占し、メンバーの成長機会を奪う
成果物・エビデンス例
  • メンタリングを担当したメンバーの成長・自立・昇格実績
  • チーム向け技術勉強会やペアプロセッションの企画・実施ログ
  • 再発防止につながる高品質なポストモーテムの主導実績

複数のシニアエンジニアをメンタリング・スポンサーし、組織の採用基準や技術標準、評価の質の向上に関与する。

実運用ルーブリック
推奨行動 (Do)
  • シニアエンジニア（L3）がスタッフ（L4）へ成長するための機会（重要プロジェクトのリード等）を作り、スポンサーとして支援する
  • エンジニア採用基準の策定や面接官トレーニングを刷新し、組織のエンジニアリング密度の維持・向上に貢献する
  • 外部カンファレンスでの登壇や技術広報を主導し、企業の技術的プレゼンスを高める
注意・アンチパターン (Don't)
  • 優秀なエンジニアを自分の専属タスク実行者として囲い込み、他チームへの貢献や成長の機会を奪う
  • 社内の知見を社外に発信することを軽視し、技術ブランディングに貢献しない
成果物・エビデンス例
  • 育成・スポンサーしたシニアエンジニアの昇格実績
  • エンジニア採用・評価プロセス（キャリブレーション）の改善実績
  • 国内メジャー技術カンファレンス（RubyKaigi, builderscon, AWS Summit等）での登壇実績

会社のエンジニアリング文化・技術規範の最高峰を体現し、次世代のStaff/Principalエンジニアを育成・輩出する。

実運用ルーブリック
推奨行動 (Do)
  • 次世代のStaff/Principal候補者を指名・育成し、全社レベルの大きな権限と役割を委譲する
  • 業界全体からトップタレントを惹きつけるためのリクルーティングに自ら関与する
  • 国内外のカンファレンスでの基調講演や業界活動を通じて、企業の技術的プレゼンスを業界最高水準に引き上げる
注意・アンチパターン (Don't)
  • 後継者を育てず、自分一人に全社の技術判断が依存するボトルネック構造を放置する
  • 社外での名声ばかりを追い、社内のエンジニアの育成や信頼関係を疎かにする
成果物・エビデンス例
  • 自身がメンタリングしたエンジニアのStaff/Principal昇格実績
  • 重要ポジション（Principal / VP等）の直接リクルーティング成功実績
  • 国内外の業界カンファレンスにおける基調講演（Keynote）登壇実績

隣のレベルで変わること

L1 (Associate / ジュニア) → L2 (Engineer / ミドル)
評価軸L1 での行動L2 で加わる・変わる行動
技術力設計・仕様を正しく理解し、AIツール等の補助も活かしつつ、テストコードとエラーハンドリングを含めて確実に実装・検証できる。機能単位の設計から実装、自動テスト、オブザーバビリティ（ログ・メトリクス）までを考慮して本番品質で構築できる。
スコープと影響チームのタスク（小さな機能追加やバグ修正）を、レビュアーのフィードバックを受けながら仕様通りに完遂できる。1つの独立した機能や改善を、要件定義から本番リリース・初期稼働の確認まで自力でリード・完遂できる。
自律性担当タスクの進捗と完了基準を把握し、詰まったら事実と試したことを整理して早めに相談・エスカレーションできる。担当領域の実装方針や技術的トレードオフを自分で判断し、リリース後の不具合やパフォーマンスにも責任を持つ。
協働とコミュニケーションレビューの指摘意図を正しく理解して修正に反映し、作業の状況や疑問点を明確にテキスト化して共有できる。他者のPRを的確にレビュー（品質・可読性・エッジケース）し、PdMや他職種と仕様のすり合わせを行う。
人を伸ばす自分の学習と成長に責任を持ち、質問やドキュメント読み込みを通じてコードベースの理解を継続的に深める。新しいメンバーのオンボーディングを支援し、自分が得た知見やトラブルシュート手順をチームのドキュメントに還元する。
L2 (Engineer / ミドル) → L3 (Senior)
評価軸L2 での行動L3 で加わる・変わる行動
技術力機能単位の設計から実装、自動テスト、オブザーバビリティ（ログ・メトリクス）までを考慮して本番品質で構築できる。複数コンポーネントにまたがる設計（Design Doc等）を主導し、非機能要件（性能・可用性・セキュリティ）のトレードオフを言語化できる。
スコープと影響1つの独立した機能や改善を、要件定義から本番リリース・初期稼働の確認まで自力でリード・完遂できる。チームの四半期目標や重要プロジェクトをリードし、技術的障害や仕様の曖昧さを解消しながら期限内に品質高く完遂させる。
自律性担当領域の実装方針や技術的トレードオフを自分で判断し、リリース後の不具合やパフォーマンスにも責任を持つ。チーム内の技術的負債やボトルネックを自ら見つけ出して優先順位をつけ、技術選定やアーキテクチャ方針の決定を主導する。
協働とコミュニケーション他者のPRを的確にレビュー（品質・可読性・エッジケース）し、PdMや他職種と仕様のすり合わせを行う。設計レビューで建設的なフィードバックを行い合意形成をリードするとともに、非エンジニアにも技術的制約を明快に説明できる。
人を伸ばす新しいメンバーのオンボーディングを支援し、自分が得た知見やトラブルシュート手順をチームのドキュメントに還元する。ジュニア〜ミドルのメンバーを継続的にメンタリングし、AI活用やレビュー文化を通じてチーム全体のエンジニアリング水準を引き上げる。
L3 (Senior) → L4 (Staff)
評価軸L3 での行動L4 で加わる・変わる行動
技術力複数コンポーネントにまたがる設計（Design Doc等）を主導し、非機能要件（性能・可用性・セキュリティ）のトレードオフを言語化できる。複数チームにまたがる複雑なアーキテクチャの一貫性を保ち、再利用可能なパターンやPaved Road（共通基盤・開発標準）を整備する。
スコープと影響チームの四半期目標や重要プロジェクトをリードし、技術的障害や仕様の曖昧さを解消しながら期限内に品質高く完遂させる。部門・組織規模の重大な技術課題やボトルネック（スケーラビリティ、技術的負債）を定義し、複数チームを巻き込んで解決に導く。
自律性チーム内の技術的負債やボトルネックを自ら見つけ出して優先順位をつけ、技術選定やアーキテクチャ方針の決定を主導する。不確実性が高く正解のない技術的意思決定を主導し、その結果と長期的な保守性に対して組織的な説明責任を果たす。
協働とコミュニケーション設計レビューで建設的なフィードバックを行い合意形成をリードするとともに、非エンジニアにも技術的制約を明快に説明できる。異なるチームやステークホルダー間の利害・技術的対立を調整し、組織全体の最適解に向けた技術的合意を形成する。
人を伸ばすジュニア〜ミドルのメンバーを継続的にメンタリングし、AI活用やレビュー文化を通じてチーム全体のエンジニアリング水準を引き上げる。複数のシニアエンジニアをメンタリング・スポンサーし、組織の採用基準や技術標準、評価の質の向上に関与する。
L4 (Staff) → L5 (Principal)
評価軸L4 での行動L5 で加わる・変わる行動
技術力複数チームにまたがる複雑なアーキテクチャの一貫性を保ち、再利用可能なパターンやPaved Road（共通基盤・開発標準）を整備する。事業の3〜5年後を見据えた技術ビジョンを描き、不可逆な大規模アーキテクチャ刷新や技術的賭けの成否に全社責任を持つ。
スコープと影響部門・組織規模の重大な技術課題やボトルネック（スケーラビリティ、技術的負債）を定義し、複数チームを巻き込んで解決に導く。会社全体の存続や成長を左右する最も困難な技術課題（壊滅的リスク、全社基盤の限界等）を解決し、事業競争力の基盤を築く。
自律性不確実性が高く正解のない技術的意思決定を主導し、その結果と長期的な保守性に対して組織的な説明責任を果たす。組織の誰も責任を持っていない重大かつ曖昧な技術的空白を自ら引き受け、経営レベルのトレードオフ判断を下す。
協働とコミュニケーション異なるチームやステークホルダー間の利害・技術的対立を調整し、組織全体の最適解に向けた技術的合意を形成する。経営陣（CTO/VPE/事業責任者）の技術的右腕として対話し、ビジネス目標を全社の技術ロードマップに接続する。
人を伸ばす複数のシニアエンジニアをメンタリング・スポンサーし、組織の採用基準や技術標準、評価の質の向上に関与する。会社のエンジニアリング文化・技術規範の最高峰を体現し、次世代のStaff/Principalエンジニアを育成・輩出する。

行動記述は海外の先進企業の公開求人・公開ラダーを参照して独自に書き下ろしています。