スキルシートの書き方｜書類で落ちないエンジニア経歴書の構成

スキルシートで落ちるとき、原因は経験不足だけではありません。同じ経歴でも、書き方が変わるだけで面談まで進むことがあります。読み手は限られた時間で「この人に何を任せられるか」を判断しています。そこが読み取れない書類が落ちます。

読み手が3分で探している4つの情報

企業や営業担当は、スキルシートから次の4点を探しています。

1. どの工程を、どこまで一人でやれるか
2. 使える技術の深さ（触ったことがある、なのか、設計判断ができる、なのか）
3. チームの中でどう振る舞うか
4. すぐ入って立ち上がれそうか

書く順番もこの優先度に合わせます。最初のページに「要約」「主要スキル」「直近2件の案件」を置き、古い案件は後半にまとめてください。時系列で古い順に並べる形式は、読み手が知りたい情報に最後までたどり着けません。

全体構成のテンプレートと、冒頭の要約の書き方

• 冒頭の要約（3〜5行）
• 主要スキルと経験年数（言語、フレームワーク、インフラ、DB）
• 得意領域と担当できる工程
• 案件経歴（新しい順）
• 資格、発信、その他

案件1件あたりの記載項目は次の形に揃えます。

• 期間、業界、チーム規模、自分の役割
• 対象システムの概要（1〜2行）
• 担当した工程と具体的な作業
• 技術構成
• 工夫した点や課題への対応

冒頭の要約は3〜5行で、事実だけを並べる

1ページ目の冒頭にある要約は、読み進めてもらえるかを決める部分です。抽象的な自己PRではなく、事実を並べます。

悪い例は「コミュニケーションを大切にし、常に新しい技術を学ぶ姿勢を持っています。チームに貢献できるよう努力します。」といった文章です。誰にでも書けるため、判断材料になりません。

良い例は次のような書き方です。

「Webアプリケーションのバックエンド開発を5年経験しています。JavaとSpring Bootでの新規設計・実装が中心で、直近2年はAWS上での構成設計と性能改善も担当しました。要件定義から参加した案件が3件あり、非エンジニアの担当者との仕様調整も行っています。」

「何を、何年、どの深さで」を並べるだけで、要約は機能します。人柄は面談で伝わるため、書類では事実に絞ってください。

悪い例と良い例：作業の羅列を判断の記述に変える

悪い例 「ECサイトの開発。Java、Spring Bootを用いて機能実装、テストを担当。」

これでは、何をどこまでやったのかが分かりません。読み手は判断できないので、より情報量の多い候補者を選びます。

良い例 「会員数約30万規模のECサイトの注文機能を担当。要件のヒアリングから詳細設計、実装、単体・結合テストまでを一人で担当しました。注文確定処理で在庫の二重引き当てが発生していたため、更新処理を悲観ロックから在庫テーブルの更新条件付きUPDATEに変更し、日次の問い合わせ件数を大きく減らしました。」

差は「規模」「担当範囲」「起きていた問題」「取った手段」「結果」が入っている点です。数字は分かる範囲で構いません。分からない場合は「大きく減りました」でも、書かないよりはるかに伝わります。

悪い例と良い例：スキル一覧の書き方

悪い例 「Java / Python / Go / TypeScript / PHP / Ruby / Kotlin / Swift」

並べるほど強く見える気がしますが、逆効果です。どれも浅いのだろうと判断されます。

良い例 - Java（5年／Spring Bootでの新規設計・実装、性能改善） - TypeScript（3年／React・Next.jsでの画面実装、状態管理設計） - Python（1年／バッチ処理の保守、業務での改修経験あり） - Go（学習中／個人開発でAPI1本を実装）

経験年数と「どこまでできるか」をセットで書けば、誇張せずに強みが伝わります。学習中のものを学習中と書くことは、信頼を落とさずに幅を示せる書き方です。

通過率を下げる落とし穴と、提出前チェック

まず、通過率を下げやすい5つの状態を潰します。

• 期間の空白を説明していない（学習期間なら「〇〇を学習」と1行入れる）
• 案件ごとの分量がバラバラで、直近が最も薄い
• 略語や社内用語をそのまま使っている
• ファイル名が「スキルシート.xlsx」のまま（氏名と更新年月を入れる）
• 更新日が古く、直近の案件が載っていない

そのうえで、提出前に次の6点を確認してください。

1. 1ページ目だけで「何ができる人か」が分かるか
2. 直近2件の案件に、判断や工夫の記述が入っているか
3. スキル一覧に習熟度が付いているか
4. 担当工程が「設計から」なのか「実装から」なのか明示されているか
5. 秘密保持に触れる固有名詞を書いていないか（業界と規模で置き換える）
6. 誤字と表記ゆれ（Java Script、MySql など）がないか

面談で聞かれることを想定して書く

スキルシートは面談の台本でもあります。書いた工夫について「なぜその方法を選んだのか」「他の案は検討したのか」は高い確率で聞かれます。書いた内容はすべて、口頭で3分説明できる状態にしておいてください。説明できない記述は削るほうが安全です。

まずは直近1件を、上の「良い例」の型で書き直してみてください。1件でも書き換わると、残りの案件も同じ粒度に揃えやすくなります。