多くの人が履歴書のプロジェクト経験を「やったことの箇条書き」にしてしまいます。
たとえば、こんな書き方です。
注文システムの開発に参加し、キャッシュ最適化、API の性能調整、障害対応を担当。
一見悪くないように見えますが、面接官が知りたい次の3点が抜けています。
- どんな課題があったのか
- あなたは何をしたのか
- その結果どう変わったのか
そこで役立つのが STAR です。
STAR とは何か
STAR は次の4要素の頭文字です。
- S = Situation：状況・背景
- T = Task：課題・役割
- A = Action：実際の行動
- R = Result：結果・成果
履歴書では、4つをそのまま見出しにする必要はありません。大切なのは、背景 → 行動 → 結果 の流れを一目で伝えることです。
最も重要なのは背景ではなく、問題をどう解いたかを証明することです。
履歴書で STAR を短く書くコツ
基本式は次のとおりです。
どんな状況で、何を担当し、どう動き、何を実現したか。
ただし、履歴書では少し圧縮したほうが自然です。
背景 + 行動 + 成果
たとえば：
大規模セール時の高負荷に対して、注文クエリ経路を最適化し、P95 レイテンシを 900ms から 180ms に短縮。
これは「やったこと」ではなく、「成果が残ったこと」を示しています。
事例1：バックエンドエンジニア
改善前：
注文システム開発に参加し、キャッシュ改善と API 性能向上を担当。
この表現は無難ですが、貢献の深さが見えません。
改善後：
セールピーク時の注文クエリ経路を主導して改善。遅いクエリのボトルネックを特定し、Redis キャッシュ戦略を再設計、ローカルキャッシュのフォールバックも追加。注文詳細 API の P95 レイテンシを 820ms から 140ms に削減し、ピーク QPS を 3 倍に引き上げた。
この形なら、状況・行動・成果が全部入っています。
事例2：PM
改善前：
CRM の見積モジュール改修を担当し、業務フローを最適化して営業体験を改善。
これでは、何が改善されたのか分かりません。
改善後：
営業の見積作成に時間がかかる問題を解消するため、CRM 見積モジュールの改修を主導。営業 12 名へのヒアリングと分析データをもとに、重複入力と多段階承認フローがボトルネックであることを特定し、見積フローを 11 ステップから 4 ステップへ圧縮。1 件あたりの作成時間を 8 分から 3 分へ短縮し、営業チームの週次アクティブ利用率を 85% まで伸ばした。
PM の履歴書では、問題定義と数字で示せる成果が特に重要です。
事例3：新卒
新卒は授業プロジェクトを「やったことの報告」にしがちです。
改善前：
学内の中古品取引プラットフォームを独力で実装し、商品投稿、検索、注文管理を実現。
改善後：
学内中古品取引の場面を想定して、学生向けの取引プラットフォームを独力で開発。商品投稿、キーワード検索、注文マッチング、通知機能を実装し、検索の遅さを解消するためにカテゴリ索引とキーワード候補を設計。検索応答時間を 200ms 以内に収め、公開後は 300 名以上の学内ユーザーに利用された。
新卒でも、工夫と結果があれば十分に強い書き方になります。
事例4：グロース・マーケティング
STAR はエンジニアだけのものではありません。グロース、マーケ、運用系ではむしろ必須です。
改善前：
SNS コンテンツ運用とキャンペーン実施を担当し、ブランド認知を向上。
改善後：
新規ユーザーの初週継続率が低い課題に対し、SNS コンテンツ運用と集客キャンペーンを企画。チャネル別 CTR を見ながら企画テーマを調整し、広告文を 6 パターン A/B テストして高CV版を採用。月間新規登録数を 42% 増やし、ランディングページの CVR を 3.1% から 5.4% に改善した。
活動の説明ではなく、数字で成果を示すのがポイントです。
よくある4つの比較
1. 職責から成果へ
悪い例：
API 開発と障害対応を担当。
良い例：
コア API の再設計を主導し、エラー率を 2.3% から 0.4% に改善。
2. 参加から主導へ
悪い例：
プロジェクト開発に参加。
良い例：
ログインフローの再設計を主導し、認証モジュールを独力で実装。
3. 曖昧から具体へ
悪い例：
ユーザー体験を改善。
良い例：
登録フローを 5 ステップから 3 ステップへ短縮し、重複入力項目を 7 個削減。
4. 感覚から証拠へ
悪い例：
プロジェクトは順調に進んだ。
良い例：
公開後 2 週間で API 平均応答時間が 61% 改善し、サポート問い合わせが 28% 減少。
STAR で書き直すテンプレート
次の形で書くと整理しやすくなります。
[状況] において、[課題] を担当し、[行動] によって、[成果] を実現した。
例：
大規模セールの高負荷環境において、注文経路の最適化を担当し、キャッシュ再設計・ API 分割・遅いクエリ削減により、P95 レイテンシを 820ms から 140ms に改善した。
余裕があれば、事業インパクトも加えるとさらに良くなります。
この改善により、ピーク QPS は 3 倍に増え、タイムアウト警告も 2 種類減少した。
注意したい3つの落とし穴
1. Situation を長く書きすぎる
背景は短く十分です。履歴書は報告書ではありません。
2. ツール名だけを並べる
使った技術を並べるだけでは不十分です。その技術で何を達成したかを書きましょう。
3. 結果を「リリースした」で終わる
公開は結果ではありません。数字や改善幅が必要です。
すぐ使えるチェックリスト
- プロジェクトの背景が一目で分かる
- 自分の役割が明確に伝わる
- 行動が具体的に書かれている
- 成果が測定できる
- 単なる作業記録ではなく、貢献が見える
5つ全部が満たせれば、かなり強いプロジェクト記述になります。
まとめ
STAR は、履歴書をきれいに見せるためのテクニックではありません。プロジェクト経験を証拠に変えるための型です。
良いプロジェクト文は、次の3つにすぐ答えられる必要があります。
- どんな問題があったか
- 自分は何をしたか
- どんな結果を出したか
もしまだ曖昧に感じるなら、経験が足りないのではなく、情報の整理が足りないだけかもしれません。
簡単に見直したい場合は、DeepResume に履歴書をアップロードして無料診断を受けてみてください。成果の定量化、キーワードの網羅、ATS 対応度を見ながら、プロジェクト記述の改善点を具体的に確認できます。