Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — たくさん書けば昇進するのか
公開ラダーは実際に何を測っているのか
4つのアーキタイプ — あなたはどこに立っているか
インパクトはどうやって「証拠」になるのか
グルーワークの罠 — Reillyが実際に言ったこと
書くことがレバレッジになる
政治抜きで可視化する
正直なノート — ラダーはノイズが多い
AI時代の脚注
おわりに
参考資料

はじめに — たくさん書けば昇進するのか

昇進が止まったエンジニアが最初に手を伸ばす処方箋は、たいてい「もっと多く、もっと速く」です。チケットをより多く閉じ、PRをより多く出し、週末も書く。それでも1年後、レベルは変わっていません。

理由は単純です。公開されているエンジニアリング・ラダーで、アウトプット量を軸に据えているものは一つもないからです。これは推測ではなく、実際にドキュメントを開けば確認できる事実です。この記事では、実際のラダーの記述、Will Larsonによるスタッフ以上のエンジニアの研究、そしてTanya Reillyのグルーワーク論を根拠に、「本当は何が評価されているのか」を整理します。

公開ラダーは実際に何を測っているのか

progression.fyiには、CircleCI、Dropbox、Monzo、Etsy、Spotify、Square、Rent the Runwayなど数十社のキャリアフレームワークが公開されています。並べて読むと、語彙は違っても測っている軸は驚くほど重なります。

Rent the Runwayのラダーは最も早く公開されたものの一つで、後続の多くのフレームワークが真似することになる4本の柱を確立しました — "Technical Skill"、"Get Stuff Done"、"Impact"、"Communication & Leadership"。

Dropboxのキャリアフレームワークはもっと直截です。ドキュメントは "Dropbox measures the success of its engineers largely on business impact" と述べたうえで、レベル期待値を3つの軸で定義します — Scope(スコープ)、Collaborative Reach(協業の到達範囲)、Levers for Impact(インパクトのレバー)。そしてこう明言します。これらの期待値こそが "the what that determines the difference between an IC3 and IC4" である、と。スタッフ(IC5)のスコープはこう書かれています — "I deliver multi-year, multi-team product or platform goals"、そして "open-ended problems that require difficult prioritization, defining both the what and how"。協業の到達範囲は "I am increasingly influencing the roadmaps of other Dropbox teams" です。

CircleCIはE1(Associate)からE6(Principal)までの6段階を持ちますが、レベルを分けるのはインパクトが届く範囲です — "from task to epic, team level, and onwards ... to across several teams and, ultimately, across the organization"。そして仕事の性質そのものが変わります。業務は "shifts over time from execution to include facilitating, guiding, and mentoring others, whether or not they are in a management role"。彼ら自身が挙げる例が明快です。ジュニアはテストを書き、最上位レベルは複数チームのテスト戦略を導く。同じ主題、違うレバレッジ。

CircleCI E1 -> E6 : インパクトの到達範囲が広がる
  task  ->  epic  ->  team  ->  several teams  ->  organization

Dropbox IC3 -> IC5 : 3つの軸が同時に大きくなる
  Scope              自分のプロジェクト ->  multi-year, multi-team goals
  Collaborative      自分のチーム       ->  他チームのロードマップに影響
  Levers for Impact  直接の実行         ->  戦略、判断、ロールモデル

どのラダーにも存在しない軸:
  「書いたコードの量」

ここで一つ正直になるべき点があります。Rent the Runwayに "Get Stuff Done" が確かに存在するとおり、実行力は間違いなく評価されます。ただしそれはすべてのレベルにおける前提条件です。レベルを引き上げる軸ではなく、欠けていれば失格になる軸です。レベル間で実際に変わるのはスコープとレバレッジです。シニアがスタッフに届かない典型的な理由は、実行力の不足ではありません。実行がいつも、誰かが決めたスコープの中でしか起きていないからです。

4つのアーキタイプ — あなたはどこに立っているか

Will Larsonは複数企業のスタッフ以上のエンジニアにインタビューし、4つのアーキタイプとして整理しました。

Tech Lead — "guides the approach and execution of a particular team"。マネージャーと組んで一つのチームの技術的方向と実行を導きます。最も一般的で、Larsonの観察では調査したすべての会社に存在しました。多くの人が最初に到達するスタッフの姿です。
Architect — "responsible for the direction, quality, and approach within a critical area"。API設計やインフラのように長く続く中核領域を、複数年の時間軸で担います。おおむねエンジニア100人規模を超えて初めて生まれます。
Solver — "digs deep into arbitrarily complex problems and finds an appropriate path forward"。組織が指名した難問に深く潜り、解決すれば次の火事場へ移ります。継続的なオーナーシップを持たない点で、前の二つとは異なります。
Right Hand — "extends an executive's attention, borrowing their scope and authority"。役員のスコープと権限を借りて複雑な組織を動かします。4つの中で最も稀で、通常はエンジニア1,000人規模になって初めて現れます。

重要なのは、Larsonがこれらを処方箋ではなく観察として提示していることです。彼はこう書いています — "Being a Staff-engineer is not just a role, rather it's the intersection of the role, your behaviors, your impact, and the organization's recognition."

だから現実的な問いは「自分はどのアーキタイプになりたいか」ではなく、**「今の会社に席が存在するアーキタイプは何か」**です。50人の会社でArchitectになろうとするのは、存在しないポジションに向かって走ることです。逆にチームという概念が弱い組織なら、Solverへの道はずっと広く開いています。

インパクトはどうやって「証拠」になるのか

ここで最も大きな誤解が生じます。インパクトを生むことと、インパクトが読み取られることは別の仕事です。そして昇進は後者で決まります。

スコープの大きい仕事は、本質的に痕跡が薄いのです。2つのチームが半年間もめていたインターフェース論争をまとめたとして、成果物はコード30行と合意が一つ。コミットログにはほとんど残りません。だからスタッフレベルの仕事は、意図的に証拠が残る形でやる必要があります。

設計ドキュメントとRFC。 スタッフの仕事の半分は「何を作るか」を定義することです(Dropboxの表現を借りれば "defining both the what and how")。その定義がドキュメントとして残れば、それこそがあなたがそのレベルの判断を下した証拠になります。
障害対応のリード。 インシデントコマンダーを引き受け、ポストモーテムを書き、再発防止項目を最後まで閉じる。組織が最も脆い瞬間に誰が方向を示したかは、全員が覚えています。
メンタリングとレビュー。 DropboxのIC5には "I serve as a role model for other Dropbox engineers" が明示されています。他人のコードを良くすることは趣味ではなく、ラダーの項目です。
チーム間のアンブロッキング。 他チームのロードマップを動かした瞬間を記録しておきましょう。それがDropboxの言う協業の到達範囲そのものです。

そしてこれらすべての頂点に、StaffEngが言う「スタッフプロジェクト」があります。定義はこうです — "complex and important enough that the person who completes it has proven themselves as a Staff engineer"。特徴は3つ。最初はスコープが定まっておらず("poorly scoped but complex and important")、ステークホルダーが多く割れており、リーダーシップが全社ミーティングで話題にするほど目立つ。成功も失敗も、全員が見ています。

グルーワークの罠 — Reillyが実際に言ったこと

Tanya Reillyの"Being Glue"は、この議論で最も引用され、最も誤読されている文章です。

グルーワークとは、オンボーディング、メンタリング、他人のアンブロッキング、チーム間の合意形成、ドキュメント作成、設計レビュー — 誰にも指示されていないが、無ければプロジェクトが崩れる仕事のことです。誤読はここから始まります。Reillyは**「グルーワークをするな」とは一度も言っていません。** 彼女はグルーワークこそがプロジェクトの成否を分けると述べています。

彼女の実際の論点は二つです。

第一に、分配と可視性の問題。昇進につながらないこの種の仕事は、特定の人々に偏って積み上がります(とりわけ女性に)。そして評価の季節になると、当の本人が「技術的な成果が足りない」と言われるのです。Reillyはこのフィードバックを一刀両断します。"not technical enough" はゲートキーピングであり、行動に移せない言葉だ、と。何をせよと言われているのか分からないからです。

第二に、置き換えの問題。彼女の最も有名な一文がこれです — "If you only do glue, you will only get better at glue."。要は only です。グルーワークが技術的な深さを補完するなら、それがまさにスタッフエンジニアの姿です。グルーワークが技術的な深さを置き換えるなら、それはキャリアの袋小路です。

彼女の処方箋もロマンチックではありません。マネージャーと昇進要件を明示的に合意すること。実際にやっている仕事に見合った肩書きを要求すること。証拠となる成果物を残すこと。そしてそれでも駄目なら — グルーを一度置いて、測定可能な技術的成果物を作れ、と。"Stop being the unofficial lead."。公式のリードでないなら、公式のリードの仕事を無償で肩代わりするのはやめよ、という意味です。

そしてこれはマネージャーと同僚に向けた言葉でもあります。Reillyはグルーワークをする人を公に認めよ、ただし正しい名前で呼べと言います — "publicly give them credit! And not for helping, but for leading."

書くことがレバレッジになる

Reillyの著書 The Staff Engineer's Path は、スタッフの仕事を3つの柱に分けます — 大局を見ること(big picture)、プロジェクトの実行(execution)、他者を引き上げること(leveling up)。そしてこの3つは技術的な土台の上に立たねばならない、と釘を刺します。

この3本の柱すべてを貫く道具が「書くこと」です。理由はレバレッジにあります。会議での説得はその部屋にいる人にしか届かず、1時間後には蒸発します。よく書かれた設計ドキュメントは、あなたが眠っている間も説得し、半年後に入社する人も説得し、あなたがいない部屋でも説得します。スコープがチームを越えた瞬間 — つまりスタッフの定義そのものの瞬間 — あなたはすべての部屋にいることはできません。ドキュメントだけが行けます。

コードも同じ原理で書きます。読む人のために書かれたコードこそがレバレッジを生むという話は、AIがコードを保守する時代でも、人間のために書くで別途まとめました。

政治抜きで可視化する

「見えるようにすること」を政治と同義に捉えるエンジニアは多いものです。だから何も言わず、誰にも知られないまま昇進を逃します。

区別は簡単です。政治とは、存在しないインパクトを在るように見せること。可視化とは、存在するインパクトを読めるようにすること。 後者は誠実な労働であり、実のところ、あなたを評価する人々への配慮でもあります。彼らにはあなたの半年間を代わりに再構成する時間などありません。

StaffEngの昇進ガイドが繰り返す項目も結局これです — スポンサーを見つける、決定が下される部屋に入って居続ける、昇進パケットを書く、スタッフプロジェクトを引き受ける。ここでスポンサーとは、おもねる相手ではありません。あなたがいない部屋で、あなたの仕事を正確に説明できる人のことです。そのためには、彼らがあなたの仕事を正確に知っている必要があります。それを伝えることは政治ではなく、業務です。

実務的にはこの程度で十分です。決定はドキュメントに残し、書いたドキュメントは影響を受ける人に実際に送り、成果はチームの名で語りつつ、自分が下した判断は明確にする。そして半年ごとに、自分の昇進パケットを先に書いてみてください。書くことが何も無いと気づいたなら、それこそが今日知るべき事実です。

正直なノート — ラダーはノイズが多い

ここまで読んで、ラダーを精密な測定器だと誤解しないでください。

ラダーは会社ごとに違います。progression.fyiに集められたフレームワークは、レベルの数も、軸の名前も、強調点もバラバラです。Larsonの観察どおり、Architectはエンジニア100人、Right Handは1,000人規模になって初めて現れます。つまり同じ人物が、A社ではシニア、B社ではスタッフでありえます。これはあなたへの評価ではなく、組織構造についての事実です。

運も大きい。StaffEngはスタッフプロジェクトを得る条件の一つを正直に認めています — "your company having a pressing need to solve a Staff-level problem, which can require some patience"。会社にスタッフ級の問題が無ければ、スタッフ級の証拠は作れません。そのうえ、経営ラインがあなたに賭ける意思まで重なる必要があります。

だからレベルを自我にしないでください。制御できるのはスコープを広げる習慣と証拠を残す習慣であり、制御できないのはタイミングです。ただし前の二つを備えた人は、機会が来たときに準備ができています。

AI時代の脚注

コードのアウトプットは安くなりつつあります。かつて1週間かかった実装が1日になり、その差はさらに開くでしょう。

ここで陥りやすい結論が「だからエンジニアの価値は下がる」です。ラダーを見直すと話は逆転します。そもそもどのラダーもアウトプット量を測ってなどいませんでした。 ラダーが測っていたのは、曖昧な問題をスコープに変える力("defining both the what and how")、複数チームにまたがる判断、そして何を作らないかという決定です。それらは今日のモデルが肩代わりしてくれる軸ではありません。むしろ実装が安くなるほど、間違ったものを見事に実装するコストは目に見えて大きくなります。

副作用もあります。AIは新しいグルーの罠を作ります。ドキュメントも、要約も、プロトタイプも数分で量産できるので、忙しく見えることがかつてなく簡単になりました。 活動量はスコープではない、という原則はそのままです。むしろより冷静に問うべきです — この成果物は、誰のどんな決定を変えたのか。

不慣れな環境で曖昧さをスコープに変える力がなぜ高くつくようになるのかは、Forward Deployed Engineerを目指すで別の角度から扱いました。

おわりに

まとめるとこうです。昇進はアウトプット量ではなくスコープとレバレッジです。実行力は入場券であり、レベルを上げるのはインパクトが届く範囲です。アーキタイプは処方箋ではなく地図なので、自社に実際に存在する席を見てください。インパクトは生んで終わりではなく読まれる必要があるので、証拠を残してください。グルーワークは不可欠ですが、技術的な深さを置き換えた瞬間に罠になります。そしてラダーはノイズが多いので、レベルを自我にしないでください。

正直な助言を一つだけ残すなら、これです。次の四半期、「何をもっと書こうか」と問うのはやめて、**「今、誰も所有していない重要な問題は何か」**と問うてください。その問いに答え、答えをドキュメントに残す習慣こそ、どの会社のどのラダーでも通用する唯一のものです。