この頁が向いている人
この頁は、未経験からエンジニアへの転職を目指す人のためのポートフォリオの作り方です。デザイナーや写真家のポートフォリオは、見た目と作品の並べ方が主役になります。エンジニアの応募で見られるのは、作った物が動くか、説明が書いてあるか、コードが読めるかの 3 つです。見た目を整える前に、この 3 つを先にそろえます。
転職ロードマップでは 4 つ目の段「ポートフォリオを整える」にあたります。まだ作る物が無い人は、先に転職ロードマップの 3 つ目の段で 1 つ作って公開してください。
応募で見られる 3 つの点
未経験の人の応募で、書類を読む人が確かめたいのは「この人は 1 人で物を動かせるか」です。作品の数や技術の珍しさより、次の 3 つの点で答えが出ます。
よくある落ち方は、開くとエラーが出る、使った技術の名前だけが README に並んでいる、1 つのファイルに全部入っている、の 3 つです。
出す前に、自分の作品を URL、README、コードの 1 ファイル の順で開いてみてください。知らない人が初めて開く順と同じです。どこかで止まったら、そこが最初に直す所です。
動くか
URL は README のいちばん上に置きます。ログインが要る物は、試し用のアカウントを書いておきます。開いた人が自分で会員登録をしないと中が見られない作品は、その手前で閉じられてしまいます。
無料の公開先は、しばらく使わないと止まる物や、期限のある物があります。応募の前の日に、自分で URL を開いて確かめます。HTML、CSS、JavaScript だけで動く物なら、GitHub Pages で公開できます。GitHub の説明では、公開のリポジトリなら無料のプランで使えます。サーバーやデータベースを使う物は、GitHub Pages では動かないので、別の公開先が要ります。
README
README は、作品の取扱説明書であり、面接で話す原稿の元にもなります。書く順は、次の実例の「直したあと」の形をそのまま使えます。
コードが読めるか
全部を読む人はほとんどいません。1 つか 2 つのファイルを開いて、名前の付け方、関数の分け方、エラーのときの扱いを見ます。見せたいファイルがあるなら、README に「まずここを読んでください」と 1 行で案内します。
実例 タスク管理アプリの README を直す
ゆめさくの実践プロジェクトにある「タスク管理アプリ」を例にします。TypeScript、Express、Prisma、PostgreSQL、React で、ログインつきの社内向けタスク管理を作る課題です。作り終えたあとに、よくある README と、直したあとの README を並べます。中身は説明のための例です。
直す前
# タスク管理アプリ
React と Express と PostgreSQL で
作りました。
## 使った技術
- TypeScript
- React
- Express
- Prisma
- PostgreSQL
これでは、何のための物か、どこで試せるか、どこを自分で作ったかが分かりません。技術の名前は、ほかの応募者の README にも同じように並んでいます。
直したあと
# 期限と担当で見るタスク管理
小さな会社の社内で、誰が何をいつまでに
抱えているかを 1 枚で見るためのアプリです。
## 試す
- URL https://example.com
- 試し用のアカウントは下に書きました
## 自分で足した所
- 期限切れのタスクだけを絞り込む機能
- 同時に直したときに上書きしない仕組み
- 足した所のコミットは
README の下にまとめました
## 教材から始めた所
- 画面の骨組みと、ログインの仕組み
## AI の使い方
- 一部のコード生成。
絞り込みの SQL を Claude Code に
書かせ、テストで確かめました
## まだできていないこと
- スマホの幅で表が横にはみ出す
## まずここを読んでください
- server/src/tasks/filter.ts
直したあとの README は、上から読むと面接の答えの順になっています。何のために作ったか、どこで試せるか、何を自分でやったか、何がまだか。面接で「この作品について話してください」と言われたら、この順で話せば足ります。
学習パスと道場で作った物を、そのまま載せる手順
教材の課題をそのまま載せると「写しただけ」と見られる、とよく言われます。隠す必要はありません。教材から始めた所と、自分で足した所を分けて見せれば、課題は立派な作品になります。ゆめさくの学習パスの実践プロジェクトは、出発点のコードから章ごとに作り進める形なので、この分け方がそのまま使えます。
- 出発点を自分のリポジトリに置く。教材の出発点のコードを、自分の GitHub のリポジトリに入れます。最初のコミットの説明は「教材の出発点」とします
- 章ごとにコミットする。教材の章を 1 つ終えるたびにコミットします。あとから見た人が、どの順で作ったかを追えます
- 教材に無い物を 1 つ足す。小さくてかまいません。絞り込み、並べ替え、CSV の書き出し、入力の確かめなど、自分か身近な人が困りそうな所から選びます
- 公開して URL を README の一番上に置く。 試し用のアカウントも書きます
- README で 2 つを分ける。「教材から始めた所」と「自分で足した所」の節を作り、足した所のコミットを並べます
足す物は、技術の難しさよりなぜ足したかを 1 文で言えるかで選びます。「期限切れを探すのに毎回全部を見ていたので、絞り込みを足した」と言えれば、面接で話が続きます。
道場で解いた問題は、1 問ずつを作品として並べても伝わりにくい物です。解いた数を並べるより、作品の中で同じ考え方を使った所を README で指します。たとえば、道場で練習した探索や集計の考え方を、作品のどの関数で使ったかを書きます。
学んだことの証拠は、ゆめさく Proof にも残せます。テストの通過、コードの実行、説明への回答が、学んだ証拠として記録されます。Proof を外に公開する仕組みは今準備中なので、応募では作品の URL と GitHub のリポジトリを中心にします。
AI で作った物の書き方
Claude Code、Cursor、GitHub Copilot などの AI を使って作るのは、今はふつうのことです。隠すより、どれだけ使ったかを決まった言葉で書くほうが、読む人に伝わります。ゆめさく Proof では、AI の使い方を次の 5 つの段で記録しています。README にもこの言葉をそのまま使えます。
AI が書いた所を、自分の言葉で説明できるかを確かめます。なぜこの書き方なのか、この行を消すと何が壊れるのか、どのテストで確かめたのか。3 つに答えられない所は、面接で聞かれる前に読み直します。
コードの大部分を AI に書かせたなら、見せどころは仕様と確かめ方に移ります。何を作るかを言葉で決め、テストを先に書き、AI が出した差分を読んで受け取った、という流れを README に書きます。この進め方はAI駆動開発の頁にまとめています。
いくつ、何を作るか
作品は、途中の物を 3 つ並べるより、最後まで作って公開した 1 つのほうが伝わります。1 つ目は、目指す職種で使う技術で作ります。職種がまだ決まっていない人は、先に職種から選ぶ学ぶ順番を見てください。
出す前の点検表
応募の前に、上から順に「はい」と言えるかを見ます。
- URL を開くと、説明のとおりに 1 回使える
- ログインが要る物には、試し用のアカウントが書いてある
- README の最初の 3 行で、何のための物かが分かる
- 自分で足した所と、教材から始めた所が分かれている
- AI の使い方を、5 つの段のどれかの言葉で書いている
- 「まずここを読んでください」のファイルが 1 つある
- まだできていないことを、1 つ以上書いている
- パスワードや API の鍵が、コードにも履歴にも入っていない
- スマホの幅で開いても、使えなくはない
- この作品について 3 分話せる
パスワードや API の鍵を一度でもコミットしたら、消すコミットを足しても履歴に残ります。見つけたら、まずその鍵を使えなくして新しい鍵に替えます。
よくある疑問
載せてかまいません。教材から始めた所と自分で足した所を README で分け、足した所を 1 つ以上作ってください。分けずに載せると、どこまでが自分の力かを読む人が判断できません。
書かないで面接で聞かれ、説明できないほうが困ります。どれだけ使ったかを決まった言葉で書き、AI が書いた所を自分の言葉で説明できるようにしておけば、使ったこと自体は問題になりにくくなります。
エンジニアの応募では、見た目より動くことと説明が先に見られます。文字が読める、ボタンが押せる、スマホで崩れきらない、の 3 つがそろえば足ります。
決まった数はありません。まず 1 つを最後まで作って公開し、この頁の点検表を全部通してください。2 つ目は、1 つ目で足りなかった技術を補う物にします。
出典
