エンジニアの自己PRを「STAR法」で構造化する——曖昧なアピールを"伝わる実績"に変える型

「コミュニケーション力に自信があります」——その自己PR、ほぼ全員が書いている。
刺さる自己PRには型がある。STAR法をエンジニア向けにカスタマイズした構造化フレームワークと、Before/Afterの実例を紹介する。

---

「コミュニケーション力に自信があります」は、なぜ刺さらないのか

スキルシートの自己PR欄でいちばん多い記述がこれだ。
「コミュニケーション力に自信があります」
「チームでの業務も問題ありません」
「新しい技術の習得に意欲的です」

悪いことは何も書いていない。
でも、読む側にとっては判断材料にならない。

スキルシートを最初に見るのは、エージェントの営業かクライアントのPMだ。彼らは1日に何十枚ものスキルシートを見ている。
その中で「コミュニケーション力に自信があります」と書いてあっても、「で、具体的に何ができるの？」としか思わない。

以前「エンジニアに求められる「コミュ力」は、明るさじゃない」でも書いたが、コミュニケーション力は抽象的に書いても伝わらない。
「報連相の型」の記事でも触れた通り、伝え方には型がある。

自己PRも同じだ。型に当てはめるだけで、曖昧なアピールが「この人と一緒に働いたらどうなるか」を想像できる実績に変わる。

その型が、STAR法だ。

---

STAR法とは？エンジニア向けにカスタマイズする

STAR法は、もともと採用面接で使われるフレームワークだ。4つの要素で経験を構造化する。

• S（Situation）：どんな状況だったか
• T（Task）：何が課題だったか
• A（Action）：自分は何をしたか
• R（Result）：結果どうなったか

これをエンジニアの文脈に読み替えると、こうなる。

| STAR | エンジニア向けの読み替え | 具体例 |
|---|---|---|
| S: 状況 | どんなプロジェクト・チーム構成だったか | ECサイトリニューアル、5名チーム |
| T: 課題 | 何が問題・ボトルネックだったか | レスポンス速度が遅く、CVRが低下していた |
| A: 行動 | 自分はどんな判断・実装・提案をしたか | DBクエリの最適化とキャッシュ戦略を提案・実装 |
| R: 結果 | 数字や変化でどう改善されたか | レスポンス時間50%短縮、CVR15%改善 |

ポイントは「自分が何をしたか」を明確にすることだ。チームの成果ではなく、自分の貢献を書く。「チームで改善しました」ではなく、「自分がこの部分を担当し、この判断をした」と書けるかどうか。

これだけで、自己PRの解像度はまったく変わる。

---

Before/After で見る——NG自己PRとOK自己PRの差

実際にどう変わるか、3パターンの Before/After を見てほしい。

パターン1：バックエンドエンジニア（経験3年）

NG：

バックエンドの開発を担当しています。Javaを使ったAPI開発が得意です。チームでの開発経験もあり、コミュニケーションを大切にしています。

OK（STAR法）：

会員数50万人のECサイトのバックエンドを担当（S）。 注文処理のレスポンスが3秒以上かかっており、カート離脱率の増加が課題だった（T）。 自分がDBクエリの実行計画を分析し、N+1問題の解消とRedisによるキャッシュ導入を提案・実装した（A）。 結果、レスポンスを0.8秒に短縮し、カート離脱率が20%改善した（R）。

パターン2：フルスタックエンジニア（経験7年・リーダー経験あり）

NG：

フロントエンドからバックエンドまで幅広く対応できます。チームリーダーの経験もあり、メンバーの育成にも力を入れています。

OK（STAR法）：

社内向けSaaSプロダクトの開発チーム（6名）でテックリードを担当（S）。フロントとバックの技術選定がバラバラで、メンバー間のコードレビューが機能していなかった（T）。 技術スタックの統一方針を策定し、レビューガイドラインを作成。週次でコードレビュー会を主導した（A）。 レビューの平均対応時間が3日から1日に短縮し、リリースサイクルが月1回から隔週に改善した（R）。

パターン3：インフラエンジニア（経験5年）

NG：

AWSを使ったインフラ構築に携わっています。障害対応や監視設計も担当しており、安定したシステム運用に貢献しています。

OK（STAR法）：

月間PV300万のメディアサイトのインフラ運用を担当（S）。 月に2〜3回のサーバーダウンが発生しており、復旧に平均2時間かかっていた（T）。 CloudWatchのアラート設計を見直し、オートスケーリングの閾値調整と障害時のランブック整備を自分が主導した（A）。 障害発生率が月0〜1回に減少し、復旧時間を平均20分に短縮した（R）。

3つとも、変わったのは「事実の追加」だけだ。新しいスキルを身につけたわけでも、すごい実績を捏造したわけでもない。自分がやったことを、構造的に整理しただけ。それだけで印象はまったく違う。

数字を入れるだけで、説得力は倍になる

3つのOK例に共通していることがもうひとつある。数字が入っていることだ。

「改善しました」と「50%短縮しました」では、読んだ側のインパクトがまるで違う。数字は客観性の証拠だ。「頑張りました」は主観。「レスポンスを3秒から0.8秒にした」は事実。読む側が判断しやすいのは、言うまでもなく後者だ。

「でも正確な数字がわからない」という人もいるだろう。厳密な数字でなくてもいい。「約30%」「2時間→20分程度」のように概算で構わない。大事なのは、数字を入れようとする意識だ。この意識があるだけで、自己PRの説得力は格段に上がる。

数字にできるものは思っている以上に多い。チームの人数、プロジェクトの期間、対応したチケット数、短縮した時間、削減した工数、改善した指標。日常業務の中に数字の種は転がっている。普段から「これ、数字で言うとどのくらいだろう」と意識しておくと、スキルシートを書くときに困らない。

---

自己PRに書ける「成果」がないと思っている人へ

ここまで読んで、「自分にはそんな数字で語れる成果がない」と思った人もいるかもしれない。

気持ちはわかる。でも、それは「成果がない」のではなく、「成果を成果として認識できていない」だけだ。

成果とは、売上が上がったとか、表彰されたとか、そういう派手なものだけじゃない。エンジニアの仕事における成果は、もっと地味なところにある。

たとえば、こんなことも立派な成果だ。

• 手動だったデプロイをCI/CDに置き換えて、作業時間を30分から5分に短縮した
• ドキュメントが散在していたのを整理して、オンボーディングの時間が半分になった
• 属人化していた運用手順をランブック化して、自分以外でも対応できるようにした
• レビューで指摘していた共通パターンをESLintルールに落とし込んで、レビュー工数を削減した

「当たり前にやっていたこと」の中に、成果は埋まっている。それを掘り出すには、自分に対してこう質問してみるといい。

「このプロジェクトで、自分がいなかったらどうなっていたか？」

この質問に対して「たぶん誰かがやっていた」と思うかもしれない。でも「自分がやった」という事実は変わらない。それを言語化して書くのが自己PRだ。

---

利己的な自己PRと、利他的な自己PR

もうひとつ、自己PRの質を分ける大事なポイントがある。

「自分がすごい」を伝えようとしている自己PRと、「自分がチームやプロジェクトにどう貢献したか」を伝えている自己PR。この違いは、読む側にははっきりわかる。

たとえばこの2つを比べてみてほしい。

利己的な書き方：

高度な技術力を活かし、難易度の高い実装を担当しました。短期間で完了させ、高い評価を得ました。

利他的な書き方：

チームの開発速度がボトルネックになっていたため、共通コンポーネントの設計と実装を担当しました。結果、他のメンバーの実装工数が約30%削減され、チーム全体の開発速度が向上しました。

前者は「自分はすごい」という主張だ。後者は「自分がいたことで、チームがどう良くなったか」というストーリーだ。

読む側が知りたいのは後者だ。なぜなら、スキルシートを読むPMやクライアントは「この人がうちのチームに入ったら、どう貢献してくれるか」を想像しているからだ。

自分の技術力をアピールすることが悪いわけじゃない。でも「技術力がある」で終わるのではなく、「その技術力で周囲にどんな良い影響を与えたか」まで書けると、一段も二段も上の自己PRになる。

これはスキルシートに限った話じゃない。普段の仕事でも、「自分が」ではなく「チームが」「プロジェクトが」を主語にして考えられるエンジニアは、結果的にいちばん高く評価される。利他的であることは、回り回って自分のキャリアを押し上げる。

---

自己PRの言語化を習慣にする

自己PRは、転職するときに慌てて書くものじゃない。

いちばん良いのは、プロジェクトが一区切りつくたびに振り返って書き留めておくことだ。「何が課題で、自分は何をして、どうなったか」。これを数行メモしておくだけで、スキルシートを更新するときの負担が劇的に減る。

半年前のプロジェクトの詳細を正確に思い出すのは難しい。でも直後なら鮮度の高い情報が書ける。この差は大きい。

スキルシートは「作り直すもの」ではなく「更新するもの」だ。定期的に少しずつ更新していけば、常に最新の自分のキャリアが整理された状態を維持できる。

スキルシートの書き方全般については「面談に呼ばれるスキルシートと、書類で落ちるスキルシートの違い」も参考にしてほしい。

自己PRの言語化に悩んだら、Skillsheet-Port のAI構成補助を使ってみるのもひとつの手だ。フォーム入力で体裁が自動で統一されるので、「中身をどう書くか」に集中できる。STAR法の型を頭に入れた上で使うと、叩き台の質がさらに上がる。

▶ 無料でスキルシートを作ってみる → https://www.skillsheet-port.com/

---

まとめ——型があれば、誰でも「伝わる自己PR」は書ける

自己PRが書けない原因は、才能がないからじゃない。型を知らないだけだ。

STAR法で整理すれば、「コミュニケーション力に自信があります」が、「要件定義フェーズでクライアントとの認識齟齬を防ぐ確認プロセスを導入し、手戻りを30%削減した」に変わる。

変わったのは事実じゃない。伝え方だ。

**スキルシートは、あなたの実績を「伝わる形」にパッケージする場所だ。**やってきたことは同じでも、書き方ひとつで評価はまったく変わる。

まずはいちばん直近のプロジェクトをSTAR法で書き出してみてほしい。5分で、自分の見え方が変わるはずだ。