FAANG の履歴書：ビッグテックの採用担当者が見ているもの

FAANG 向けの履歴書（英文レジュメ）とは、より厳しい基準で読まれるソフトウェアエンジニアの履歴書のことです。この頭字語（Meta、Amazon、Apple、Netflix、Google）は Facebook の旧社名よりも長生きし、今ではビッグテック全般を指して使われています。つまり、Google 向け、Microsoft 向け、Stripe 向けの履歴書は、同じふるいにかけられます。そこの採用担当者は長い応募の列をさばいているので、最初の読み方は流し読みです。そして各社は、その流し読みで何を見つけたいのかを公開しています。

私はビッグテックの採用に関わったことはなく、このガイドに内部情報はありません。Google、Meta、Amazon が自社の採用ページで公開していることと、しっかりした ソフトウェアエンジニアの履歴書 の構成をもとに、自分の箇条書きと比べられる架空の例を紹介します。

日本からの応募について一言：日本の定型の履歴書や職務経歴書とは違い、ビッグテックへの応募では英文レジュメを使うのが基本です。写真、生年月日、性別などの個人情報は書かず、1 ページにまとめます。このガイドで説明するのは、その形式です。

ビッグテックの採用担当者が見ているもの（各社の言葉で）

Google の採用ページは、履歴書を「あなたのこれまでの経験とインパクトを知る最初の機会」と呼び、古いファイルを編集するのではなく、職ごとに白紙の文書から始めるよう勧めています。そのページにある具体的な指示は次のとおりです（Google Careers, How we hire）。

• 「スキルと経験を職務内容に合わせてください。自分の仕事を応募資格に直接結びつけてください（データを含めることも忘れずに）。」
• 最低限の応募資格を満たしているか確認し、履歴書でそれが伝わるようにする。
• 「携わった、あるいは管理したプロジェクトについて具体的に書いてください。結果はどうでしたか？ 成功をどう測りましたか？」
• 「リーダーの役割を担ったことがあれば教えてください。チームの規模は？ 仕事の範囲は？」
• 「短くまとめてください。長さの決まりはありませんが、明確で簡潔であることが重要です。」

Meta の採用プロセスのページは、「読みやすい形式で、職歴、スキル、実績が目立つ」履歴書を求め、応募前に最低限の応募資格を確認するよう勧めています。また、採用サイトには応募者 1 人につき 1 つの履歴書しか保存されないと書かれています（Meta Careers, Hiring process）。

Amazon の面接（インタビューループ）のページは、「何が起きるか、どう準備するか」の項目に、リーダーシップ・プリンシプル、行動面接の質問、STAR メソッドを挙げています（Amazon Jobs, Interview loop）。プリンシプル自体は公開されています。「Deliver Results」はリーダーに「ビジネスの重要なインプットに集中し、適切な品質で、適切なタイミングで届ける」ことを求め、「Ownership」は「リーダーはオーナーである」と述べています（Amazon, Leadership Principles）。結果とその測り方が書かれた箇条書きは、面接での STAR 形式の回答の書き出しにもなります。

この 3 社のページをあわせて読むと、ふるいは箇条書きごとの 3 つのテストにまとまります。

規模

規模とは、あなたが取り組んだものの大きさです。Google はリーダーの役割について（チームの規模、仕事の範囲）はっきり尋ねており、同じ問いはコードにも当てはまります。利用ユーザー数、毎秒のリクエスト数、担当したサービス数、処理した金額、チームのエンジニア数、本番での稼働期間。規模のない箇条書きは、週末の趣味のプロジェクトにも、会社全体を動かすシステムにも読めてしまい、採用担当者にはどちらか判断できません。

インパクト

インパクトとは、あなたがいたことで起きた変化です。「検索サービスに携わった」は席に座っていたことしか示しません。「検索の p95 レイテンシーを 600 ms から 180 ms に短縮」は成果です。ビッグテックの求人は一定の規模の課題を説明しており、採用担当者はあなたの過去の成果をその規模と照らし合わせています。

数値

数値とは、その変化を測ったものです。Google のページは「データを含めることを忘れずに」と書き、成功をどう測ったかを尋ねています。数値には基準が必要です。「レイテンシーを 70% 短縮」は「600 ms から」がなければ意味を持ちません。数値はダッシュボード、障害報告、A/B テストの結果、スプリントレビューから得られます。推定値しかない場合は「約」と書き、説明できる範囲にとどめてください。面接官はその数値をどう出したかを聞いてきます。

FAANG の履歴書の箇条書きに使う XYZ フォーミュラ

Google の採用ページにはこう書かれています。「迷ったら『[Y] で測定される [X] を、[Z] を行うことで達成した』というフォーミュラに頼ってください。」面接準備のページでも同じ式を繰り返し、Google は「データが大好き」だと付け加えています（Google Careers, Interview prep）。このフォーミュラは採用ページより前からあります。Google の人事部門（People Operations）を率いた Laszlo Bock が 2014 年の LinkedIn の投稿 で公開し、能動的な動詞で始める、結果を数字で測る、比較のための基準を示す、何をしたかを書く、という助言を添えていました。

エンジニアの箇条書きでは、3 つの枠は次のように対応します。

• X、達成したこと。 システムの変化やユーザーにとっての成果。速くなった、安くなった、信頼性が上がった、ローンチした、移行した、障害を取り除いた。
• Y、測定値。 基準付きの数値。「14 時間から 25 分に」「月 3,000 万件の取引に対して」「12 のサービスにまたがって」。
• Z、方法。 何を、何を使って作ったか。設計上の判断と技術です。キーワードが入るのもこの Z なので、パーサーは「Kafka」や「Terraform」を、それを使ったことを証明する文の中で見つけます。

順番は自由です。成果が際立つなら X から、規模が要点なら Y から、求人が求めている技術が要点なら Z から始めます。大切なのは、重要な箇条書きに 3 つともそろっていることです。

FAANG の履歴書の箇条書きの例（架空）

以下のエンジニアは架空の人物で、会社もすべての数値も作り話です。それぞれのペアは、多くの人が書く箇条書きと、同じ仕事を規模、インパクト、測定値を入れて書き直したものです。例は日本語に訳していますが、実際の英文レジュメでは英語で書きます。

Mateus Ferreira、ソフトウェアエンジニア、Tidewater Analytics（架空）、経験 5 年。

変更前：「データ取り込みパイプラインに携わった。」

変更後：「cron で動くバッチ処理だった取り込みパイプラインを Kafka と Flink によるストリーミング設計に作り直し、インフラ費用を変えずに 1 日の処理量を 4,000 万件から 3 億 1,000 万件のイベントに増加。」

変更前：「API のパフォーマンスを改善した。」

変更後：「集計処理を ClickHouse の事前計算済みマテリアライズドビューに移し、1,900 社の企業顧客向けレポート API の p99 レイテンシーを 2.4 秒から 380 ms に短縮。」

変更前：「オンコールと信頼性向上を手伝った。」

変更後：「合計 99.9% の可用性目標を持つ 6 つのサービスのオンコールを担当。ランブックとアラートルールを作成し、2 四半期で週あたりの呼び出しを約 25 回から 7 回に削減。」

変更前：「ジュニアエンジニアを指導した。」

変更後：「新しいエンジニア 3 名のオンボーディングと指導を担当し、全員が入社 3 週間以内に本番へリリース。チームのコードレビューのガイドラインを作成し、現在 4 チームが使用。」

変更前：「Kubernetes への移行を主導した。」

変更後：「エンジニア 4 名で、22 のサービスを VM ベースのデプロイから GKE 上の Kubernetes へ 7 か月かけて移行するプロジェクトを主導。顧客に影響する障害はゼロ、デプロイ時間は 40 分から 6 分に短縮。」

変更前：「営業チーム向けの社内ツールを作った。」

変更後：「React と FastAPI でセルフサービスの利用状況ダッシュボードを構築し、30 人の営業チームの毎週の手作業によるエクスポートを置き換え。リリースから 1 か月以内に 30 人全員が利用。」

注目すべきパターンが 2 つあります。変更後の版は、技術をリストではなく文の中で挙げています。そして、どれも会社全体の数値を自分のものとして主張していません。それぞれ Mateus が担当した部分を、面接官が掘り下げられる動詞（「作り直し」「担当」「主導」）で主張しています。

数値がない場合

きれいな数値が出ない仕事もあります。リファクタリング、設計レビュー、誰も目にしなかった障害を防いだセキュリティ修正などです。そうした箇条書きには、数値の代わりに規模を書きます。「認証モジュール（11,000 行、3 サービス）をリファクタリングし、共有された可変のセッションキャッシュを除去。変更はフラグの裏でリリースし、60 日間リグレッションなし。」大きさ、影響範囲、期間も立派な測定値です。

1 ページ

Google は長さの決まりはなく、明確で簡潔であることを求めると言っています。ビッグテックの履歴書は、経験 8 年ほどまでは 1 ページが慣例で、各社のページにもそれ以上を勧める記述はありません。2 ページ目は経歴の長いスタッフレベルのエンジニアのためのもので、その場合でも古い職歴は 1 行ずつに圧縮します。

1 ページに収めるには、次の順で削ります。キャリアの目標の文、趣味の行、いちばん古い職歴の箇条書き、職歴ですでに証明しているスキルと重なるプロジェクト、そして規模、インパクト、測定値のどれもない箇条書き。これらを削らずに済ませるために、フォントを 10 ポイント未満にしたり、余白を 0.5 インチ（約 1.27 cm）未満にしたりしないでください。採用担当者は、1 語も読む前に詰め込まれたページに気づきます。

フォームで求められない限り、カバーレターは省きます。Google のページには、同社はカバーレターを求めておらず、その時間を履歴書に使うよう勧めると書かれています。

最低限の応募資格と「履歴書は 1 つ」のルール

Google も Meta も、応募前に最低限の応募資格を確認し、履歴書でそれを満たしていることを示すよう求めています。最低限の応募資格はチェックリストとして扱ってください。各行について、それを証明する箇条書きやスキルの項目を指させるようにします。必須の項目が履歴書から抜けていて、実際の経験には当てはまるなら、追加してください。経験そのものに欠けているなら、足りないのが 1 項目だけで、それ以外が強い場合にだけ応募します。

Google の採用ページによると、応募できるのは 30 日ごとに 3 件までです。ばらまくのではなく、合う 3 件を選んでください。Meta は採用サイトに応募者 1 人につき 1 つの履歴書を保存するので、Meta 向けの履歴書は、同時に応募するすべての Meta の職をカバーする必要があります。そのうちの 1 つではなく、それらの職の重なりがいちばん大きい部分に向けて書いてください。応募ごとに新しいファイルを受け付ける会社なら、1 件ずつカスタマイズします。その方法は 求人内容に合わせて履歴書をカスタマイズするガイド にあります。

リファラル（社員紹介）の扱い方

リファラルは、一般の応募の列ではなく社員の推薦を通じて、あなたの履歴書を採用担当者の前に届けます。履歴書が証明すべきことは変わらず、書類選考や面接を飛ばせるわけでもありません。ファイルを読んでもらうための手段と考え、頼む前にファイルを仕上げておいてください。

• あなたの仕事を見たことがある人に頼みます。 紹介のフォームでは、社員があなたをどう知っているか、同僚と比べてあなたの仕事はどうかを聞かれることがよくあります。元同僚やオープンソースの協力者なら答えられますが、LinkedIn で知り合っただけの人には答えられません。
• 手間をかけさせないようにします。 求人 ID、カスタマイズした PDF、その職に合う理由を 3 行で送ります。紹介者はそれをフォームに貼り付けます。
• 自分でも応募します。 紹介が遅れても応募が存在するよう、同じ履歴書を採用サイトからも提出し、そのことを紹介者に伝えます。
• 1 社につき 1 人に頼みます。 同じ職への複数のリファラルは積み上がりませんし、5 人に頼むと集めているように見えます。
• 結果にかかわらずお礼を伝えます。 リファラルは社員の時間と、わずかながら評判を使ってもらうことです。

FAANG の履歴書で目立つ失敗

チームの数値を自分のものにする。 機能を 1 つ作ったエンジニアが「売上を 40% 伸ばした」と書けば、会話が終わってしまう質問を面接で招きます。自分の担当部分を、適切な動詞で主張してください。

あいまいな動詞。 「手伝った」「参加した」「関わった」は、その場にいたことしか伝えません。「構築した」「担当した」「主導した」「設計した」は、何をしたかを伝えます。

社内用語をそのまま使う。 「Falcon を Hydra に移行」は、前の会社の外では何の意味もありません。「注文マッチングサービスを新しいイベントバスに移行」なら、どこでも意味が通じます。

40 項目のスキル一覧。 どの 10 個なら話せるのか、採用担当者に推測させることになります。今月面接で聞かれても答えられるツールだけを残してください。

証拠の代わりに知名度。 有名な会社の名前は履歴書の助けになりますが、そこでの仕事の規模や数値の代わりにはなりません。

バズワード。 「情熱的」「結果重視」「最先端」「シナジー」。1 ページに入る行数は限られているので、事実に使ってください。

読み取りより見た目を優先する。 アイコン、スキルバー、写真のある 2 段組みのレイアウトは見栄えがしても、解析するとノイズになります。ビッグテックへの応募は、人が見る前に応募者追跡システム（ATS）を通ります。本物のテキストと標準的な見出しを持つ 1 段組みの PDF なら、その過程を無事に通過します。パーサーが探す用語については 履歴書のキーワードガイド で説明しています。

履歴書の残りの部分を仕上げる

FAANG の履歴書を支えるのは箇条書きですが、サマリー、スキル、プロジェクト、学歴のセクションも正しくなければならず、書式は ATS を通過できなければなりません。ソフトウェアエンジニアの履歴書ガイド には、コピーして使える 1 ページのテンプレート、中堅とシニアの架空の完全な例 2 つ、セクションごとの助言があります。この記事は、その上に重ねる、より厳しい基準です。

それぞれ最低限の応募資格が違う複数のビッグテック企業に同時に応募するなら、私が開発している無料のオープンソースツール Resume Matcher が、マスター履歴書を保持し、求人ごとにカスタマイズ版を作ります。すでに使っている AI モデルで自分のマシン上で動き、コードによるチェックが勤務先、役職、日付を固定し、モデルが作り出そうとした数値を元に戻します。これはほかのどこよりもここで重要です。ビッグテックの履歴書にでっち上げた数値があれば、最初の技術面接で明らかになるからです。

役に立ったら

各社は何を見ているかを伝えてくれています。あとは、それに答える箇条書きを書くことです。このガイドやツールが役に立ったら、GitHub の Resume Matcher にスターを付けていただけると、ほかのエンジニアが見つけやすくなります。私、Saurabh Rai は GitHub、X、LinkedIn でフォローできます。