ポートフォリオの作り方【未経験者向け実例付き】

「ポートフォリオって何を作ればいいの?」「チュートリアル通りのアプリじゃダメなの?」「未経験者でも評価されるポートフォリオの条件は?」

未経験からエンジニア転職を目指す方の多くが、ポートフォリオ作成で悩みます。私も31歳で営業職からエンジニア転職を目指した際、何を作れば評価されるのか全くわかりませんでした。

しかし、試行錯誤の末、実用的な課題を解決するアプリを作成したことで、面接では「このポートフォリオは素晴らしい」と高評価を得られました。結果、3社から内定を獲得できました。

この記事では、私が実際に作成したポートフォリオの実例と、未経験者が評価されるポートフォリオの作り方を、具体的に解説します。

なぜポートフォリオが必要なのか
評価されるポートフォリオの5つの条件
私が作成した3つのポートフォリオ実例
レベル別:作るべきポートフォリオ
ポートフォリオ作成の7ステップ
よくある質問と回答
ポートフォリオで避けるべき5つのNG
まとめ:ポートフォリオは未経験者の最強の武器
次に読むべき記事

なぜポートフォリオが必要なのか

未経験者にとって唯一の「実績」

未経験者には実務経験がありません。企業が判断できるのは:

❌ 実務経験(ない) ❌ 開発実績(ない) ⭕ ポートフォリオ(唯一の判断材料)

つまり、ポートフォリオは未経験者の全てです。

書類通過率が2倍以上変わる

私の実体験データ:

ポートフォリオなし(学習初期)

応募:10社
書類通過:0社(0%)
「実績がないので判断できません」と不採用

ポートフォリオあり(3つ作成後)

応募:43社
書類通過:14社(32.6%)
面接でポートフォリオの話が中心に

ポートフォリオの有無で、書類通過率が**0%→33%**に変わりました。

面接の話題の8割がポートフォリオ

面接では、ポートフォリオについて詳しく聞かれます。

実際に聞かれた質問

なぜこのアプリを作ったのか?
技術選定の理由は?
苦労した点は?
どう解決したか?
今後追加したい機能は?

これらの質問に答えることで、問題解決能力・学習意欲・コミュニケーション能力をアピールできます。

評価されるポートフォリオの5つの条件

企業が評価するポートフォリオには、明確な条件があります。

条件1:実際の課題を解決している

NG例:チュートリアルの焼き直し

Todoアプリ
ブログアプリ
SNSクローン

これらは学習には良いですが、ポートフォリオとしては弱いです。

OK例:実用的な課題解決

前職の業務を効率化するツール
自分や家族の困りごとを解決
地域の課題を解決
趣味の管理を便利に

私の例:営業支援ツール

前職の営業時代、「顧客情報がExcelで管理が大変」「案件の進捗が見えない」という課題がありました。

そこで、営業チーム向けの顧客・案件管理アプリを作成。実際に元同僚5人に使ってもらい、フィードバックを反映しました。

面接では、「実際の課題を理解し、解決策を提案できる」と高評価でした。

条件2:コードの質が保たれている

企業は、あなたのコードを必ず見ます。

チェックされるポイント

変数名・関数名が適切か
- NG: data1, func2, x
- OK: customer_name, calculate_total_sales, user_id
コメントが適切に入っているか
- 複雑なロジックには説明
- なぜそうしたかの理由
インデントが揃っているか
- 可読性の基本
- Rubocop等のLinterを使用
テストコードがあるか
- RSpec, Minitestなど
- 重要な機能のテストは必須
エラーハンドリングができているか
- try-catch等の例外処理
- ユーザーにわかりやすいエラーメッセージ

私が実践したこと

Rubocopでコード品質チェック
RSpecでテストカバレッジ70%以上
変数名は必ず英語で意味が通るように
複雑なロジックには日本語コメント

面接で「コードが丁寧で読みやすい」と評価されました。

条件3:GitHubで適切に管理されている

GitHubの使い方も評価対象です。

チェックされるポイント

READMEが充実しているか
- アプリの概要
- 使用技術
- 機能一覧
- 使い方(スクリーンショット付き)
- 環境構築手順
コミットメッセージが丁寧か
- NG: fix, update, aaa
- OK: Add user authentication feature, Fix login error handling
コミット履歴が適切か
- 1機能ごとにコミット
- 大きすぎるコミットは避ける
- コミットの粒度が適切
ブランチ戦略があるか(理想)
- feature/〇〇
- developブランチ
- Pull Requestの活用

私のREADME例

# 営業支援ツール

## 概要
営業チーム向けの顧客・案件管理アプリケーションです。
Excelでの管理の手間を削減し、案件の進捗を可視化します。

## 使用技術
- Ruby 3.2.0
- Rails 7.0.4
- PostgreSQL 14
- RSpec
- Docker

## 機能一覧
- 顧客管理(CRUD)
- 案件管理(ステータス管理)
- 売上予測(グラフ表示)
- 検索機能
- CSV出力

## 実際の画面
(スクリーンショット3枚)

## なぜ作ったか
前職の営業時代、Excelでの管理に課題を感じていました...

## 工夫した点
- ユーザーからのフィードバックを5回反映
- レスポンシブデザイン対応
- テストカバレッジ75%

## 今後の展開
- リマインダー機能の追加
- 売上レポート機能の強化

このREADMEを見せた面接官から「とても丁寧で、開発の背景がよくわかる」と言われました。

条件4:実際に動くデモが見られる

企業は実際に触って確認したいと考えています。

デプロイ方法

Heroku(無料枠あり)
- 最も簡単
- Railsとの相性が良い
- 最近は制限が厳しくなった
Render(無料枠あり)
- Herokuの代替として人気
- デプロイが簡単
- おすすめ
AWS(一部無料)
- 本格的
- 学習にもなる
- 設定は少し複雑
Vercel(フロントエンド向け)
- ReactやNext.js向け
- 無料で高速

私の場合

2つのアプリをHeroku、1つをRenderにデプロイしました。面接では、URLを共有して実際に触ってもらいました。

「実際に動くものを見せられるのは素晴らしい」と評価されました。

条件5:技術選定の理由が説明できる

「なぜその技術を選んだのか?」は必ず聞かれます。

よくある質問

Q: なぜRailsを選んだのですか? A(悪い例): 「なんとなくです」 A(良い例): 「日本語ドキュメントが豊富で、初学者でも学びやすいと判断しました。また、求人数もRailsが多いため、実務で活かせると考えました」

Q: なぜPostgreSQLを選んだのですか? A(悪い例): 「チュートリアルで使っていたから」 A(良い例): 「本番環境で広く使われており、Herokuでもデフォルトのため選択しました。MySQLとも比較しましたが、データ型の豊富さでPostgreSQLを選びました」

技術選定は必ず理由を説明できるように

私は面接前に、使用した全ての技術について「なぜ選んだか」を整理しました。この準備が面接で非常に役立ちました。

私が作成した3つのポートフォリオ実例

実際に作成したポートフォリオを詳しく紹介します。

ポートフォリオ1:営業支援ツール【最も評価された】

概要前職の営業チーム向けの顧客・案件管理アプリケーション

使用技術

Ruby 3.2 / Rails 7.0
PostgreSQL 14
Bootstrap 5
RSpec
Devise(認証)
Chartkick(グラフ)

機能

顧客管理(CRUD)
案件管理(ステータス管理)
売上予測(月次・四半期)
グラフによる可視化
検索・フィルター機能
CSV出力
ユーザー認証

開発期間:3週間

設計:3日
実装:12日
テスト:3日
デプロイ・修正:3日

工夫した点

実際のユーザーからフィードバック
- 元同僚5人に実際に使ってもらった
- 「検索機能がほしい」→追加
- 「CSVで出力したい」→追加
データの可視化
- Chartkickでグラフ表示
- 売上予測が一目でわかる
- ダッシュボード形式
レスポンシブデザイン
- スマホでも見やすい
- 営業は外出先でも確認できる
テストコード
- RSpecでモデル・コントローラーのテスト
- カバレッジ75%

面接での評価

「実際のビジネス課題を理解し、解決策を提案できる視点が素晴らしい。前職の経験を活かせている」

「実際に使ってもらってフィードバックを反映する姿勢が良い。これは実務でも重要」

「コードが丁寧で、テストもしっかり書けている」

このポートフォリオで3社から内定

ポートフォリオ2:読書記録アプリ

概要読んだ本を記録・管理し、読書メモを残せるアプリ

使用技術

Ruby 3.2 / Rails 7.0
PostgreSQL 14
Tailwind CSS
RSpec
楽天ブックスAPI

機能

本の登録(手動・API検索)
読書ステータス管理(読書中・読了・積読)
読書メモ・感想
読書目標設定
読書統計(月間・年間)
タグ機能

開発期間:2週間

工夫した点

外部API連携
- 楽天ブックスAPIで書籍検索
- ISBN入力で自動登録
- 書影も自動取得
統計機能
- 月間読書冊数のグラフ
- ジャンル別分析
- 読書ペースの可視化
UI/UX
- Tailwind CSSで洗練されたデザイン
- カード形式で見やすく
- ドラッグ&ドロップでステータス変更(予定)

面接での評価

「外部APIを使えるのは実務でも重要なスキル」

「UIが洗練されている。デザインセンスもある」

技術的な広がりを示せたポートフォリオ

ポートフォリオ3:地域イベント情報共有アプリ

概要地域のイベント情報を投稿・共有できるアプリ

使用技術

Ruby 3.2 / Rails 7.0
PostgreSQL 14
React 18(フロントエンド)
Google Maps API

機能

イベント投稿
地図表示
カテゴリー別検索
いいね・コメント機能
マイページ

開発期間:3週間

工夫した点

Reactでフロントエンド
- Rails(API) + React(SPA)
- モダンな技術スタック
Google Maps API
- イベント場所を地図表示
- 位置情報検索
非同期通信
- Ajaxでスムーズな操作
- リアルタイム更新

面接での評価

「Rails以外にReactも学習している姿勢が良い」

「Google Maps APIなど、実務で使う技術を経験している」

技術の幅を示せたポートフォリオ

レベル別:作るべきポートフォリオ

学習期間・スキルレベル別に、作るべきポートフォリオを提案します。

レベル1:学習3ヶ月目【最初のポートフォリオ】

目標:基礎的なCRUD操作ができることを示す

おすすめテーマ

タスク管理アプリ
日記アプリ
家計簿アプリ
蔵書管理アプリ

必須機能

ユーザー登録・ログイン
データの作成・表示・更新・削除
検索機能
レスポンシブデザイン

使用技術

Rails(またはPHP、Node.js等)
PostgreSQL(またはMySQL)
Bootstrap(またはTailwind CSS)

開発期間:2週間

レベル2:学習4〜5ヶ月目【実用的なポートフォリオ】

目標:実際の課題を解決し、実用性を示す

おすすめテーマ

前職の業務を効率化するツール
家族・友人の困りごとを解決
地域の課題を解決
趣味の管理を便利に

必須機能

CRUD操作
実用的な機能(グラフ、統計、通知等)
テストコード(カバレッジ50%以上)
デプロイ済み

使用技術

フレームワーク(Rails, Laravel, Express等)
データベース(PostgreSQL, MySQL等)
CSS フレームワーク
テストフレームワーク

開発期間:3週間

レベル3:学習6ヶ月以降【技術力を示すポートフォリオ】

目標:技術の幅と深さを示す

おすすめテーマ

APIを使った実用アプリ
SPA(Single Page Application)
リアルタイム機能(WebSocket等)
複雑なビジネスロジック

必須機能

レベル2の全て
外部API連携
非同期処理
テストカバレッジ70%以上
CI/CD(GitHub Actions等)

使用技術

フロントエンド(React, Vue.js等)
バックエンド(Rails API, Node.js等)
外部API(Google Maps, 楽天API等)
Docker(コンテナ化)
AWS(デプロイ)

開発期間:4週間

ポートフォリオ作成の7ステップ

具体的な作成手順を解説します。

ステップ1:テーマを決める【1日】

テーマ選びの3つのポイント

自分の経験と結びつく
- 前職の業務
- 趣味・興味
- 日常の困りごと
実用性がある
- 実際に使える
- 課題解決につながる
技術的に実現可能
- 今のスキルで作れる
- 調べれば実装できる

私の思考プロセス

「前職で困っていたことは?」 → 「顧客管理がExcelで大変だった」 → 「Webアプリで管理できたら便利」 → 「営業支援ツールを作ろう!」

ステップ2:機能を洗い出す【1日】

機能の優先順位をつける

必須機能(MVP)

顧客登録・一覧・編集・削除
案件登録・ステータス管理
検索機能

あったらいい機能

グラフ表示
CSV出力
通知機能

後回し

モバイルアプリ
多言語対応
高度な分析

最初はMVPに絞ることが重要です。完璧を目指すと、いつまでも完成しません。

ステップ3:画面設計・DB設計【2日】

画面設計

紙に手書きでスケッチ
Figma(無料)で簡単なワイヤーフレーム
画面遷移図

DB設計

テーブル構成
カラム定義
リレーション

私は紙に手書きで設計しました。高度なツールは不要です。

ステップ4:環境構築【1日】

準備するもの

エディタ(VS Code)
Git/GitHub
データベース(PostgreSQL等)
フレームワークのインストール

Dockerを使う場合

docker-compose.ymlを準備
環境の再現性が高い
面接でも評価される

ステップ5:実装【2週間】

実装の進め方

Week 1:基本機能

Day 1-2:モデル作成、マイグレーション
Day 3-4:CRUD実装
Day 5-6:認証機能
Day 7:デザイン適用

Week 2:追加機能とブラッシュアップ

Day 8-9:検索機能、フィルター
Day 10-11:統計・グラフ
Day 12-13:テストコード
Day 14:リファクタリング、デプロイ

毎日GitHubにコミット

コミット履歴は面接で見られます。継続的に開発している証拠になります。

ステップ6:テストコード作成【3日】

テストの優先順位

モデルのテスト(必須)
- バリデーション
- アソシエーション
- メソッド
コントローラーのテスト(推奨)
- CRUD操作
- 認証チェック
統合テスト(できれば)
- ユーザーの操作フロー

最低でもカバレッジ50%以上を目指しましょう。

ステップ7:デプロイとREADME作成【2日】

デプロイ

Heroku/Renderにデプロイ
動作確認
エラー修正

README作成

アプリの概要
使用技術
機能一覧
スクリーンショット
なぜ作ったか
工夫した点

READMEはあなたのプレゼン資料です。丁寧に作りましょう。

よくある質問と回答

Q1:何個作れば十分ですか?

A:最低2個、できれば3個

私の経験:

1個目:基礎的なCRUD
2個目:実用的なアプリ(最も評価された)
3個目:技術の幅を示すアプリ

3個あれば、書類選考はほぼ通過しました。

Q2:チュートリアル通りのアプリはダメですか?

A:学習には良いが、ポートフォリオとしては弱い

チュートリアルは学習過程として重要です。しかし、それをポートフォリオとして提出するのは避けましょう。

解決策

チュートリアルで学ぶ
自分なりにアレンジ
機能を追加
別のテーマで作り直す

Q3:デザインが苦手です。どうすればいいですか?

A:CSSフレームワークを使いましょう

おすすめ

Bootstrap(最も簡単)
Tailwind CSS(モダン)
Material-UI(React向け)

私もデザインは苦手でしたが、Bootstrapを使うことで見栄えの良いUIを作れました。

Q4:コードを書くのが遅く、完成しません

A:完璧を目指さず、MVPで一旦完成させる

60%の完成度で一旦デプロイ

基本機能だけで公開
後から機能追加
完璧を目指すと終わらない

私も最初のポートフォリオは、基本機能だけで公開しました。その後、面接の合間に機能を追加していきました。

Q5:GitHubのスター数が少なくて不安です

A:スター数は全く関係ありません

企業が見ているのは:

コードの質
READMEの丁寧さ
コミット履歴
アプリの実用性

スター数は気にしなくてOKです。

Q6:オリジナリティが出せません

A:あなた自身の経験から考えましょう

質問リスト

前職で困っていたことは?
趣味で不便に感じることは?
家族・友人の困りごとは?
地域で解決したい課題は?

この質問に答えれば、必ずオリジナルなテーマが見つかります。

Q7:エラーが多くて進みません

A:エラーは学習の証拠です

エラー解決のプロセス:

エラーメッセージを読む
Google検索(英語でも)
Stack Overflow, Qiita
公式ドキュメント
15分考えてわからなければ質問

私も500回以上エラーに遭遇しましたが、1つ1つ解決することで成長しました。

ポートフォリオで避けるべき5つのNG

NG1:チュートリアルそのまま

Rails TutorialのTwitterクローンをそのまま提出するのはNGです。

対策

自分なりにアレンジ
機能を追加・削除
デザインを変更
テーマを変える

NG2:動かないアプリ

デプロイしたURLが404エラー、機能が動かない等はNGです。

対策

デプロイ後に必ず動作確認
主要機能は全て動くように
エラーページも用意

NG3:READMEが空っぽ

READMEがない、または「工事中」だけ書いてあるのはNGです。

対策

最低限の情報は必ず記載
スクリーンショットを入れる
なぜ作ったかを書く

NG4:コードが汚い

インデントがバラバラ、変数名が適当等はNGです。

対策

Linter(Rubocop等)を使用
変数名は意味がわかるように
コメントを適切に

NG5:テストコードが全くない

テストコードがないのは、実務を理解していないと判断されます。

対策

最低限のテストは書く
カバレッジ50%以上を目指す
重要な機能は必ずテスト

まとめ:ポートフォリオは未経験者の最強の武器

評価されるポートフォリオの5つの条件

実際の課題を解決している
コードの質が保たれている
GitHubで適切に管理されている
実際に動くデモが見られる
技術選定の理由が説明できる

作成の7ステップ

テーマを決める(1日)
機能を洗い出す(1日)
画面設計・DB設計(2日)
環境構築(1日)
実装(2週間)
テストコード作成(3日)
デプロイとREADME作成(2日)

私の結果

ポートフォリオ:3個作成
開発期間:合計8週間
書類通過率:0%→33%
内定:3社

最後に

ポートフォリオは、未経験者にとって唯一の実績であり、最強の武器です。

私も最初は「何を作ればいいかわからない」と悩みました。しかし、前職の経験を振り返り、実際の課題を解決するアプリを作ったことで、面接では高評価を得られました。

完璧を目指す必要はありません。60%の完成度で一旦公開し、フィードバックをもらいながら改善していく姿勢が大切です。

この記事のステップに従って、まずは1個目のポートフォリオを作ってみてください。2週間後、あなたは成長した自分に出会えるはずです。

応援しています!

なぜポートフォリオが必要なのか

未経験者にとって唯一の「実績」

書類通過率が2倍以上変わる

面接の話題の8割がポートフォリオ

評価されるポートフォリオの5つの条件

条件1:実際の課題を解決している

条件2:コードの質が保たれている

条件3:GitHubで適切に管理されている

条件4:実際に動くデモが見られる

条件5:技術選定の理由が説明できる

私が作成した3つのポートフォリオ実例

ポートフォリオ1:営業支援ツール【最も評価された】

ポートフォリオ2:読書記録アプリ

ポートフォリオ3:地域イベント情報共有アプリ

レベル別:作るべきポートフォリオ

レベル1:学習3ヶ月目【最初のポートフォリオ】

レベル2:学習4〜5ヶ月目【実用的なポートフォリオ】

レベル3:学習6ヶ月以降【技術力を示すポートフォリオ】

ポートフォリオ作成の7ステップ

ステップ1:テーマを決める【1日】

ステップ2:機能を洗い出す【1日】

ステップ3:画面設計・DB設計【2日】

ステップ4:環境構築【1日】

ステップ5:実装【2週間】

ステップ6:テストコード作成【3日】

ステップ7:デプロイとREADME作成【2日】

よくある質問と回答

Q1:何個作れば十分ですか?

Q2:チュートリアル通りのアプリはダメですか?

Q3:デザインが苦手です。どうすればいいですか?

Q4:コードを書くのが遅く、完成しません

Q5:GitHubのスター数が少なくて不安です

Q6:オリジナリティが出せません

Q7:エラーが多くて進みません

ポートフォリオで避けるべき5つのNG

NG1:チュートリアルそのまま

NG2:動かないアプリ

NG3:READMEが空っぽ

NG4:コードが汚い

NG5:テストコードが全くない

まとめ:ポートフォリオは未経験者の最強の武器

次に読むべき記事

コメント