エンジニア転職のポートフォリオ｜採用側が見る評価の3つの軸

こんにちは！SiiD代表エンジニアのセイトです。

エンジニア転職のポートフォリオは、作れば評価されるものではありません。書類選考を通り、面接で技術的な会話が続くところまで持っていける作品だけが、選考であなたを助けてくれます。逆に言えば、面接官が5分で質問を切り上げてしまうポートフォリオは、時間をかけて作っても評価にほとんど貢献しません。

採用する側・エンジニア組織を預かる側として選考に関わってきた立場から、実際に評価が分かれるポイントだけを書きます。まずは、送られてきたポートフォリオを採用側がどう見ているかから。

採用側がポートフォリオを見る3つの軸

ポートフォリオが送られてきたとき、採用側は作品を鑑賞しているわけではありません。「この人を採ったとして、現場で戦力になるか」を短時間で見積もるために見ています。判断に使っている軸は、大きく次の3つです。

＜画像：ポートフォリオの評価3軸の図解。中央に「ポートフォリオ」、そこから「①技術的に偏っていないか」「②本人が本当に作れるレベルか」「③ユニークさ（技術／テーマ）」の3方向に矢印。3つの下に共通のゴールとして「面接で技術的な会話が続くか」を置く＞

1. 片側だけで完結する作品は、扱える範囲が狭いと見なされる

Webアプリケーションは、画面（フロントエンド）だけでも、サーバー側の処理（バックエンド）だけでも成立しません。どちらか片方で完成してしまう作品は、それだけで評価の上限が決まります。

たとえば見た目のきれいなWebサイトを提出しても、それがHTML・CSS・JavaScriptだけで作れてしまうものなら、データベースを設計した経験もサーバー側のロジックを書いた経験も伝わりません。次章で扱うCRUD・認証・外部API連携の3点セットは、この偏りを埋めるためのものです。

2. 説明できない機能は、載せないほうが有利

採用側は、実力とアウトプットが釣り合っているかを見ています。疑っているわけではなく、面接で何をどこまで聞けるかを見極めているのです。

学習期間が3ヶ月と書かれているのに、大規模な決済機能やリアルタイム通信を備えた作品が出てくると、面接では必ず「どこをどう実装したのか」を細かく聞かれます。そこで答えられなければ、作品の完成度が高いほど印象は悪くなります。技術的に背伸びをするより、自分が中身を全部説明できる範囲で作るほうが選考では有利です。

3. 他の応募者と見分けがつく一点を用意する

ここでのユニークさは、技術面とテーマ面のどちらかで構いません。使っている技術の組み合わせが珍しい、題材が身近で具体的、どちらでもいい。求められているのは独創性そのものではなく、他の応募者と区別がつく手がかりです。

学習教材をなぞっただけのToDoアプリやブログ風アプリが弱いのは、機能が足りないからではなく、この手がかりがまったく無いからです。

3つの軸が向かう先は「面接で話が続くか」

3つの軸は独立して並んでいるように見えますが、行き着く先は同じです。技術的に幅があり、自分で説明でき、他と違う点があるポートフォリオは、面接で質問が続きます。

面接官にとって、技術の話が具体的に展開できる応募者は評価しやすい相手です。逆に「頑張って作りました」で終わってしまうと、質問の糸口がなく、人物面の話に切り替わります。技術職の選考で技術の話ができないまま終わるのは、それ自体が大きな機会損失です。

ポートフォリオを作るときは、完成させることをゴールにせず、面接でこの作品について30分話せるかを基準に設計してください。以降の章は、そのための具体的な手順です。

CRUD・認証・APIの3点セットを外さない

技術的な偏りを避けるために、最低限おさえておきたい機能が3つあります。CRUD、認証、外部APIとの連携です。この3つが揃っていれば、Webアプリケーション開発のひととおりの流れを扱えることが伝わります。

＜画像：Webアプリの3点セットの構成図。左に「ブラウザ（画面）」、中央に「サーバー（アプリケーション）」、右に「データベース」を配置し、中央から上方向に「外部API」への矢印。中央とデータベースの間に「CRUD（作成・参照・更新・削除）」、ブラウザと中央の間に「認証（ログイン・権限）」のラベルを置く＞

CRUD：データを扱えることの最低条件

CRUDはCreate（作成）・Read（参照）・Update（更新）・Delete（削除）の頭文字で、データベースに対する基本操作をまとめた呼び方です。投稿する、一覧で見る、編集する、消す。この4つが動くということは、画面・サーバー処理・データベースが一本の線でつながっているという証明になります。

見落とされがちなのは更新と削除です。作成と一覧表示だけで止まっている作品はかなり多いのですが、更新・削除には「他人のデータを勝手に操作されないか」「削除したデータに紐づくデータをどうするか」といった設計判断が必ず伴います。面接で聞かれやすいのもここです。

認証：他人のデータと自分のデータを分ける

認証（ログイン機能）は、ユーザーごとにデータを分けるために必要です。逆に言えば、認証がないアプリは全員が同じデータを見る前提で作られているということで、設計としてかなり単純になります。

自前で実装してもいいですし、Firebase AuthenticationのようなIDaaS（ID管理をサービスとして提供する仕組み）を使っても構いません。大事なのは、ログインしているユーザーが誰かをサーバー側でどう判定しているのか、自分の言葉で説明できることです。「ライブラリを入れたら動きました」で止めないでください。

API：外部と通信する経験があること

APIは、他のサービスの機能やデータをプログラムから呼び出すための窓口です。天気、地図、決済、生成AIなど、実務のアプリケーションはほぼ必ず外部と通信します。

外部APIを1つ組み込むだけで、通信の失敗をどう扱うか、キー（認証情報）をどこに置くか、レスポンスをどう画面に反映するかといった、実務そのものの論点に触れることになります。自作の機能を1つ増やすより、はるかに費用対効果が高いので必ず入れておきましょう！

やりがちなNG例：HTML・CSS・JavaScriptだけのWebサイト

企業サイト風のページや、アニメーションの効いたランディングページ。見た目のインパクトはありますが、これらはHTML・CSS・JavaScriptだけで完成してしまいます。

デザイン職やマークアップ職を志望するなら適切な作品ですが、Webアプリケーションエンジニアの選考ではフロントエンドに偏った作品と受け取られます。すでにこの手の作品を持っているなら、そこにログインと投稿機能を足してアプリケーション化するだけでも評価は変わります。

なお、3点セットが揃っていても、公開されていて実際に触れる状態になっていなければ選考では読まれません。動くURLと、何をどう作ったかが書かれたREADMEはセットで用意してください。

コードを置くGitHubリポジトリも公開設定にしておきます。採用側はコードそのものだけでなく、コミットの粒度やメッセージも見ています。1回のコミットに全ファイルをまとめて入れているようなリポジトリは、チーム開発の経験がない印を自分から出しているのと同じです。

企画は実在する1人の困りごとから始める

機能構成が決まっても、何を作るかが決まらないという相談は非常に多いです。ここでつまずく原因はほぼ共通していて、先に「作りたいもの」を考えてしまうことにあります。順番を逆にしてください。

ペルソナは架空の人物ではなく実在の人物にする

ペルソナとは、そのサービスを使う典型的なユーザー像のことです。マーケティングの解説では「30代女性、会社員、趣味は……」といった架空の人物像を組み立てますが、ポートフォリオの企画では実在する具体的な誰かを置いてください。

親、友人、前職の同僚、部活の後輩、自分自身。誰でも構いませんが、実際に話を聞ける相手であることが条件です。架空の人物を置くと、困りごとも自分の都合のいいように作れてしまい、「本当にそんな人いますか？」と聞かれた瞬間に企画が崩れます。

実在の人物を置くと、企画の説明がそのまま面接で使えます。「前職の店長が、シフト希望をLINEで受け取って手作業で表に転記していたので、それを置き換えました」と言えれば、課題設定の妥当性を疑う人はいません。

類似サービスを3つ挙げて、そこからのズレを1点だけ作る

企画が固まったら、必ず似ているサービスを調べて3つ挙げておきます。これは真似をするためではなく、次の2つのために必要です。

世の中にある解決策を知らないまま作り始めるのを防ぐ
面接で「それ、◯◯というサービスがありますよね」と言われたときに答えられる

そのうえで、自分の作品が既存サービスとどこで違うのかを1点だけ決めます。全部違うものを作る必要はありません。むしろ、ゼロから独創的なものを狙うと難易度が跳ね上がり、完成しないまま転職活動の期限が来ます。

「シフト管理サービスは多いが、飲食店のアルバイトが使う前提でスマートフォンだけで完結する」。この程度のズレで十分です。オリジナリティは、面接で違いを1文で言えるかどうかが基準であって、量ではありません。

課題が解決できているかを最後に確認する

作り終わったら、最初に置いた実在の人物にもう一度見せてください。使ってもらえれば理想ですが、それが難しくても意見を聞くだけで違います。

ここで「便利だけど、これなら今のやり方でいい」と言われたら、その作品はまだ課題を解決できていません。厳しい確認ですが、面接官も同じところを見ています。課題設定・解決策・結果がひとつながりで説明できる作品は、機能数が少なくても評価されます。

企画で落ちる人がハマる3つのアンチパターン

添削をしていると、企画段階での失敗はほぼ3パターンに収まります。いずれも技術力ではなく、サービスを見てきた量の不足が原因です。該当したときの直し方も併せて書きます。

1. 「それ本当に使う？」というアイデア

一番多いのがこれです。機能としては動くけれど、誰も日常的には使わない。たとえば「読んだ本の感想を投稿してシェアするアプリ」は、企画としては成立しているように見えますが、投稿する動機が弱く、初回以降使われません。

直し方：その作品を、自分が1週間続けて使えるかを考えてください。使う理由が「作ったから」しかないなら、使う場面が具体的に決まっていないということです。実在のペルソナに立ち返り、その人が今どんな手作業をしているかから作り直します。

2. 「それ、Excelでよくない？」で終わってしまう

データを登録して一覧で見るだけのアプリは、表計算ソフトで代替できます。面接官がこの一言を出した時点で、作品の存在意義を説明できないと厳しくなります。

直し方：表計算ソフトが苦手なことを1つ載せます。複数人が同時に更新する、権限によって見える範囲を変える、条件を満たしたら自動で通知する、外部サービスからデータを取ってくる。どれか1つでも入れば、アプリケーションとして作る理由が生まれます。基本構成として挙げた外部API連携は、ここでも効きます。

3. PCとスマートフォンのどちらが前提かを決めていない

意外に軽視されるのがこれです。利用シーンを詰めていない作品は、画面設計を見ればすぐに分かります。現場で使う想定なのにPCの広い画面でしか成立しないレイアウトだったり、逆にデスクワーク前提の管理画面がスマートフォン幅で作られていたりします。

これは作り始める前にしか直せません。企画の時点で主に使われるのはどちらかを決め、そちらの画面から作ってください。両方に対応させる場合も、優先する側を決めておかないとレイアウトの判断がぶれます。面接では「なぜスマートフォン優先にしたのか」と聞かれるので、ユーザーの利用シーンで答えられる状態にしておきましょう。

ネタの引き出しは毎日のアプリレビューで貯める

前章のアンチパターンは、どれも「世の中のサービスを見てきた量」で防げます。企画が思いつかないのは発想力の問題ではなく、単純に引き出しが空だからです。そして引き出しは、意識的に埋めれば1〜2ヶ月で目に見えて増えます。

やることはシンプルで、自分が普段使っているアプリやWebサービスを1日1つ選び、作り手の視点で見るだけです。眺めるのではなく、次の観点でメモを取ります。

画面の数と役割：一覧・詳細・作成・設定など、どんな画面で構成されているか
データの単位：何を1件として保存しているか（投稿、予約、商品、メッセージなど）
ユーザーの種類：一般ユーザーと管理者で見えるものがどう違うか
外部連携：地図、決済、通知、ログイン連携など、外のサービスを何に使っているか
自分ならどこを変えるか：使いにくいと感じた画面と、その理由

慣れれば1つ10分程度で終わります。3行のメモで十分なので、続けやすい形にしてください。

ただし、機能を書き写すだけでは引き出しになりません。なぜその画面構成なのか、なぜその情報を最初に見せているのかまで推測して書くと、自分が設計する側に回ったときに使えます。たとえばフリマアプリの出品画面が最初にカメラを起動する設計になっているのは、出品の離脱が写真撮影で起きやすいからだと推測できます。

この「推測して言語化する」練習は、そのまま面接でも効きます。「最近気になったサービスは？」という質問はよく出ますが、分解した経験がある人の答えは具体性がまったく違います。

生成AIは見た目と設計に使い、説明責任は自分が持つ

生成AIを使ったかどうかを問題にする企業は、私が関わってきた選考ではほぼ見かけなくなりました。問われるのは、AIが書いた部分をどこまで理解しているかです。使いどころを間違えると評価を下げますが、正しく使えば手数は確実に増えます。

UIは遠慮なくAIに整えてもらう

未経験からのポートフォリオで、見た目の粗さが原因で損をしているケースは多いです。配色がちぐはぐ、余白が詰まっている、フォントサイズが揃っていない。中身が良くても、最初の画面で雑な印象がつくと不利になります。

ここは生成AIが得意な領域です。画面のスクリーンショットを渡して改善点を挙げてもらう、TailwindCSSのようなCSSフレームワーク（用意されたクラスを組み合わせて見た目を作る仕組み）を前提にコンポーネントを書き直してもらう、といった使い方で十分整います。デザインの学習に時間を使うより、AIに整えさせて中身の作り込みに時間を回すほうが合理的です。

設計の相談は、答えではなく検証を投げる

企画が固まったあと、データベースのテーブル構成や画面遷移をAIに相談するのも効果的です。ただし出てきた案をそのまま採用すると、面接で「なぜこの設計にしたのか」に答えられなくなります。次の3つで潰してから採用してください。

各テーブルについて「このカラムが無いと何が壊れるか」を1つずつ挙げさせる
主要な画面を1枚選び「この画面を表示するのに何回データベースを参照するか」を書かせる
「この設計で将来困る場面を3つ」を挙げさせ、そのうち自分の作品で実際に起きるものだけ対処する

ここまでやると、設計の理由を自分の言葉で説明できる状態になります。

説明できないコードを残さないこと

問題になるのは、AIが出力したコードを理解しないまま組み込んでしまう場合です。面接では「この処理は何をしていますか」「なぜこのライブラリを選びましたか」と踏み込んで聞かれます。ここで答えられないと、作品全体の信頼性が一気に下がります。

判断基準はシンプルで、自分のポートフォリオの中に、他人に説明できない行を1行も残さないことです。理解が追いつかないコードが出てきたら、削るか、理解できる実装に置き換えるか、AIに解説させて理解するかのどれかを選んでください。

AIを使ったこと自体は隠す必要がありません。むしろ「この部分は生成AIに書かせたうえで、こういう理由でこう直した」と説明できるほうが、実務での使い方をわかっている人という評価になります。

仕事で作れる立場なら、ポートフォリオより実務を選ぶ

ここまではゼロからポートフォリオを作る前提で書いてきましたが、今の職場で何かを作れる立場にいる人は、話が変わります。実務で使われているものは、個人開発のポートフォリオより強い実績です。

理由は単純で、実務のシステムには自分以外の利用者がいて、要望と制約があり、動かなくなったら困る人がいるからです。この条件下で作って運用した経験は、個人開発では再現できません。

エンジニア職の場合

すでにエンジニアとして働いているなら、業務で担当した機能や改善をそのまま職務経歴書に書けます。社外に出せないコードでも、担当範囲・技術選定の理由・遭遇した課題とその解決を言語化しておけば、面接では十分に伝わります。

その前提で、個人開発は「業務で扱えない技術を触った証明」として補助的に使うのが効率的です。業務がバックエンド中心ならフロントエンドの作品を、レガシーな環境なら新しめのフレームワークを、といった具合に、経歴の穴を埋める目的で選びます。

事務職・営業職など、非エンジニア職の場合

エンジニア職ではなくても、社内の手作業を自動化できる場面はどこにでもあります。実際に評価につながりやすいのは、次のようなものです。

営業先リストの作成を自動化する（各社が公開しているデータや、提供されているAPIから情報を集めて整形する）
ExcelのVBA（Excelに標準で組み込まれているプログラミング機能）で、日々のデータ入力・集計を自動化する
スプレッドシートとGoogle Apps Script（Googleのサービスを自動化できるスクリプト実行環境）で、申請や集計のフローを仕組み化する
定型的な報告書の作成を、既存のツールとAPIを組み合わせて省力化する

派手さはありませんが、「業務課題を見つけて、自分で作って、実際に使われている」という流れは、未経験者のポートフォリオが最も再現しにくい部分そのものです。削減できた作業時間を数字で言えるなら、さらに強くなります！

なお、Webサイトから自動でデータを集める場合は、対象サイトの利用規約とrobots.txt（クローラーへの許可設定を書いたファイル）を必ず確認し、アクセス頻度にも配慮してください。規約違反のツールを実績として提出すると、逆に判断力を疑われます。

そして、業務で作ったものは会社の資産です。コードや画面をそのまま公開するのは避け、面接では「何を課題として、どう解決し、どんな結果になったか」を口頭で説明する形にしてください。

作り始める前に決めきることが、評価を決める

評価されるポートフォリオの条件は、技術的に偏っていないこと、自分で全部説明できること、他の応募者と区別がつくことの3つです。そのために、CRUD・認証・外部API連携という基本構成を外さず、企画は実在する誰かの困りごとから立ち上げる。生成AIは見た目と設計に使い、説明できないコードは残さない。

決める工程のほうが手を動かす工程より長く見えますが、順序を逆にすると、完成してから作り直すことになります。

とはいえ、企画の妥当性や技術構成が適切かどうかは、自分ひとりでは判断しづらい部分でもあります。私が代表を務めるAIプログラミングスクール SiiD では、ポートフォリオや仕様書の添削、模擬面接まで含めた転職支援を用意しています。講師は現役エンジニアに加えて、人事部長・社長を経験した採用側の人間もいます。自分の作品でどこまで戦えるか相談したい方は、個別説明会で直接聞いてください。