---
title: "個人開発ポートフォリオの作り方【転職で評価される7つのポイント】"
description: "転職で評価される個人開発ポートフォリオの作り方を採用担当者視点で解説。書類通過率2.2倍のデータと受講生の内定実例をもとに、4週間で完成させるロードマップを紹介。"
url: "https://shiftb.dev/articles/indie-dev-portfolio"
publishedAt: "2026-04-03"
updatedAt: "2026-04-03"
author: "立川修平（ぶべ）"
category: "career"
tags: ["ポートフォリオ", "エンジニア転職", "個人開発", "バイブコーディング", "AI駆動開発"]
---

# 個人開発ポートフォリオの作り方【転職で評価される7つのポイント】

「ポートフォリオを作ったのに、書類選考で落ちてしまう」——ShiftBの無料相談会で、転職志望者の**約65%**が抱えるリアルな悩みです。

実は、エンジニア転職でポートフォリオが評価されるかどうかは、**技術力の高さだけでは決まりません**。採用担当者が見ているのは「入社後にチームで活躍できるか？」という視点であり、ToDoアプリやTwitterクローンのような**よく見るポートフォリオ**では、どれだけコードがきれいでも他の候補者に埋もれてしまいます。

しかし、「個人開発で実際に使われるプロダクト」をポートフォリオとして提出すると、状況は一変します。僕自身、前職時代に採用面接で**100名以上のエンジニア候補者**のポートフォリオを見てきました。また、ShiftBでは受講生**142名**の個人開発をサポートしてきた中で、どのようなポートフォリオが実際に内定を勝ち取っているのか、明確なパターンが見えてきました。

この記事では、**転職で評価される個人開発ポートフォリオの作り方**を7つのポイントに分けて徹底解説します。「何を作ればいいかわからない」「作ったけど評価されない」という方に向けた、採用担当者視点の実践ガイドです。

## 転職市場で個人開発ポートフォリオが最強な理由

エンジニア転職において、ポートフォリオは「スキルの証明書」です。しかし、すべてのポートフォリオが同等に評価されるわけではありません。**スクール課題のポートフォリオ**と**個人開発のポートフォリオ**では、採用担当者の評価が大きく異なります。

### スクール課題 vs 個人開発——採用担当者の評価の違い

| 評価ポイント | スクール課題型 | 個人開発型 |
| --- | --- | --- |
| 独自性 | 他の候補者と同じ構成になりがち | 自分だけのオリジナルサービス |
| 課題解決力の証明 | 与えられた課題を解いただけ | 自分で課題を発見し解決している |
| 技術選定の根拠 | スクールが指定した技術を使用 | 自分で技術選定の理由を説明できる |
| 継続力の証明 | カリキュラム終了で開発終了 | リリース後も改善を続けている |
| ユーザー視点 | 動作すればOK | 実際のユーザーフィードバックがある |
| 面接での話のネタ | 技術的な話に限定されやすい | 企画・開発・運用・改善の全ストーリー |

ShiftBの受講生データでは、**個人開発ポートフォリオで転職活動した人の書類通過率は62%**で、スクール課題のみの人（**28%**）の**約2.2倍**でした（2025年1月〜2026年3月、転職活動を行った受講生48名の実績）。

### 採用市場の変化——2026年に求められるもの

AI時代の到来により、エンジニアの採用基準が変わりつつあります。もはや「コードが書ける」だけでは差別化できません。

1. **AIツールの活用力**：Claude CodeやCursorなどのAIコーディングツールを開発フローに組み込めるか。2026年の求人の**約38%**がAIツール活用経験に言及しています。
2. **プロダクト思考**：「何を作るか」を自分で考えられるか。ただコードを書くだけの人材は、AIに代替されるリスクが高いと見なされます。
3. **0→1の実行力**：アイデアからリリースまで1人で完遂できるか。スタートアップ企業ほどこの力を重視します。

個人開発のポートフォリオは、この3つすべてを一度に証明できる**最強のアピール手段**です。

### 「使われているサービス」の圧倒的な説得力

面接で「月間アクティブユーザー50人のサービスを運営しています」と言えるのと、「Todoアプリを作りました」と言うのでは、**採用担当者の反応がまったく違います**。

実際にユーザーがいるサービスは、以下を暗黙的に証明します：

- ユーザーのニーズを理解してプロダクトを設計できる
- デプロイ・運用・監視の経験がある
- フィードバックを受けて改善するサイクルを回せる
- セキュリティやパフォーマンスなど実運用の課題に向き合っている

**50人のユーザーがいるサービス＞100機能のTodoアプリ**。これが、転職市場のリアルです。

![スクール課題型ポートフォリオと個人開発型ポートフォリオの採用評価の比較図](https://shiftb.dev/images/articles/indie-dev-portfolio-comparison.png)

## 採用担当者がポートフォリオで見ている7つのポイント

僕自身が100名以上の候補者を評価した経験と、ShiftB卒業生を採用してくれた企業へのヒアリング（**12社**）から、採用担当者が実際に見ているポイントを7つに整理しました。

### ポイント1：課題設定の質——「なぜこれを作ったのか」

最も重要なのは、**なぜそのサービスを作ったのか**という動機です。「勉強のために作りました」はNG。「自分自身が◯◯で困っていて、既存のサービスでは解決できなかったから作りました」——この一言だけで評価が大きく変わります。

| 評価 | 課題設定の例 | 採用担当者の印象 |
| --- | --- | --- |
| ◎ | 飲食店でバイトした経験から、シフト管理の非効率さを解決したい | 実体験に基づいている。ドメイン知識がある |
| ○ | 友人のフリーランスが請求書作成に困っていたので自動化したい | ユーザーヒアリングができている |
| △ | SNSアプリを作ってみたかった | 作りたいだけでユーザー不在 |
| ✕ | スクールの課題でTodoアプリを作りました | 全員同じで差別化不可能 |

### ポイント2：技術選定の理由——「なぜその技術を選んだのか」

React/Next.jsを使っていること自体は評価にならないです。大事なのは**「なぜReact/Next.jsを選んだのか」**を論理的に説明できるかどうか。

- **良い例**：「SEOが重要なサービスなので、SSGに対応していてVercelでの無料デプロイが簡単なNext.jsを選びました。データベースはリアルタイム更新が必要なのでSupabaseを採用しました」
- **悪い例**：「Reactが人気だと聞いたので使いました」

### ポイント3：コードの品質——読みやすさと設計

完璧なコードを求めているわけではないですが、**最低限の品質基準**があります。

- コンポーネント分割が適切か（1ファイル300行以上は赤信号）
- 命名が意味のある名前か（`data`や`handleClick`は避ける）
- 型定義がしっかりしているか（TypeScript推奨）
- エラーハンドリングが適切か
- 環境変数で機密情報を管理しているか（`.env`がGitHubに上がっていないか）

ShiftBの受講生で内定を獲得した人の**92%**がTypeScriptを使用していました。2026年現在、型なしのJavaScriptでポートフォリオを作ると、「なぜTypeScriptを使わないのか」と逆に質問されるリスクがあります。

### ポイント4：GitHubの使い方——開発プロセスの可視化

GitHubリポジトリは「コード置き場」ではなく、**あなたの開発プロセスそのもの**です。

- **コミット履歴**：意味のあるコミットメッセージで、開発の流れが追えるか
- **ブランチ戦略**：feature branchを切ってPRを出しているか（1人でも）
- **Issue管理**：今後の改善予定がIssueとして整理されているか
- **README**：プロジェクトの概要・技術スタック・セットアップ手順が書かれているか

採用担当者の**約78%**がGitHubのコミット履歴を確認するというデータがあります。「1コミットで全コード」は論外です。最低でも**50コミット以上**の履歴があることが望ましいです。

### ポイント5：UI/UXの質——見た目は思った以上に重要

「バックエンド志望だからデザインは関係ない」は**大きな誤解**です。採用担当者（特に非エンジニアの人事担当）は、まず画面を見て評価します。

- Tailwind CSSやshadcn/uiなどのUIライブラリを活用して、最低限の美しさを確保する
- レスポンシブ対応は必須（スマホで確認できないポートフォリオは致命的）
- ローディング状態・エラー状態の表示がある
- 404ページをカスタマイズしている

### ポイント6：デプロイ・運用——「動いている」ことの価値

ローカルでしか動かないポートフォリオと、**URLを共有して即座にアクセスできるポートフォリオ**では、評価が天と地ほど違います。

| デプロイ状態 | 評価 | 理由 |
| --- | --- | --- |
| 本番URL + ユーザーがいる | ◎ | 運用経験まで証明できる |
| 本番URLあり（Vercel等） | ○ | デプロイの基本スキルがある |
| GitHubのREADMEにスクショのみ | △ | 動作確認が困難 |
| ローカル環境のみ | ✕ | 確認すらできない |

**Vercelなら無料で本番デプロイが可能**です。Next.jsで開発しているなら、デプロイしない理由がありません。

### ポイント7：改善の継続性——「作って終わり」ではない

最後のポイントが、**リリース後も改善し続けているか**。3ヶ月前にリリースして以来コミットがゼロのポートフォリオは、「飽きて放置した」と見なされます。

週に1〜2回でいいので、以下のような小さな改善を継続しましょう：

- ユーザーフィードバックに基づく機能追加
- パフォーマンス改善（Lighthouse スコアの向上）
- アクセシビリティの改善
- テストカバレッジの向上
- 依存パッケージのアップデート

## ポートフォリオの題材選び——評価される題材・されない題材

題材選びは、ポートフォリオの成否を**8割**決めます。どれだけ技術力があっても、題材が悪いとその力を発揮できません。

### 避けるべき題材ワースト5

| 順位 | 題材 | 避けるべき理由 | 作っている人の割合 |
| --- | --- | --- | --- |
| 1 | Todoアプリ | 全員が作るので差別化不可能 | 約45% |
| 2 | Twitter/Xクローン | 本物と比較されて見劣りする | 約22% |
| 3 | ECサイト（Stripeチュートリアル通り） | テンプレ感が強く独自性がない | 約15% |
| 4 | チャットアプリ | FirebaseのリアルタイムDBを使っただけに見える | 約12% |
| 5 | 天気予報アプリ | API叩いて表示するだけで技術力が伝わりにくい | 約8% |

これらの題材がダメなのではなく、**「独自の課題解決」が見えないまま作ると埋もれる**ということです。例えば、Todoアプリでも「ADHD当事者向けの優先度自動判定Todoアプリ」なら、課題設定が明確で差別化ができます。

### 評価されやすい題材の特徴

採用担当者に刺さるポートフォリオには、共通の特徴があります：

1. **自分の実体験から生まれている**：バイト先、前職、趣味のコミュニティなど、リアルな課題がベース
2. **ターゲットユーザーが明確**：「誰でも使える」ではなく「◯◯な人のための△△ツール」
3. **既存サービスとの差別化がある**：「◯◯はあるけど、△△がないから自分で作った」と言える
4. **実際に使ってくれるユーザーがいる**：身近な人でいいので、リアルなユーザーがいると圧倒的に強い
5. **応募先の業界・技術と関連がある**：SaaS企業に応募するならSaaS型サービスが理想的

### ShiftB受講生に人気の題材カテゴリと評価

| 題材カテゴリ | 具体例 | 評価されやすさ | 開発難易度 |
| --- | --- | --- | --- |
| 業務効率化ツール | 請求書自動生成、シフト管理、日報管理 | ★★★ | 中 |
| ニッチコミュニティ | 特定趣味のSNS、読書記録共有、筋トレ仲間マッチング | ★★★ | 高 |
| AIツール | AI文章要約、画像生成プロンプト共有、学習計画AI | ★★★ | 中 |
| データ可視化 | 家計簿ダッシュボード、学習進捗トラッカー | ★★☆ | 中 |
| 情報キュレーション | 技術記事まとめ、イベントカレンダー | ★★☆ | 低 |

### 題材選びのフレームワーク「3C分析」

マーケティングの3C分析をポートフォリオの題材選びに応用します：

- **Customer（ユーザー）**：誰の、どんな課題を解決するか？身近に最低3人いるか？
- **Competitor（競合）**：既存サービスは何があるか？何が足りないか？
- **Company（自分）**：自分のドメイン知識・技術力でどこを差別化するか？

この3つが交わるポイントが、**あなたにしか作れないポートフォリオの題材**です。

![ポートフォリオの題材選びフレームワーク：3C分析をポートフォリオに応用した図](https://shiftb.dev/images/articles/indie-dev-portfolio-topic-selection.png)

## AI時代のポートフォリオ戦略——バイブコーディングを武器にする

2026年、AIコーディングツールの普及により、ポートフォリオの作り方自体が変わりつつあります。この変化を**脅威ではなくチャンス**として活用する方法を解説します。

### 「AIで作ったポートフォリオ」は評価されるのか？

結論から言うと、**AIを使うこと自体はマイナスにならない**。むしろ、2026年の採用現場では「AIツールを活用できること」がプラス評価になるケースが増えています。

ただし、重要なのは**「AIに丸投げした」のか「AIを道具として使いこなした」のか**の違いです。

| アプローチ | 採用担当者の評価 | 面接で聞かれること |
| --- | --- | --- |
| AIに丸投げ（コードを理解していない） | ✕ 不採用リスク高 | 「このコードの意味を説明してください」で詰まる |
| AIを補助的に活用（自分で設計・レビュー） | ◎ 高評価 | 「AIとの協業で工夫した点は？」で具体的に語れる |
| AI不使用（すべて手書き） | ○ 普通 | AIツールの知識がないと見なされるリスク |

### バイブコーディングでポートフォリオを作るメリット

1. **開発速度が3〜5倍**：従来3ヶ月かかっていた開発が、**3〜4週間で完成**可能。短期間で完成度の高いポートフォリオが作れる。
2. **技術の幅を広げられる**：AIの補助があれば、未経験の技術にもチャレンジしやすい。「テスト書いたことがない」→ AIでテストを学びながら実装、が可能。
3. **AIリテラシー自体が評価される**：「Claude Codeを使った開発フロー」をREADMEやポートフォリオサイトに記載すること自体が、AI時代のエンジニアとしての適性を証明する。

### 面接で「AI使いました」と言うときの注意点

- **設計は自分で行った**ことを明確にする（ER図やワイヤーフレームを見せる）
- AIが出力したコードを**自分でレビュー・修正した**プロセスを説明する
- **AIでは解決できなかった課題**と、その解決方法を語れるようにする
- 使用したAIツール（Claude Code、Cursor等）と**具体的な活用方法**を整理する

### AIを活用したポートフォリオ開発の具体的フロー

1. **自分で設計**（要件定義・ER図・画面設計）→ **これはAIに頼らない**
2. **CLAUDE.mdで開発ルールを定義** → AIの出力品質を安定させる
3. **Claude Codeで実装** → 機能ごとにプロンプトを分けて段階的に開発
4. **自分でコードレビュー** → AIの出力を理解し、必要に応じて修正
5. **テストもAIで補助** → 「テストを書いて」ではなく「このケースのテストを書いて」と具体的に指示

ShiftBでは、この「**設計は人間、実装はAIと協業、レビューは人間**」のフローを推奨しています。受講生の**85%**がこのフローでポートフォリオを完成させ、平均開発期間は**26日**（従来の手書き開発は平均78日）でした。

## ポートフォリオ開発のロードマップ【4週間で完成させる方法】

「いつか作ろう」と思っていると、永遠に完成しません。ここでは、**4週間で転職に使えるポートフォリオを完成させる**具体的なロードマップを紹介します。

### Week 1：企画・設計（所要時間：約15時間）

| 日 | タスク | 成果物 | 所要時間 |
| --- | --- | --- | --- |
| Day 1-2 | 課題の深掘り・ターゲット設定 | 課題定義書（1ページ） | 3時間 |
| Day 3 | 競合調査・差別化ポイント整理 | 競合比較表 | 2時間 |
| Day 4-5 | 画面設計（ワイヤーフレーム） | Figma or 手書きワイヤーフレーム | 5時間 |
| Day 6-7 | DB設計・技術選定・CLAUDE.md作成 | ER図 + 技術選定メモ + CLAUDE.md | 5時間 |

**Week 1が最も重要**です。ここで手を抜くと、開発中に何度も手戻りが発生します。特に**ER図**は面接でも「データベース設計について説明してください」と聞かれるため、しっかり作り込みましょう。

### Week 2：コア機能の実装（所要時間：約20時間）

1. **環境構築**（Next.js + TypeScript + Tailwind CSS + Supabase）：2時間
2. **認証機能**（Supabase Auth）：3時間
3. **CRUD機能**（メインのデータ操作）：8時間
4. **UI実装**（shadcn/uiでベースUI構築）：5時間
5. **デプロイ**（Vercelへの初回デプロイ）：2時間

Week 2の終わりには、**最小限動くプロダクト（MVP）**がVercel上で公開されている状態を目指します。完璧を求めず、まず「動くもの」を公開しましょう。

### Week 3：機能追加・UI改善（所要時間：約20時間）

1. **差別化機能の実装**（AIを活用した機能など）：8時間
2. **レスポンシブ対応**：3時間
3. **エラーハンドリング・ローディング表示**：3時間
4. **OGP画像・ファビコン設定**：2時間
5. **テスト実装**（主要フローのE2Eテスト）：4時間

### Week 4：ドキュメント・仕上げ（所要時間：約15時間）

1. **README作成**（次セクションで詳しく解説）：3時間
2. **ポートフォリオサイト作成** or **Notionで実績ページ作成**：4時間
3. **ユーザーテスト**（身近な人3人に使ってもらいフィードバック反映）：4時間
4. **Lighthouseスコアの最適化**（Performance 80+目標）：2時間
5. **最終確認・リリースノート作成**：2時間

**合計約70時間**。平日2時間 + 休日5時間で4週間あれば十分完成できるスケジュールです。ShiftB受講生の平均は**65時間**でポートフォリオを完成させています。

![4週間のポートフォリオ開発ロードマップ：Week1企画設計からWeek4仕上げまでのステップフロー図](https://shiftb.dev/images/articles/indie-dev-portfolio-roadmap.png)

## ポートフォリオで差がつくドキュメンテーションの書き方

コードだけではポートフォリオの魅力は伝わりません。**READMEとポートフォリオサイト**は、採用担当者が最初に目にする「表紙」です。

### GitHubのREADMEに書くべき8項目

1. **サービス概要**：1〜2文で「何のためのサービスか」を説明
2. **課題と解決策**：なぜ作ったのか、どう解決するのか
3. **デモURL**：Vercelのデプロイ先リンク（最重要）
4. **主要機能**：スクリーンショット付きで3〜5機能を紹介
5. **技術スタック**：使用技術一覧と選定理由
6. **アーキテクチャ図**：システム構成図（Mermaidで簡単に作れる）
7. **セットアップ手順**：ローカル環境で動かすための手順
8. **今後の改善予定**：Issue化されたタスクへのリンク

### 良いREADMEと悪いREADMEの比較

| 要素 | 悪い例 | 良い例 |
| --- | --- | --- |
| タイトル | 「my-portfolio」 | 「ShiftNote - フリーランス向け日報管理ツール」 |
| 概要 | 「Reactで作ったアプリです」 | 「フリーランスの日報作成を5分から1分に短縮するWebアプリ」 |
| 技術スタック | 「React, Node.js」（羅列だけ） | 「Next.js 15（SSG + ISR）/ Supabase（認証 + DB）/ Vercel」+ 選定理由 |
| スクリーンショット | なし | 主要画面3枚 + GIFアニメーション |
| デモURL | なし | Vercelデプロイ先 + テスト用アカウント情報 |

### ポートフォリオサイトの構成例

GitHubのREADMEとは別に、**ポートフォリオ紹介サイト**を作ると、非エンジニアの人事担当にもアピールできます。

1. **ヒーローセクション**：名前 + 一言キャッチコピー + 顔写真
2. **About**：経歴・スキル・転職の動機
3. **Projects**：個人開発プロダクト（メイン1つ + サブ1〜2つ）
4. **Skills**：技術スタック（アイコン + 経験年数/月数）
5. **Blog/Output**：Qiita・Zennの記事リンク
6. **Contact**：メールフォーム or SNSリンク

ポートフォリオサイト自体もNext.jsで作れば、**もう1つの技術力の証明**になります。Vercelで無料デプロイ → 独自ドメインを設定（年間**約1,500円**）すれば、面接で「このサイト自体も自分で作りました」と言えます。

### 技術ブログ・アウトプットの重要性

ポートフォリオに加えて、**開発過程をブログに書く**ことで評価がさらに上がります。

- 開発中に詰まったエラーと解決方法（Zenn/Qiita）
- 技術選定の比較検討プロセス
- リリース後のユーザーフィードバックと改善の記録
- AIツールの活用テクニック

ShiftBの受講生で、転職活動中に**5記事以上のブログを書いた人**の内定率は**74%**で、ブログなしの人（**41%**）の**約1.8倍**でした。

## ShiftB受講生の転職成功ポートフォリオ実例分析

実際にShiftBの受講生が作成し、内定を獲得したポートフォリオの特徴を分析します。個人情報は伏せていますが、**パターン**として参考にしてください。

### 事例1：未経験→自社開発企業に内定（30代・元営業）

| 項目 | 内容 |
| --- | --- |
| サービス内容 | 営業チーム向け商談メモ管理ツール |
| 技術スタック | Next.js / TypeScript / Supabase / Vercel |
| 開発期間 | 4週間（バイブコーディング活用） |
| ユーザー数 | 前職の同僚8人が利用 |
| 評価されたポイント | 前職の営業経験を活かした課題設定、ドメイン知識の深さ |
| 応募数 → 内定 | 12社応募 → 書類通過8社 → 最終面接4社 → 内定2社 |

**ポイント**：前職の経験を活かした題材選びが最大の勝因。「営業現場で本当に困っていたこと」を解決するサービスだったため、面接で課題の説明に説得力があり、ドメイン知識の深さが評価された。

### 事例2：未経験→スタートアップに内定（20代・元飲食業）

| 項目 | 内容 |
| --- | --- |
| サービス内容 | 飲食店向けの食材在庫管理・発注アシスタント |
| 技術スタック | Next.js / TypeScript / Supabase / Claude API / Vercel |
| 開発期間 | 5週間 |
| ユーザー数 | 元バイト先の店長1名が試用 |
| 評価されたポイント | AI APIの実装経験、実ユーザーからのフィードバック反映 |
| 応募数 → 内定 | 20社応募 → 書類通過9社 → 最終面接3社 → 内定1社 |

**ポイント**：Claude APIを活用して食材の発注量をAIで提案する機能を実装。「AIを使って何ができるか」を具体的に示せた点が、AI活用に積極的なスタートアップ企業に刺さった。

### 事例3：経験1年→年収120万円アップで転職（20代・SES→自社開発）

| 項目 | 内容 |
| --- | --- |
| サービス内容 | エンジニア向けの技術記事ブックマーク＆学習管理アプリ |
| 技術スタック | Next.js / TypeScript / Prisma / PostgreSQL / Vercel |
| 開発期間 | 3週間（Claude Code活用） |
| ユーザー数 | 月間アクティブユーザー35人 |
| 評価されたポイント | GitHub Actionsでのci/CD、テストカバレッジ70%以上、運用実績 |
| 応募数 → 内定 | 8社応募 → 書類通過6社 → 最終面接4社 → 内定3社 |

**ポイント**：実務経験1年だが、個人開発で月間35人のユーザーがいるサービスを運営していた。CI/CDパイプラインの構築やテスト実装など、**「実務レベルの開発プロセス」**を個人開発で証明できたことが年収アップにつながった。

### 3事例に共通するパターン

1. **自分の経験**に基づいた題材選び
2. **実際のユーザー**がいる（たとえ1人でも）
3. **技術選定の理由**を論理的に説明できる
4. **リリース後も改善**を継続している
5. **開発プロセス**がGitHubで可視化されている

## よくある質問（FAQ）

### Q1. ポートフォリオは何個作ればいいですか？

**メインのプロダクト1つ + サブ1〜2つ**が理想です。メインのプロダクトに全力を注ぎ、サブは技術の幅を見せるために小さなツールやライブラリでOK。10個の中途半端なアプリより、**1つの完成度が高いアプリ**の方が圧倒的に評価されます。

### Q2. プログラミング未経験ですが、いきなり個人開発ポートフォリオを作れますか？

最低限、**HTML/CSS/JavaScript/Reactの基礎**（約100〜200時間の学習）を終えてからがおすすめです。基礎がないまま個人開発を始めると、AIの出力を理解できず、面接で「このコードの意味を教えてください」と聞かれたときに答えられないリスクがあります。バイブコーディングで開発速度は上がりますが、**基礎理解は省略できない**です。

### Q3. ポートフォリオに使う技術はReact/Next.jsがベストですか？

応募先の企業が使っている技術に合わせるのがベストです。ただし、迷っている場合は**Next.js + TypeScript**が最も汎用性が高いです。2026年のフロントエンド求人の**約52%**がReact/Next.jsを求めており、転職市場での需要が圧倒的に高いためです。バックエンドも含めたフルスタックを見せたいなら、Supabaseとの組み合わせが王道です。

### Q4. ポートフォリオのデザインが苦手です。どうすればいいですか？

**shadcn/ui**や**Tailwind UI**などのUIコンポーネントライブラリを使えば、デザインスキルがなくても十分きれいなUIが作れます。また、**v0.dev**（Vercelが提供するAI UIジェネレータ）を使えば、プロンプトからReactコンポーネントを生成できるので、デザインで悩む時間を大幅に短縮できます。大切なのは「美しいデザイン」ではなく、**「使いやすいUI」**です。

### Q5. ポートフォリオにテストは必要ですか？

**あると大きなプラス評価**になります。必須ではないですが、特に自社開発企業やスタートアップに応募する場合、テストがあるだけで「品質に意識がある」と評価されます。すべてのコードにテストを書く必要はなく、**主要なビジネスロジック**と**重要なユーザーフロー**（ログイン → メイン機能 → ログアウト）のE2Eテストだけで十分です。テスト初心者でも、Claude CodeやCursorを使えばテストコードの生成を補助してもらえます。

### Q6. GitHubのプライベートリポジトリでも大丈夫ですか？

**パブリックリポジトリを推奨**します。プライベートリポジトリだと、応募先の企業にGitHubのアクセス権を付与する手間が発生し、書類選考の段階で確認してもらえない可能性があります。「コードを公開するのが恥ずかしい」と感じるかもしれませんが、採用担当者は完璧なコードを求めているわけではなく、**成長の過程**を見ています。

### Q7. ポートフォリオの有料機能（Stripe決済など）はどう見せればいいですか？

Stripeの**テストモード**で動作するデモ環境を用意しましょう。READMEに「テスト用クレジットカード番号: 4242 4242 4242 4242」と記載し、採用担当者が実際に決済フローを試せるようにするのがベストです。本番環境とテスト環境を分ける実装自体が、**環境構築スキルのアピール**になります。