以下は
の翻訳です。
2025年12月4日
最近、Sean Goedeckeが書いた「Staff+エンジニア」についての優れたエッセイをいくつか読んでいる。彼の著作（特に『Software engineering under the spotlight（スポットライトを浴びるソフトウェアエンジニアリング）』や『It’s Not Your Codebase（それは君のコードベースではない）』）は極めて鋭く、ビッグテックに身を置く者なら誰しもが痛いほど身に覚えのある内容だ。
書類上のスペックを見れば、私は彼が描写する型にぴったり嵌まる。Googleのシニアスタッフエンジニアだ。しかし、彼の文章を読んだ後、私はどうにも拭い去れない違和感を覚えた。最初はそれを単なる冷笑主義だと思って片付けようとしたが、よく考えてみると、問題はSeanの文章にあるのではなく、私の読み方にあったのだ。
Seanは悲観的なことを言っているのではない。エンジニアが「代替可能な資産」として扱われ、優先順位が四半期ごとに変わる世界において、どう立ち回るべきかを正確に描写しているのだ。しかし、私の仕事はそれとは全く似ていない。そして、もし私が彼の言うような環境や方法で働こうとすれば、数ヶ月で燃え尽きてしまうだろうということを、私は心の底で理解している。
その代わりに、私は別の道を歩んできた。「スポットライト」よりも「システム」を、「代替可能性」よりも「スチュワードシップ（責任ある管理・守護）」を優先する道だ。
住む世界が違う
私たちが異なる道を歩んでいる根本的な理由は、Seanと私が、全く異なる法則に支配された別の世界で働いているからだ。
Seanの経歴を見る限り、彼は主に外部顧客向けのプロダクトチーム [1] で働いてきた。ビジネス目標は四半期ごとにピボット（転換）し、成功は収益やMAU（月間アクティブユーザー）で測定される。このような環境では、「スポットライト」を浴びるように最適化することは完全に理にかなっている。ビッグテックにおけるプロダクト開発は、VPやPM、UXデザイナーといった多くの人々が強い意見を持ってひしめき合う混雑した部屋のようなものだ。そこで成功するには、機敏に動き、エグゼクティブが現在注目しているものに対して確実にコミットし続けなければならない。
一方で、私はキャリアのすべてを「舞台裏」で過ごしてきた。つまり、開発者ツールやインフラチームだ。
私のチームの顧客は、AndroidやChrome、そしてGoogle全体に散らばる何千人ものエンジニアだ [2]。Google製品のエンドユーザーは、私たちの存在すら知らない。私たちの関心事は、開発者が製品のパフォーマンス指標を収集し、詳細なトレースを用いて問題をデバッグするためのツールを確実に提供することにある。
この環境では、リーダーシップとの関係性が大きく異なる。私たちは「誰もがやりたがる旬のプロジェクト」になることはまずないため、エグゼクティブが無理に介入してくることもない。実際、私のチームは歴史的にPM（プロダクトマネージャー）の採用に苦労してきた。GoogleのPMのキャリアラダーは、派手な外部向けローンチを評価するようにできているため、私たちの仕事は彼らにとって「昇進の材料」になりにくいのだ。また、私たちのフィードバックはエンジニアから直接届く。間にPMを挟むと情報の伝達ロスが発生し、緊密で高帯域なフィードバックループが鈍くなってしまう。
これらすべての要因により、私たちのチームは「ボトムアップ」で運営されている。エグゼクティブから「これをやれ」と言われるのではなく、自分たちで顧客にとって最もインパクトがあると判断した機能やツールを考え、構築する。エグゼクティブの役割は、私たちが他のプロダクト担当チームに与えている影響を考慮し、私たちが実際に問題を解決しているかを確認することに留まる。
「スチュワードシップ（守護）」による複利の効果
Seanが描写するプロダクト環境では、目標が四半期ごとに変わり、機能が実験的であるため、「スピード」こそが究極の通貨となる。市場が変わる前に出荷し、反復し、時には次へと移らなければならない。しかし、インフラや開発者エクスペリエンス（DevEx）において、通貨となるのは「コンテキスト（文脈）」だ。
エンジニアを代替可能な資産として扱うことは、このコンテキストを破壊する。新しい視点を得ることはできるかもしれないが、システムが実際にどのように壊れるかという暗黙知を失うことになる。一つのシステムに長期的に留まる「スチュワードシップ」は、短期的なローテーションでは決して得られない複利的なリターンをもたらす。
第一のリターンは、パターンマッチングによる効率化だ。一つのドメインに何年も留まれば、新しいリクエストが真に「新しい」ことは稀になる。私は単にコードをデバッグしているのではない。私のツールと、何百もの多様なエンジニアリングチームが交差する地点をデバッグしているのだ。新しいチームが「独特な」問題を抱えてやってきたとき、私は過去を振り返ってこう言える。「2021年にCameraチームと同じアプローチを試しました。それが失敗した正確な理由と、実際に機能するアーキテクチャはこれです」と。
しかし、より強力なリターンはシステム的なイノベーションだ。毎年チームを交代していては、今見えている急性のバグを解決することしかできない。しかし、ある種の問題は、長い年月をかけてようやくその全体像を現す。
最近私が主導したプロジェクト「Bigtrace」を例に挙げよう。これは、私が同じ場所に長く留まり、問題の輪郭を見極め続けたからこそ生まれた解決策だった。
- 2023年初頭（観察）: あるパターンに気づき始めた。Google内のチームがテラバイト、あるいはペタバイト級のパフォーマンス・トレースを収集しているが、その処理に苦労している。エンジニアはデータを解析するために脆弱でカスタムなパイプラインを自作し、解析の反復がどれほど遅く苦痛であるかを不満に思っていた。
- 2023年の大部分（調査）: すぐにプロダクションシステムの構築に飛びついたわけではない。他のプロジェクトをこなしながら、1年の大半を背景で静かにプロトタイピングに費やした。不満を漏らしていたエンジニアたちからフィードバックを集めたが、彼らとは長年の信頼関係があったため、正直で内省的なフィードバックをくれた。私は、彼らがどのようなUX、レイテンシ、スループットを求めているかを学び、それをどう実現すべきかを考え抜いた。
- 2023年末〜2024年初頭（実行）: 私たちは、トレースのための分散型ビッグデータクエリエンジンであるBigtraceを構築し、ローンチした。今日、それは月に20億件以上のトレースを処理し、100人以上のエンジニアにとって日常業務に欠かせないツールとなっている。
もし私が「代替可能性を最適化せよ」というアドバイスに従い、新しいプロジェクトを求めて2023年にチームを去っていたら、Bigtraceはこの世に存在しなかっただろう。
私は調査フェーズで去り、後任者は同じエンジニアの「ノイズ（不満）」を耳にすることになったはずだ。しかし、欠けているパズルのピースを認識するための歴史的背景がなければ、Bigtraceのようなものを構築するのは困難だっただろうと思う。
「ノー」と言える力
「スポットライト」を追いかけるべきだという最も誘惑的な主張の一つは、それがリソースとエグゼクティブの注目を保証するというものだ。しかし、その注目は諸刃の剣である。
注目度の高いプロジェクトはしばしば不安定だ。エグゼクティブの気まぐれ、政治的な駆け引きがつきまとい、短期的な生存のために長期的な品質が犠牲にされることも少なくない。一部のエンジニアにとって、この混沌を切り抜けることはスリルだろう。しかし、システムの安定性を重視する私たちにとって、それは罠のように感じられる。
スチュワードシップの利点は、別の種類の資本、すなわち「信頼」を生み出すことだ。長年にわたり信頼性の高いツールを提供し続けていれば、製品を脅かすような「スポットライト」に対して「ノー」と言うための政治的資本を得ることができる。
最近、スポットライトはAIに当たっている。あらゆるチームがAIの導入を迫られている。私たちも繰り返し尋ねられた。「なぜPerfetto（トレースツール）にLLMを統合しないのか？」と。もし私が視認性（目立つこと）を最適化していたなら、答えは明白だ。LLMのラッパーを構築し、リーダーシップにデモを見せ、「AIファースト」を宣言すればいい。私のキャリアにとっては簡単な勝利だっただろう。
しかし、システムの守護者として、私はPerfettoの核心的な価値が「精密さ」であることを知っている。カーネル開発者がレースコンディションをデバッグするときに必要なのは、正確なタイムスタンプであって、AIの「ハルシネーション（幻覚）」ではない。ユーザーは、私たちが「これが問題だ」と言ったとき、それが事実であり、存在しない問題のために1週間も無駄なデバッグをさせられることはないと信じている。
もちろん、これをやりすぎないことも重要だ。懐疑主義が「拒絶主義（足を引っ張ること）」になってはならない。AIについても、「永遠にノー」ではなく、「正しく実現できるようになるまでノー」なのだ [3]。
スポットライトを追いかけるエンジニアは、このアプローチを機会損失と見るかもしれない。私はこれを、製品の根幹である「ユーザーの信頼」を守る行為だと考えている。
インパクトの「別の通貨」
スポットライトから離れることでエンジニアが抱く最も一般的な恐怖は、キャリアの停滞だ。「Google I/Oで派手な機能を発表せず、VPのトップ5リストにも載っていないのに、どうやってスタッフエンジニア以上に昇進できるのか？」という論理だ。
確かに、「エグゼクティブからの視認性」という通貨は失う。しかし、インフラの世界では、それに劣らず価値があり、かつ安定した2つの代替通貨を手に入れることができる。
シャドウ・ヒエラルキー（影の階層）
プロダクト組織では、自分の上司の上司を感心させる必要がある。しかし、インフラ組織では、「顧客」の上司を感心させることが重要になる。
私はこれを「シャドウ・ヒエラルキー」と呼んでいる。自分のVPにコードの複雑さを理解してもらう必要はない。他の重要な組織のスタッフエンジニアたちに、あなたのツールを必要とさせればいいのだ。
Pixelチームのシニアスタッフエンジニアが自分のVPに「Perfettoがなければ次のPixelのデバッグは不可能です」と言ったとき、その言葉には絶大な重みが宿る。その言葉は報告ラインを駆け上がり、ディレクターやVPレベルで交差して、自分のマネージャーへと降りてくる。
この種の支持は、政治的ではなく技術的であるため、極めて強力だ。偽ることは難しい。重要なシステムの守護者であれば、昇進のパケット（推薦資料）は、社内で最も尊敬されるエンジニアたちによる「この人物の仕事が私たちの成功を可能にした」という証言で埋め尽くされる。
ユーティリティ・レジャー（有用性の台帳）
プロダクトチームがDAUや収益を注視している間、私たちはエンジニアリングの健全性を追跡する指標を信頼する。
- 有用性（Utility）: 私たちのツールで修正されたすべてのバグは、エンジニアが私たちを役立ててくれた証拠だ。それは有用性の最も純粋な測定値である。
- 重要性（Criticality）: Pixelチームがローンチを妨げるカクつきを直すためにPerfettoを使ったり、Chromeがメモリリークを直すために使ったりすれば、私たちのインパクトは必然的に彼らの成功と結びつく。
- 遍在性（Ubiquity）: エンジニア人口の大部分を占有することは、あなたが「共通言語」を作り出した証拠だ。社内の互いに無関係な部署同士が、共有されたPerfettoのトレースを「全員が理解できる共通リファレンス」として協力し合うのを目にするとき、その価値は明白になる。
- 規模（Scale）: ペタバイトのデータを飲み込み、数十億のトレースを処理することは、どんなデザインドキュメントよりもアーキテクチャの回復力を証明する。
「重要性（VIPチームがこれを必要としている）」と「有用性（バグが修正されている）」を組み合わせれば、エグゼクティブの組織改編にも左右されない、強固な昇進の根拠を構築できる。
アーキタイプと主体的選択
スタッフのアーキタイプ
「スタッフソフトウェアエンジニアになるには複数の道がある」という考えに気づいたのは、私が最初ではない。Will Larsonはその著書『Staff Engineer』の中で、Staff-plusエンジニアを4つのアーキタイプに分類している。
Seanが描写しているのは「ソルバー（Solver）」や「ライトハンド（Right Hand）」だ。これらはエグゼクティブの意志の代行者として、火に飛び込み、問題が安定したら次へと移る。私が描写しているのは「アーキテクト（Architect）」や「テックリード（Tech Lead）」だ。特定のドメインに対する長期的な所有権と、深い技術的コンテキストによって定義される役割である。
「運が良かっただけだ」という反論
「あなたは良いチームを見つけただけで運が良かった。私たちにはそんな贅沢はない」という批判が聞こえてきそうだ。
私のこれまでのアドバイスには、2つの注釈が必要だ。第一に、この戦略は、長期的なインフラ投資を維持できるほど利益を上げている企業でなければ成立しない。この道はスタートアップや成長初期の企業には存在せず、ビッグテックに最適化されたものだ。
第二に、良いチームに巡り合うには確かに運が必要だ。外からチームや会社の文化を正確に評価するのは非常に難しい。しかし、チームを見つけるのは運だったかもしれないが、そこに10年近く留まり続けたのは「選択」である。
そして、私の経験上、私のチームは特段特別なわけではない。Android内だけでも、他にも5つのチームを挙げることができる [4]。ディレクターやVPの交代はあるかもしれないが、核心となるミッションとエンジニアリングチームは安定し続けている。
これらのチームが稀に見えるのは、存在しないからではなく、往々にして「無視されている」からだ。派手なプロダクトローンチのような急速な勝利も、「キラキラした新機能」もないため、競争が激しくない。もし「何十億人のユーザーに届けること」や、友人や家族に使ってもらうことにモチベーションを感じるなら、ここにはその満足感はない。それがこの道を選ぶための「入場料」だ。
しかし、もし長期的なシステムを構築したいと考え、外部からの承認と引き換えに深い技術的オーナーシップを手に入れたいのであれば、カーテンの裏側を覗いてみるだけでいい。
結論
テック業界は「速く動け（Move Fast）」と教えたがる。しかし、別の道もある。深さ、忍耐、そして他者がその上に立つ基礎を築くという静かな満足感からレバレッジ（影響力）が生まれる道だ。
大企業で意味のある、インパクトの大きなキャリアを築くために、スポットライトを追いかけ続ける必要はない。時には、問題領域に腰を据え、Bigtraceを作れるほど深く理解できるまで何年も留まり続けることこそが、最も野心的な選択になるのだ。
[1] ここで言うプロダクトチームとは「フロントエンドチーム」という意味ではない。バックエンドエンジニアであっても、エンドユーザーに直接提供されるものの一部を担当していれば、それはプロダクトチームである。
[2] これが全てではない。Perfettoはオープンソースであり、外部の開発者のことも大切にしているが、会社から給料をもらっている理由はそこではない。会社から見ればオープンソースのバグ対応は「無駄な時間」かもしれないが、私たちはオープンソースのミッションを信じているからこそ取り組んでいる。
[3] 補足すれば、LLMは「PerfettoにAIを入れる」ための最善の解決策ですらないかもしれない。個人的には、ニューラルネットワークのような「古き良き」機械学習技術に多くの価値があると考えている。トレース分析の多くはパターンマッチングだからだ。これは来年探索したいと考えている。
[4] Android Kernel, Android System Health, Android Runtime, Android Camera HAL, Android Bionicなど。
免責事項
記事は、一般的な情報提供のみを目的としてのみ作成したものであり、投資家に対する有価証券の売買の推奨や勧誘を目的としたものではありません。また、記事は信頼できると判断した資料およびデータ等により作成しておりますが、その正確性および完全性について保証するものではありません。また、将来の投資成果や市場環境も保証されません。最終的な投資決定は、投資家ご自身の判断でなされますようお願いします。
