☕ JavaSteps Java と Web 開発を順番に学べる学習サイト
最初から学ぶ
基本 なし 約10分

ポートフォリオの作り方

Spring Boot CRUD アプリと GitHub を、未経験就職で伝わる形に整える方法を整理する。README の書き方、コミット履歴の見せ方、現実的な完成ラインまでを扱う。

Spring Boot で CRUD アプリを作った。GitHub にもコードを上げた。では、それを就職活動でどう見せるか。

この記事では、「何を作るか」ではなく「どう伝えるか」を整理します。未経験からの就職で、手元の Spring Boot CRUD アプリと GitHub をどう活用するかに絞って進めます。

ポートフォリオの役割

ポートフォリオとは、自分のスキルや成果物を見せるための作品集です。IT 就職では、GitHub 上のコードやアプリがポートフォリオの中心になることが多いです。

未経験からの就職活動では、実務経験がないぶん「何ができるか」を口頭だけで伝えるのが難しくなります。動く成果物と、それを説明する GitHub リポジトリがあると、採用側が短時間でスキルや取り組み方を確認しやすくなります。

ただし、ポートフォリオがあれば必ず採用されるわけではありません。企業や職種によって、ポートフォリオの重みは異なります。Web 系・自社開発の企業では重視される傾向がありますが、SIer や受託開発ではそこまで求められない場合もあります。

この記事では「ポートフォリオは必須」とは言いません。ただ、未経験で実務経験が薄いほど、動く成果物と GitHub は強い補助線になりやすい、という前提で進めます。

GitHub README に書く項目

README（README.md）は、リポジトリのトップに置く説明文です。GitHub ではリポジトリを開いたときに最初に表示されるため、採用側が最初に読む場所になりやすいです。

README がないリポジトリ、または「Spring Boot のアプリです」の1行だけのリポジトリは、見る側にとって手がかりが少なすぎます。何のアプリか分からないまま、わざわざコードを読み解いてくれる人は多くありません。

README に書く項目を整理します。

アプリの概要

「誰のどんな不便を解決するアプリか」を1〜2文で書きます。

## 概要

日々の学習記録を登録・管理できる Web アプリです。
学習時間と内容をフォームから登録し、一覧・編集・削除ができます。

想定ユーザーは1人に絞ると書きやすくなります。「学習記録を毎日残したい初学者」「タスクを整理したい個人ユーザー」のように、具体的な人物を想像してください。

画面キャプチャ

アプリの画面を3〜5枚に絞って載せます。枚数が多すぎると散漫になるので、代表的な画面に絞るのがポイントです。

載せる候補の例:

  • 一覧画面
  • 登録画面
  • 編集画面
  • バリデーションエラーの表示
  • ログイン後の画面（認証を実装している場合）

画面キャプチャだけでは「見た目はきれいだけど中身が分からない」になりやすいので、次の機能一覧や技術スタックとセットで効果が出ます。

機能一覧

アプリにどんな機能があるかを箇条書きで整理します。

## 機能一覧

- 学習記録の一覧表示（ページング付き）
- 学習記録の新規登録
- 学習記録の編集・削除
- 入力バリデーション（未入力・文字数上限）
- 日付による絞り込み検索

「できること」を具体的に並べると、アプリの規模感が伝わります。

技術スタック

アプリに使っている技術の一覧です。言語、フレームワーク、DB、テンプレートエンジン、ビルドツールなどを並べます。

このサイトの流れで作った Spring Boot アプリなら、まずは学習記事と同じ標準構成をそのまま書けば十分です。あとから PostgreSQL などに発展させた場合は、その差分を README に追記します。

## 技術スタック

| カテゴリ | 技術 |
|----------|------|
| 言語 | Java 25 |
| フレームワーク | Spring Boot 4.x |
| 画面 | HTML / CSS / JavaScript（fetch） |
| ORM | Spring Data JPA |
| DB | H2 Database |
| ビルド | Maven |
| バージョン管理 | Git / GitHub |

自分が実際に使ったものだけを書いてください。 この表はこのサイトの主線で作るアプリの構成です。Thymeleaf や Bootstrap のように、使っていない技術を「よく見るから」と足すと、採用側がリポジトリを開いたときに説明と実装が食い違います。ポートフォリオで信頼を得るための README で信頼を落とすことになるので、追加した技術がある場合だけ行を足す、という使い方をしてください。

技術選定理由

技術スタック（アプリに使っている技術の一覧）を並べるだけでなく、「なぜその技術を選んだか」を一言ずつ添えます。

## 技術選定理由

- **Spring Boot**: 設定をまとめやすく、CRUD アプリの構築に集中できる
- **Spring Data JPA**: DB 操作のコードを整理しやすく、基本的な CRUD を少ないコードで実装できる
- **Thymeleaf**: Spring Boot との統合が標準で用意されていて、サーバーサイドレンダリングの学習に適している
- **Bootstrap**: CSS を一から書かなくても画面を整えやすく、レスポンシブ対応も最小限の手間で実現できる
- **H2 Database**: 追加インストールなしで動かせるため、学習用の CRUD アプリをすぐ確認しやすい

「学習中なので」「よく使われているから」だけでは理由として弱くなります。短くてよいので、その技術を使って何が楽になったか、何に適していたかを書きます。

起動手順・環境変数・確認方法

起動手順は省略しがちですが、省略すると「このアプリは動かせるのか？」という疑問を残します。採用側が手元で動かすかどうかに関わらず、起動手順が書いてあること自体が「動く状態で管理している」という信頼につながります。

このサイトの標準構成では、Java 25、Spring Boot 4.x、Maven Wrapper、H2 Database を使います。まずはその前提で README を書き、外部 DB やデプロイ設定を追加したら後から追記する形で十分です。

書く項目:

  • 前提となる環境（JDK のバージョン、DB の種類）
  • DB の準備手順（H2 なら不要、外部 DB なら作成手順）
  • 環境変数の設定（外部 DB や API キーを使う場合）
  • 起動コマンド
  • 起動後の確認方法（ブラウザで何にアクセスするか）
## 起動手順

### 前提

- JDK 25
- Maven Wrapper（`mvnw` / `mvnw.cmd`）
- H2 Database（追加インストール不要）

### DB のセットアップ

このサイトの標準構成では H2 Database を使うため、別途 DB サーバーを用意しなくても起動できます。

### 環境変数

H2 のままなら、環境変数の説明は必須ではありません。PostgreSQL など外部 DB を使う場合だけ、次のような値を README に追記します。

| 変数名 | 説明 | 例 |
|--------|------|----|
| DB_URL | DB の接続 URL | jdbc:postgresql://localhost:5432/learning_log |
| DB_USERNAME | DB のユーザー名 | postgres |
| DB_PASSWORD | DB のパスワード | password |

### 起動

**Windows の場合**

```text
.\mvnw.cmd spring-boot:run

macOS / Linux の場合

./mvnw spring-boot:run

確認

ブラウザで http://localhost:8080 にアクセスし、一覧画面が表示されれば起動成功です。


H2 のままでも、起動手順が省略なく書かれていれば十分に伝わります。PostgreSQL などへ発展させた場合は、その時点で接続設定や環境変数を追記してください。

環境変数に実際のパスワードやトークンを書かないように注意してください。サンプル値を載せ、実際の値は各自で設定するよう案内します。

## コミット履歴・Issue・Pull Request の見せ方

コミット履歴は「量」より「粒度」と「メッセージ」が見られやすいです。1コミットで何百行も変えているより、変更の意味が追える単位でコミットされているほうが印象がよくなります。

### コミットメッセージ

何を変えたかが伝わる形にします。

伝わりにくい例:

```text
update
fix
修正
いろいろ変更

伝わりやすい例:

feat: 学習記録の新規登録機能を追加
fix: バリデーションエラー時にフォームの入力値が消える問題を修正
refactor: 一覧取得処理を Service クラスに移動
docs: README に起動手順を追加

先頭に feat / fix / refactor / docs のような種別を付けると、変更の種類が一目で分かります。

Issue と Pull Request

個人開発でも、Issue と Pull Request（PR）を使うと「計画を立てて進めている」ことが伝わります。

  • Issue: 「登録機能を実装する」「バリデーションを追加する」のように、やることを1つずつ Issue に書く
  • ブランチ: feature/add-create-form のように、Issue に対応するブランチを切る
  • Pull Request: ブランチの作業が終わったら PR を作り、main にマージする

main ブランチに直接コミットし続けるより、この流れのほうが開発の進め方を理解していることが伝わります。過去のコミットをすべてやり直す必要はありませんが、これから追加する機能や修正で意識するだけでも履歴は変わります。

よくある弱い見せ方

採用側から見て「もったいない」と感じやすいパターンを整理します。

README がない・1行だけ

コードがあっても、何のアプリか分からなければ評価のしようがありません。README は最初に読まれる場所です。

チュートリアルをそのまま公開している

Spring Boot の公式チュートリアルや書籍のサンプルコードをそのまま置いているだけでは、「写しただけ」に見えやすくなります。テーマを変える、フィールドを追加する、表示を工夫するなど、自分なりの変更が1つでもあると印象が変わります。

動かない状態で公開している

起動手順が書いてない、依存関係が壊れている、DB の設定が抜けている。こうした状態は「管理できていない」という印象につながります。公開するなら、動く状態を維持してください。

コミット履歴が「initial commit」の1回だけ

全コードを一括でコミットしていると、開発の過程が見えません。機能ごと、画面ごとなど、変更の単位が追える履歴のほうが伝わります。

秘密情報をコードに含めている

DB のパスワード、API キー、トークンなどがコードに直接書かれていると、セキュリティの意識を疑われます。環境変数や設定ファイル（.gitignore で除外）を使って管理してください。

1本を完成させる価値

「作品が1本しかない」と不安になるかもしれません。しかし、複数のソースで共通して言われているのは、説明が不足した複数の作品より、1本の完成された作品のほうが伝わりやすいということです。

「完成」とは、高度な機能を詰め込むことではありません。

  • アプリが動く
  • README で概要・機能・技術・起動方法が説明されている
  • コミット履歴から開発の流れが追える
  • 改善予定があるなら README に書いてある

この状態に到達していれば、1本でも十分に伝わります。

改善予定を README に書くことは、未完成を隠すより誠実です。「何が未対応で、次に何を直すか」が明示されていれば、課題を把握して優先順位をつけられる人だと伝わります。

このサイト読者向けの現実的な完成ライン

このサイトで Spring Boot まで学んだ読者が目指す完成ラインを整理します。

最低限のライン

  • Spring Boot CRUD アプリが動く状態で GitHub に公開されている
  • README に概要、機能一覧、技術スタック、起動手順が書いてある
  • コミット履歴が「initial commit」だけではなく、複数のコミットに分かれている

もう一歩進めるライン

  • 技術選定理由が README に書いてある
  • 画面キャプチャが README に貼ってある
  • Issue と PR を使った開発の流れが残っている
  • バリデーションやエラーハンドリングが実装されている
  • 改善予定が README に書いてある

さらに強くするライン

  • テストコードがあり、README に実行方法が書いてある
  • ログイン機能（Spring Security）が実装されている
  • GitHub プロフィールの Bio とピン留めリポジトリが整っている
  • 学習の過程や工夫点をまとめた技術記事がある

すべてをそろえる必要はありません。最低限のラインに達したら、そこで一度止めて応募の準備に移ってください。上の2つのラインを積み上げるのは、応募と並行して余裕があるときだけで足ります。書類に書ける内容が増えるのは、ここから先の作り込みよりも前職の経験の整理のほうです。どこで止めて次に進むかは どこまで学べば応募していいか にまとめています。

チェックリスト

自分のリポジトリを見直すときに使ってください。

README

  • アプリの概要が1〜2文で書いてあるか
  • 想定ユーザーが分かるか
  • 機能一覧があるか
  • 技術スタックが表や箇条書きで整理されているか
  • 技術選定理由が一言ずつ書いてあるか
  • 画面キャプチャが3〜5枚あるか
  • 起動手順が省略なく書いてあるか
  • 外部 DB や API キーを使うなら、環境変数や設定値の説明があるか
  • 起動後の確認方法が書いてあるか
  • 改善予定があるなら書いてあるか

コミット・Git

  • コミットが「initial commit」の1回だけになっていないか
  • コミットメッセージから変更内容が分かるか
  • 秘密情報（パスワード、API キーなど）がコードに含まれていないか
  • .gitignore で設定ファイルやビルド成果物が除外されているか

Issue・PR（できれば）

  • 機能単位で Issue を作っているか
  • Issue に対応するブランチを切っているか
  • PR でマージしているか

アプリの状態

  • 起動手順に従って実際に動くか
  • チュートリアルのコピーではなく、自分なりの変更があるか
  • バリデーションやエラーメッセージが実装されているか

次へ

ポートフォリオの見せ方が整理できたら、手元の Spring Boot CRUD アプリに戻って README を書き始めてください。

完璧を目指す必要はありません。まず README を1回書いて GitHub に上げる。コミット履歴を意識して次の機能を追加する。チェックリストで足りない項目を1つずつ埋める。それだけで、見え方は大きく変わります。