スキルシートの自己PR欄は、書き方によって扱いが大きく変わる項目です。しっかり読まれることもあれば、ほとんど読み飛ばされることもあります。
この記事では、読み飛ばされる自己PRの共通点と、案件先に伝わる書き方を、そのまま使える型と例文で整理します。
自己PRが読み飛ばされる理由
内容が悪いから読まれない、というわけではありません。理由はもっと単純で、ほぼ全員が同じことを書いているからです。
次のような文章は、多くのスキルシートで見かけます。
新しい技術のキャッチアップに前向きに取り組んでいます。チームでのコミュニケーションを大事にし、円滑な開発を心がけています。
書いてある内容そのものは、まったく悪くありません。ただ、同じことが書かれたシートが何枚も並ぶため、読んでも人物像の違いが分かりません。差が出ない情報は、読む側にとって判断材料にならないので、自然と飛ばされます。
もうひとつの理由は、主観だけで構成されていることです。「前向き」「大事にしている」「心がけている」は、本人の姿勢であって、事実ではありません。事実でないものは検証できないので、読む側は判断に使えません。
効くのは「人柄」ではなく「行動と結果」
では何を書けばいいのか。答えはシンプルで、やったことと、その結果どうなったかです。
同じことを伝えるにしても、次のように書き換えられます。
| こう書きがち | 案件先に伝わる書き方 |
|---|---|
| コミュニケーションを大事にしています | 仕様の認識違いを減らすため、着手前に確認事項を整理してチームに共有していました 「大事にしている」という姿勢ではなく、実際にやった行動を書くと再現性が伝わります。 |
| 品質の高い成果物を作る自信があります | テスト自動化の仕組みを整備し、リリース前の手動確認の工数を削減しました 「自信」は主観です。何をして何が良くなったかに置き換えます。 |
| 新しい技術のキャッチアップが得意です | 新フレームワーク導入の可否をPoCで検証し、結果を技術選定の判断材料として提出しました 学習意欲ではなく、学んだ結果どう業務に反映したかを書きます。 |
| チームに貢献してきました | 新メンバーのオンボーディングを担当し、独力で開発を進められる状態まで支援しました 「貢献」は範囲が広すぎます。誰に対する何の貢献かを具体にします。 |
| 責任感を持って業務に取り組みます | 障害発生時の一次対応を担当し、原因調査から復旧、再発防止策の実装まで行いました 責任感は、任された範囲を書けば自然に伝わります。 |
共通しているのは、形容詞を、動詞と結果に置き換えているという点です。「丁寧」「迅速」「柔軟」といった言葉は、それ自体では何も伝えません。何をしたのかが書かれていれば、丁寧さは読む側が勝手に判断してくれます。
この考え方は自己PR欄に限りません。経歴欄の書き方も同じ発想です。詳しくは経験を案件に伝わる言葉に翻訳する書き方にまとめています。
そのまま使える型
書き出しに迷うときは、次の順番で組み立てると形になります。
- 1. 何ができる人か … 担当できる領域と工程を1行で
- 2. その根拠 … 実際にやった行動を1〜2つ
- 3. どう働くか … チームでの立ち回りを1行
この3つで足りる理由は、読む側が知りたいことがこの順番だからです。まず何を任せられるかを判断し、次にその根拠を確認し、最後に一緒に働けそうかを見る。読む順番に沿って書かれていると、短くても伝わります。
この型に当てはめると、次のようになります。
バックエンドを中心に、要件定義から実装・運用保守まで一貫して担当してきました。直近では決済機能の改修を担当し、外部APIとの連携で失敗時のリカバリ処理まで含めて実装しています。仕様に不明点がある場合は着手前に確認を取り、手戻りを減らす進め方を意識しています。
3行で、担当領域・具体的な仕事・仕事の進め方がすべて入っています。特別な実績がなくても、この形にはできます。
分量は3〜5行、200〜300文字で十分です。長く書いても読まれる量は増えません。むしろ要点が埋もれます。
書くことがないと感じたときは
自己PR欄で手が止まる人は多いのですが、材料がないわけではありません。経歴の中にあるのに、実績だと思っていないだけであることがほとんどです。
次の問いに当てはまるものがあれば、それが材料になります。
| 思い出す観点 | そこから書けること |
|---|---|
| チームで最初に相談される領域は何だったか | その領域が実質的な得意分野です |
| 後輩やメンバーに教えたことはあるか | 育成・オンボーディングの経験として書けます |
| 障害やトラブルで動いたことはあるか | 運用面を任せられる根拠になります |
| 面倒だから改善した作業はあるか | 効率化・自動化の実績です |
| 途中から任された仕事はあるか | 信頼されて範囲が広がった証拠です |
特に多いのが、「当たり前すぎて書かなかった」というパターンです。毎日やっていることは実績だと感じにくいのですが、読む側にとっては十分に判断材料になります。
たとえば「障害が起きたら一次対応をしていた」は、多くの現場で当たり前の業務です。ただ、案件先から見ると運用まで任せられるかどうかの判断材料になります。同じ実装担当でも、動ける範囲が違うと分かるからです。
書くかどうか迷ったら、「これができない人もいるか」を考えてみてください。できない人がいるなら、それは書く価値のある情報です。
経験が浅いときの書き方
経験年数が短いと、自己PRに書けることが少ないと感じがちです。ただ、案件先が経験の浅い人に見ているのは実績の量ではありません。
見られているのは、次のような点です。
| 見られている点 | 書き方の例 |
|---|---|
| 指示を待たずに動けるか | 不明点を放置せず、確認して進める習慣があることを、具体的な場面で書く |
| 何を任せると伸びるか | 担当してみて手応えがあった領域を、率直に書く |
| 基礎が身についているか | 使った技術を、どういう場面でどう使ったかまで書く |
やってはいけないのは、経験の浅さを埋めようとして広げて書くことです。少ない経験でも正確に書かれているほうが、実際には評価されます。書ける範囲が狭いことは、そのまま書いて問題ありません。
やらないほうがいいこと
逆に、書くと損をする書き方もあります。
| やらないほうがいいこと | 理由 |
|---|---|
| 経歴欄と同じ内容を繰り返す | 読む側は経歴を先に見ています。同じ情報だと読む意味がなくなります |
| できることを広く書きすぎる | 「なんでもできます」は、何が得意か分からないのと同じです |
| 実際より広げて書く | 面談で深掘りされたときに崩れます。面談はスキルシートを見ながら進みます |
| 謙遜して短くまとめる | 控えめに書くことと、正確に書くことは別です。やったことは省略せずに書きます |
| 志望動機のように書く | スキルシートは応募書類ではありません。意欲より、担える範囲を書きます |
3つ目は特に注意が必要です。自己PR欄は自由記述なので、つい広めに書きたくなりますが、面談で確認される前提で書いてください。
職種によって、書く内容は変わります
同じ型を使っても、強調する部分は職種で変わります。
| 職種 | 強調するとよい点 |
|---|---|
| バックエンド | 担当した工程の範囲、設計判断、性能や信頼性への対応 |
| フロントエンド | UIの実装範囲、設計の共通化、パフォーマンスやUXへの配慮 |
| インフラ・SRE | 構築と運用の両面、自動化した範囲、障害対応の経験 |
| PM・PMO | 管理した規模（人数・期間）、調整した相手、進め方の工夫 |
職種別の経歴の書き方は職種別スキルシートの記入例にまとめています。自己PRの材料が見つからないときは、こちらから逆算するのも有効です。
まとめ
自己PR欄は、書き方ひとつで読まれるかどうかが変わります。
- 読み飛ばされるのは内容が悪いからではなく、全員が同じことを書いているから
- 効くのは人柄ではなく行動と結果。形容詞を動詞に置き換える
- 型は「何ができる人か → その根拠 → どう働くか」の3行
- 書くことがないときは、経歴の中で他人に頼られた場面を探す
- 広げて書かない。面談で確認される前提で書く
自己PR欄は、経歴欄では伝えきれない「複数の案件にまたがる強み」を書ける唯一の場所です。経歴欄はプロジェクト単位で区切られるため、案件をまたいで積み上げてきたもの——改善の姿勢、育成の経験、担当領域の広がり——は、ここでしか伝えられません。
埋めておくと、担当者が案件先に説明するときの材料が増えます。「この方は実装だけでなく、運用の改善まで自分から動く方です」という一言が添えられるかどうかで、伝わり方は変わります。
スキルシート全体の構成はスキルシート完全ガイドに、項目ごとの記入例は無料テンプレート（Excel）にまとめています。
スキルシートを登録して案件の紹介を受ける（登録は無料・最短1分）