エンジニアの自己PR｜第二新卒が未経験でも書ける3要素と例文6パターン【2026年版】

〜「学習意欲があります」は、未経験エンジニアの自己PRで最も多く、最も情報量の少ない一文です〜

エンジニア職の自己PRは、実務経験の有無で書き方がまったく変わります。

実務経験がある場合は、扱った技術、担当した工程、チームでの役割を書けば形になります。

問題は実務未経験の場合です。書ける実務がないため、「学習意欲があります」「新しい技術を吸収する姿勢があります」に収束してしまう。これは、応募者のほぼ全員が書いている内容です。

ただ、未経験でも書ける材料は必ずあります。学習の進め方、作ったもの、詰まったときの解決方法、そして前職での「業務を改善した経験」。この4つです。

この記事では、経験の有無それぞれについて、例文6本つきで整理します。

1. 結論：エンジニアの自己PRは3要素で決まる

① 「何を作ったか」ではなく「なぜそう作ったか」を書く

成果物の説明だけでは差がつきません。「なぜこの構成にしたか」「どんな選択肢があって、なぜこれを選んだか」。技術的な判断ができるかどうかが、最も見られる部分です。

② 詰まったときの解決過程を書く

実務では、うまくいかない場面のほうが多いです。エラーが出たとき、仕様が分からないとき、どう調べて、どう解決したか。この過程は、実務での動き方をそのまま予測させます。

③ 前職の業務経験を「エンジニア視点」で書き直す

未経験者が最も見落とす材料です。前職で表計算ファイルを整えた、手順書を作った、業務の非効率を見つけた。これらは全部、エンジニアの仕事と同じ思考です。

2. なぜ定番の自己PRが落ちるのか

共通しているのは、「事実」は書いてあるが「判断」が書かれていないことです。

エンジニア職の採用担当が知りたいのは、「この人は、正解が決まっていない場面でどう考えるか」です。技術は入社後にも学べますが、考え方の型は簡単には変わりません。

だから、成果物の説明ではなく、判断の説明を書いてください。

✕ 「タスク管理アプリを作りました。ログイン機能とデータベース連携を実装しています。」

○ 「タスク管理アプリを作りました。当初は1つのテーブルにタスクとユーザーを持たせていましたが、複数ユーザーでの利用を想定してテーブルを分離しました。この変更で、後からユーザーごとの表示を追加する際に、既存の処理を変えずに済みました。」

同じ成果物でも、後者は「設計を考えた形跡」が見えます。

3. 編集長の実体験：未経験エンジニアの書類を見た話

前職でSaaS企業に転職した後、社内でエンジニアの中途採用の書類を見る機会がありました。営業側の立場でしたが、未経験採用の枠について意見を求められたためです。

そこで、エンジニアリングマネージャーが言っていたことが印象に残っています。

マネージャー「未経験の書類って、8割が同じなんですよ。『スクールで3ヶ月学習しました』『ポートフォリオを作りました』『学習意欲があります』。この3点セット」

私「じゃあ、残りの2割は何が違うんですか」

マネージャー「詰まった話が書いてあるんです。『ここでエラーが出て、公式ドキュメントを読んで、こう理解して、こう直した』みたいな。これがあると、その人が実務でどう動くか想像できる」

私「エラーの話を書くと、能力が低いと思われませんか」

マネージャー「逆です。実務は詰まってからが本番なので。詰まらない人なんていない。詰まったときにどう動くかが全部です」

もう一つ、印象的だった話があります。

マネージャー「あと、前職の経験を書いてる人が強い。『営業で使ってた顧客リストが手作業で更新されてて、非効率だと感じた』みたいな。それって、要件定義そのものなんですよ。業務の課題を見つけて、システムで解けると考えた。この人は入社後に何を作るべきか考えられる」

この2つが、未経験エンジニアの自己PRで最も効く材料です。

「詰まった話」と「前職の業務課題」。どちらも、学習期間の長さやポートフォリオの完成度より、はるかに強く効きます。

4. 未経験の場合：4つの材料

材料1：学習の内容と継続の証明

「◯ヶ月学習しました」だけでは不十分です。期間ではなく、「今、何ができる状態か」を書いてください。

材料2：作ったものと、その判断

「なぜ作ったか」が個人的な課題であることは、まったく問題ありません。むしろ、自分の困りごとを解決するために作ったほうが、動機が明確で説明しやすくなります。

材料3：詰まったときの解決過程

これが最も差がつく材料です。

書き方の例

「開発中、一覧画面の表示が遅くなる問題が発生しました。データを1件ずつ取得する処理になっていたことが原因と考え、まず何回のデータベースアクセスが発生しているかをログで確認しました。1画面で50回以上のアクセスが発生していたため、関連データをまとめて取得する形に変更したところ、表示時間が約3秒から0.5秒程度に改善しました。」

「エラーが出た→調べた→直った」ではなく、「どう調べたか」を書いてください。ログを見た、公式ドキュメントを読んだ、仮説を立てて切り分けた。この過程が、実務での動き方の予測材料になります。

材料4：前職での業務改善

最も見落とされる材料です。

これらは全部、要件定義・設計・改善というエンジニアの仕事と同じ構造です。

5. 経験1〜2年の場合：書くべきこと

「担当工程」を明示するのが最も重要です。実装だけなのか、設計から関わったのか、要件定義に同席したのか。ここが曖昧だと、最も狭い範囲で判断されます。

6. 例文6パターン

例文①：営業 → Webエンジニア（未経験）

前職ではSaaS企業の法人営業を2年間担当していました。担当社数は年間約60社です。

業務のなかで、顧客情報を営業支援システムと表計算ファイルの2箇所で管理しており、入力の重複と不整合が常態化していました。表計算側の入力項目を整理し、関数で自動集計する形に変更したところ、週次の集計作業が約4時間から1時間に短縮されました。この経験から、業務の非効率を仕組みで解決することに関心を持ち、開発側に移りたいと考えるようになりました。

現在、Ruby on Railsを6ヶ月間学習しており、読書記録を管理するWebアプリケーションを1本制作しています（ソースコードを公開しております）。制作中、一覧表示が遅くなる問題が発生した際は、ログを確認してデータベースへのアクセス回数が過剰であると特定し、関連データをまとめて取得する形に変更して表示時間を約3秒から0.5秒程度まで改善しました。

実務経験はありませんが、業務の課題をシステムで解決するという視点は、前職と共通していると考えています。

例文②：事務職 → インフラエンジニア（未経験）

前職では総務部で2年間、PCの管理と社内の問い合わせ対応を担当していました。社員約80名分のPC設定、アカウント管理、ネットワークの一次対応が主な業務です。

業務のなかで、新入社員のPC準備に1台あたり約3時間を要していました。手順が担当者ごとに異なっていたため、設定項目を洗い出してチェックリストを作成し、あわせて共通設定を事前に適用したイメージを用意する運用に変更したところ、1台あたり約1時間まで短縮できました。

この経験から、システムを支える側の仕事に関心を持ち、インフラエンジニアを志望するようになりました。現在はLinuC-1を取得済みで、自宅の仮想環境でLinuxサーバーを構築し、Webサーバーの設定とログの確認を実践しています。

構築の過程で、外部から接続できない問題が発生した際は、サーバー側のファイアウォール設定とポートの開放状況を順に確認し、原因を特定しました。切り分けの手順を意識して進めることは、前職の問い合わせ対応でも継続して行ってきたことです。

例文③：SES（経験1年半）→ 自社開発

受託開発企業にて、業務システムの開発を1年半担当しました。使用技術はJava、Spring Boot、PostgreSQLです。3案件に参画し、うち1案件では詳細設計から実装、単体テストまでを担当しました。

直近の案件では、在庫管理システムの検索機能を担当しました。当初の実装では、検索条件が増えるたびに条件分岐が増え、コードの見通しが悪くなっていました。条件の組み立てを共通の処理に切り出す形に変更したところ、機能追加時の修正箇所が1箇所に集約され、その後の追加要望3件をいずれも半日以内で対応できるようになりました。

チームは5名で、日次のコードレビューに参加していました。レビューでは、命名と処理の分割について指摘を受けることが多く、意識的に改善してきました。

現在は受託案件が中心で、リリース後の改善に関わる機会が限られています。自社サービスの継続的な改善に携わりたいと考え、貴社を志望しました。

例文④：販売職 → QAエンジニア（未経験）

アパレル店舗で2年半、販売と在庫管理を担当しました。1日平均70名の接客と、週2回の在庫照合が主な業務です。

在庫照合では、システム上の数値と実在庫の差異が月に10件程度発生していました。差異の内容を3ヶ月分記録して分類したところ、「返品処理の登録漏れ」「セール品の値札貼り替え時の入力ミス」の2つで8割を占めることが分かりました。この2つに絞った確認手順を作成して共有したところ、差異は月2〜3件まで減りました。

この経験から、想定と実際のずれを見つけて原因を特定する作業に手応えを感じ、QAエンジニアを志望するようになりました。現在はテスト設計の基礎を学習しており、同値分割・境界値分析の考え方をもとに、身近なWebサービスのテストケースを作成する練習を続けています。

実務経験はありませんが、差異の原因を分類して手順に落とし込むという進め方は、前職で継続して行ってきたことです。

例文⑤：エンジニア（経験2年）→ より上流へ

受託開発企業にて、Webアプリケーションの開発を2年間担当しました。使用技術はPHP、Laravel、MySQL、AWS（EC2、RDS）です。5案件に参画し、うち2案件では要件定義の打ち合わせに同席し、画面設計から実装までを担当しました。

直近の案件では、クライアントの要望が「一覧を見やすくしてほしい」という抽象的なものでした。実際の運用を伺ったところ、1日に何度も同じ条件で絞り込んでいることが分かり、検索条件の保存機能を提案しました。実装後、クライアントの作業時間が1日あたり約30分削減されたとの報告を受けています。

この経験から、要望をそのまま実装するのではなく、実際の業務を確認したうえで解決策を設計する部分に関心を持ちました。

貴社では、開発担当が顧客との要件定義から関わると伺っています。実装の経験を土台に、上流工程まで担当範囲を広げていきたいと考えています。

例文⑥：異業種 → 社内SE（未経験）

前職では製造業の生産管理部門で、生産計画の作成と進捗管理を2年間担当しました。取扱品目は約300点、月次の生産計画を作成していました。

業務のなかで、生産計画の作成に月あたり約20時間を要していました。各工程の担当者から表計算ファイルで情報を集め、手作業で統合していたためです。入力フォーマットを統一し、集計用のファイルに自動で反映される形に変更したところ、作成時間を月8時間程度まで短縮しました。

この取り組みを通じて、業務の流れを理解している人がシステム側に立つことの価値を実感し、社内SEを志望するようになりました。現在は基本情報技術者を取得しており、あわせて業務システムの選定について学習しています。

エンジニアとしての実務経験はありませんが、製造現場の業務フローを理解していることと、非効率を見つけて手順から変えてきた経験は、社内システムの企画・導入で活かせると考えています。

7. 落ちる自己PRの型5つ

5番目について補足します。「未経験なので、前職の話は関係ない」と考えて職務経歴を薄く書く人がいますが、これは最も大きな損失です。

前職の業務知識は、エンジニアとして働くときの武器になります。営業出身ならCRM、経理出身なら会計システム、製造出身なら生産管理システム。その領域の業務が分かるエンジニアは、どの会社でも不足しています。

8. 面接で追撃される3つの質問

Q1.「その設計にした理由を教えてください」

ポートフォリオを提出すると、必ず来ます。「教材の通りに作りました」は避けてください。1箇所でいいので、自分で判断した箇所を用意しておいてください。「テーブルを分けた理由」「この機能を追加した理由」など。

Q2.「詰まったとき、どうやって解決しましたか」

実務での動き方を測る質問です。「調べました」だけでは不十分です。「エラーメッセージで検索した」「公式ドキュメントを読んだ」「ログを出して切り分けた」など、具体的な手段を答えてください。

Q3.「これから何を学びたいですか」

「幅広く学びたい」は落ちます。応募先で使われている技術を求人票から確認し、「◯◯を業務で使えるレベルまで習得したいです」と具体的に答えてください。

9. よくある質問

ポートフォリオは何本必要ですか？

1〜2本で十分です。本数より、「なぜその構成にしたか」を説明できることのほうが重要です。3本の説明できない作品より、1本の説明できる作品のほうが評価されます。

教材の通りに作ったものでもいいですか？

そのままでは弱いです。教材で作ったものに、自分で1つ機能を追加してください。そして、その追加部分について「なぜ追加したか」「どう実装したか」を説明できるようにしてください。この1つがあるかないかで、面接の内容が変わります。

学習期間はどのくらい必要ですか？

Webアプリ系なら300〜500時間が目安です。期間で言えば3〜6ヶ月。ただし、期間より「今、何ができる状態か」が見られます。自己PRには期間ではなく到達点を書いてください。

前職と関係ない領域を志望する場合、業務経験は書くべきですか？

書いてください。直接の関連がなくても、「業務の課題を見つけて改善した経験」はエンジニアの仕事と同じ構造です。また、チームで働いた経験、期日を守った経験も評価対象になります。

資格は自己PRに書くべきですか？

書いてください。特にインフラ系（LinuC、CCNA、AWS認定）と基本情報技術者は、実務未経験の場合に「独学で継続できた証明」として機能します。ただし、資格だけを並べるのではなく、そこで学んだことを実践した内容とセットにしてください。

GitHubのアカウントは必須ですか？

必須ではありませんが、あると明確に有利です。ソースコードが読める状態になっていること、READMEに設計の意図が書かれていることが評価されます。また、学習の継続がコミット履歴で見えるという副次的な効果もあります。

実務経験1年でも「経験者」として応募できますか？

できます。ただし、多くの求人が「実務経験2年以上」を条件にしているため、応募できる範囲は限られます。1年の場合は、担当した工程と技術を具体的に書き、「何ができるか」を明確にしてください。第二新卒歓迎の求人も併せて探すと選択肢が広がります。

チーム開発の経験がありません。

個人開発でも、書き方で補えます。「他の人が読むことを想定してREADMEを整備した」「コミットメッセージを規則に沿って書いた」など、チームで働くことを意識した形跡を示してください。また、前職でのチームワークの経験を書くことも有効です。

10. まとめ：今夜やる3つのこと

エンジニアの自己PRは、「学習意欲」から離れた瞬間に強くなります。判断と、詰まった過程を書いてください。

今夜やること

① 作ったもの（または学習中の内容）で、「自分で判断した箇所」を1つ書き出す（なぜその構成にしたか）

② 学習中に「詰まって解決した場面」を1つ思い出し、調べた手順まで書く（エラーメッセージ、ドキュメント、ログ）

③ 前職で「業務の非効率を見つけて改善した経験」を1つ書く（表計算の自動化、手順書の作成、二重入力の解消）

②と③が、未経験エンジニアの自己PRで最も差がつく材料です。ポートフォリオの完成度を上げるより、この2つを書くほうが、書類の通過率に効きます。

この先、読むべき記事

• 未経験エンジニアのポートフォリオ｜第二新卒が評価されるのは「何を作ったか」ではない（成果物の作り方）
• 未経験エンジニアの志望動機｜第二新卒が通る例文6パターンと落ちる書き方（志望動機の書き方）
• 未経験エンジニアの面接｜第二新卒が聞かれる想定問答13と評価される答え方（面接の準備）
• 未経験職種の自己PR｜第二新卒が経験を翻訳する3手順と例文7パターン（翻訳の手順）

この記事を書いた人

木戸 悠介（きど ゆうすけ）／なぜキャリア？運営者。

23歳で上場企業子会社に新卒入社し、飲食・宿泊・レジャー領域のメディア広告営業を担当。25歳で第二新卒として障がい福祉領域のSaaS企業へ転職し、営業から営業企画へ職種を変えた経験を持つ。2ヶ月で10社に応募し2社から内定。現在は自分の会社を経営している。