ポートフォリオの作り方

ポートフォリオに「載せてはいけない」NG事例集

生田 陸人
監修
LuaGate エンジニア / 現役エンジニア
編集 LuaGate編集部

このレッスンで分かること

  • この記事では「ポートフォリオに「載せてはいけない」NG事例集」を ポートフォリオ作成 の現場で使える形で整理します
  • ポートフォリオに載せてはいけないNG事例を知る重要性 をおさえれば、現場で迷ったときに立ち戻れる
  • 1. チュートリアルそのままの写経プロジェクト をおさえれば、現場で迷ったときに立ち戻れる
  • なぜチュートリアル作品は評価されないのか？ をおさえれば、現場で迷ったときに立ち戻れる
  • 改善のポイント をおさえれば、現場で迷ったときに立ち戻れる

ポートフォリオに「載せてはいけない」NG事例集 とは

エンジニア採用担当者の評価を下げる「ポートフォリオのNG事例」を徹底解説。チュートリアル作品、セキュリティ不備、コードの乱れ、不十分なREADMEなど、未経験者が陥りやすい罠を回避し、内定率を高めるための具体的な改善策を学びます。

ポートフォリオに「載せてはいけない」NG事例を知る重要性

エンジニア転職において、ポートフォリオはあなたの技術力を証明する最大の武器です。しかし、多くの未経験者が陥る罠があります。それは、「何でも載せれば評価が上がる」という勘違いです。採用担当者は非常に忙しく、一つのポートフォリオを確認する時間は数分、早ければ数十秒です。

その短い時間の中で、もし評価を下げる要素（NG事例）を見つけてしまったらどうなるでしょうか？技術力以前に「プロ意識が低い」「エンジニアとしての基礎が欠けている」と判断され、不採用通知が届くことになります。本レッスンでは、せっかくの努力を台無しにしないために、ポートフォリオに載せてはいけないNG事例を徹底解説します。

結論先出し — NG事例は 「写経」「汚いコード」「秘匿情報の漏洩」「貧弱なREADME」「壊れたUI」の5系統 に集約される。1つでもあれば書類落ちの理由になります。

diagram (will load when visible)

1. チュートリアルそのままの「写経」プロジェクト

最も多いNG事例が、プログラミング学習サイトや技術書のチュートリアルをそのまま作り、公開しているケースです。

なぜチュートリアル作品は評価されないのか？

採用担当者が知りたいのは、「あなたが自ら考え、問題を解決できる能力があるか」です。教材の指示通りにコードを書く「写経」は、タイピングの練習にはなりますが、エンジニアとしての思考プロセスを証明することにはなりません。

避けたい例

Markdown

### 制作物一覧 - Todoリスト（教材の通り） - 掲示板アプリ（教材の通り） - 天気予報アプリ（APIを表示するだけ）

良い例

Markdown

### 制作物一覧 - カレンダー連携機能付きTodoリスト - メンション・画像投稿機能を追加した掲示板 - 独自のデータ分析を加えた天気予報アプリ

改善のポイント

もしチュートリアルで作ったものを載せたい場合は、必ず「オリジナルの付加価値」を加えてください。例えば、Todoリストなら「カレンダー連携機能」を追加したり、掲示板なら「画像投稿やメンション機能」を自力で実装したりすることで、初めてあなたの実力として評価されます。

2. 汚いソースコードと「スパゲッティコード」

ポートフォリオのURLだけでなく、GitHubのリポジトリも必ずチェックされます。そこでコードが読みづらいと、チーム開発に適さないと判断されます。

避けるべきコードの状態

  • 変数名・関数名が適当はa, b, data1 など、意味がわからない命名は厳禁です。

避けたい例

JavaScript

// 何のデータか分からない const d = "2023-10-01"; function check(a) { // 処理内容... }

良い例

JavaScript

// 役割が明確な命名 const registrationDate = "2023-10-01"; function isValidEmail(email) { // 処理内容... }
  • 1つのファイルが長すぎる：1つのファイルに何千行も書かれていると、メンテナンス性が低いと見なされます（リファクタリング不足）。
  • コメントが全くない、または不要なコメントが多いは適切なコード解説がない、あるいは逆に「ここから開始」といった当たり前のコメントばかりなのはNGです。
  • インデント（字下げ）がバラバラはコードの見た目が整っていないのは、プロとしての基礎ができていない証拠です。

整理されたコードを保つために

リファクタリング（外部の動作を変えずに内部構造を整理すること）を必ず行いましょう。また、Linter（コードの書き方をチェックするツール）やFormatterを導入し、標準的なコーディング規約に沿った美しいコードを目指してください。

3. セキュリティ意識の欠如：秘匿情報の公開

これは技術力の低さ以上に、エンジニアとしての信頼を致命的に損なうNG行為です。実務では顧客データや機密情報を扱うため、セキュリティ意識が低い人は採用を控えられる傾向にあります。

公開してはいけない情報（一例）

項目具体的な例
APIキーAWSのアクセスキー、Google Maps API、OpenAI APIのキーなど
パスワードデータベースの接続パスワード、外部サービスのログイン情報
環境変数.envファイルに含まれる設定情報
個人情報テストデータとして入れた本物の氏名、メールアドレス、電話番号

防止策：.gitignore の活用

GitHubにアップロードする際、公開したくないファイルを指定する .gitignore ファイルを正しく設定してください。万が一、過去のコミット履歴にAPIキーを含めてしまった場合は、まず必ず該当キーを無効化・再発行してください。その上で、履歴ごと削除するか（git filter-repo 等）、リポジトリを作り直す必要があります。

diagram (will load when visible)

ここまでの要約 — セキュリティ事故は 「コードレビュー以前の不採用フラグ」。.gitignore と環境変数管理は 最初のコミット前 に整備しましょう。

4. READMEが未整備、または不親切

GitHubのトップ画面に表示される README.md は、プロジェクトの「顔」です。ここがスカスカだと、中身を見る前にブラウザを閉じられてしまいます。

READMEのNG例

  • タイトルしかないは何を作るためのリポジトリか説明がない。
  • セットアップ手順がないはローカルで動かす方法がわからない。
  • デプロイ先のリンク（URL）がないは実際に動くものを見せるための配慮がない。
  • スクリーンショットがないは視覚的にどのようなアプリか伝わらない。

理想的なREADMEの構成案

  1. アプリ名と概要（一言で魅力を伝える）
  2. 使用技術スタック（言語、フレームワーク、ライブラリ、インフラ）
  3. 主な機能一覧
  4. デプロイ先URLとテスト用ログイン情報
  5. アプリを作成した背景・解決した課題
  6. こだわったポイント・苦労した点
  7. ローカル実行環境の構築手順

5. デザイン・UI/UXが著しく損なわれている

「バックエンド志望だからデザインは関係ない」というのは大きな間違いです。採用担当者はエンドユーザーの視点でもポートフォリオを見ます。

注意すべきポイント

  • リンク切れ・ボタンが反応しないは最低限の動作チェックが行われていない印象を与えます。
  • レスポンシブ未対応はスマホで見た時にレイアウトが崩れている（現代のWeb開発ではスマホ対応は必須です）。
  • 著作権侵害をしている画像の使用はネット上の画像を勝手に使うのは法的なリスクがあります。フリー素材サイト（Unsplashやいらすとや等）を正しく利用しましょう。
  • 「未完成」の文字があるは未完成の機能を堂々と載せるのは避けましょう。見せるなら完成した部分だけに絞るべきです。

6. まとめ：引き算の美学で「最高の一品」を作る

ポートフォリオ作成において大切なのは、「量よりも質」です。10個の低品質なプロジェクトを並べるよりも、1個の高品質で丁寧に作り込まれたプロジェクトの方が遥かに高く評価されます。

今回紹介したNG事例に心当たりがある方は、今すぐ修正を始めましょう。特に「セキュリティ」と「コードの綺麗さ」は、エンジニアとしての姿勢を問われる部分です。これらをクリアすることで、採用担当者に「この人なら安心して現場を任せられる」と思わせることが、内定への第一歩となります。

NG事例を避けることは、技術をアピールすることと同じくらい重要です。自分の作品を客観的に見直し、プロとして恥ずかしくない状態に仕上げていきましょう！

次は、既存サービスを参考にしつつ、どのようにオリジナリティを出していくかを学んでいきましょう。

現場でよくある具体例

  1. Aさん (受託企業内定) は GitHub の README 冒頭に「誰の何を解決するか」を 3 行で書き、デプロイ URL を最上段に置いた。それだけで書類通過率が 2 倍に
  2. Bさん (自社開発内定) は技術選定理由を README の「Why this stack?」セクションに明記。面接が「決定根拠の深掘り」中心になり、暗記質問が消えた
  3. Cさん (落選続き → 内定) はテーブルを切ってコミット履歴を整理。「feat: 機能追加」のような Conventional Commits に変えた途端、レビュー観点での評価が上がった

次にとるべきアクション

  1. 今のポートフォリオを採用視点で 30 秒見直す — README・デプロイ URL・スクショの 3 点が即座に伝わるか確認する
  2. 改善ポイントを GitHub Issue 化する — 「ポートフォリオに「載せてはいけない」NG事例集」で得た観点を、自分のリポジトリの Issue として 3 件登録する
  3. 実装/修正を次の 1 週間で完了させる — Issue を Pull Request に落とし込み、コミットメッセージにも改善理由を残す

次のレッスン

次は 既存サービスを「模倣」する際の注意点と付加価値の付け方 で、既存サービスを「模倣」する際の注意点と付加価値の付け方 を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

  1. PF NG事例 の要点を自分の言葉で説明できる
  2. このレッスンの最小コード (または操作手順) を見ずに書ける
  3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. PF NG事例 とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン

参考にした出典

学習を加速したい方へ

未経験エンジニア向けポートフォリオ作成ガイドを体系的にマスターするなら、chotdekiru の無料学習ポータル で実際に手を動かして学習を始めるのがおすすめです。質問・つまずきも現役エンジニアが伴走します。

復習ミニクイズ

エンジニア採用担当者に「この人なら安心して現場を任せられる」と評価されるための、最も適切なポートフォリオの改善アクションはどれですか？

参考リンク