この記事でわかること
- 未経験エンジニアのポートフォリオで評価される3つの共通点（テーマ・README・作り込み）
- 実際に書類通過・内定につながったポートフォリオ実例3つを、面接コメント付きで分解
- 同じ技術スタックなのに評価が伸びなかった例と、評価された例の分岐点
- 未経験から再現できるポートフォリオ設計3ステップ（テーマ逆算・README・詰まり対策）
公的情報源: 厚生労働省「職業情報提供サイト job tag」（参照）
作ったポートフォリオを「採用目線で見るとどう映るか」を先に知りたい方へ。無料カウンセリングで添削だけ受けることもできます。
結論を先に書きます
未経験エンジニアのポートフォリオで評価されるのは、技術スタックの派手さではありません。「なぜこのテーマか30秒で語れる／READMEが意思決定型／狭くてもユーザー体験まで作り込む」の3点です。
世の中の「未経験 ポートフォリオ 評価」の記事は、「ToDoアプリはダメ」「オリジナル要素を入れろ」といった抽象論が多めです。ただ本当に知りたいのは、評価された／されなかったポートフォリオがどこで分岐したかのはずです。
この記事では未経験エンジニア3人のポートフォリオを並べ、面接で評価された理由を分解します。なお本人特定を避けるため、内容は当事者の経験と同期の事例を再構成しています。
- 評価の分岐点は「何を作ったか」より「なぜ作ったか」と「どう伝えたか」
- 評価された3例は技術力が突出していたわけではなく、テーマと語りが一貫していた
- 厚労省「job tag」のWeb職要件でも、コーディング以上に要件理解と説明・ドキュメント化が重視されている
なお厚生労働省「職業情報提供サイト job tag」（参照・2026年5月閲覧）の「Webプログラマ」「システムエンジニア」の職業情報でも、コーディング能力以上に「業務要件の理解」「説明・ドキュメント化」が要素として整理されています。ポートフォリオで「READMEと語り」が技術スタックの派手さより評価される感触は、こうした公的なスキル要件とも方向が合っています。
評価されるポートフォリオの3つの共通点
3人のポートフォリオを並べると、評価された側に明確な共通点がありました。技術力の高さより、書類通過と面接通過に直接効いた3点です。
- 「なぜこのテーマを選んだか」が30秒で語れる
- READMEが「読み手の意思決定」を意識して書かれている
- 動く範囲が狭くてもいいから、ユーザー体験まで本気で作り込んでいる
この3点は、以降の実例すべてに共通していました。順番に、実際のポートフォリオで見ていきます。
実例1：営業職向けの顧客リスト管理アプリ（元営業）
1つ目は、元営業の未経験者が作った「営業職向けの顧客リスト管理アプリ」です。
| 項目 | 内容 |
|---|---|
| 機能 | 顧客の登録・編集・削除／訪問履歴の記録／次回アクション日のリマインダ／検索・絞り込み／タグ管理 |
| 技術 | Ruby on Rails / PostgreSQL / Bootstrap / Heroku |
| 制作期間 | 2週間（スクール期間の週10〜11） |
| 結果 | 面接5社中4社で同趣旨の高評価 |
技術的に飛び抜けたものはありません。CRUD・検索・タグ管理・リマインダは、どれもチュートリアルレベルの実装です。それでも面接5社のうち4社で、同じ趣旨のコメントをもらいました。
- 「営業出身でこのテーマを選んだ理由が腹落ちする」
- 「実際に使うユーザーを想像して作っているのが分かる」
- 「READMEに『これを作った背景』が書いてある」
評価の決め手は、テーマ選びと語りの一貫性でした。「営業時代に欲しかったツール」というロジックで前職から逆算し、READMEと面接の語りが完全に揃っていたのです。
READMEは「背景 → 解決したい課題 → 機能一覧 → 技術選定理由 → 今後追加したい機能」の5層構造。さらに「次回アクション日のリマインダ」のような、営業の実務でしか気づかない細部を機能に落とし込んでいました。技術力でジュニアに勝つのは難しくても、テーマと語りなら差別化できる、という典型例です。
実例2：英語学習者向けの単語レビューアプリ（同期A）
2つ目は、元・塾講師の同期Aさん（仮）が作った「単語×例文」のレビューアプリです。
| 項目 | 内容 |
|---|---|
| 機能 | 英単語と例文をセットで登録／忘却曲線に沿った復習リマインダ／間違いの記録／復習成功率の可視化 |
| 技術 | Ruby on Rails / PostgreSQL / Chart.js / Heroku |
| 制作期間 | 3週間（スクール期間の週10〜12） |
| 結果 | 応募12社・書類通過7社・内定3社 |
Aさんは応募12社で書類通過7社・内定3社という高い通過率を取りました。技術スタックは実例1と似ていますが、評価された軸が少し違います。
- 「忘却曲線」という学習理論を機能設計に落とし込んでいた（テーマと自己経験の必然的な接続）
- Chart.jsで復習成功率を時系列グラフ化し、「未経験でもデータ可視化に踏み込める」シグナルを出した
- READMEに「自分が英語学習で挫折した経験」を書いていた
面接では「Chart.jsはどう学んだか」を聞かれ、「公式ドキュメントと、Qiitaの3本の記事で詰まったところを乗り越えた」と答えたところ、独学力を評価されたそうです。
ポイントは、忘却曲線 → 復習リマインダ → 成功率グラフ、と機能と技術選定がロジカルにつながっていること。「詰まったところの解消経路を語れる」ことが、面接の独学力評価で効きました。
テーマと技術選定の必然性は、自分では気づきにくい弱点です。第三者に「なぜこの技術か」を突っ込んでもらうと、面接前に穴が見つかります。
無料カウンセリングでポートフォリオを添削してもらう（PR）詳細はリンク先をご確認ください
実例3：飲食店の営業時間×天気連動アプリ（同期B）
3つ目は、元・飲食店スタッフの同期Bさん（仮）が作った「営業時間×天気」連動アプリです。
| 項目 | 内容 |
|---|---|
| 機能 | 地元飲食店の営業時間を登録／天気APIと連動し「今日の営業時間が変わるか」を表示／口コミ投稿 |
| 技術 | Ruby on Rails / PostgreSQL / OpenWeatherMap API / Bootstrap / Heroku |
| 制作期間 | 3週間 |
| 結果 | 応募8社・書類通過5社・内定1社（第一志望の自社開発企業） |
Bさんは応募8社で書類通過5社・内定1社。通過率の数字こそ高くありませんが、最終的に第一志望の自社開発企業に内定しました。評価された軸はこの3つです。
- 外部API連携（OpenWeatherMap）を入れていた（未経験では明確な差別化要因）
- 「飲食店の営業時間は天気で変動する」という現場知識がテーマに反映されていた
- READMEに「なぜAPIを天気で選んだか」の意思決定理由が書かれていた
外部API連携には「APIキーの管理」「リクエスト失敗時のハンドリング」など、実務で必要な小さな筋肉が見えます。面接で「APIリクエストが失敗したらどう処理しているか」を聞かれ、想定外のレスポンスへの対応コードを画面共有で見せたところ、現場感覚を評価されたそうです。
「飲食店スタッフだったから気づける課題」という、前職からの逆算がここでも効いています。
評価されなかった同期のパターン
3人とは別に、評価が伸びなかったポートフォリオにも共通点があります。技術スタックや実装の難易度は、評価された側とほとんど変わりません。それでも書類通過率に明確な差が出ました。
- ToDoアプリ・メモアプリ・タスク管理アプリのような「教材通り」のテーマ
- READMEが「機能一覧」と「使い方」だけで、「なぜ作ったか」が書かれていない
- 自分の前職経験との接続がゼロ
つまり分岐点は実装力ではありません。「何を作ったか」より「なぜ作ったか」と「どう伝えたか」が、未経験ポートフォリオの評価を分けます。
未経験ポートフォリオの設計3ステップ
ここまでの3実例から、未経験エンジニアのポートフォリオ設計を3ステップに整理します。順番に進めれば、教材通りのポートフォリオから「あなた専用のテーマ」に変わります。
- 前職・属性からテーマを逆算する
- READMEを「面接官の3分」で書く
- 「詰まったところ」と「乗り越え方」を3つ用意する
ステップ1：前職・属性からテーマを逆算する
「自分が前職で困っていたこと」「自分の属性だから気づける課題」を、紙に20個書き出します。この中からWebアプリで解決できそうなものを1つ選びます。教材から離れた瞬間に、ポートフォリオは「あなた専用のテーマ」になります。
ステップ2：READMEを「面接官の3分」で書く
READMEは、面接官が3分で読み切れる構造にします。評価された3人が共通で使っていたのは、次の5層です。
- このアプリは何を解決するか（2行）
- なぜ作ったか（自分の経験と課題の接続）
- 機能一覧
- 技術選定の理由（なぜRailsか、なぜこのDBか、なぜこのAPIか）
- 今後追加したい機能（運用フェーズへの想像力）
ステップ3：「詰まったところ」と「乗り越え方」を3つ用意する
面接で必ず聞かれるのが「ポートフォリオで一番詰まったところは？」です。ここで「特にありませんでした」と答えると、独学力の評価が下がります。逆に3つほど詰まった経験と乗り越え方を語れると、未経験でも「自走できそう」という印象に変わります。
ポートフォリオが完成したら、エージェントに添削をもらう
ポートフォリオが完成しても、それが「未経験エンジニア採用の角度でどう映るか」は自分では分かりません。
完成直後にTechGoやレバテックキャリアの担当者にURLを共有して添削をもらうと、指摘は技術より「READMEの『なぜ作ったか』が弱い」「機能一覧が長すぎてコア機能が見えない」という構造の話に集中しやすい傾向があります。
ここを直してから応募を始めると、書類通過率の手応えが変わります。添削での差し戻しが効くポイントです。
「なぜ作ったか」が弱い、コア機能が埋もれている——こうした構造の穴は、応募前に潰すほど書類通過率に効きます。まずは無料カウンセリングで採用目線の添削を受けてみてください。
TechGoの無料カウンセリングを申し込む（PR）詳細はリンク先をご確認ください
よくある質問
ポートフォリオ制作と未経験IT転職について、よく聞かれる質問を整理します。
Q1. ToDoアプリでもポートフォリオとして通用しますか？
テーマと語りの作り込み次第で通用します。教材通りのToDoアプリ単体だと埋もれますが、「自分の属性だから気づける課題」を足してオリジナルのテーマに寄せ、READMEで「なぜ作ったか」を語れれば評価対象になります。逆に技術スタックを盛っても、ストーリーがなければ書類段階で落ちやすいです。
Q2. 未経験で学ぶべき言語は何ですか？
Web系受託を目指すなら JavaScript（HTML/CSS）→ Ruby on Rails か PHP（Laravel） の順が現実的です。求人数の観点でもWeb系言語は安定しています。最初の1〜2ヶ月は「言語」より、環境構築とGitの壁を越えるのが鍵です。
Q3. ポートフォリオ制作にどのくらい期間をかけるべきですか？
実例3つはいずれも2〜3週間で制作しています。期間を延ばすより、テーマの必然性とREADMEの作り込みに時間を寄せるほうが効果的です。動く範囲は狭くても構いません。狭くてもユーザー体験まで作り込むほうが、機能数を増やすより評価されます。
Q4. 外部API連携は入れたほうがいいですか？
入れられるなら差別化要因になります。実例3のように、外部API連携は「APIキー管理」「リクエスト失敗時のハンドリング」など実務で必要な筋肉が見えるためです。ただし無理に盛る必要はありません。テーマの必然性とセットで選ぶことが前提です。
Q5. エージェントは何社使うべきですか？
2社が基準です。1社は大手総合型、もう1社はIT特化型（レバテックキャリア・TechGo等）の組み合わせが現実的です。多すぎるとスケジュール管理で詰むため、面接管理が破綻しないラインで運用してください。ポートフォリオの添削は、IT特化型のほうが採用目線の指摘が具体的になりやすいです。
まとめ｜「何を作ったか」より「なぜ作ったか」
未経験エンジニアのポートフォリオは、技術の派手さではなく次の3点で評価が分岐します。
- なぜこのテーマを選んだかを30秒で語れるか
- READMEが面接官の3分で意思決定できる構造か
- 詰まったところと乗り越え方を語れるか
ToDoアプリでも、テーマと語りの作り込み次第で通過します。逆に技術スタックを盛っても、ストーリーがなければ書類段階で落ちます。
迷っているなら、まず1つ「自分の属性だから気づける課題」をテーマに置き、READMEとセットで仕上げてからエージェントに見せる流れがおすすめです。完成したら採用目線の添削を一度受ける——これが遠回りに見えて、いちばんの近道になります。
テーマとREADMEを仕上げたら、応募前に一度プロの目を通すと書類通過率の精度が上がります。無料カウンセリングで添削だけ受けることもできます。
今すぐ無料カウンセリングを申し込む（PR）詳細はリンク先をご確認ください
関連記事
免責事項
※本記事は転職・求人サービスの公開情報と利用者の声をもとにした整理です。最終的なサービス選択・転職判断は各公式サイトの最新情報および厚生労働省等の公的情報をご確認のうえご判断ください。労務・契約条件に関わる重要な判断は、必要に応じて社会保険労務士・弁護士など有資格者へご相談ください。
