Javaエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
Javaエンジニアのスキルシートは、JavaとSpringなどのバージョン、担当した工程、チームの規模と自分の立場をプロジェクトごとにそろえて書き、担当内容には「何を作ったか」に加えて「どんな技術の判断をしたか」を書くのが基本です。Javaの案件はチームで進む中〜大規模の開発が多く、読み手は「この人を、どの工程の、どの役割に入れられるか」を短い時間で判断しようとします。
独立までの準備や出身ごとの違いはJavaエンジニアがフリーランスになるには、案件で問われる技術の中身はJavaエンジニアのスキルの記事で扱っています。この記事では、それをシートの上でどう見せるかに絞って解説します。
スキル一覧はバージョンと使い方を添える
Javaの読み手は、スキル一覧で技術の世代を確かめます。「Java」「Spring」とだけ書くと、古いバージョンの保守が中心なのか、新しい環境で開発してきたのかが分かりません。バージョンと、どう使ったかを括弧で添えます。
記入例（架空）：
| 区分 | 書き方 |
|---|---|
| 言語 | Java（8・11・17、計8年。直近3年は17で設計から担当）、Kotlin（1年・API開発） |
| フレームワーク | Spring Boot（2系・3系、5年）、Spring Security（認証・認可の設計）、Spring Batch（2年） |
| データアクセス | MyBatis（4年）、JPA（2年・性能の調査を含む） |
| アプリケーションサーバー | 組み込みのサーバー、従来型のアプリケーションサーバー（保守） |
| DB | Oracle（5年・SQLの調整）、PostgreSQL（3年・設計） |
| ビルド・テスト | Maven、Gradle、JUnit、Mockito |
| 開発の進め方 | Git、プルリクエストでのレビュー、CI |
| クラウド | AWS（コンテナでの実行環境の構築と運用） |
バージョンは、使った範囲を書けば十分です。全部の細かい版を書く必要はありませんが、主な世代（Java 8か17以降か、Spring Bootの2系か3系か）は読み手がよく確かめる点なので、はっきり書いておきます。
社内独自のフレームワークは「中身」で書く
SIerや大きな会社では、社内で作った独自のフレームワークで開発していることがあります。その名前をそのまま書いても、社外の読み手には伝わりません。中身を一般的な言葉で書きます。
- 書き換え前：社内フレームワーク○○（5年）
- 書き換え後：Spring MVCをもとにした社内共通のフレームワーク（画面・バッチ）で開発（5年）。共通部品の改修にも参加
もとになっている技術や、どの層（画面、業務ロジック、データアクセス、バッチ）を担っていたかを書くと、一般的なフレームワークに置き換えたときの経験として読んでもらえます。
工程は表記をそろえて示す
Javaの業務システムの案件では、工程の名前で役割を判断することが多くあります。プロジェクトごとに工程の表記がばらばらだと、読み手は比べにくくなります。シート全体で工程の名前を一つに決め、プロジェクトごとに担当した工程に印をつける形にすると、一目で伝わります。
| 要件定義 | 基本設計 | 詳細設計 | 実装 | 単体テスト | 結合テスト | 総合テスト | 運用・保守 |
|---|---|---|---|---|---|---|---|
| ◯ | ◯ | ◯ | ◯ | ◯ |
Web系の開発で工程の区切りがはっきりしていなかった場合は、無理に当てはめず、「設計」「実装」「テスト」「リリース・運用」のように大きく分けたうえで、担当内容に具体的に書きます。設計に関わった場合は、作った設計書の種類（画面設計書、API仕様書、テーブル定義書、バッチの設計書など）を書くと、どの粒度の設計を任せられるかが伝わります。
規模と立場は「全体」と「自分のチーム」を分ける
Javaの大きなプロジェクトでは、全体で数十人以上が関わり、その中にいくつものチームがあることがあります。「規模：50名」とだけ書くと、自分がその50名をまとめていたように読めてしまいます。
- プロジェクト全体の規模：おおまかな人数
- 自分のチームの規模：何人のチームか
- 自分の立場：メンバー、サブリーダー、リーダー
- 担った管理の範囲：レビュー、タスクの割り振り、進捗の報告など
このように分けて書くと、リーダーの経験がある方は、何人をどこまで見ていたかが正しく伝わります。
担当内容には技術の判断を書く
Javaのシートで差がつくのは、担当内容の書き方です。「〇〇機能の設計・実装を担当」だけでは、どの深さで関わったかが伝わりません。担当した範囲に加えて、自分が判断したことを一言添えます。
| 書き換え前 | 書き換え後（架空） |
|---|---|
| API開発を担当 | 受注のAPIの設計と実装を担当。同時更新への対策として楽観ロックを採用し、競合時のエラーの返し方を決めた |
| バッチ開発を担当 | 夜間の集計バッチを設計。途中で失敗したときに途中から再実行できるよう、処理の単位を区切った |
| 性能改善を担当 | 画面の表示が遅い原因をSQLの実行計画から特定し、インデックスの追加と取得の仕方の見直しで改善した |
| バージョンアップを担当 | JavaとSpring Bootの版上げで、依存ライブラリの洗い出しと、名前空間の変更への対応を担当 |
成果を数字で書ける場合は、処理時間の変化などを書くと伝わりやすくなります。ただし、利用者の数や取引の件数など、発注元の事業に関わる数字は書かないでください。書いてよい範囲はスキルシートと守秘義務の記事で扱っています。
記入例（架空）
次は、書き方の型を示すための例です。業種と規模はぼかしてあり、実在のプロジェクトではありません。
期間：20XX年7月〜翌年12月（1年6か月）
案件概要：保険業向け 契約管理システムのバージョンアップと機能追加
規模・立場：プロジェクト全体は数十名規模。自分は開発チーム5名のリーダー
担当工程：基本設計、詳細設計、実装、単体テスト、結合テスト
使用技術：Java 8から17、Spring Boot 2系から3系、MyBatis、Oracle、Maven、Git
担当内容：版上げの影響調査として、依存ライブラリと非推奨のAPIを洗い出し、対応の方針を作成。契約の変更を扱う機能の設計と実装。メンバーのレビューとタスクの割り振り
工夫・成果：影響調査の結果を一覧にし、対応の要否を機能の担当者と分担して確認できるようにした。版上げ後の結合テストで見つかった不具合の原因を、ライブラリの挙動の違いまで特定した
実際に書くときは、ご自身の経験に置き換えてください。
古い経歴と新しい経歴の並べ方
Javaの経歴が長い方は、Java 8以前や従来型のアプリケーションサーバーでの経験が多くを占めることがあります。古い技術の経験も、保守や移行の案件では強みです。ただし、すべてを同じ分量で書くと、直近の経験が埋もれます。
- 直近の数年：上の記入例の形で、くわしく書く
- それより前：期間、業種、立場、主な技術を1〜2行にまとめる
- 移行の経験：古い版から新しい版への移行に関わった場合は、古い経歴の中でも、移行前と移行後の版が分かるように書く
要約の欄では、応募する案件の技術の世代に合わせて、どの経験を上に置くかを入れ替えます。新しい案件に応募するなら直近の版での経験を、保守や移行の案件なら古い版での経験の長さを、先に書くと伝わります。
GitHubや個人の開発の扱い
Web系の案件では、GitHubのアカウントや個人で作ったものを求められることがあります。載せる場合は、次の点に気をつけます。
- 業務で書いたコードは載せない：発注元や前職の権利と守秘義務に関わるため
- 個人の開発は経歴と分ける：プロジェクト欄ではなく、別の欄に「個人の開発」として書く
- 学習中の技術は区別する：実務で使っていない技術は「学習中」「個人の開発で使用」と書き、実務の経験年数に含めない
個人の開発は、新しい技術を自分で試していることの裏付けになりますが、実務の経験の代わりとして読まれることは多くありません。あくまで補う材料として書きましょう。
よくある質問
古いバージョンの経験ばかりで、新しい版の経験がありません。
古い版での経験も、保守や移行の案件では評価されます。版を正直に書いたうえで、業務の理解、設計書の作成、性能の調査など、版に関係なく生かせる経験を担当内容にくわしく書きましょう。新しい版を学んでいる場合は、実務の経験と分けて「学習中」と書いておくと、面談で食い違いが起きません。
テスト工程が中心の経歴です。どう書けばよいですか？
テストの経験も、書き方で伝わり方が変わります。テストの観点を作ったのか、テスト仕様書を書いたのか、自動テストを作ったのか、不具合の原因を調べて直したのかを分けて書きましょう。実装や設計にも少しでも関わった経験があれば、工程の印と担当内容に書いておくと、次の案件で担える範囲が広がります。
Kotlinの経験はJavaのシートに書いてよいですか？
書いてかまいません。スキル一覧の言語の行に、Javaとは分けて経験年数と使い方を書きます。Springで使っていた場合は、プロジェクト欄にもJavaとどう組み合わせていたかを書くと、JVMの上での開発の経験として読んでもらいやすくなります。