なぜ数字が効くのか
数字は「比較できる形」に変えるための道具です。読み手が自社の状況と重ねられるかどうかが分かれ目になります。
採用担当は1件の書類を数分で読みます。そのとき「パフォーマンス改善を担当しました」と書かれていても、どの規模の、どれくらいの改善なのかが分からないため、判断に使えません。
数字が入ると、読み手は自社の環境と照らし合わせられます。「月間120万リクエストのAPI」と書いてあれば、自社の規模と近いか遠いかがすぐ分かります。つまり数字は自慢ではなく、読み手が判断するための材料です。
もう1つの効果は、再現性の証明です。数字で語れる人は、自分の仕事を観測して改善したという事実がそこに含まれます。同じ成果でも「たまたま」ではないと伝わります。
数字は成果を大きく見せるためではなく
読み手が判断できるようにするために書く
数字が出ない人が見落としている4つの型
「変化」だけが数字ではありません。規模・変化・頻度・範囲の4つの型で探すと、必ず何か見つかります。
1規模
ユーザー数・リクエスト数・データ量・チーム人数
例: 月間120万リクエストのAPI
2変化
施策の前後を比べる。最も強い型
例: p95を1.8秒→320msに短縮
3頻度・時間
回数と、削減できた時間
例: デプロイを週1回→1日3回に
4範囲
担当した工程・機能・環境の数
例: 要件定義〜運用の5工程を担当
数字が書けないと感じている人の多くは、②の「変化」だけを探しています。改善案件を担当していなければ変化の数字は出ませんが、①の規模はどんな仕事にも必ずあるのです。
保守運用が中心でも「月間の問い合わせ対応件数」「担当しているテーブル数」「バッチの本数」は数えられます。新規開発なら「実装した機能数」「対応した画面数」「連携した外部APIの数」があります。
職種別・使える指標カタログ
自分の職種の欄を見て、思い当たるものを1〜2個だけ選びます。すべて埋める必要はありません。
| 職種 | よく使われる指標 |
|---|---|
| バックエンド | レスポンスタイム(p95) / エラー率 / スループット / クエリ数 / バッチ処理時間 |
| フロントエンド | LCP・CLSなどの表示速度 / バンドルサイズ / 離脱率 / 対応ブラウザ数 |
| インフラ・SRE | 稼働率(SLO) / MTTR / 障害件数 / 月額コスト / デプロイ頻度 |
| データ | データ量 / パイプラインの実行時間 / 集計の遅延 / クエリコスト |
| モバイル | 起動時間 / クラッシュ率 / アプリサイズ / ストア評価 / DL数 |
| QA・テスト | テストカバレッジ / 自動化率 / リグレッション件数 / 実行時間 |
| リード・EM | チーム人数 / レビューの滞留時間 / リリース間隔 / 立ち上がり期間 |
指標を選ぶときのコツは、応募先が困っていそうなことに近い指標を選ぶことです。求人票に「レガシー刷新」とあればデプロイ頻度やテストカバレッジ、「急成長中」とあればスループットや稼働率が刺さります。
自分がどの役割で評価されたいかによっても選ぶ指標は変わります。役割ごとの違いはエンジニアのキャリアパスで整理しています。
測っていないときの数字の作り方
正確な計測値でなくて構いません。概算であることを明示し、根拠を自分で説明できる状態にします。
① 「約」を付けて概算で書く
「約」「およそ」を付ければ、厳密な計測値でなくても誠実な表現になります。ログやチケット、リリースノート、Gitの履歴を見返すと、当時の数字はかなり復元できます。
② 分母を必ず添える
「50%削減」だけでは、元が月4時間なのか400時間なのか分かりません。率を書くときは実数を、実数を書くときは規模を添えてください。分母のない率は、読み手に警戒されます。
③ 根拠を1行で言えるようにしておく
面接では「その数字はどうやって測りましたか」と高い確率で聞かれます。「監視ツールのダッシュボードで週次に確認していた値です」「対応チケットの件数を月ごとに集計しました」と即答できれば、それ自体が評価になります。答えられない数字は書かないでください。
④ 書けない数字は丸める
公表されていない売上・契約金額・顧客名は書きません。「月間数百万リクエスト規模」「メンバー約10名」のように丸めれば、規模感は伝えつつ守秘の問題を避けられます。
書き方の型とBefore/After例文
「① 対象と規模 → ② やったこと → ③ 変化」の順に並べるだけで、読みやすい1行になります。
① 対象と規模
何を担当したか。分母になる数字をここに置く
月間120万リクエストの検索API
② やったこと
技術的な打ち手を具体的に。動詞で終わらせる
N+1クエリの解消とキャッシュ層の追加
③ 変化
前→後で示す。1つだけでよい
p95を1.8秒→320msに短縮
月間120万リクエストの検索APIで、N+1クエリの解消とキャッシュ層の追加を行い、p95を1.8秒→320msに短縮
例1：パフォーマンス改善
APIのパフォーマンス改善を担当しました。
月間約120万リクエストの検索APIで、N+1クエリの解消とRedisによるキャッシュ層の追加を実施。p95レスポンスタイムを1.8秒→320msに短縮しました。
例2：テストの整備
テストコードを整備し、品質向上に貢献しました。
主要3機能に自動テストを導入し、カバレッジを約32%→71%へ。リリース後のリグレッション起因の障害を月平均4件→0〜1件に削減しました。
例3：インフラのコスト削減
AWSのコスト削減に取り組みました。
未使用EBSの棚卸しとRDSインスタンスのサイズ見直し、Auto Scalingの導入により、月額インフラ費用を約38万円→24万円（約37%減）に。可用性の指標は変更前と同水準を維持しています。
例4：チームのリード
チームのリーダーとしてメンバーの育成に取り組みました。
6名チームのテックリードとして、レビュー観点の明文化と当番制を導入。PRの平均マージ時間を約3.5日→1日に短縮し、新メンバーが単独で機能をリリースするまでの期間を約3ヶ月→6週間に縮めました。
セクションごとの構成や職務要約の書き方は職務経歴書の書き方ガイドで解説しています。経験が浅く実績が薄いと感じる場合は経験が浅い人の書き方も参考にしてください。
このサイトの作成ツールは、実績欄に入力例が出るので「どの粒度で書けばいいか」を見ながら書けます。登録不要・無料で、入力データはブラウザ内にのみ保存されます。
やってはいけない数字の使い方
数字は面接で必ず掘られます。説明できない数字は、書かない方が有利です。
× 盛る
面接で経緯を聞かれれば崩れる。1つ崩れると他の記述もすべて疑われる
× 分母を隠す
「300%改善」は元が小さいと逆効果。実数を併記して誠実さを見せる
× チームの成果を自分の成果にする
担当範囲を1行添えるだけで解決する。省くと確認されたときに苦しい
× 指標が目的とずれている
カバレッジだけ上げた、といった話は「何のために」を問われる
最後に確認したいのは、その数字が「読み手にとっての価値」に結びついているかです。速くなった、安くなった、壊れにくくなった、人が育った——このどれかにつながっていれば、数字は自然に意味を持ちます。
よくある質問
Q.数字が本当に何もない場合はどうすればいいですか？
「変化」の数字が無いだけで、「規模」の数字はほぼ必ずあります。担当したサービスの登録ユーザー数、1日のリクエスト数、テーブル数、チームの人数、担当した機能の数、対応した問い合わせ件数——どれも規模を示す数字です。まず規模を書き、そのうえで自分が担当した範囲を明記してください。それだけで「何をどのくらいの環境でやったか」は伝わります。
Q.前職の数字を書くと守秘義務違反になりませんか？
公表されていない売上・利益・契約金額・顧客名は書かないでください。一方で、レスポンスタイム・エラー率・チーム人数・カバレッジといった技術的な指標は、企業を特定する情報でない限り問題になりにくい範囲です。判断に迷う場合は「月間数百万リクエスト規模」「メンバー約10名」のように丸めて書けば、規模感を伝えつつリスクを避けられます。
Q.パーセントと実数、どちらで書くべきですか？
両方書くのが最も強いです。「エラー率を0.8%→0.1%（月間の障害起因の問い合わせ約40件→5件）」のように、率と実数をセットにすると分母が伝わります。どちらか一方なら、元の規模が大きい場合はパーセント、小さい場合は実数の方が誠実に見えます。「300%改善」は元が小さいと逆に疑われます。
Q.チームで出した成果はどう書けばいいですか？
成果はチームのものとして書き、自分の担当範囲を1行で添えてください。「6名チームで基盤移行を完遂（自分は認証まわりの設計と移行スクリプトを担当）」という書き方なら、誇張せずに貢献が伝わります。チームの成果を主語なしで書くと、面接で担当範囲を確認された時に印象が悪くなります。
Q.数字を入れすぎると読みにくくなりませんか？
なります。目安は1つの実績につき数字は1〜2個までです。最も伝えたい変化を1つ選び、必要なら分母を添える程度に留めてください。すべての行に数字が並ぶ書類は、かえってどれが重要か分からなくなります。
