1 ポイント 投稿者 GN⁺ 2025-12-05 | 1件のコメント | WhatsAppで共有
  • 大手ハイテク企業の製品中心の文化は短期成果と可視性を重視する一方、インフラ・開発者向けツール分野では持続性とシステム管理が中核価値として機能している
  • 著者はGoogleで開発者ツールとインフラチームに所属しており、経営陣の注目よりもエンジニア顧客の信頼と効率性を優先する
  • 長期的な**システム管理(stewardship)**によって蓄積された文脈と経験が、Bigtraceのような大規模プロジェクトのイノベーションへとつながる
  • 短期的な注目を追う代わりに信頼と技術的影響力を資産化し、必要な時に“ノー”と言える政治的資本を確保した
  • テック業界の速い回転が続く中でも、深さと持続性に基づくキャリアパスが存在し、これは長期的な影響力を生み出す代替モデルである

異なる世界でのエンジニアリング

  • 製品チームは外部顧客を対象としており、**収益・月間アクティブユーザー数(MAU)**など短期指標で成果を評価する
    • この環境では経営陣の注目を得るために**機敏性と可視性(スポットライト)**が不可欠
  • 一方、インフラ・開発者向けツールチームは社内エンジニアを顧客とし、製品の性能・デバッグを支援するツールとシステムを構築する
    • 経営陣の注目が少なく、PM採用が難しい構造のため、エンジニア中心の**ボトムアップ(bottom-up)**運営形態
    • チームは自分たちで最も影響度の高い問題を定義して解決し、経営陣はその影響を検証する

管理(stewardship)の複利効果

  • 製品環境では速度が主要な通貨だが、インフラ環境では**文脈(context)**が中核資産
    • エンジニアを交換可能なリソースとして扱うと文脈が消え、システムの暗黙知が失われる
  • 長期的な管理で得られる第一の利益はパターン認識による効率性
    • 長期間ひとつのドメインにとどまることで、新しいリクエストが過去の事例と結びつき、素早い問題解決が可能になる
  • 第二の利益はシステム的イノベーション
    • 長期観察でのみ明らかになる問題を解決できた結果がBigtrace
      • 2023年初め、Google内の複数チームが**性能トレースデータ(テラバイト〜ペタバイト規模)**を処理できないという課題を観測した
      • 1年間プロトタイプ調査とフィードバック収集を重ね、2024年初頭にBigtraceを構築
      • 現在は月間20億件以上のトレースを処理し、100人以上のエンジニアが利用
    • もし短期プロジェクトに移ることを選んでいたらBigtraceは存在しなかっただろう

「ノー」の力

  • 可視性の高いプロジェクトは資源と注目を獲得する一方、政治的な変動と品質低下のリスクも伴う
  • 長期管理で蓄積した信頼資本は、スポットライトの誘惑を拒絶する力を与える
    • 例として、AIブームの中でもPerfettoへのLLM統合を求められたが、**精度(precision)**を中核価値として慎重に対応した
    • カーネルデバッグなどでは正確なタイムスタンプが不可欠で、幻覚(hallucination)は許容できない
    • ただし“永遠の拒否”ではなく、“正しく実装されるまで保留する”という姿勢を維持した

影響力の代替通貨

  • スポットライトを離れると経営陣の可視性は下がるが、技術的信頼と有効性という別の通貨を獲得できる
  • Shadow Hierarchy(シャドウ・ヒエラルキー)
    • インフラ組織では、自分の上司より顧客組織の上司から認められることが重要
    • たとえば、Pixelチームが「Perfettoなしではデバッグできない」と言うと、その影響は経営陣ラインを通じて伝達される
    • これは政治ではなく、技術的信頼に基づく擁護であり、昇進評価においても強力な証拠となる
  • Utility Ledger(ユーティリティ・レジャー)
    • Utility: バグ修正時にツールが使われることで純粋な有用性が証明される
    • Criticality: 主要製品チームの成功と直接つながる
    • Ubiquity: 複数の組織が同じトレースを共有して協業
    • Scale: ペタバイト級データ処理でアーキテクチャの堅牢さを証明
    • これら指標の組み合わせにより、組織再編でも揺るがない継続的インパクトを確保できる

スタッフエンジニアのタイプと選択

  • Will Larsonの『Staff Engineer』によると、スタッフエンジニアにはSolver/Right HandArchitect/Tech Leadなど、複数のタイプがある
    • 前者は経営陣の意思を実行する問題解決者、後者は特定ドメインの長期的オーナー
  • 著者は後者に属し、深い技術的文脈と長期的責任を重視する
  • このアプローチは収益性の高い大企業環境でのみ可能なことが多く、運と選択の両方が作用する
    • 良いチームに出会うことは運だが、長期間残りながらリーダーへ成長することは選択
    • こうしたチームは外部から注目されないが、継続的なミッションと安定したエンジニアリング文化を維持する

結論

  • 技術産業は「より速く動け」という合言葉を強調するが、深さと忍耐の道も存在する
  • スポットライトを追わなくても意味のある、影響力のあるキャリアを構築できる
  • 問題領域に長く留まり、持続可能なシステムを作り上げることこそが、最も野心的な選択である

1件のコメント

 
GN⁺ 2025-12-05
Hacker Newsの意見
  • 25年以上働いて学んだのは、自分のストーリーと成果を自分で所有しなければ、誰かに横取りされるということ
    特に大企業では、人気のある人が手柄をさらっていくことが多い
    別にスポットライトを浴びる必要はないが、記録を残すことが重要
    社内ドキュメントや社外発表を通じて、自分の貢献を明確に残すべき

    • こういうことは米国企業に限らず、どんな組織でも似たように起こる
      人気がなければ野球チームでもベンチに座らされるし、大学院入試やMLコミュニティでも同じ
      世の中は一種の人気競争システムのように回っている
    • こうした政治的な構造のせいで、私は会社員生活から離れようとしている
      単に働いて報酬を得る構造ではなく、自己PRが必須なら、いっそ自分の仕事を自分で所有し、コントロールするほうがいいと思う
    • とはいえ、すべてのキャリアがスポットライトを浴びるプロジェクトで作られるわけではない
      私は会社の中で信頼こそが最も重要な通貨だと思っている
      長い時間をかけて複数の成功したプロジェクトに関わっていれば、最終的にリーダーシップはその共通点に気づく
      昇進は遅くても、評判とネットワークが積み上がり、安定した成長につながる
    • FAANGでは、ある段階を過ぎて「rest & vest」状態になると、こうした問題は気にならなくなる
      すでに十分に稼いでいるので、クレジットに関心がなくなる
    • 私も何度か、実力より良い関係のおかげで機会を得たことがあるし、逆に関係が悪くて損をしたこともある
      今はバランスが取れているが、多くの人はそうではないように見える
  • これは本当によく書かれた文章
    「政治が嫌いだ」というニュアンスだけに注目するのではなく、InfraとDevExの政治的構造を理解する必要がある
    私はSlackで5年間インフラPMとして働いたが、プロダクトのローンチプロセスを学んだのは4年目になってからだった
    社内顧客(プロダクトエンジニア)の成功を支援することが核心で、「Shadow Hierarchy」フィードバックが昇進の鍵だった
    こうした社内での成功を最適化すれば、安定性とキャリアの両面で報われる
    ただし、ビジネスの本質を無視できるチートコードではない

    • 中規模の会社でも、こうした社内政治とフィードバック構造は同じように機能する
  • 筆者はプロダクトエンジニアリングとインフラエンジニアリングの評価の違いをうまく捉えている
    ただ、Googleという特殊な環境を前提にした一般化には、やや素朴さも感じる
    市場環境やリーダーシップの優先順位が変われば、自分が積み上げた価値も再定義しなければならない

    • 原文の筆者もその点は認識していた
      自分の文章が普遍的な成功ガイドではないことを強調し、環境が違えば別の戦略が必要だと述べている
    • 別の読者は「そうした指摘はすでに記事の末尾で扱われている」として、ナイーブではないと反論している
  • 大企業では人気投票的な評価がよくある
    「コミュニティリーダーシップ」のような曖昧な基準で評価されることも多い
    しかし、静かに良い仕事をし、他人を助けることこそ本当の価値だと思う

    • VC的な「抽象的価値」とMBA的な「ROIへの執着」の間でバランスを取るのは難しいと感じる
    • 目立たない深い技術作業はしばしば過小評価され、扱いを誤るとシステム全体が崩れるリスクがある
    • 最近はコード品質を評価できないマネージャーが多く、結局は人気で評価が決まってしまう
      エンジニアは堅実なコードと自己PRのどちらかを選ばなければならないジレンマに置かれる
    • 昔は問題を解決したときだけ称賛され、継続的な成果は当然視されていた
      結局、適切なインセンティブ設計こそが組織運営の核心になる
  • 25年のキャリアの大半で2年ごとに転職してきたが、今の会社では4年目になる
    社内プラットフォームを構築しながら実際の顧客課題を解決しており、政治とは無関係にそれが毎日の原動力になっている

    • こうしたボトムアップの成功はまれだが、ひとたび起こればとてつもないエネルギーを与えてくれる
  • インフラとツーリングのエンジニアとして長く同じチームにいたが、この記事の内容は現実によく合っている
    たまにわかりやすい成果もあるが、ほとんどは落ち着いて満足感のある日常的な技術作業

  • 私もプロダクトチームよりインフラチームで働くほうが好き
    リーダーシップの気まぐれに振り回されにくく、技術的完成度に集中できる
    今は中堅企業で、静かに他チームのインフラ改善を進める仕事を楽しんでいる

  • こういう文章で自分の価値を弁護しなければならない状況自体、良い兆候ではない
    もちろん自己PRやカリスマ性が昇進に有利なのは事実だが、世の中をさらに悪くしてまでそうする必要はない
    Wozniakのように黙々と働く人も必要だ

  • 筆者がスポットライトを避けられたのは、すでにStaff Engineerだったからだ
    スタートアップ時代は信頼を得ていたので、わざわざ自分を目立たせる必要はなかったが、BigTechでは政治色が強かった
    私は短期目標として稼いで去るつもりだったが、若いインターンが正当に認められるよう支援することのほうが難しかった
    今は自分のプロジェクト自体が可視性を与えてくれるので、あえて宣伝しなくてもよくなった

    • ただし、これに同意しない人もいる
      GoogleでL3の頃からスポットライトを追わなくても、同僚エンジニアとの共有と協業だけで十分に評価されたという
  • 十分な**資本(社会的であれ金銭的であれ)**を確保できれば3年間は耐えられ、2年目に成果が出れば初期の試行錯誤は忘れられる
    問題は、外したときのリスク

    • もう一つのリスクは、大きな問題を未然に防いでも、その価値を誰にも理解してもらえないこと
      バグのないリリースのために尽力しても、結局は残業して問題を解決した人だけが称賛される現実がある
    • しかし、顧客と十分に対話し、市場の文脈を理解すれば、リスクは下げられる
      もちろん運もあるが、機会は準備した人に訪れると信じている