Javaの学習がひと通り終わって、次はポートフォリオを作ろうと思っているのに、「何を作ればいいのかわからない」という状態で止まっていませんか。
とりあえずToDoアプリを作ろうとしているけれど、本当にそれでいいのか不安。スクールの教材は一通りやったけど、転職活動に使えるレベルかどうかの基準がわからない。そういった悩みを抱えている方のために書いた記事です。
結論から言うと、採用担当者がポートフォリオを見るとき、「アプリが動くかどうか」だけを確認しているわけではありません。設計の意図が伝わるか、なぜその題材を選んだか説明できるか、この2点が評価の土台になっています。
この記事では、Javaエンジニアとして転職を目指す方に向けて、評価される題材の選び方・技術スタックの段階的な組み合わせ方・GitHubのREADMEの書き方・面接での伝え方まで、ポートフォリオ作りに必要な情報を一通りまとめました。
この記事でわかること
- 採用担当者がポートフォリオで実際に見ているポイント
- ToDoアプリ以外の評価される題材5選（難易度・所要時間付き）
- 最低限・加点・上級の技術スタック段階別の選び方
- GitHubのREADMEに必ず書くべき5項目と例文
- 面接で「なぜ作ったか」を3文で伝えるフレーム
- 書類選考を落とすNG例7つとその理由
Javaのポートフォリオ、何を作れば転職に通るのか
ポートフォリオを作る前に、まず採用担当者がどういう目線で見ているかを理解しておくことが先決です。「動くものを作れば通る」という認識のままでいると、何時間もかけて作ったものが書類選考で落とされ続ける状況に陥ります。
採用担当者が本当に見ている5つのポイント
採用担当者がポートフォリオで確認すること
- ① デプロイされているか：URLにアクセスして実際に動かせるか
- ② GitHubのコードが読めるか：コミット履歴・ディレクトリ構成・コードの読みやすさ
- ③ READMEに設計の意図があるか：なぜその技術を選んだか・工夫した点が書かれているか
- ④ 題材に独自性があるか：同じものを出している応募者との差別化
- ⑤ 面接で話せるストーリーがあるか：作った理由・苦労した点・学んだことを言語化できるか
コードの品質はもちろん見られますが、未経験者や第二新卒の採用では「その人がどういう思考プロセスで開発したか」が重視されます。コードが不完全でも、なぜその設計にしたかを説明できる応募者のほうが評価されるケースは多いです。
「動くアプリがあれば通る」は大きな誤解
ポートフォリオを1つ仕上げれば書類が通ると思っている方は少なくありません。しかし現実には、動くアプリがあっても書類で落ちているケースは多く、その多くはREADMEが空・デプロイ未対応・題材がスクール教材と区別がつかない、という共通点があります。
採用担当者は1日に数十件の応募を処理しています。ポートフォリオを見る時間は平均で3〜5分程度と言われており、その短時間で判断が下されます。動くかどうかはその判断の前提にすぎず、判断材料はREADMEと面接でのストーリーにあります。
ToDoアプリでは書類選考を通過できない理由
Java学習の定番課題としてToDoアプリがあります。シンプルなCRUD操作を実装するには適した題材ですが、転職用のポートフォリオとして提出するには問題があります。
毎日100人が同じものを提出している現実
ToDoアプリはプログラミングスクールの定番課題です。その結果、Java系の求人に応募してくる未経験者の多くが、同じ構成・同じ機能・似たようなUIのToDoアプリを提出しています。
採用担当者の立場から見ると、「また同じものが来た」という状態です。機能が同じ、見た目も似ている、GitHubのリポジトリ名も似ている。そうなると、個別のコードを丁寧に読む前に、印象として埋もれてしまいます。
ToDoアプリがNG・ToDoアプリが許容されるケースの違い
ToDoアプリ自体が絶対にNGというわけではありません。問題は題材ではなく中身です。
NGになるケース：基本的なCRUD操作だけ実装・デプロイなし・READMEが空・スクールの課題をそのまま提出。
許容されるケース：認証機能・チーム共有機能・通知・カレンダー連携などを追加して発展させている。READMEに「なぜこの機能を追加したか」の説明がある。前職の業務経験と絡めたストーリーがある。
シンプルな題材であっても、そこに自分の意思と工夫の跡が見えるなら評価対象になります。逆に言えば、題材を派手にしても中身が薄ければ意味がありません。
NG題材と推奨される代替案の整理
| NG題材 | 問題点 | 代替案 |
|---|---|---|
| ToDoアプリ（基本CRUD） | 提出数が多く差別化できない | タスク管理＋期限通知＋チーム機能に発展 |
| スクール教材そのまま | 独自開発かどうか判断できない | 題材を変える・機能を独自追加する |
| チュートリアルのコピー | 理解度が測れない | 同じ機能を自分で設計して書き直す |
| フロントのみ（バックエンドなし） | Javaエンジニアとしての評価にならない | Spring Boot＋DB連携まで実装する |
転職市場で評価される題材5選【難易度・所要時間付き】
ここからが記事の核心です。採用担当者に刺さる題材には共通点があります。それは「なぜ作ったか」を話せるストーリーが生まれやすいことです。前職経験と絡めると説得力が増すため、各題材に「どんな経歴の人に向いているか」も合わせて紹介します。
① タスク管理・日程調整アプリ
難易度：中 ／ 所要時間：3〜4週間
ToDoアプリの発展形です。単純なタスク追加・削除だけでなく、期限管理・優先度設定・複数ユーザーでの共有・通知機能を加えることで、採用担当者から見た評価が大きく変わります。
最低限実装すべき機能：ユーザー認証（Spring Security）、タスクのCRUD、期限・優先度の設定、ログイン中ユーザーごとのデータ分離。
前職経験との掛け合わせとして特に有効なのが営業・企画職です。「見積もり管理ツール」「商談フォローアップ管理」など、自分が実際に使っていた業務をシステム化するストーリーを作ると、面接でのエピソードが自然に生まれます。
② ECサイト・ショッピングカート機能
難易度：高 ／ 所要時間：4〜6週間
ECサイトは実務での需要が高く、採用担当者にとって「実際の業務イメージが持ちやすい」題材です。商品一覧・検索・カート追加・購入フロー・注文履歴という一連の流れを実装すると、セッション管理・DB設計・状態管理のスキルをまとめて示せます。
最低限実装すべき機能：商品一覧・詳細ページ、カート機能（セッション管理）、注文処理（トランザクション）、管理者画面（商品追加・在庫管理）、ユーザー認証。
小売・サービス業・接客業の経験がある方は、「自分がスタッフとして困っていた在庫管理の問題をシステム化した」という切り口が有効です。実体験に基づいた題材選定は、面接官の興味を引きやすくなります。
③ 勤怠管理・社内業務システム
難易度：中 ／ 所要時間：3〜5週間
Java案件の多くは、企業の業務システム開発や基幹システムの保守・改修です。勤怠管理・社内ツールの類はJava実務のど真ん中に位置します。この題材を選ぶことで「Javaが使われる現場のイメージを持っている」という印象を与えられます。
最低限実装すべき機能：出退勤打刻・月次集計、社員・部門のマスタ管理、管理者と一般ユーザーの権限分離、CSV出力。
事務職・バックオフィス経験者との相性が特に高い題材です。「Excelで管理していた勤怠表をシステム化した」「手作業だった集計をDBに移した」という切り口は説得力があります。採用担当者から見ても、実務への適応力が伝わりやすい構成です。
④ ブログ・メディアサイト
難易度：中 ／ 所要時間：3〜4週間
ブログサイトは一見地味に見えますが、CRUD全機能・認証・セッション・画像アップロード・記事の公開/下書き管理と、Webアプリの基本要素をほぼ網羅できる題材です。WordPressのような既存CMSとの比較を交えてREADMEに書くと、設計への理解度を示せます。
最低限実装すべき機能：記事の投稿・編集・削除・一覧表示、カテゴリ・タグ、ユーザー認証（管理者のみ投稿可）、コメント機能。
ライター・編集・広報経験者がこの題材を選ぶと、「実際にコンテンツを運用してきた視点から、使いやすいCMSを作りたかった」というストーリーが成立します。
⑤ 家計簿・収支管理アプリ
難易度：中〜高 ／ 所要時間：4〜5週間
家計簿アプリは機能の幅が広く、グラフ表示・外部API連携・日付処理・カテゴリ集計などを加えることで、技術的な深みを表現できます。見た目のわかりやすさもあり、デモとして説明しやすい題材です。
最低限実装すべき機能：収支の入力・編集・削除、月次・カテゴリ別の集計、グラフ表示、ユーザー認証。
グラフ表示まで実装すると、ポートフォリオのデモ画面が視覚的に映えるため、面接時の印象にも直結します。金融・保険・会計事務所経験者はもちろん、「お金の管理を日頃から意識している」という切り口は誰でも使えます。
段階別 技術スタックの選び方【最低限/加点/上級】
「Spring Bootは使うべきか」「AWSまで対応しないと不利か」という疑問を持つ方は多いです。技術スタックは全部入りが良いわけではなく、自分の習熟度と作りたいものに合わせて段階的に積み上げるのが正解です。
| 段階 | 技術要素 | 目的 |
|---|---|---|
| 最低限ライン | Java + Spring Boot + MySQL + GitHub + デプロイ済みURL | 書類通過に必要な最低条件 |
| 加点レベル | JUnit + Docker + Spring Security + REST API | 他の未経験者と差をつける |
| 上級レベル | AWS + CI/CD（GitHub Actions）+ Swagger | 経験者に近い評価につながる |
最低限ライン：Spring Boot + MySQL + GitHub + デプロイ済みURL
Java系の求人に応募する際、ポートフォリオに最低限含まれていないと選考に進めない要素があります。Spring Bootはデファクトスタンダードのフレームワークで、これを使わずに素のServletで書いてしまうと「現場の技術感覚がない」という印象を与える場合があります。
MySQLはRDBの基本であり、Spring Bootとの組み合わせで動かせることを示す意味があります。GitHubは開発の過程を見せる場所で、コードを公開していないと採用担当者が確認できません。そしてデプロイ済みURLがあることで、「このアプリは実際に動く」という信頼感が生まれます。
デプロイ先の選択肢：Render（無料・Spring Boot対応）、Railway、Heroku（有料）など。AWSが難しい段階ではRenderが現実的です。Spring Bootの基礎はSpring Boot入門記事で確認してください。
加点レベル：JUnit・Docker・Spring Security を追加する意味
JUnit（テストコード）：テストを書いている応募者は少数派です。メインの機能に対してテストクラスを1つでも書いてあると「品質意識がある」という評価につながります。
Docker：Dockerfileを置いておくと「環境構築の知識がある」「チーム開発を意識している」という印象を与えられます。アプリをコンテナで動かせる状態にしておくだけで十分です。
Spring Security：認証・認可の実装は多くのWebアプリで必要なスキルです。ログイン機能を実装している場合、Spring Securityを使っているかどうかを採用担当者は確認します。
上級レベル：AWS・CI/CD・Swagger まで対応できると何が変わるか
AWS（EC2やRDS）でのデプロイ、GitHub ActionsによるCI/CDパイプライン、Swaggerを使ったAPI仕様書の作成まで対応できると、未経験者ではなく「即戦力に近い候補者」として扱われます。ただしこのレベルは必須ではなく、学習時間に余裕がある段階で取り組む選択肢です。
「技術を詰め込みすぎる」罠
技術を詰め込みすぎると逆効果になる
- 使い方が分からないまま入れた技術は、面接で即座にバレる
- 技術の種類は多くても、アプリ自体が未完成・動かない状態は最悪の評価
- 「なぜその技術を選んだか」を答えられない技術は逆効果になる
使っている技術すべてについて、選定した理由を1文で言えるかどうかが基準になります。答えられない技術は、むしろ外したほうが安全なケースもあります。
GitHubのREADMEはこう書く【必須5項目・例文付き】
コードを公開するだけでは不十分です。採用担当者がGitHubを開いたとき、まず最初に目に入るのがREADMEです。ここで「何のアプリか」「どう動かすか」「なぜ作ったか」が伝わらなければ、コードを読んでもらえないまま判断が下されます。
採用担当者がREADMEを読む理由
READMEは採用担当者にとってスクリーニングツールです。1日に複数の応募者のGitHubを確認する中で、READMEが整っていないリポジトリは「コードを読む以前に、整理する習慣がない」という印象を与えます。逆に、READMEが丁寧に書かれているだけで「この人はアウトプットを意識している」という評価が先に立ちます。
必須5項目と書き方
READMEに必ず含める5項目
- ① アプリの概要（2〜3文）：何のアプリか・誰のためか・どんな課題を解決するか
- ② 使用技術スタック：言語・フレームワーク・DB・インフラを箇条書きで列挙
- ③ 機能一覧：実装済みの主要機能をリスト形式で
- ④ 環境構築の手順：cloneからローカル起動までの手順（コマンド付き）
- ⑤ 設計の意図・工夫した点：なぜその技術を選んだか・実装で意識したこと
例文（① 概要）：
前職の事務業務でExcel管理していた勤怠データをシステム化したアプリです。Spring Boot + MySQLで構築し、管理者・一般ユーザーの権限分離・月次集計・CSV出力に対応しています。
「設計の意図・工夫した点」を書く箇所が最も差を生む
5項目の中で採用担当者が最も注目するのが⑤です。ここに何も書いていない応募者が多いため、丁寧に書くだけで大きく差がつきます。
書く内容の例：
- Spring SecurityでBCryptによるパスワードハッシュ化を実装した理由
- サービス層・リポジトリ層を分けたディレクトリ構成にした理由
- JUnitでサービスクラスのテストを書いた目的
コードを書いた理由を1〜2文で書くだけで十分です。「こう書いた方がいいと思った」という自分の判断が記録されていると、採用担当者に「考えながら開発できる人」という印象を与えられます。
ポートフォリオ作成の5ステップ【スケジュール付き】
何から手をつければいいか迷っている方向けに、題材決めからポートフォリオ完成までの流れを5ステップで整理します。
STEP1 題材と技術スタックを決める（1〜2日）
題材選びに時間をかけすぎるのは避けましょう。この記事で紹介した5題材の中から、自分の前職経験と結びつけやすいものを選ぶのが最短ルートです。技術スタックは最低限ラインから始め、Spring Boot + MySQL + GitHub + デプロイ先（Renderなど）の構成を決めたら、即座にプロジェクトを立ち上げることが大切です。
STEP2 MVPで一度完成させる（2〜4週間）
MVP（Minimum Viable Product）とは、最低限動く状態のことです。完璧な機能を追加する前に、コアとなる機能だけで一度完成させることが重要です。例えばECサイトなら「商品一覧・カート・注文」だけでも動く状態を作ってからデプロイします。機能を全部揃えてから公開しようとすると、開発が長引いて途中で力尽きる可能性が高まります。
STEP3 GitHubに公開・デプロイする（2〜3日）
コードをGitHubに上げ、本番環境（Renderなど）にデプロイします。コミット履歴が残っていることが重要なので、最初から機能単位でコミットする習慣をつけておくことが理想です。デプロイ後は、自分でURLにアクセスして実際に機能が動くか確認します。
STEP4 READMEを整える（1〜2日）
前のセクションで解説した5項目を書きます。スクリーンショットを撮って画像を入れると、READMEを開いた際の第一印象が大きく変わります。READMEを書くことで、自分がこのアプリで何をどう実装したかを言語化する機会にもなります。書くのに詰まった部分があれば、それが面接で聞かれる部分でもあります。
STEP5 面接で話せるストーリーを3文で作る（1〜2日）
ポートフォリオが完成したら、面接での説明文を準備します。①なぜ作ったか、②何を作ったか、③何を学んだかの3文で話せる状態にしておくことがゴールです。ポートフォリオは作って終わりではありません。面接で話せてはじめて機能します。
面接でポートフォリオをどう説明するか【頻出Q&A付き】
ポートフォリオを提出しても、面接で説明できなければ評価は半減します。採用担当者が必ず聞く質問と、それに対する答え方のフレームを紹介します。競合記事ではほとんど触れられていない部分です。
採用担当者が必ず聞く3つの質問
面接でポートフォリオについて質問される際、以下の3つは必ずと言っていいほど出てきます。
- 「このアプリを作ったきっかけを教えてください」
- 「なぜSpring Bootを使いましたか？」（なぜこの技術スタックにしましたか？）
- 「開発の中で最も苦労した部分はどこですか？」
これらは「ちゃんと自分で考えて開発したか」を確認するための質問です。答えられない場合、スクールの教材をそのまま出しているだけ・コードを理解せず書いたという印象を与えてしまいます。
「なぜ作ったか」を3文で伝えるフレーム
「なぜ作ったか」3文フレーム
- ① 背景（自分の経験・課題）：前職でXXという業務を担当しており、YYという非効率さを感じていました。
- ② 作ったもの：そこで、ZZという機能を持つアプリをSpring BootとMySQLで開発しました。
- ③ 学んだこと：開発を通じて、Spring Securityによる認証設計とJUnitを使ったテストの書き方を実践的に学ぶことができました。
例文：
前職では事務として勤怠データをExcelで管理していましたが、月末の集計作業に毎回2〜3時間かかっている状況を改善したいと思っていました。そこで、勤怠の打刻・月次集計・CSV出力ができるシステムをSpring BootとMySQLで開発しました。開発を通じて、権限管理の設計と集計クエリのチューニングを実践で学ぶことができました。
この構成で話すと、「実体験から課題を見つけて、エンジニアとして解決しようとした人」という印象が伝わります。
技術選定の理由を聞かれたときの答え方
「なぜSpring Bootを使いましたか？」という質問に対して、「スクールで習ったから」「有名だから」という答えでは評価が下がります。
有効な答え方の型：「〇〇という要件に対して、△△という理由で□□が適切と判断しました。」
例：「認証・認可の実装が必要なアプリだったため、Spring Securityとの統合が標準でできるSpring Bootが適切と判断しました。またJava系フレームワークの中で情報量が最も多く、調べながら学習を進めやすかった点も選定理由のひとつです。」
「最も苦労した部分」については、困ったこと→調べたこと→解決方法→学んだことの4ステップで答えると、思考プロセスが伝わります。
よくある失敗と対策【NG例7つ】
書類選考が通らない応募者のポートフォリオには、共通するパターンがあります。以下のNG例に自分が当てはまっていないか確認してください。
NG① スクール教材をそのまま提出
採用担当者の視点
コードを理解して書いたのか、指示に従っただけなのか判別できない。同じリポジトリ構成のものが1日に何件も届いているため、即座に気づく。
スクールの課題として作ったアプリをそのまま提出する応募者は多いですが、採用担当者はすぐに気づきます。問題はスクールで学んだことをベースにすることではなく、それを元に自分で機能を追加・設計を変更していないことです。最低1つ以上の独自機能を加えることで、オリジナルであることを示せます。
NG② デプロイなし・動かない状態で提出
URLがない・アクセスするとエラーが出る・ローカルでしか動かないポートフォリオは、採用担当者が動作確認できません。確認できないものは評価もできないため、実質ゼロ評価になります。Renderを使えば無料でSpring Bootアプリをデプロイできます。
NG③ READMEが空またはほぼ空
リポジトリを開いてREADMEが数行しかない状態は「整理する習慣がない」という印象に直結します。コードがどれだけ優れていても、READMEで第一印象が悪くなると採用担当者がコードを読む前に離脱します。
NG④ 技術を詰め込みすぎて未完成
AWS・Docker・CI/CD・Swaggerを全部入れようとして、アプリ本体の基本機能が動かない状態になっているケースがあります。完成している基本機能 > 動かない最新技術の詰め合わせです。技術を追加するのは、MVPが完成してデプロイが済んでからにしましょう。
NG⑤ コミットメッセージが「fix」「update」だけ
GitHubのコミット履歴は開発プロセスの記録です。「fix」「update」だけのメッセージが並んでいると、何を実装したか・何を修正したかが読み取れません。コミットメッセージは機能単位で書く習慣をつけます。例：feat: ユーザー認証機能を追加、fix: ログイン後のリダイレクト先を修正。
NG⑥ 「なぜ作ったか」を答えられない
面接で「なぜこのアプリを選んだのですか？」と聞かれて答えられないのは、ポートフォリオを「作ること」だけを目的にしていたサインです。題材を決める段階から「なぜこれを作るか」を言語化しておく習慣をつけることが、面接対策の最短ルートでもあります。
NG⑦ リポジトリが1つしかない
GitHubに公開しているリポジトリが1つだけの場合、採用担当者には「この1つしか作っていない」という印象を与えます。学習の過程で書いたコード・練習用のプログラムでも、GitHubに上げておくことで「継続的に開発している人」という印象を作れます。完成度が低いものを公開することに抵抗を感じる方もいますが、リポジトリ数が複数ある方が評価は高くなります。
ポートフォリオ作成をスクールでサポートしてもらう選択肢
独学でポートフォリオを作ることは可能ですが、エラーで詰まったときの解決時間・コードレビューを受けられないこと・転職サポートの有無によって、完成までの時間と質に大きな差が出ます。
スクールでサポートしてもらうことのメリット
スクール活用のメリット
- 現役エンジニアからのコードレビューを受けられる：自己流の書き方・設計の問題点を指摘してもらえる
- 詰まったときの相談先がある：独学ではエラー解決に数日かかるケースも、メンターがいれば数時間で解決できる
- ポートフォリオの評価フィードバックをもらえる：転職に通るレベルかどうかを確認できる
- 転職サポート・求人紹介：スクール経由の求人・面接対策のサポートがある
独学との最大の違いはフィードバックループの速さです。自分では気づけない問題をメンターに指摘してもらいながら修正する経験は、実務でのチーム開発にも直結します。
ポートフォリオ支援が充実しているJava対応スクールの選び方
Java対応スクールを選ぶ際は、Spring Bootがカリキュラムに含まれているか、ポートフォリオのコードレビューが組み込まれているか、転職サポートの実績が公開されているかを確認してください。Java転職に強いスクールの詳細な比較はJava転職に強いプログラミングスクール比較7選でまとめています。
まとめ：Javaポートフォリオで転職を成功させるためのチェックリスト
転職活動に入る前に、以下の項目をすべて満たしているかを確認してください。
| 確認項目 | 状態 |
|---|---|
| 題材がToDoアプリ・スクール教材のままになっていない | □ 完了 |
| Spring Boot + MySQL + GitHubで構築されている | □ 完了 |
| デプロイ済みURLがある（アクセスして動作確認済み） | □ 完了 |
| READMEに5項目（概要・技術・機能・手順・工夫）が書かれている | □ 完了 |
| コミット履歴が機能単位で残っている | □ 完了 |
| 「なぜ作ったか」を3文で話せる | □ 完了 |
| 「技術選定の理由」を1文で答えられる | □ 完了 |
| 「最も苦労した点」を4ステップで答えられる | □ 完了 |
ポートフォリオは完璧に仕上げてから出すものではありません。MVPで一度完成させてデプロイし、転職活動と並行して磨いていく形が現実的です。採用担当者が見ているのは完成度だけでなく、READMEの設計意図・面接でのストーリー・コミット履歴の残し方といった「この人がどう考えて開発したか」です。
Java転職のより広い全体像についてはJavaエンジニア転職完全ガイドを、Java学習の進め方についてはJava独学の始め方と挫折しないコツを合わせて参考にしてください。
