大手広告プラットフォーム開発で見えた、エンジニアキャリアの天井と抜け道
エンジニアキャリアを3〜4年積んでくると、「次にどこに行くか」という選択が出てくる。スタートアップで裁量を取りに行くか、メガベンチャーで大規模システムを学ぶか、フリーランスで単価を上げるか。どこに行っても得るものと失うものがある。
私自身は、フロントエンドメインの会社員として2年弱、その後フリーランスとしてフロント・バック両方を2年弱経験した後、大手広告プラットフォームの開発にフルスタックエンジニアとして入社した。そこで2年半働いて退職した今、その経験を振り返ると「得ようとして得られたものは確かにあった。同時に見えてしまった天井もあった」というのが率直な総括だ。
この記事では、大手広告プラットフォーム開発の現場で実際に得られたものと、長期的に見たときに見えてしまう構造的な天井について書く。同じキャリアパスを考えているエンジニアの判断材料になればと思う。
なぜ「広告プラットフォーム」を選んだか
入社前から、私はこの会社を「インフラ経験を積む踏み台」として明確に意識していた。
フリーランスでフロントとバックは触ってきたが、AWS の新規構築や大規模トラフィック設計といった経験は、個人の案件ではどうしても積めない。そういう「規模がないと触れない経験」を意図的に取りに行きたかった。
つまり、「ここで定年まで働く」ではなく、「2〜3年で必要なものだけ取って次に行く」という前提で入社した。これがその後の判断軸を最後までブレさせなかった要因だと思う。
想定通り得られた3つの経験
入社して、想定通り得られたものが3つある。
1. 大規模トラフィックを捌く経験
これは中小規模のサービスでは絶対に得られない経験だ。秒間数千〜数万リクエストが飛んでくるシステムをどう設計し、どこにキャッシュを置き、どうスケールアウトさせるか。机上で読む本と、実際にプロダクション環境で運用するのとでは情報量が桁違いに違う。
RDS の負荷を逃がすための Read Replica 設計、CDN とオリジンサーバーの責務分担、CloudWatch アラートの閾値設計といった「規模が大きくなって初めて必要になる知識」は、ここでしか身につかない。
2. AWS の新規構築経験
既存の AWS 環境をいじる経験はどこでも得られるが、ゼロから設計して構築する経験は希少だ。VPC 設計、サブネット分割、IAM 設計、CI/CD パイプライン構築。設計判断のひとつひとつが後から効いてくることを、実感として理解できた。
これは退職後にフリーランスとして再独立した時の単価交渉で大きく効いた。AWS 新規構築経験者という肩書きは、SaaS 連携や中小規模の構築案件で確実にプラスになる。
3. フルスタックエンジニアとしての横断視点
フロント → API → DB → インフラまで全レイヤーを見る経験を積めたことで、設計の質が上がった。「フロントから見た API 設計」「インフラから見たアプリケーション設計」のような視点は、特定レイヤーに閉じこもっていると育たない。
意外な「抜け道」だった
ここまでが入社前から取りに行こうとしていたもの。むしろ私が驚いたのは、「この経験が積める職場の転職難易度が、想定より低かった」ことだった。
大手広告プラットフォーム＝メガサービス＝難関、というイメージがあるかもしれないが、実際にはそうでもない。理由はいくつかある。
- 広告ドメインはエンジニアに人気が低い：BtoC 感が薄く、応募者から避けられがち - 使用技術がレガシー：モダンな技術が好きなエンジニアは寄ってこない - 絶対的な人手不足：大規模システムを維持する人員が常に足りない
つまり、「メガサービスを動かす経験は欲しいが、流行の技術スタックにこだわらない」エンジニアにとっては、入りやすい狙い目だった。同じスキルで FAANG 系や有名メガベンチャーを狙うより、明らかに勝率が高い。
私はこの構造を理解した上で動いていたので、結果的にこの抜け道を効率的に使えた形になる。
見えてしまった3つの天井
ただし、入って2年が経つ頃には、明確な天井が見えていた。
天井1：エンジニアの年収が伸びにくい
広告プラットフォーム業界に共通する構造的な問題かもしれない。エンジニアの市場価値とは別の基準で給与テーブルが決まっており、外から入ってきた人間が頭一つ抜けるレンジまで上がるには相当な時間がかかる。
具体的な数字は伏せるが、同等スキルセットのエンジニアがメガベンチャーや外資系で得られる年収と比較して、おそらく100〜200万円の差はあった。フリーランスとして時給ベースで動いた場合との比較では、その差はさらに広がる。
天井2：技術スタックがレガシー
社内で使われている技術が10年前から大きく変わっていなかった。レガシーであること自体は悪ではない。安定して動いているシステムを書き換える理由はないからだ。問題は、社内文化として「新しい技術へキャッチアップすることへの意識が薄い」ことだった。
エンジニア個人が新しい技術を学ぼうとしても、業務で触れる機会がない。社内勉強会も少ない。これが2年、3年と続くと、市場価値という観点では明確にマイナスに振れる。「いる間は安定だが、出た時に困る」というタイプの環境だ。
天井3：AWS の利用範囲が限定的
これも盲点だった。AWS を新規構築できる現場ではあったが、使われているサービスは基本的なものに限られていた。EC2/ECS、RDS、CloudFront、S3、CloudWatch といったコアサービスには触れるが、Lambda の本格活用や Aurora Serverless、Step Functions による複雑なワークフロー設計といった応用的な使い方を学ぶ機会はほぼなかった。
「AWS をやった」と言える状態にはなるが、「AWS で複雑な要件を解ける」状態にはならない。
2年半で辞めた判断
入社時点で「インフラを経験する踏み台にする」と決めていたので、必要な経験を得られた段階で退職することは予定通りだった。AWS の新規構築を一巡終え、本番運用のトラブルシューティングも何度か経験した時点で、ひとつの区切りとした。
辞めた今、振り返って判断は正解だったと思っている。理由は単純で、辞めた後の市場価値の伸びが、その会社に残っていた場合のキャリアより明らかに大きかったからだ。
現在は時給6000円を超える単価でフリーランスとして動いており、フロント・バック・インフラのフルスタックで仕事を受けられる状態になっている。これは大手広告プラットフォーム時代の経験がベースにあるからこそ取れた単価だ。経験を「取りに行く期間」と「売る期間」を意識的に分けたことが、結果的に効いた。
同じキャリアパスを考えている人へ
3〜4年目あたりのエンジニアで、「次のキャリアステップで何を取りに行くか」を考えている人に伝えたいことが3つある。
1. 「学べる経験」を明確に決めてから入る
漠然と入ると、業務に飲まれて目的を見失う。「大規模トラフィックの設計」「AWS 新規構築」「特定のドメイン知識」など、具体的に何を取りに行くかを言語化してから入ること。私の場合は「AWS 新規構築」と「大規模トラフィック経験」の2つだった。
2. 出口戦略を最初から設計しておく
「2〜3年で○○の経験を積んだら次に行く」と決めておくと、判断軸がぶれない。会社の居心地が良くなってきた頃に「もう少し残ろうかな」となるのが一番危険なパターンで、これを防ぐためには入社時点で出口を決めておくしかない。
3. レガシースタックの会社に長居しない
レガシースタックの会社に長くいると、市場価値が静かに毀損する。これは数年単位で気づかないうちに進行するので、定期的に外の市場（スカウト、エージェント、転職サイト）に自分の価値を晒して確認するべき。