ポートフォリオの作り方
採用担当者が「見るポイント」と「見ないポイント」
採用担当者が「見るポイント」と「見ないポイント」 とは
エンジニア採用担当者がポートフォリオで重視する「論理的思考」「コードの可読性」「Git運用」と、実は重視されない「デザイン」「機能数」の違いを解説。評価を最大化するための戦略を学びます。
エンジニアとして就職・転職活動を始める際、避けて通れないのが「ポートフォリオ」の作成です。しかし、多くの未経験者が「すごい機能を作らなければ」「最新の技術を使わなければ」と、採用側の意図とは異なる方向に努力を注いでしまいがちです。
採用担当者は、限られた時間の中で何百人ものポートフォリオを確認します。彼らが本当に見ているのは、実はコードの量や機能の派手さではありません。本レッスンでは、採用担当者の視点を理解し、「評価されるポイント」と「実はあまり見られていないポイント」を明確にすることで、最短ルートで内定に近づく戦略を学びます。
採用担当者は コードを読む前に
READMEとデプロイURLを見る。「動く」「読める」「理由が言語化されている」の3つを満たせば、技術スタックが地味でも通過率は跳ね上がる。
採用担当者の評価フロー
ポートフォリオを受け取った採用担当者が、どの順番で何を見ているかを図にすると次のようになります。最初の30秒で離脱されるか、コードまで読み込んでもらえるかは、この入口で決まります。
採用担当者がポートフォリオで「見ているポイント」
採用担当者がポートフォリオを開いた際、まず確認するのは「この人と一緒に働きたいか」「最低限の自走力があるか」という点です。具体的には以下の4つのポイントを重点的にチェックしています。
1. 「なぜこれを作ったか」という論理的な思考プロセス
最も重要なのは技術力そのものよりも、「課題解決の意識」です。「流行っているから」という理由ではなく、「身近な人のこんな悩みを解決したいから」「既存のサービスにはこの機能が足りないと思ったから」といった明確な動機が求められます。
- 誰の、どんな課題を解決するアプリか？
- なぜその技術選定（言語やフレームワーク）をしたのか？
これらがREADME（説明書）に言語化されていると、ビジネス視点を持ったエンジニアとして高く評価されます。
2. コードの「読みやすさ」と「一貫性」
プロの現場では、コードを書く時間よりも読む時間のほうが圧倒的に長いです。そのため、「他人が読んで理解できるコードか」が厳しくチェックされます。
良い例
JavaScript
// 良い例：変数名から中身や役割が推測できる const activeUserList = ["田中", "佐藤"];
避けたい例
JavaScript
// 悪い例：中身が何かわからない const a = ["田中", "佐藤"];
- 適切な変数名・関数名は
aやdata1といった意味不明な名前ではなく、役割が伝わる名前になっているか。 - インデントとコーディング規約はコードの書き方に一貫性があるか（
PrettierやESLintなどのツールを活用しているとなお良い）。 - 責務の分離は1つの関数やファイルが長すぎず、適切に分割されているか。
3. GitHubを正しく使いこなせているか
開発プロセスそのものも評価対象です。完成したコードを一度にアップロードするのではなく、「開発の履歴（コミット履歴）」が見られます。
良い例
プレーンテキスト
// 良い例：変更内容がひと目でわかる feat: ログイン機能の実装 fix: ユーザー登録時のバリデーションエラーを修正
避けたい例
プレーンテキスト
// 悪い例：何をしたか履歴から追えない update 修正 あいうえお
- コミットメッセージの適切さは「修正」だけでなく「〇〇機能の実装」「△△のバグ修正」など、履歴から変更内容がわかるか。
- プルリクエスト（
PR）の活用は自分一人での開発であっても、PRを作成し、自分でセルフレビューを行っている形跡があると、実務のフローを理解していると見なされます。
4. アプリケーションの「完成度」と「動作の確実性」
意外と多いのが、送られてきたURLを開いてもエラーで動かない、あるいは使い方がわからないというケースです。最低限、以下のチェックリストをクリアし、「動作の確実性」を保証する必要があります。
| チェック項目 | 採用担当者の視点 |
|---|---|
| リンク切れがないか | 基本的な確認不足。仕事が雑という印象を与える。 |
| テスト用アカウントがあるか | ログインが必要な場合、すぐに試せる配慮があるか。 |
| エラーハンドリング | 存在しないページにアクセスした際、404ページが表示されるか。 |
採用担当者が「実はあまり見ていないポイント」
逆に、未経験者が時間をかけすぎているものの、採用合否に直結しにくいポイントも存在します。リソースを賢く配分するために、以下の点は「ほどほど」で構いません。
1. プロ級の洗練されたUIデザイン
エンジニア採用（特にバックエンド志望）の場合、デザイナーのような美しいデザインは求められていません。
もちろん、清潔感があり使いやすいことは大切ですが、アニメーションを凝ったり、独自のアイコンを作成したりすることに時間をかけすぎるのは非効率です。BootstrapやTailwind CSSなどのフレームワークを使い、標準的なレイアウトが整っていれば十分です。
2. 機能の「多さ」
「10個の機能がある未完成なアプリ」よりも「3個の機能が完璧に動作するアプリ」のほうが評価されます。未経験者のポートフォリオで「SNS機能、EC機能、チャット機能……」と盛り込みすぎると、一つひとつの実装が甘くなり、バグが目立ちやすくなります。コアとなる機能を絞り込み、その品質を高めることに注力しましょう。
「もっと機能を追加しないと見劣りするかも...」と不安になるかもしれませんが、まずは一つの機能を丁寧に、エラーなく作り込むことがプロへの第一歩です！
3. 難易度の高い最新技術の「つまみ食い」
理由もなく「最新だから」というだけで複雑な技術（例：マイクロサービス、高度なインフラ構成）を取り入れても、基礎が疎かであれば逆効果です。採用担当者は「なぜそれを使ったの？」と必ず質問します。最新技術を使いこなせずバグだらけになるよりは、安定した技術で堅実な設計ができることを示すほうが信頼に繋がります。
デザインの華美さ 機能数の多さ 流行りの最新技術 の3つは、未経験者が時間を溶かしがちな「コスパが悪い努力」。完璧に磨くより、評価される4つの本質に時間を振り直すほうが内定に近い。
評価を最大化するためのREADME戦略
採用担当者が一番最初に見るのはGitHubのREADME.mdです。ここで興味を持ってもらえなければ、コードすら見てもらえません。以下の構成でREADMEを作成することをお勧めします。
- アプリ概要 → 一言で何をするアプリか。
- デプロイURL → すぐに触れる状態にする。
- 使用技術（技術スタック） → 言語、DB、インフラ、選定理由。
- 「こだわったポイント」 → 工夫した点や苦労した解決策（ここが一番の評価ポイント！）。
ER図・システム構成図→ 視覚的に設計能力をアピール。
まとめ：相手の「時間」を尊重する姿勢が内定への近道
採用担当者は非常に多忙です。彼らの視点に立つということは、「いかに短い時間で自分の実力を正しく理解してもらえるか」を考えることと同義です。派手な機能で驚かせる必要はありません。読みやすいコード、整理されたドキュメント、そして「なぜ作ったか」という熱意。これらを丁寧に整えることが、結果として最も高い評価に繋がります。
次のステップでは、これらのポイントを踏まえた上で、未経験者が最低限目指すべき「ポートフォリオの基準ライン」について詳しく見ていきましょう。
次のレッスン
次は 未経験者が作るべきポートフォリオの「最低ライン」 で、未経験者が作るべきポートフォリオの「最低ライン」 を学びます。
事前確認 — 進む前に次の 3 つができることを確認しましょう。
- 採用担当の視点 の要点を自分の言葉で説明できる
- このレッスンの最小コード (または操作手順) を見ずに書ける
- 練習問題やクイズで間違えた箇所を読み直して理解した
理解度チェック (30 秒)
Q. 採用担当の視点 とは何か、1 文で説明してください。
A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。
関連レッスン
復習ミニクイズ
エンジニア採用担当者がポートフォリオを評価する際、最も重視しているポイントは次のうちどれですか？