エンジニアの英語レジュメ：技術の担当範囲と成果を伝える書き方

エンジニアの英語レジュメは、日本語の職務経歴書を一文ずつ英訳しただけでは、技術の担当範囲が伝わりにくくなることがあります。最初に整理したいのは、自分が変えたコンポーネント、判断したこと、確認できる成果です。英語の強い動詞を探すのは、その後で構いません。

目標は、読みやすく、面接で説明できるレジュメです。チーム全体の成果を自分一人の実績にしたり、ローカル実験を本番の売上効果にしたりする必要はありません。この記事では日本語で整理した経験を英語の箇条書きへ変え、根拠を残す方法を、架空の例とともに説明します。

担当範囲がまだ曖昧なら、Explain Your Engineering Ownershipで、自分が決めたこととチームが決めたことを分けて話してみてください。英文添削ではなく、レジュメの主張を口頭で確かめる練習です。

翻訳する前に応募先が欲しい情報を並べる

求人票を読んで、必要な技術だけでなく、任せたい仕事を抜き出します。たとえば「APIの設計と運用」「UIの品質とアクセシビリティ」「データ処理の信頼性」は、同じ技術名の列挙では表現できません。関連する経験を前に出し、関係の薄い業務を短くします。

応募先の地域、役割、指定フォーマットも確認してください。英文レジュメに何を含めるか、何ページにするか、どの形式で送るかは、全ての企業で同じとは限りません。求人の提出条件や応募フォームがあるなら、それを優先します。写真や個人情報を日本語書類から自動的に移すのではなく、必要な項目を確かめます。

技術職なら、職歴やプロジェクトの各項目に「何を担当したか」が見えるようにします。ツールの一覧は補助であり、使っただけなのか、設計・実装・運用したのかを代わりに説明するものではありません。

MIT CAPDのスキル記述ガイドは、活動、プロジェクトの文脈、結果を整理するPARと、読みやすい箇条書きを紹介しています。ここではその考え方を、技術的な担当範囲を加えて使います。採用率やATSの点数を保証する形式ではありません。

一つの実績を「範囲・行動・根拠」に分解する

最初の日本語メモは文章にしなくて構いません。「請求APIのWebhook処理」「重複受信への対応」「自分が実装」「設計方針はリーダーと合意」「リプレイのテスト追加」のように、確認できる事実を先に並べます。

次にチームの成果と自分の行動を分けます。チームでサービスを公開しても、自分が担当したのが一画面なら「サービス全体を設計した」とは書けません。一方で、担当範囲が小さいから弱いとは限りません。どの失敗を防ぎ、どの制約の中で実装したかが分かれば、技術的な判断を示せます。

このメモはレジュメ本文を長くするためではありません。短い英文へ削るときに、どの情報を落としてよいか判断するためです。社内のコードや顧客情報をレジュメに添付せず、公開できる範囲の説明にします。

公開できる個人開発のコードを示す場合は、確認した版を固定すると説明がずれにくくなります。GitHubのパーマリンクの説明では、ブランチ先頭のURLは更新され得る一方、コミットIDを含むリンクは特定の版を指します。ただし、版の固定は自分の貢献や実測結果の証明ではありません。共同作業で何を変更したか、テストをどう行ったかは別に説明します。

動詞は強さより、自分の役割との一致で選ぶ

Implementedは自分が実装した変更、Investigatedは調査、Proposedは提案、Coordinatedは調整を表現する候補です。Ledは、実際に進め方や人をまとめる責任を持った場合に使います。手伝った経験を言い換えるだけでリーダーシップの実績にはできません。

en worldの英文レジュメガイドも行動を表す動詞を紹介しています。ただし動詞の選択は、事実の範囲を変えないことが前提です。大きな言葉へ置き換えるより、対象と変更を具体的にしましょう。

Responsible for backend developmentは担当分野を示しますが、読者には実際の変更が見えません。Improved performanceも、何の性能をどう確かめたかが不明です。後ろに技術をたくさん足すだけでは、この不明点は解消しません。

過去の仕事には過去形、現在継続している仕事には現在形など、期間との整合性も確認します。社内略語や独自の役職名は、外部の人に意味が通じる説明を添えます。ただし正式な職位を、経験より上位の職位へ変更しないでください。

書き換え例1：バックエンドの担当を具体化する

以下の経験、企業、数値は全て説明用の架空例です。そのまま自分の実績として使わず、実際の変更へ置き換えてください。

曖昧な記述：

Responsible for backend development using Java.

変更を具体化した記述：

Implemented idempotent webhook handling for the billing service in Java and PostgreSQL, adding replay and conflict tests.

対象は請求サービスのWebhook処理、行動は実装、根拠はリプレイと競合のテストです。この例は収益増や本番障害ゼロを主張していません。導入済みならその範囲を追記できますが、開発環境の実装なら本番運用に見える表現を避けます。

面接で想定する確認は、What did you implement yourself?、How did you handle duplicate events?、What was outside your scope?です。これに答えられない場合は、英語力より実績の範囲を整理し直す必要があるかもしれません。

チームで方針を決め、自分がテストだけを追加したなら、Added replay and conflict tests for the billing service's webhook handlerの方が正確です。文を大きく見せるより、担当と検証を一致させます。

書き換え例2：フロントエンドの品質を示す

曖昧な記述：

Created user-friendly screens with React.

具体化した記述：

Implemented keyboard navigation and focus restoration for a React settings dialog, with tests for Escape dismissal and return focus.

この文では「使いやすい」という主観を、キーボード操作、フォーカス、検証対象へ変えています。ただしこれだけで全てのアクセシビリティ要件を満たしたとは主張していません。実際に行っていない監査やユーザーテストを追加しないでください。

確認質問は、Where does focus go when the dialog closes?、How did you test keyboard behavior?、Which accessibility requirements did you not verify?です。コードの仕組みと確認範囲を説明できれば、結果に大きな数字がなくても具体的な仕事が伝わります。

デザイン案を提案しただけならProposed、実装を他の人と分担したなら自分の範囲を限定します。個人開発では、プロジェクト欄に試作であることを示し、社内ユーザー数や本番導入を架空に作らないことが重要です。

書き換え例3：数字には母数と観測条件を残す

パイプラインを速くしたという架空の例で、固定した10,000行のデータを同じローカル環境で処理したとします。変更前の5回の所要時間は20、22、18、21、19分、変更後は12、14、10、13、11分です。ここに並べた数値は計算説明用であり、実際に計測したベンチマークではありません。

英語にするなら、次のように観測範囲を残します。

Reduced median processing time from 20 to 12 minutes across five local runs of a fixed 10,000-row fixture by removing repeated parsing.

これはローカルの所要時間の記述であり、本番のコスト40%削減、ユーザー待ち時間40%削減、売上への影響は示していません。また、所要時間の40%減少と処理速度の増加率を混同しないでください。同じ仕事量なら比率の分母が変わりますが、その値を別の業務成果へ転用できるわけではありません。

実際の測定では、入力、機器、キャッシュ、並列度、失敗した実行を含めた条件を確認します。少数回のローカル測定は本番負荷の代表性や因果効果を十分に示さない場合があります。数字を採用する前に、何を比較でき、何を比較できないかをメモしてください。

数字がない成果も、確認できる形にする

信頼できる計測が残っていなければ、百分率を作る必要はありません。テストを追加した、運用手順を公開した、手動の重複作業を一つ除いた、APIのエラー契約を明文化した、といった成果にも対象と完了状態を示せます。

たとえば「品質を向上した」を、Added regression tests for retry and timeout paths in the payment clientへ変えると、何を残したかが見えます。「事故を防いだ」まで言うには、それを裏付ける別の根拠が必要です。まだ承認待ちの提案なら、実装済みの成果に書き換えずProposedを使います。

成果の数を増やすために同じ変更を何行にも分ける必要もありません。二つの箇条書きが同じ能力しか示していないなら、一つを短くし、別の判断や検証が見える経験を選びます。技術、規模、責任、結果のどこが違うのかを読者が理解できるようにします。

ミニレジュメの構成と求人票への対応

次は架空の構成例です。応募先の指定があれば、その形式に合わせます。名前や連絡先には自分の正確な情報を使い、公開版では必要に応じて個人情報を除きます。

EXPERIENCE
Software Engineer | Example Team | 2024–2026
- Implemented idempotent webhook handling for the billing service
  in Java and PostgreSQL, adding replay and conflict tests.

PROJECTS
Settings Dialog Prototype | React, TypeScript
- Implemented keyboard navigation and focus restoration,
  with tests for Escape dismissal and return focus.

SKILLS
Java, PostgreSQL, React, TypeScript

求人票との対応も、単語を機械的に増やすのではなく、根拠とセットにします。

技術欄に載せるものは、使い方や関与した範囲を説明できるか確認します。求人票のキーワードが重要でも、経験のない技術を実務スキルとして足すのは避けてください。「学習中」を示すなら、その欄と具体的なプロジェクトを分ける方法があります。

送る前に英文と実績を別々に点検する

一回目は英語を確認します。動詞の時制、主語を省いた箇条書きの統一、製品名、日付、表記ゆれ、読みにくい長文を見直します。二回目は事実を確認します。自分が実装したのか、共同作業なのか、本番か試作か、数字の分母は何かを一文ずつ点検します。

PDFなど指定された形式へ出したら、文字の選択やコピーで内容が崩れないか、リンクが開くか、連絡先と日付が欠けていないかを見ます。シンプルな形式は確認をしやすくしますが、特定のレイアウトやATSスコアで通過を保証することはできません。

最後に、各箇条書きを英語で短く説明してみます。暗記した文だけでなく、Why this approach?、How did you measure it?、What would you change?へ答えます。説明すると限定条件が増えるなら、その限定がレジュメにも必要か考えてください。

共同作業を説明する際は、The team delivered...とI implemented...を分けて練習できます。チームが達成したことを先に紹介しても、その後で自分の変更を特定すれば責任が明確になります。質問に答えるたび「実は担当していません」と修正するより、最初から正しい範囲を示しましょう。

未経験の領域を聞かれたときの答えも用意します。I tested this in a local prototype, but I have not operated it in production.のように、学んだことと経験していないことを分けます。レジュメに全ての限界を長く書く必要はありませんが、試作を実務に見せる曖昧さは取り除いてください。

PracHubでレジュメの主張を口頭で確かめる

以下は英文添削やATS採点ではなく、書いた経験を面接で説明する練習です。他社・一般の質問を含むため、自分の応募先の問題と同一視しないでください。

まずExplain Your Engineering Ownershipで、最も重要な箇条書きの範囲を説明してみましょう。短い英文から、自分の行動と根拠へ戻れるなら、そのレジュメは面接の会話を始める材料になります。

出典・参考資料

• MIT CAPD：Resumes — Writing about your skills
• en world：英文レジュメの書き方ガイド
• GitHub Docs：Getting permanent links to files