Staff Engineer

一言でいうと

管理職へ進まずに影響範囲を広げる上位のエンジニア職で、チームを越えた技術課題を見つけ、解決まで持っていくことを担当します。

この職種の出自と登場時期

背景にあるのは、優秀なエンジニアが昇進するために管理職になるしかないという構造への反省です。米国の大手テック企業は以前から、管理職と並ぶ技術職の等級（シニア → スタッフ → プリンシパル）を持っていましたが、その中身は各社の内部知識にとどまっていました。

外へ整理されたのは2021年です。Will Larson が StaffEng でこの職種の実像を集め、書籍にまとめました。同資料は役割を4つの型に分類しています。特定領域を深く担当する Tech Lead 型、組織全体の技術方向を示す Architect 型、複数チームにまたがる長期課題を扱う Solver 型、組織の接着剤として動く Right Hand 型です。この分類が、抽象的だった上位職の議論に具体的な輪郭を与えました。なお、ここでいう Tech Lead 型と Architect 型は StaffEng が定義した型の名称で、職種としてのテックリードやソフトウェアアーキテクトとは指すものが違います。

国内では2022年前後から、等級制度を公開する事業会社を中心に使われ始めています。ただし国内では、この等級を置いていても実態がテックリードの延長にとどまる例も多く、求人票では影響範囲の確認が必要です。

ミッション

責任範囲は、1つのチームでは解けない技術課題を前に進めることです。担当が決まっていない問題を自分で見つけ、関係者を巻き込んで着地させるところまでが対象になります。

そのため、成果は書いたコードでは測れません。組織全体の開発速度、重大な障害の減少、技術選択の質といった、間接的で時間のかかる指標で評価されます。

主な業務範囲

• 組織横断の技術課題の特定。複数チームで繰り返し起きている問題を見つけて定義する
• 設計の方向づけ。全社に影響する技術選定と移行計画を提案し、合意を作る
• 難所への投入。行き詰まったプロジェクトに入り、技術的な突破口を作る
• 技術文書の作成。判断の背景と選択肢を残し、他のチームが同じ判断を再現できるようにする
• 育成。テックリードやシニアエンジニアの相談相手になり、判断の質を上げる

求められる能力

技術面では、複数領域にまたがる設計判断ができることが前提です。特定の言語やフレームワークの熟練よりも、システム全体の構造とトレードオフを読む力が問われます。

もう一つ求められるのが、権限のない状態で人を動かす力です。指揮命令の関係がない相手に提案を通す必要があり、文書で説得する力と、他チームの事情を理解する姿勢が成果を分けます。

この職種に就く人のキャリア経路

多いのはテックリードからの移行です。担当チームでの実績を土台に、影響範囲を組織全体へ広げていく流れが一般的です。Engineering Manager を経験した人が技術職へ戻る形もあります。

Principal Engineer やソフトウェアアーキテクトへ進む例が代表的です。CTO や VPoE として経営側に回る人もいます。

隣接職種との違い

採用担当の見極めポイント

• 求人票では、期待する影響範囲を具体的に書いてください。等級名だけでは、テックリードとの違いが候補者に伝わりません
• 職務経歴書では、自分の担当外の課題に踏み込んだ経験を確認してください。担当領域の成果しか出てこないなら、直近で他チームに口を出した場面を1つ挙げてもらってください
• 社内に等級制度がない状態でこの呼称を使うと、入社後の評価基準が曖昧になります。制度の有無を募集前に整理してください

求人・市場の傾向

国内の母集団は薄く、この呼称で経歴を書いている候補者は限られます。等級名を公開していない会社の在籍者は検索に出てこないため、件数は実態より小さく見えます。媒体では各領域の職種カテゴリで引き、経歴のなかに組織横断の技術課題を扱った記述があるかで絞る進め方が現実的です。技術記事や登壇資料が判断材料になる場合もあります。

等級制度の有無と、期待する課題の実例を1つ載せてください。抽象的な期待だけでは、テックリードとの違いが伝わりません。

関連キーワード

デュアルラダー / 技術等級 / 組織横断 / 技術戦略 / 設計文書 / メンタリング / 影響力