「ポートフォリオって、結局どこを見られるの？」
未経験で転職を考え始めると、ここが一番不安になりますよね。SNSや体験談を追うほど情報が増えて、完成度やデザイン、GitHubまで気になってしまう。僕も学習初期に“正解探し”にハマって、2週間くらい調べるだけで手が止まったことがあります。結論を少し先に言うと、未経験 ポートフォリオで見られるのは作品の豪華さだけではありません。むしろ「なぜ作ったか」「どう詰まってどう直したか」「次にどう改善するか」が伝わるかが重要です。この記事では、採用側の視点で転職 ポートフォリオ 評価のポイントを整理しつつ、評価が下がりやすいNG例と、まず整えるべき“見せ方・説明の型”までまとめます。読むだけで、次に何を準備すればいいかがはっきりするはずです。
未経験が不安になるのは「見られるポイント」が見えないから
ポートフォリオって、作る前から不安になりますよね。
「何を作ればいいんだろう」もそうだし、そもそも「どこを見られるの？」が分からない。
この“基準のなさ”が一番しんどいです。
僕も未経験の頃、ここで完全に止まりました。
当時は仕事をしながら学習していて、平日は1日1時間が限界。
だからこそ遠回りしたくなくて、正解を探し続けたんです。
結果、手を動かす時間より、調べる時間が増えました。
そして余計に不安になりました。
この章では、まずその不安の正体を言語化します。
「自分だけじゃない」と分かるだけで、かなりラクになります。
SNSや体験談を見て焦る心理
未経験の頃、僕はSNSと転職体験談を毎日のように見ていました。
「このポートフォリオで内定」
「未経験でも3ヶ月で転職成功」
そういう投稿を見ると、希望も湧くんです。
でも同時に、焦りも強くなります。
特にしんどいのが、情報が多すぎて判断できなくなること。
ある人は「TodoアプリでOK」。
別の人は「React必須」。
さらに別の人は「デザインが大事」。
みんな言うことが違う。
未経験の自分には、どれが正しいのか分からない。
だから「もっと調べないと」と思ってしまう。
僕はこれで、2週間くらい“検索だけして何も作ってない状態”になりました。
平日の1時間を全部YouTubeと記事に使ってしまって、手を動かしたのは最後の10分だけ。
そして寝る前にスマホを見て、また焦る。
「自分だけ足りない」感が出ると、どんどん自信が削られます。
本当は比較する相手が違うのに、つい比べてしまうんですよね。
この時期にいちばん辛かったのは、スキル不足というより、
“何が足りないか分からない不安”でした。
不安の正体は“比較”と“基準の不在”
未経験のポートフォリオ不安は、だいたい2つに分解できます。
ひとつは比較。
もうひとつは基準がないこと。
つまり、「誰と比べて」「何が正解か分からない」状態です。
未経験者が抱えがちな不安を、悩みとして整理するとこうなります。
- 完成度が低いと落ちるのでは？
- デザインが素人っぽいとダメ？
- コード量が少ないと評価されない？
- 流行技術（React/TypeScriptなど）がないと不利？
- GitHubをちゃんと使ってないとマズい？
- READMEや説明が弱いと見てもらえない？
- 面接で「工夫点」を聞かれたら答えられないかも
- そもそも何を作れば“正解”なのか分からない
これ、どれも自然な不安です。
真面目にやろうとしている人ほど、全部気になります。
ただ、ここで知っておいてほしいのは、採用側が見ているのは“全部を完璧に揃えた人”ではないということです。
次の章では、採用側が実際に見ているポイントを「完成度以外」の観点で整理します。
見られるポイントが分かると、急にやることが絞れてきます。
不安が「行動」に変わる感覚が出てくるはずです。
採用側がポートフォリオで見ているのは“完成度”だけじゃない
未経験の人ほど、「完成度を上げないと評価されない」と思いがちです。
僕もそうでした。
見た目を整えて、機能を増やして、なんなら流行の技術も入れて。
でも、実際の採用現場はもっと現実的です。
採用側が不安なのは「この人、入社してから伸びるか？」です。
未経験だと職務経歴で判断できないぶん、ポートフォリオが“人となり”の材料になります。
だから見られるのは、作品の豪華さよりも「考え方」と「向き合い方」。
これを知っておくと、無駄に消耗しなくなります。
技術力より見られる“3つ”
未経験ポートフォリオで一番大事なのは、技術の種類より“3つ”です。
思考、学習姿勢、説明力。
言い換えると、こうです。
- なぜ作ったか
- どう詰まってどう直したか
- 次にどう改善するか
ここが話せる人は強いです。
逆に、どんなにそれっぽい作品でも、ここが弱いと評価は伸びません。
「動きます」で終わると、採用側が判断できないからです。
僕も一回、これで失敗しました。
学習初期に、チュートリアルをなぞって作ったアプリを提出したんです。
動くし、見た目もそこそこ。
でも面接で「工夫した点は？」と聞かれて、言葉が出ませんでした。
正直、作ったというより“作らされた”に近かったからです。
その瞬間、空気が変わったのを今でも覚えています。
じゃあ、具体的に何が評価されやすいのか。
判断軸として整理すると、次のポイントが見られます。
- 目的がある（何の課題を解決したいかが分かる）
- ユーザー想定がある（誰に向けたものかが言える）
- 完走している（小さくても最後まで仕上げている）
- READMEがある（使い方・工夫点・改善点が書かれている）
- 改善点を言語化している（次に直したい点が具体的）
- コミットが積み上がっている（試行錯誤が見える）
- エラー対応の記録がある（詰まり→解決の痕跡が残っている）
ここまで揃っていると、作品の“完成度”が多少粗くても評価されやすいです。
なぜなら、現場でも必要な力だから。
仕事って、正解が一発で出ることの方が少ないです。
エラーが出て、調べて、直して、また出て。
その繰り返しをちゃんと回せるか。
採用側はそこを見ています。
未経験ポートフォリオが“面接の会話の土台”になる話
ポートフォリオの役割を一言で言うなら、面接の会話の土台です。
採用側にとっては、質問が作りやすい。
応募者にとっては、話せる材料が増える。
ここが大きいです。
僕が転職活動で一番ラクになったのは、作品を見ながら会話できた時でした。
それまでは「勉強してます」「やる気あります」しか言えなかった。
正直、それだけだと弱いです。
でもポートフォリオがあると、具体に落ちます。
「この機能はなぜ入れた？」
「どこで詰まった？」
「次は何を改善する？」
こういう質問に、経験がなくても答えられるようになる。
答えられると、相手の反応が良くなる。
反応が良いと、自分も落ち着く。
この流れで信頼が積み上がります。
逆に、作品があっても説明できないと苦しいです。
面接官が深掘りしたくても、話が広がらない。
だからこそ、未経験は「作る」より「説明できる形にする」までがセットです。
次の章では、逆に評価が下がりやすいポートフォリオの特徴を整理します。
「やらない方がいいこと」を先に知っておくと、余計な遠回りを減らせます。
逆に評価が下がりやすいポートフォリオの特徴
未経験のポートフォリオって、「何をやれば評価されるか」より先に、
「何をやると一気に損するか」を知っておく方が安心です。
ここを避けるだけで、見てもらえる確率が上がります。
僕も最初の頃、やらかしました。
作品を一応作ったのに、反応が薄い。
「頑張って作ったのに…」と落ち込みました。
後から見返すと原因はシンプルで、相手に伝わる形になっていなかったんです。
採用側は忙しい。
だから“分かりにくいポートフォリオ”は、それだけで不利になります。
目的不明・説明不足だと、見てもらえない
評価が下がりやすい一番のパターンは、目的不明と説明不足です。
これ、技術以前の問題なんですよね。
たとえば、リンクを開いた瞬間にこう思われたらアウトです。
「で、これは何？」
「どう使うの？」
「どこが工夫？」
この3つが分からないと、見ている側は深掘りできません。
採用側の気持ちになると分かりやすいです。
未経験応募は数が多い。
1つのポートフォリオに時間をかけられません。
だから最初の30秒〜1分で「会話になりそうか」を判断されがちです。
そこで説明がないと、次に進まれます。
僕がやった失敗は、まさにこれでした。
当時、作品ページだけ作って満足していました。
使い方も書いてない。
何を意識したかも書いてない。
「見れば分かるでしょ」と思ってたんです。
でも面接で「これ、何を想定して作ったの？」と聞かれて詰まりました。
自分の中では当たり前でも、相手には伝わっていない。
ここで痛感しました。
最低限、伝えるべきは3つです。
何のアプリか。どう使うか。どこが工夫か。
これがあるだけで、見られ方が変わります。
丸写し感が強いと“成長の再現性”が見えない
もうひとつ、評価が落ちやすいのが丸写し感です。
チュートリアル自体が悪いわけではありません。
むしろ未経験の学習としては普通です。
問題は「自分の言葉がない」ことです。
- 作品がチュートリアルそのまま
- READMEが薄い、またはテンプレのまま
- 改善や試行錯誤が見えない
こうなると、採用側は不安になります。
「入社後も指示待ちにならないかな」
「壁にぶつかったら止まらないかな」
つまり“成長の再現性”が見えないんです。
僕も一度、チュートリアルをそのまま出したことがあります。
コミットも1回だけ。
READMEも最低限。
今思えば、完全に“課題提出”でした。
面接で深掘りされても「動画の通りです…」しか言えない。
あの瞬間、ポートフォリオって作品じゃなくて「会話の材料」なんだと分かりました。
だから未経験のうちは、派手な差分はいりません。
小さな工夫でいい。
「自分で考えた痕跡」を残す。
それが信頼に直結します。
提出前にチェックするNG項目をまとめます。
これは行動整理として、そのまま使ってください。
- リンク切れがある（GitHub、デモ、画像など）
- スマホ表示が崩れている（最低限の確認不足）
- 何のアプリか一言で説明できない
- 使い方が書かれていない（READMEなし／薄い）
- 工夫点・苦労した点が見えない
- コミットが極端に少ない（1回だけ等）
- 動作確認ができない（ログイン情報が不明、データが消える等）
- チュートリアルとの差分がゼロに見える
ここまで読んで、「じゃあ何を整えればいいの？」が見えてきたと思います。
次の章では、不安を減らすために“まず何から”手を付けるかを、準備の順番として整理します。
焦らなくて大丈夫です。やることは意外とシンプルです。
不安を減らすために、まず何から整えればいい？
ここまで読んで、「見られるポイントは分かった。
でも、結局いまの自分は何から手を付ければいいの？」となりますよね。
この段階で大事なのは、転職を急がないことです。
未経験の転職って、勢いだけで動くとメンタルが削れます。
僕も一度、準備が浅いまま応募して、面接でうまく話せず落ち込みました。
「やっぱ無理かも」と感じたのは、スキル不足より“準備不足で戦ったこと”が原因でした。
だから、この章では行動を「学習・準備フェーズ」に着地させます。
やることはシンプルです。
見せ方と説明を整える。
それから、作る順番を決める。
これだけで、不安はかなり減ります。
最初に整えるべきは“見せ方”と“説明の型”
未経験のポートフォリオで差がつくのは、実は作品より先に“見せ方”です。
中身が同じでも、伝わり方が違うと評価が変わります。
採用側は忙しい。
だから、ぱっと見て理解できる形にしておくのが優先です。
一番効くのが、READMEのテンプレ化です。
僕も最初はREADMEを軽視していました。
「コードを見れば分かるでしょ」と思ってたんです。
でも面接に同席する側になって気づきました。
READMEがない作品は、会話が作りにくい。
質問しづらい。
結果、深掘りされずに終わることがあります。
それって、もったいないですよね。
READMEは難しくありません。
型さえあれば書けます。
最低限、これだけは入れておくと強いです。
「何ができるか」「使い方」「工夫点」「今後の改善」。
特に“今後の改善”は、未経験の強い武器になります。
伸びしろを自分で把握している人は、印象がいいからです。
もうひとつは、学習ログの残し方。
これはGitHubのIssuesでも、Notionでも、メモでもOKです。
大事なのは、詰まったことと解決を残すこと。
僕は学習初期、エラー対応で半日溶かした日が何回もありました。
その時の解決メモが、あとで面接の話題になりました。
「どこで詰まりました？」に具体で答えられるだけで、会話が一気に現実的になります。
「何から作る？」で迷う人のための最短手順
次に、よくある迷いを終わらせます。
「何から作る？」問題です。
最短で決める順番はこれです。
職種→言語→作る規模。
逆にすると迷います。
たとえば「言語から選ぶ」と、情報が多すぎて止まります。
「Javaが求人多い」「Pythonが人気」「React必須」みたいに。
でも職種を決めれば、言語は自然に絞れます。
WebならJavaScript中心。
インフラならLinuxとクラウド基礎。
ここが決まると、次に作るものの規模も決めやすいです。
制作も、いきなり大作は不要です。
ミニ制作→小作品→仕上げ。
この順にすると、完走体験が積み上がります。
完走できると自信がつく。
自信があると継続できる。
未経験はここが一番大事です。
今日からできる準備チェックリストを置いておきます。
迷ったら、これを上から順にやってください。
- 目指す職種を1つ決める（Web/インフラ/社内SEなど）
- 学習言語（軸）を1つに絞る
- 作るものを1つに絞る（ミニ制作でOK）
- READMEを“型”で書く（何ができる／使い方／工夫点／改善点）
- 改善点を3つだけ書き出す（次に直す場所を決める）
- 詰まったことと解決を1つログに残す（短くてOK）
- 最後にスマホ表示とリンク切れだけ確認する
ここまでできたら、もう「見られるのが怖い」状態ではありません。
準備が整うと、不安は“作業”に変わります。
次にやるべきは、ミニ制作を回しながら、小作品に育てていくこと。
この記事で整理した型を使えば、転職ではなく“学習・準備フェーズ”でもちゃんと前に進めます。
