仕事・転職
ITエンジニアの自己PRの書き方｜状況別の例文8パターンと、職務要約との書き分け
公開日： ／ 著者：Direct typeカスタマーサクセス
この記事の要点
- ・自己PRで手が止まる原因の多くは、職務要約と同じことを書こうとしていることにあります
- ・自己PRに書くのは、仕事で大事にしていること、それが表れた場面、これから関わりたいことの3つです
- ・数字が出せない、経験が浅い、ブランクがあるなど、状況別に8パターンの例文を掲載しています
- ・企業は「何ができるか」と同じくらい「何をやりたいか」を見ています
職務経歴は書けたのに、自己PRの欄だけ手が止まる。 そういう方は少なくありません。
手が止まる理由の多くは、職務要約と同じことを書こうとしているからです。 職務要約との違いが分かれば、自己PRに何を書けばいいかが見えてきます。その書き分け方と、状況別の例文8パターンを紹介します。
1. 自己PRと職務要約の書き分け
自己PRが埋まらないのは、職務要約で書いた内容をもう一度書こうとしているからかもしれません。職務要約は「何をしてきたか」、自己PRは「どういうエンジニアか」を伝える欄です。同じ実績を並べると、読み手には同じ内容が2回続いているように見えます。
| 観点 | 職務要約 | 自己PR |
|---|---|---|
| 伝えること | 何をしてきたか | どういうエンジニアか |
| 中心になる内容 | 経験年数・領域・実績 | 仕事の進め方・大事にしていること・志向 |
| 時間軸 | 過去 | 過去の姿勢と、これから |
| 読み手が知りたいこと | 要件に合うか | 一緒に働けそうか |
Direct typeでは、職務経歴書で伝えるものを「スキル」と「思想」の2つに分けて考えています。スキルは技術の幅・深さ・応用力、思想は技術や仕事に対する考え方やこだわりです。企業はこの2つを通じて、カルチャーマッチするのか、自社でどう活躍してくれそうかを見ています。
技術や実績は、技術スキルと職務経歴の欄ですでに伝わっています。自己PRは、それらを読んでも分からない、仕事への考え方を伝える場所だと考えると、書く内容が決まりやすくなります。
自己PRの内容で、書類選考の結果が変わることもあります
年齢や経験年数だけを見れば採用要件を満たしていなかった人が、職務経歴書や自己PRの内容が魅力的だったことで書類選考を通過し、面接でもそれを伝えて有名企業に内定したというケースは、珍しくありません。Direct typeでも、実際にこうした例がありました。
経歴の条件だけでは届かない場面でも、自己PRが判断を変える材料になりうるということです。
2. 自己PRに書く3つの要素
書く内容は、仕事で大事にしていること、それが表れた具体的な場面、これから関わりたいことの3つです。この順に並べると、読み手が人物像をつかみやすくなります。
| 要素 | 書く内容 | 切り口の見つけ方 |
|---|---|---|
| 大事にしていること | 仕事の進め方で意識していること | 仕事で「これだけは外さない」と意識していることは？ |
| それが表れた場面 | 実際にあったことを1件だけ | それが一番よく表れた出来事は？ そのとき何を判断した？ |
| これから関わりたいこと | 今後の志向。特定の企業に寄せすぎない | 次の職場で、今より増やしたい仕事は？ |
書き出しに迷ったら、表の「切り口の見つけ方」にある質問に1つずつ答えてみてください。答えをつなげれば、そのまま自己PRの下書きになります。全体で200〜300字程度が目安です。文字数より、読み終えたときに「この人はこういうエンジニアだ」と一言で言えるかどうかが大切です。要素を詰め込むと焦点がぼやけるので、伝えたいことは1つか2つに絞るとまとまります。
読み手は、人事と現場の2人いることが多い
職務経歴書を最初に読むのは、技術に詳しくない人事であることが多く、そのあと技術を見極めたい現場のマネージャーがじっくり読みます。
自己PRも同じです。技術に詳しくない人でも要点が分かる言葉で書きつつ、現場の責任者が読んだときに判断の中身が伝わる具体性を残しておくと、両方の読み手に届きます。
「場面」は、扱える課題の難しさを伝える部分です
3つの要素のうち、読み手が最も具体的に想像するのは「それが表れた場面」です。企業はこの部分から、あなたがどんな課題に向き合ってきた人なのかを読み取ろうとします。
どんな課題を、何を根拠に判断して解決に導いたか。そこまで書けていると、読み手はあなたがどの程度の難しさの仕事を任せられる人なのかを具体的に想像できます。実績の大きさより、判断の中身が伝わるかどうかで印象が変わります。
3. 状況別の例文8パターン
自分の状況に近いものを選んでお使いください。そのまま貼り付けるのではなく、ご自身の経験に置き換えることが前提です。事実と異なる内容は、面接で掘り下げられた際どこかに矛盾が生じ、最終的に信頼を損ねてしまう原因となります。
パターン1：実績を数字で語れる
工数削減や速度改善など、成果を数値で示せる方
原因を推測で決めず、計測して特定してから手を打てることが、私の強みです。ECサイトのフロントエンド開発を3年担当しており、主要ページの表示が遅く、スマートフォンからの離脱が多いことが課題でした。まず計測してボトルネックを特定し、画像の読み込み方とスクリプトの分割を見直した結果、表示完了までの時間を3.2秒から1.4秒に短縮しました。この強みを活かして、今後はパフォーマンスを設計段階から考慮できる立場で、プロダクト全体の体験改善に関わりたいと考えています。
この例文の組み立て
- ・大事にしていること：原因を推測で決めず、まず計測して特定する
- ・それが表れた場面：表示の遅さを、読み込み方とスクリプトの分割の見直しで3.2秒から1.4秒に短縮した
- ・これから関わりたいこと：パフォーマンスを設計段階から考える立場で、体験改善に関わる
ポイント：数字は1つに絞るほうが印象に残ります。複数並べると、どれが強みなのかが伝わりにくくなります。
パターン2：実績が数字になりにくい（保守・運用）
成果より「防いだこと」が中心になる方
障害は、起きてから直すより、起きる前に防ぐ。これが、私が強みとしてきた仕事の進め方です。社内システムの保守運用を4年間担当し、月に一度ログの傾向を確認して、異常の兆しがあれば閾値を超える前に対処することを習慣にしてきました。直近3年間、計画外の停止は起きていません。アラートの閾値も運用の実態に合わせて見直し、夜間の不要な呼び出しを減らしました。目立つ仕事ではありませんが、止まらないことそのものに価値があると考えています。今後は運用で得た知見を活かして、設計段階から可用性に関わる仕事をしたいと考えています。
ポイント：「起きなかったこと」も実績です。停止が起きていない期間や、未然に防いだ事象は、数字がなくても具体的に書けます。
パターン3：経験が浅い（実務3年未満）
実績の大きさより、伸びしろを伝えたい方
課題に気づいたら自分から提案し、必要な技術を短期間で身につけて形にすることを得意としています。テストエンジニアとして2年間、Webサービスの品質保証に携わっています。入社時は手動テストが中心でしたが、リリースのたびに回帰テストの工数が膨らんでいたため、自動化を自分から提案しました。業務外の時間でテストフレームワークを学び、3か月ほどで主要なシナリオの自動化を任されるようになりました。この強みを活かして、今後はテスト設計の段階から、品質の作り込みに関わりたいと考えています。
ポイント：経験年数が短い場合は、「何を、どのくらいの期間で、どう身につけたか」を具体的に書くと、伸びしろが伝わります。
パターン4：転職回数が多い
経歴に一貫性があることを示したい方
これまで3社で開発に携わってきましたが、いずれも決済や与信といった金融領域のシステムです。扱う金額の性質上、処理の正しさを最優先に設計する考え方が身につき、仕様を読む際は、例外時にお金がどう動くかから確認する習慣があります。この考え方を軸に、職場が変わってもすぐに立ち上がれることが私の強みで、直近の職場では参画から2か月で設計レビューを担当しています。今後も金融領域で、要件定義から関われる仕事をしたいと考えています。
ポイント：回数そのものを説明するより、扱ってきた領域や担当工程の共通点を軸にすると、経歴の一貫性が伝わります。
パターン5：SES・受託から自社開発を目指す
担当できる工程が限られていた方
限られた担当範囲の中でも、後工程で困らないように先回りして動くことには自信があります。SES企業に所属し、3つの現場でJavaを用いた業務システムの開発を担当してきました。参画先では詳細設計以降が中心でしたが、仕様の矛盾に気づいたときは実装の前に現場のリーダーへ確認し、手戻りが起きない形に調整してきました。参画のたびに業務の流れを図にまとめ、後から入るメンバーが迷わないようにもしています。今後は、作ったものが誰にどう使われているかまで見届けられるよう、自社サービスの開発に企画の段階から関わりたいと考えています。
ポイント：担当工程が限られていたことは、正直に書いて構いません。そのうえで、限られた範囲の中で何を工夫したかを書くと評価につながります。
パターン6：マネジメント経験がある
実装から離れていた期間がある方
8名の開発チームでリーダーを務めた2年間で、リリース後に見つかる不具合を前年の半分以下に減らしました。メンバーの得意領域を踏まえてタスクを割り振り、レビューで見る観点を文書にまとめて共有するなど、仕組みを整えてチーム全体の開発の質を底上げするのが私の持ち味です。週に一度はメンバーと1対1で話す時間を設け、詰まっている箇所を早めに拾うようにしています。この強みを活かして、今後は技術選定にも責任を持つ立場で、開発組織づくりに関わりたいと考えています。
ポイント：マネジメント経験を書く場合も、技術的な判断を伴っていたことを示すと、実装から離れた印象になりにくくなります。
パターン7：技術領域を変えたい
これまでと違う領域に挑戦したい方
オンプレミス環境で可用性を確保してきた5年間の経験が、私の一番の武器です。サーバ構築を担当するなかで、3年目からはクラウド移行の検証も任されてきました。業務外でも学習を続け、AWSの認定資格を取得しています。クラウドの構成を考えるときも物理環境での経験が判断の土台になっており、現職ではシステムごとにクラウドへ移すべきかの判断材料を整理して提案しています。今後はクラウドを前提とした基盤設計に軸足を移し、これまでの知見を活かしたいと考えています。
ポイント：これまでの経験が新しい領域でどう活きるかを書くと、単なる未経験者ではないことが伝わります。
パターン8：ブランクがある
離職期間や、現場を離れていた期間がある方
私の強みは、現場を離れていても学びを止めず、自分で形にできることです。前職を退職後、家族の事情で1年間仕事を離れていました。その間もキャッチアップを続け、個人でFlutterを使ったモバイルアプリを開発し、ストアで公開しています。開発ではテストを先に書く進め方を取り入れ、機能を足しても既存の動作が壊れないように心がけました。まずは既存アプリの改善から着実に貢献し、早い段階で戦力になれるよう努めたいと考えています。
ポイント：ブランクは1行で事実だけを書き、その期間に何をしていたかに字数を使うほうが、前向きに受け取られます。
4. 「何をやりたいか」で、届くスカウトが変わる
職務経歴書において「●●をやりたい」という希望条件を示すことは極めて重要です。希望が明確であればあるほど、企業は求める役割を具体的にイメージできるため、最適なスカウトを提示しやすくなります。一方で、希望条件が不透明な場合、企業側は自社への適性や意欲を判断しきれず、スカウト送信を躊躇する傾向にあります。
同じ経歴でも、後半の一文で伝わり方は変わります。
ずっとJavaをやってきました。だから、今後もJavaを活かしたいです。
ずっとJavaをやってきました。だけど、新しい技術も経験したいです。
前半は同じでも、後半によって、企業が声をかけたいと考えるポジションは変わります。3つ目の要素「これから関わりたいこと」を書いておく意味は、ここにあります。
Direct typeでは、希望職種が記載されている場合、基本的に希望職種に沿ったスカウトが送られます。希望職種の設定と、自己PRの「これから関わりたいこと」が揃っていると、企業側も提案するポジションを判断しやすくなります。
同じ言葉でも、志向によって合う会社が変わります
社風との相性を重視する企業ほど、「何を目指しているか」という志向性を厳しく見ています。たとえば「最新技術を常にチェックしている」という事実ひとつをとっても、企業側の捉え方は分かれます。「技術そのものを徹底的に追究したいギーク志向」なのか、「最適な技術選定で事業に貢献したいプロダクト志向」なのか。この志向の差が、求める社風とのミスマッチを防ぐ重要なポイントになります。
どちらが良いということではありません。なぜそうしているのかを一言添えておくと、読み手が自社に合うかどうかを判断しやすくなります。
5. やりたいことは、行動とセットで書く
まだ経験していない技術を「やりたいこと」として書くときは、それに向けて自分が何をしているかを添えると、本気度が伝わります。
伝わりにくい書き方
Scalaでの開発に興味があります。
本気度が伝わる書き方
Scalaでの開発に興味があり、業務では触る予定がないため、プライベートでコードを書いて動かしたりしています。
「興味があります」だけでは、どの程度の関心なのかが読み手には分かりません。小さくても行動が添えられていると、入社後に自分で学びながら伸びていく姿が想像しやすくなります。まだ何もしていない場合は、少しでも手を動かしてから書くほうが、言葉に重みが出ます。
6. 避けたい3つの書き方
読み終えたあとに「結局どういうエンジニアなのか分からない」状態になるのが、最も避けたい結果です。次の3つが、その原因になりやすい書き方です。
| 避けたい書き方 | 伝わりにくい理由 | 直し方 |
|---|---|---|
| 職務経歴の要約になっている | 上の欄を読めば分かる | 実績ではなく、進め方や大事にしていることを書く |
| 誰にでも当てはまる言葉で終わる | 「コミュニケーション能力」だけでは判断できない | それが表れた場面を1件添える |
| 技術名を並べて終わる | 技術スキルの欄と重複する | その技術を使って何を判断したかを書く |
なかでも2番目はよく見かけます。「コミュニケーション能力があります」で終えるのではなく、「仕様の矛盾に気づいたときは、実装の前に必ず確認するようにしています」と書くと、同じことを言っていても伝わり方が変わります。
書いた自己PRが、どう受け取られるか確かめる
Direct typeはITエンジニア向けのスカウト型転職サービスです。職務経歴と自己PRを登録すると、あなたの経歴に関心を持った企業からスカウトが届きます。どんな企業が、どのポジションで声をかけてくるか。それ自体が、書いた内容がどう受け取られたかを知る手がかりになります。求職者の利用は完全無料です。
無料で会員登録する求人は首都圏が中心で、大阪・愛知・福岡に一部あります。それ以外の地域でオフィス出社を前提とした求人は限られます（フルリモートは全国可）。Direct typeはスカウト型のため、応募して初めて企業とのやり取りが始まります。キャリア相談・書類添削・面接対策は提供していません。
Direct typeが自分に合うか、AIに聞いてみる
Direct typeが公開している情報をAIが読んだうえで、あなたに合うサービスかを整理して答えます。
回答は各AIサービスが生成するものです。内容の正確性・最新性を当社が保証するものではありません。ChatGPT、Google、Claude、Perplexityは各社の商標です。
この記事のまとめ
- ・自己PRで手が止まるのは、職務要約と同じことを書こうとしているから
- ・職務要約は「何をしてきたか」、自己PRは「どういうエンジニアか」
- ・書く要素は大事にしていること・それが表れた場面・これから関わりたいことの3つ
- ・読み手は人事と現場の2人。分かりやすさと具体性の両方を残す
- ・「何をやりたいか」が書かれていないと、希望に合わないスカウトが届きやすい
- ・やりたい技術は、行動とセットで書く
- ・例文は自分の経験に置き換えて使う
ITエンジニアの自己PRに関するよくある質問
Q
自己PRに、保有資格を書いてもいいですか？
＋
資格そのものは保有資格の欄に書き、自己PRでは繰り返さないほうが読みやすくなります。自己PRで触れるなら、資格を取った理由や、学んだ内容を業務でどう使ったかを書いてください。取得の事実より、その過程で何を判断したかのほうが人物像が伝わります。
Q
面接で自己PRを求められたら、書類と同じ内容を話せばいいですか？
＋
書類の内容を軸にして構いませんが、読み上げるだけでは足りません。書類に書いた場面を1つ選び、そのとき何に迷い、何を根拠に判断したかまで話せるように準備しておくと、深掘りの質問にも答えやすくなります。書類と話す内容が食い違わないことも大切です。
Q
自己PRに書く強みが見つからない場合は、どうすればいいですか？
＋
強みを探すより先に、これまでの業務を棚卸しするのがおすすめです。担当したプロジェクトごとに、困っていたこと、自分で判断したこと、その結果を書き出していくと、繰り返し出てくる行動が見えてきます。それが強みの原型です。Direct typeでは、この棚卸しをAIとの対話で進められる業務棚卸しプロンプトを会員向けに無料で提供しています。
Q
自己PRは、一度書いたら更新しなくてもいいですか？
＋
半年から1年に一度は見直すことをおすすめします。転職を考えていない時期でも、この頻度で更新しておくと安心です。時間が経つほど業務の詳細を思い出しにくくなるためです。担当範囲が広がったときも、更新のタイミングです。
Q
生成AIを使って自己PRを書いてもいいですか？
＋
言葉を整える補助として使うのは有効です。ただし生成AIは、話していない数字や成果を補ってしまうことがあります。提出前に、書かれている内容がすべて事実かを必ず確認してください。Direct typeの業務棚卸しプロンプトには、話していない数字や成果を創作・誇張しないというルールを組み込んでいます。
Q
自己PRで、失敗した経験に触れてもいいですか？
＋
触れて構いません。失敗そのものより、その後に何を変えたかを書くと、判断の質や改善の姿勢が伝わります。ただし自己PRの主題は強みなので、失敗は「それをきっかけに身についたこと」を説明する材料として使うのが自然です。
Q
自己PRに、チームで出した成果を書いてもいいですか？
＋
書いて構いませんが、その中で自分が担った役割と判断を明確にしてください。「チームで不具合を半分に減らした」だけでは、あなたが何をしたのかが読み手に伝わりません。「レビュー観点を文書にまとめて共有した」のように、自分の行動まで書くと評価につながります。
Q
GitHubや技術ブログは、自己PRに書いたほうがいいですか？
＋
持っているなら、伝えて構いません。ただし注意点もあります。技術に詳しくない担当者には内容まで理解されない場合があること、選考向けに形だけ整えたリポジトリは見抜かれやすいこと、業務の都合で公開できない人も多いことです。アウトプットは補強の材料として添え、自己PRの文章そのものは別にしっかり書いておくのが確実です。
