
ついに、目を見張るような報酬パッケージと、その上部に権威あるロゴが入ったオファーレターを受け取ったとき、私は成功したと感じました。サービス会社で何年も働き、その後、プロセスが比較的単純で期待が明確な中堅テクノロジー企業に勤めた後、私は約束の地、つまり FAANG 企業のシニア エンジニア職へと向かっていました。
最先端の技術、優秀な同僚、何十億もの人が使用する製品に取り組むというビジョンが私の頭の中で踊っていました。無料のグルメランチを食べながら技術的な深い議論を交わし、世界を変えるような複雑なエンジニアリングの問題を解決することを想像していました。
5 年経った今も私はここにいますが、私の経験は... 予想とは違っていました。必ずしも悪いというわけではなく、多くの点で良いのですが、私が想像していたものとは明らかに違います。もし誰かが、私が仕事を始める前に、実際の仕事の「一日」のビデオを見せてくれたら、私は彼らが私にまったく間違った役割を見せていると思ったかもしれません。
あなたがテクノロジー大手で上級職を目指しているなら、その仕事を始める前に誰かが私に言って欲しかったことをここに記します。
最初の課題はオンボーディング中に発生しました。社内のツール環境は広大かつ高度で、学習すべきカスタム構築システムが数十個ありました。
運用データに対してクエリを実行したり、簡単な構成変更を行ったりしたいですか? 多くの場合、複数のシステムや承認プロセスを操作したり、異なるタイムゾーンのチームとの調整が必要になることがあります。
忘れられないある日、私は自分のチームが所有するサービスの許可ワークフローに数時間を費やしました。そのプロセスは徹底したもので、セキュリティと説明責任を考慮して設計されていましたが、新人にとっては間違いなく学習曲線でした。
忘れられないある日、私は自分のチームが所有するサービスのログを表示する許可を得るために 4 時間も費やしました。承認ワークフローは、あらゆる再帰関数が嫉妬するような循環参照を経由しました。
もちろん、ドキュメントはあります。数千ページに及ぶドキュメントで、そのほとんどは時代遅れです。私は最初の 3 か月を、頭字語の学習 (最後に数えたところ、社内 TLA は 347 個ありました) と、作業中のシステムに関する正確な情報がどの wiki にあるかを調べることに費やしました。社内ツールが 1995 年に設計されたように見える一方で、一般向けには洗練された直感的な製品を構築するという皮肉な状況は、私にはよくわかっていました。
入社したとき、私はほとんどの時間を難しい技術的問題に取り組むことに費やすつもりでした。実際には、コードの作成に約 20% の時間を費やしています。残りは? 会議、ドキュメント作成、レビュー、計画、政治です。
シニア エンジニアとしての価値は、どれだけコードを書いたかではなく、どれだけ他の人を支援し、組織をうまく動かして物事を成し遂げたかで測られます。私は、自分自身をコード プロデューサーとしてではなく、力の増幅役として捉える考え方にすぐに切り替えなければなりませんでした。
FAANG 企業は、理論上は比較的フラットな階層構造を持ち、エンジニアリングのレベルもシンプルです。しかし、実際には、非公式の権力構造が複雑に絡み合っています。
初期の頃から在籍しているエンジニアもいます。彼らはキャリア ラダーではあなたと同じレベルかもしれませんが、設計レビューでは彼らの意見が 10 倍の重みを持ちます。戦略的なプロジェクトに取り組んでいる「注目度の高い」チームと、重要なインフラストラクチャを稼働させているがあまり注目されていない「メンテナンス」チームがあります。
シニア エンジニアの肩書きは、所属するチームや組織によって大きく異なる意味を持つことがすぐにわかります。消費者向け製品チームのシニア エンジニアは、クラウド インフラストラクチャや ML システムのシニア エンジニアとは根本的に異なる課題に取り組んでいる可能性があります。
私は、アーキテクチャの優雅さと革新的なソリューションを夢見て入社しました。モノリシックなレコメンデーション エンジンをスケーラブルで保守可能なものに置き換える、美しいマイクロサービス アーキテクチャを計画していました。GraphQL とイベント ソーシングを広める準備もできていました。技術スタックの近代化に関するプレゼンも練習していました。
そして現実が突きつけられました。企業が実際に気にしているのは、ビジネスに影響を与える指標なのです。
一貫性のあるハッシュと確率的データ構造を使用した巧妙なアルゴリズムでレイテンシを 5 ミリ秒短縮しましたか? アーキテクチャ レビュー委員会はメールをチェックしながら丁寧にうなずきました。ボタンを緑ではなく青にする単純な CSS 変更でクリックスルー率が 0.1% 増加しましたか? 突然、経営陣が私のデスクの周りに潜んで、毎日の最新情報を尋ねてきました。
当社が最近最も称賛した「イノベーション」の 1 つは、文字通り、ボタンをページ上で 20 ピクセル上に移動したことでした。これにより、四半期の収益が 1 億 4,000 万ドル増加しました。この変更を A/B テストしたエンジニアは、重要なインフラストラクチャのリファクタリングに数か月を費やした人々よりも早く昇進しました。
私が観察した中で最も成功しているエンジニアは、必ずしも最も優秀なエンジニアというわけではありません。彼らは、リーダーシップにとって重要な指標 (通常は MAU、維持率、収益) を理解し、それに徹底的に注力しているエンジニアです。
スタートアップでは、大規模なゼロからの書き直しや劇的な変更に慣れていました。FAANG では、段階的な改善こそが成功の鍵であることを学びました。
大規模で抜本的な変更はリスクがあり、政治的にも困難です。成功するエンジニアは、大規模な改善を、独立して出荷できる一連の小さく安全な変更に分解できる人です。華やかさは劣りますが、はるかに効果的です。
これはおそらく私にとって最大の発見でした。自分の作品について説得力のあるストーリーを語る能力は、作品そのものよりも重要である場合が多いのです。
技術リーダーがインパクトとビジネス価値に関するストーリーを巧みに作り上げたために、平凡なプロジェクトが称賛されるのを見たことがあります。逆に、エンジニアがなぜ誰も気にかけるべきなのかを説明できなかったために、画期的な技術的成果が無視されるのを見たことがあります。
技術的な作業をビジネスへの影響ストーリーに翻訳することを学ぶことは、私が身につけた最も重要なスキルです。
おそらく最も直感に反する教訓は、技術的に優れているだけでは、自分が望む場所にたどり着けないということに気づいたことです。以前の会社では、最高のエンジニアであることだけで十分でした。FAANG では、会社の理念を体現しながらも、経営陣と強い関係を築いたエンジニアこそが、本当に成功するエンジニアであることがわかりました。
これは、イエスマンになることや、ネガティブな方法で政治的駆け引きをすることを意味するものではありません。ディレクターやプリンシパル エンジニアは、異なる制約のある異なる現実の中で活動していることを理解することを意味します。彼らは、組織の優先事項、人員数の戦い、四半期ごとのビジネス レビューを両立させている一方で、あなたはデータベース スキーマの移行について心配しています。
私は、自分のプロジェクトについて話し合うためではなく、ディレクターの課題を理解するために、ディレクターと毎月コーヒーを飲むようにしました。私は、彼女の四半期ごとのプレゼンテーション用の技術的なスライドを作成するよう申し出ました。経営陣が新しい取り組みを発表したとき、私はチームの仕事をそれらのより広範な目標に結び付け、それを会社の価値観の観点から組み立てるよう努めました。
その結果、重要なプロジェクトにオーナーが必要になったとき、私の名前が挙がりました。組織再編が起こったとき (いつも起こります)、私のチームの権限は拡大しました。そして、物議を醸す技術的な決定についてサポートが必要になったとき、私の判断を信頼してくれるリーダーシップ レベルの仲間がいました。
自己宣伝的にならずにリーダーの目に留まることは、一種の芸術です。重要なのは、自分の能力をアピールしながら、真に価値を付加することです。「発見」されるのを待つのではなく、組織の技術面とビジネス面の両方を理解している人物として積極的に自分を位置づけてください。
私は、最も多くのコードを書いたり、最も賢い解決策を考え出したりするヒーローになろうとするのをやめました。その代わりに、周りのみんなの効率を高めることに集中しました。
より優れたドキュメントを作成しました。一般的なタスクを自動化するツールを構築しました。ジュニアエンジニアの指導に時間を費やしました。プロセスのボトルネックを特定して修正しました。
こうした貢献がパフォーマンス指標に直接現れることはめったにありませんが、チーム全体をより良くする人物としての評判が生まれます。これは上級レベルでははるかに価値があります。
私は人間関係の構築を仕事の邪魔ではなく、仕事の一部として捉えるようになりました。他のチームのエンジニアと定期的にコーヒーを飲みながら雑談をするようにしました。部門横断的な取り組みに自発的に参加し、他のチームが何に取り組んでいるか、自分のチームの仕事が彼らにどう影響しているかを必ず理解するようにしました。
プロジェクトや設計上の決定についてサポートが必要になったとき、見知らぬ人を説得する必要はなくなり、すでに関係を築いている人々に連絡を取ることができるようになりました。
スタートアップでは、私はすべてに「はい」と言っていました。それが、リソースが限られた環境で生き残る方法です。FAANG では、すべてに「はい」と言うことは、燃え尽き症候群と凡庸さにつながります。
私は、可視性、影響、そして自分のキャリア目標と会社の優先事項の両方との整合性に基づいてリクエストを評価することを学びました。私は、「それは今のところ私の時間を最も有効に使う方法ではありませんが、代わりにできることはこれです...」と自信を持って言えるようになりました。
この選択的なアプローチにより、本当に重要な仕事に集中することができました。
私が知る最も尊敬されている上級エンジニアには、専門分野があります。彼らは、単にあらゆることに優れているというわけではありません。彼らは「パフォーマンスの専門家」や「信頼性の第一人者」、あるいは「スケーリングの専門家」です。
私は分散システムの可観測性に関する専門知識を意図的に開発しました。私はチームの Prometheus と OpenTelemetry の達人となり、実際に意味のあるカスタム Grafana ダッシュボードを構築し、信号対雑音比を改善しながら可観測性コストを 72% 削減するトレース サンプリング システムを作成しました。
この専門分野のおかげで、私は大規模システムのアーキテクチャレビューに引き込まれ、運用中に問題が起こったときに頼りにされる存在になりました。私のポケベルは頻繁に鳴るかもしれませんが、私はスプリントバックログの一番上にあるチケットだけでなく、本当に興味のある課題を解決しています。
最初はカルチャーショックを受けましたが、FAANG での生活には予想外の利点があることに気付きました。
5年経った今、私はまた同じ選択をするでしょうか?もちろんです。ただし、より現実的な期待を持って。
この仕事は、毎日 2,000 行の完璧なコードをコミットするコーディング ヒーローになることでも、次の革新的なシステムを設計する孤独な天才になることでもありません。会社の巨大な規模を活用してインパクトを生み出すことです。技術的、組織的、人的といった複雑さを乗り越えて、何億人もの人が使用する製品を出荷することです。
FAANG 企業で上級職に就くことを考えているなら、目を覚まして臨んでください。課題は予想していたものとは異なるでしょう。IDE よりも設計ドキュメントに多くの時間を費やすことになります。時折企業用語のように聞こえるとしても、会社の方針に精通する必要があります。GitHub への貢献度グラフはまばらに見えても、影響力はあらゆるところに及ぶという、新しい成功の定義を学ばなければなりません。
しかし、適応できれば、他では習得できないスキルを身に付けることができます。自分の仕事が何百万ものユーザーに影響を与えるのを見る満足感は本物です。そして、外交官、建築家、コーチの要素を併せ持つ自分の実際の役割が、想像していた純粋に技術的な役割よりも興味深いことに気づくかもしれません。
著者は、分散システムの可観測性を専門とする FAANG 企業のシニア ソフトウェア エンジニアです。サービス企業と中堅テクノロジー企業で働いた後、5 年前に FAANG に入社し、構造化環境での経験を積んだ後、テクノロジー大手の複雑な分野に飛び込みました。