FAANG向けソフトウェアエンジニア職務経歴書の書き方

FAANG（Google、Amazon、Apple、Netflix、Meta）やその他の大手テック企業への応募は、一般的なSWEの転職活動とは根本的に異なる。採用担当エンジニアが1通の職務経歴書を見る時間は平均6〜7秒とされており、その短時間で「このエンジニアはスケールの大きな問題を解いた実績がある」と伝えなければならない。

なぜFAANG向け職務経歴書は一般的なものと違うのか

一般企業の採用では「何をやったか」が重視される。FAANGでは「どの規模で、どれだけの影響を与えたか」が問われる。同じ「検索機能を改善した」という経験でも、「月間アクティブユーザー2000万人のプラットフォームで検索レイテンシを40%削減した」と書くのとでは、評価が大きく変わる。

もう一つの違いはコードレビューや設計への関与度だ。FAANGのリクルーターとエンジニアリングマネージャーは、個人の技術的貢献と、チームやシステム全体への波及効果を区別して読む。ミッドレベル（L4〜L5相当）であれば、自分が書いたコードだけでなく、他のエンジニアの生産性や、システムの信頼性にどう貢献したかを示す必要がある。

ATSの通過も無視できない。ATSがどのように職務経歴書を解析するかを理解した上で、テーブルや複数カラムのレイアウトを避け、シンプルな構造を維持することが前提になる。

インパクト優先の箇条書きフォーミュラ

FAANGの採用基準に合わせた箇条書きは、次の構造を基本にする。

動詞 + 何をしたか + 規模・スコープ + 定量的な結果

具体例を見てみよう。

• 悪い例：「マイクロサービスアーキテクチャの設計と実装を担当した」
• 良い例：「Go製マイクロサービス5本を設計・実装し、モノリスからの移行によりデプロイ頻度を週1回から1日12回に向上させた」

数字が出せない場合でも、スコープを明示できる。「社内の3チーム・エンジニア20名が利用するCI/CDパイプラインを構築した」という書き方は、規模感を伝えつつ定性的な貢献を示す。

使う動詞にも注意が必要だ。「担当した」「携わった」は受動的に聞こえる。「設計した」「実装した」「削減した」「移行した」「標準化した」など、能動的かつ具体的な動詞を選ぶ。

何を強調し、何を削るか

強調すべき要素

• 分散システム・大規模インフラへの貢献：Kubernetes、Kafka、Spanner、DynamoDBなど、FAANGが実際に使うスタックへの経験は明記する
• オーナーシップの範囲：自分が設計のリードを取ったのか、実装のみ担当したのかを区別して書く
• 信頼性・パフォーマンス指標：SLO達成率、P99レイテンシの改善、エラーレート削減など
• オープンソースへの貢献やRFC・設計ドキュメントの執筆：技術的影響力を示す材料になる

削るべき情報

1ページに収めることがFAANGでは事実上の標準だ（経験10年超であれば2ページも許容される）。職務経歴書の枚数に関する考え方を参考にしつつ、以下は積極的に削る。

• 5年以上前の職歴の詳細な箇条書き（社名・役職・在籍期間だけ残す）
• 現職と関連性の低いスキル（例：現在バックエンドエンジニアなのにFlashやCOBOLの記載）
• 「チームワークを大切にしています」のような主観的な自己PR文
• 取得年が古く、更新されていない資格（AWS認定などは有効期限内のみ記載）
• 趣味・特技欄（スペースの無駄）

強調すべきプロジェクトと技術スタック

FAANGのエンジニアリングチームは、特定のフレームワークよりも「問題解決のアプローチ」と「スケールへの対応経験」を重視する。とはいえ、ポジションのJDに登場する技術は必ず職務経歴書に反映させる必要がある。職務経歴書をJDに合わせてカスタマイズする方法を活用し、応募ごとにスキルセクションと箇条書きを調整する作業を習慣にしよう。

サイドプロジェクトは、業務経験を補完する形でのみ記載する。GitHubのスター数やフォーク数、実際のユーザー数など、外部から検証可能な指標があれば有効だ。「個人開発でTodoアプリを作りました」は削除対象だが、「OSSライブラリをリリースし、GitHub Stars 800超、月間ダウンロード1.2万件」は残す価値がある。

技術スタックのセクションは、カテゴリ別に整理する。

• 言語：Go, Python, Java, TypeScript
• インフラ・クラウド：AWS (EC2, Lambda, RDS), GCP, Terraform
• データ：PostgreSQL, Redis, Kafka, BigQuery
• ツール：Docker, Kubernetes, GitHub Actions

スキルを羅列するだけでなく、職務経歴の箇条書きの中で実際に使用した文脈を示すことで、リクルーターが「この人は本当に使える」と判断しやすくなる。

よくあるFAANG向け職務経歴書の失敗

責任を書いて成果を書かない：「〜の開発を担当」という記述は、何も解決していない。必ず結果を添える。

スコープが曖昧：「大規模システム」「高トラフィック環境」という表現は具体性がない。DAU、QPS、データ量など、実際の数字を使う。

テンプレートのままのサマリー：「情熱的なエンジニアです」という書き出しは即座にスキップされる。サマリーを書くなら、職務経歴書のサマリーの書き方を参考に、技術的な専門性と規模感を1〜2文で凝縮する。

ATSを意識しないフォーマット：PDF変換後に文字化けするフォント、テーブルレイアウト、ヘッダー・フッターに埋め込んだ連絡先情報はATSに読み取られないことがある。ATSフレンドリーなテンプレートを使い、パース精度を上げておく。

全応募先に同じ職務経歴書を送る：GoogleのSRE職とMetaのバックエンドエンジニア職では、求めるスキルセットが異なる。AIを活用した職務経歴書最適化を取り入れ、カスタマイズの工数を減らしながら精度を上げることが現実的な対策になる。

最終確認チェックリスト

提出前に以下を確認する。

• [ ] 全ての箇条書きに動詞＋規模＋結果が含まれているか
• [ ] 1ページ（または経験10年超なら2ページ）に収まっているか
• [ ] JDのキーワードがスキルセクションと箇条書きに反映されているか
• [ ] テーブル・カラム・特殊フォントを使っていないか
• [ ] 連絡先情報がヘッダーではなく本文に記載されているか
• [ ] GitHubプロフィールのURLが最新の状態か

FAANGへの応募は競争率が高く、書類選考の基準も厳しい。しかし職務経歴書の構造と記述の精度を上げることで、同じ経験でも評価は大きく変わる。