英文レジュメの実績（Bullet Points）の書き方：弱い例と改善例

英文レジュメの実績ブレットは、**Action（何をしたか）＋Scope（誰・何を対象にしたか）＋Result（何が変わったか）**の三要素で組み立てるのが基本です。必要に応じてConstraint（制約条件）を加えます。この整理は、実務家キャリア戦略の英文職務経歴書で実績を伝える方法でも紹介されています。売上のような分かりやすい数字がなくても、ScopeとResultを事実で具体的に書けば、実績として読めるブレットになります。

この記事の共通原則（以降の各例では繰り返しません）

• 書くのは、前提として確認できている事実だけです。数字・範囲・顧客・成果を足して強く見せることはしません。
• Resultが確認できないブレットは、実績ではなく担当業務の説明です。完成した実績として扱わず、「その結果、何が変わったか」を自分に追加で質問して確認します。
• 動詞は、実際の関わり方に合うものを選びます。自分の役割を説明できない動詞は使いません。

実績ブレットの基本の型と文法

三要素を1項目に収めたときのイメージは次のとおりです。

文法や書き方については、本稿では読みやすさのため、次の3点を推奨します。公的な規則ではなく、編集上の方針です。

• 動詞から始め、主語の「I」は置きません。完了した施策や実績は過去形、現在も続いている担当業務は現在形で書きます。現職の実績でも、完了していれば過去形にします。
• ブレット1項目につき、中心となる実績は一つにします。「AをしてBもしてCもした」と詰め込むと、どれが成果か分かりにくくなります。
• 「very」のような主観的な副詞で強さを出そうとせず、事実で伝えます。

職務経歴書の一文をそのまま訳すのではなく、この型に作り直すという考え方は職務経歴書を英語にする方法で詳しく扱っています。

弱い例と改善例

（前提：経費精算の承認フローを自分が見直し、経費申請書の必須記入項目を統一した。その結果、経理から修正のために差し戻される申請が減った。件数は記録していない）

弱い例：Responsible for expense approval process.

改善例：Revised the expense approval workflow and standardized required fields on expense claim forms, reducing the number of expense claims returned by Accounting for correction.

改善例は、前提にある事実（見直した、項目を統一した、修正のための差し戻しが減った）を並べ替えただけです。何が、誰から、何のために差し戻されたのかまで書くと、読み手は成果を取り違えません。

「Responsible for」を避けたい理由と、動詞の選び方

「Responsible for」や「In charge of」が禁止というわけではありません。ただ、これらは「担当だった」という立場を示すだけで、何をして何が変わったかが伝わりません。本稿では、実績ブレットには「担当範囲」より「自分の行動と状態の変化」を書くことを勧めます。

注意したいのは、機械的な言い換えです。「担当した」を「Directed」や「Spearheaded」に置き換えると、実際の権限より大きく見せてしまうことがあります。強い動詞を並べれば評価が上がる、という前提で動詞を選ぶことはお勧めしません。判断の軸は、動詞の強さではなく実態との一致です。

調整しただけなのに Managed を使うと、管理責任まで負っていたように読まれかねません。迷ったときは、実態に近い Coordinated や Supported を選びます。動詞の候補を広げたいときはアクション動詞の一覧も参考になります。

売上の数字がない職種の実績の書き方

数字は売上や利益だけのものではありません。先ほどの解説ページでは、数字を使える切り口として次の4つが挙げられています。

• 規模：チーム人数、予算、地域、顧客
• 変化：増減率、差異
• 速度：期間短縮、処理時間
• 品質・リスク：誤り率、損失回避

数字は、手元に根拠がある範囲で使います。次のように、前提に事実があるときだけ書けます。

（前提：受注処理に5日かかっていたものを、2日に短縮した実績がある場合）

例：Reduced order processing time from 5 days to 2 days.

根拠を説明できない推測値は記載しません。概算を使う場合は、算定方法を説明でき、approximately や about など概算と分かる表現にします。問題は数字そのものではなく、根拠と表示の仕方にあります。

では、数字で表せない仕事はどうするか。同じページでは、数値化できない成果は「導入した」で終わらせず、判断や状態の変化（誰が何を判断できるようになったか、承認の手戻りがどう変わったかなど）で具体化するよう説明されています。人事・総務・法務・エンジニアの例で見てみます。

人事（前提：入社時のガイドを新規に作成した。配属先のマネージャーが、新入社員の初日からガイドに沿って動けるようになった）

弱い例：In charge of onboarding.

改善例：Created an onboarding guide that gave line managers a documented process to follow from each new hire’s first day.

総務（前提：備品の発注依頼を紙の申請からワークフローに移した。承認の手戻りが減った）

弱い例：Handled office supply orders.

改善例：Moved office supply order requests from paper forms to a workflow system, reducing rework in the approval process.

法務（前提：契約書レビューで法務確認が必要な条項のチェックリストを作成した。営業と法務の間の差し戻しのやり取りが減った）

弱い例：Responsible for contract review.

改善例：Created a checklist of contract clauses that require Legal review, reducing back-and-forth between Sales and Legal.

エンジニア（前提：夜間バッチ処理の障害対応手順を、Runbookとして新規に作成した。元の担当者以外のメンバーも一次対応ができるようになった）

弱い例：Worked on batch job maintenance.

改善例：Created a runbook for nightly batch failures, enabling additional team members to provide first-line response.

既存のRunbookに手順を書き足した場合は、事実に合わせて動詞と対象を変えます。

例（既存のRunbookに追記した場合）：Added response procedures to the existing runbook for nightly batch failures, enabling additional team members to provide first-line response.

いずれも「誰が何をできるようになったか」「どの工程の手戻りがどう変わったか」が1項目で見えます。

なお、「すべてのブレットに%や金額を入れなければならない」と考える必要はありません。本稿で参照した資料は、すべてのブレットへの数値記載を要件としていません。ハーバード大学のキャリア支援ガイドは、レジュメを具体的で事実に基づく表現にし、結果を示すよう勧めている、とこちらの記事で紹介されています。数字がなくても、具体的で事実に基づく行動と結果は示せます。

機密情報を開示できない場合と、チームの成果を切り分ける場合

金額や顧客名が出せないとき

NDAや社内規程によって、顧客名や金額を出せない場合があります。社外に出してよい範囲は、まず会社のルールや契約で確認します。業界や顧客の種類も、契約によっては開示できません。公開してよいと確認できた情報だけを使い、出せない部分は、事実として言える範囲に置き換えます。

（前提：取引先名と金額は非公開。取引先が製造業であることは公開してよいと確認できている。見積作成の手順を見直し、作成にかかる時間が短くなった。具体的な短縮幅は公開できない）

弱い例：Prepared quotations for Company X, worth a large amount.

改善例：Revised the quotation process for a manufacturing client, reducing the time required to prepare quotes.

固有名詞や金額の代わりに、公開可能と確認できた業界・顧客の種類・対象範囲を使います。「large」のように根拠のない形容は、金額の代わりになりません。

チームの成果を個人の貢献として切り分けるとき

次の3つを自分に問うと、書ける範囲が見えてきます。

1. 自分が決めたこと（判断・設計）は何か
2. 自分が実行したこと（手を動かした範囲）は何か
3. 他の人を支援しただけのことは何か

「検証を担当した」だけでは担当業務の説明にとどまります。その検証で何が分かり、誰が何を判断できたのかまで確認できて、はじめて実績ブレットになります。

（前提：チームでシステム移行を行った。自分は移行後のデータを移行元と照合する検証を担当し、不一致を洗い出した。その結果をもとに、チームが本番稼働に切り替えるかどうかを判断できた）

弱い例：Migrated the company’s system with my team.

改善例：Validated post-migration data against the source system during a system migration project, identifying mismatches so the team could make the go-live decision.

「自分一人でやった」と読める書き方は避け、チームでの取り組みであることと自分の担当部分を並べて書きます。チームの人数を添えるなら、事実として確認できるものに限ります。実績の深掘りへの答え方は、STAR法の解説で準備できます。

応募先のJDから、残す実績と削る実績を選ぶ

実績ブレットは、棚卸しした経歴をすべて並べるものではありません。JDの読み方そのものは英文Job Descriptionの読み方に譲り、ここでは、書ける実績候補の中から何を前に出すかの選び方に絞ります。

1. 棚卸しした実績候補を、JDの業務内容・必須要件と一つずつ対応づける
2. 対応する実績を前に置く。関連の薄いものは短くするか、1項目にまとめる
3. 対応する実績がない要件は、無理に作らない。未達の要件としてどう受け止めるかはRequiredとPreferredの違いで整理できる

表現をJDの語彙に寄せてよいのは、自分の実際の経験と同じ意味のときだけです。

JD：Manage vendor contracts and coordinate with Legal on renewals.

（前提：自分は取引先との契約更新の案件を担当し、更新時の確認事項を法務と事前に調整していた。その結果、法務の確認待ちで更新手続きが止まることが減った）

例：Coordinated with Legal on review points for vendor contract renewals, reducing the number of renewals delayed pending Legal review.

JDの動詞（coordinate）と実際の関わり方が一致し、Resultも確認できているので、JDの語彙を使えます。一方、自分が法務への「依頼窓口」にすぎなかったなら、「Coordinated」ではなく「Requested Legal review for…」のように実態に合わせます。

この「JDと経歴を突き合わせ、事実だけで書く」作業を求人ごとに行うのがEigoHeroの考え方で、EigoHeroで求人に合わせた英文Resumeを作成することもできます。手作業で行う場合も、上の手順は同じです。

提出前のチェックリスト

• 各ブレットは「Action＋Scope＋Result」の形になっているか。Resultが確認できないものは、担当業務ブレットとして追加確認が必要だと把握しているか
• ブレット1項目につき、中心となる実績が一つに絞られているか
• 「Responsible for」で終わっているブレットはないか
• 完了した実績は過去形、現在も続く担当業務は現在形になっているか
• 動詞は、自分の実際の権限・関与に合っているか
• 数字には根拠（集計条件・期間・計算方法）があり、説明できるか。根拠を説明できない推測値は入っていないか。概算の場合は、算定方法を説明でき、概算と分かる表現になっているか
• チームの成果と自分の担当部分が区別できているか
• 開示できない情報を、契約や会社のルールに反して書いていないか
• JDに近い実績が上に来ていて、関連の薄いものは短くなっているか

ブレットの本数については、本稿で参照した資料は一律の本数を示していません。本稿では、直近の職歴や応募職種に近い職歴を厚く、古い職歴や関連の薄い職歴を薄くする優先順位での調整を勧めます。