Developers Journey
キャリア

【実例あり】エンジニアポートフォリオの作り方と題材の選び方

【実例あり】エンジニアポートフォリオの作り方と題材の選び方

ポートフォリオを作ることは決めた。でも、何を作ればいいかわからない。

プログラミング学習を始めた人なら、一度はこの壁にぶつかるのではないでしょうか。

正直に言うと、筆者も最初は失敗しました。

「とりあえずReactの勉強になるから」という理由で、Twitterクローンを作ったんです。3週間くらいかけて、認証機能、投稿、いいね、フォロー機能まで実装。自分としては「けっこう頑張ったな」と思っていました。

でも、面接ではほぼ触れられませんでした。

たぶん採用側からすると「あ、チュートリアルやったんだな」「Udemyかな」くらいの印象だったんだと思います。悲しいけど、事実です。

その後、応募先の技術スタックに合わせて「レシピ共有サイト」を作り直したところ、面接ではソースコードを見ながら会話が進むほど詳しく見てもらえました。題材選びで、こうも印象が変わるのかと痛感した経験です。

この記事では、題材選びから公開までの手順を解説します。具体的なアイデア10選に加え、参考になる実例や、採用担当者が本当に見ているポイントも紹介します。「何を作るか」で迷っている人は参考にしてください。

結論を先に言うと、完成度の高いオリジナル作品を1つ作ることが最も重要です。

エンジニアのポートフォリオとは

エンジニアのポートフォリオとは、自分のスキルと実績を証明するための成果物集です。

履歴書や職務経歴書が「文字情報」でキャリアを伝えるのに対し、ポートフォリオは「実際に作ったもの」でスキルを証明します。

「私はReactが使えます」と書くより、Reactで作ったアプリを見せる方が説得力があるのは明らかでしょう。

ポートフォリオがあると有利になる場面

ポートフォリオが特に効果を発揮するのは、以下のような場面です。

  • 転職活動：書類選考での通過率が変わる。特に自社開発企業やWeb系企業では重視される
  • 副業案件への応募：クラウドソーシングやエージェント経由で案件に応募する際、提案の説得力が増す
  • フリーランス案件の獲得：実績がない段階でのアピール手段として有効

ポートフォリオに載せるべき内容【必須項目】

まず、ポートフォリオに何を載せるべきかを押さえておきましょう。

成果物（Webサイト、アプリなど）

最も重要なのは、実際に動作する成果物です。

  • 動作するURL：デプロイ済みで、誰でもアクセスできる状態
  • ソースコード：GitHubで公開し、コードの品質も見てもらえるようにする

各成果物の説明

成果物を載せるだけでなく、以下の情報を添えましょう。

  • 制作の目的・背景：なぜこれを作ったのか
  • 使用技術：言語、フレームワーク、ライブラリなど
  • 工夫したポイント：技術的な挑戦や、ユーザー体験への配慮
  • 制作期間：どのくらいの時間をかけたか

プロフィール情報

成果物とあわせて、自分自身の情報も記載します。

  • 名前・経歴
  • スキルセット（使える言語・フレームワーク）
  • 今後の目標
  • 連絡先

未経験者が勘違いしがちなポイント

ここで注意点を2つ挙げておきます。

1. 模写サイトだけではNG

Progateやドットインストールで学んだ後、既存サイトの模写をする人は多いです。模写自体は良い練習ですが、ポートフォリオとしては弱い。

なぜなら、模写は「練習した証拠」でしかなく、「自分で考えて作れる」ことの証明にはならないからです。

2. 数より質

10個の模写サイトより、1個のオリジナル作品の方が評価されます。

完成度の高い作品が1つあれば十分です。

【題材10選】何を作ればいい？ポートフォリオのアイデア集

「何を作ればいいかわからない」という悩みを解決するために、具体的な題材を10個紹介します。

初心者向け（HTML/CSS/JavaScript）

1. 架空店舗のLP（ランディングページ）

実在の店舗を参考に「もし依頼されたら」という想定で作るLPです。

  • 例：近所のカフェ、美容室、整体院などのサイト
  • なぜ評価される：実際の案件に近い形式で、即戦力をアピールできる
  • ポイント：レスポンシブ対応、お問い合わせフォーム、アクセスマップなどを含めると実践的

筆者コメント：Web制作会社時代、新人が最初に任されるのは地元企業のLP制作でした。架空店舗でもいいので「クライアントワークを想定した」LPを作れると、「この人、入社後すぐに案件任せられそう」と思ってもらえます。

2. 自己紹介サイト

自分のプロフィールをWebサイト化したものです。

  • シンプルだが、HTML/CSSの基礎力を示せる
  • ポートフォリオサイトの練習としても最適
  • デザインに凝りすぎず、情報を整理して見せることを意識

3. ToDoアプリ

タスク管理ができるシンプルなアプリです。

  • CRUD操作（作成・読込・更新・削除）の基本を学べる
  • JavaScriptの実力を示せる
  • ローカルストレージを使ったデータ保存まで実装すると好印象

筆者コメント：正直、ToDoアプリはポートフォリオとしては少し弱いです。検索すれば同じものが大量に出てくるので。ただ、「JavaScriptの練習」としては最適なので、練習で作った後、そこから機能を追加して差別化していくアプローチがおすすめです。

中級者向け（React/Vue/Rails等）

4. シフト管理アプリ

スタッフのシフトを管理できるアプリです。

  • 実用性があり、面接で説明しやすい
  • ログイン機能、データベース連携を含む
  • カレンダー表示、シフト申請・承認フローなど、機能を追加しやすい

筆者コメント：前職のWeb制作会社では、シフト管理がExcelで運用されていて、毎週月曜に30分かけて調整していました。当時の自分がこれを作っていたら、面接で「現場感がある」と言われた可能性が高いです。アルバイト経験がある人なら、「シフト調整の面倒さ」を実体験として語れるのも強み。

5. レシピ共有サービス

ユーザーがレシピを投稿・共有できるサービスです。

  • ユーザー登録、投稿、検索機能など、Webアプリの基本要素を網羅
  • 画像アップロード、カテゴリ分類、お気に入り機能など拡張しやすい
  • SNS的な要素（いいね、コメント）を追加すると差別化できる

筆者コメント：これは筆者が実際に作って内定をもらった題材です。「クックパッドの劣化版」と言われればそれまでですが、応募先の技術スタックに合わせて作ったことで、「この会社で働きたい」という意思表示になりました。料理が趣味なら、熱意を持って語れるのもポイント。

6. 家計簿アプリ

収支を記録・管理できるアプリです。

  • グラフ表示、カテゴリ分類など、データの可視化スキルを示せる
  • 日常で使える実用アプリなので、自分でも使い続けられる
  • 月別集計、予算設定、レポート機能など、機能追加の余地が多い

筆者コメント：「自分が使い続けられる」というのが意外と重要。完成後も使っていると、「ここが使いにくい」「この機能が欲しい」と改善点が見つかります。その改善履歴がGitHubに残っていると、「継続的に開発できる人」という印象になります。

差別化を狙うなら

7. API連携アプリ

外部APIを活用したアプリです。

  • 例：天気API、ニュースAPI、OpenAI API、Spotify APIなど
  • 外部サービスとの連携スキルを示せる
  • 「APIを使える」ことは実務で重宝されるスキル

筆者コメント：ただし注意点が1つ。「天気APIを叩いて表示するだけ」だと技術デモで終わってしまいます。「なぜこのAPIを選んだのか」「誰のどんな課題を解決するのか」まで考えて作ると、ぐっと評価が上がります。

8. 前職・趣味の知識を活かしたツール

非IT職の経験は、実は差別化要因になります。

ポイントは、「その業界にいた人じゃないと気づかない課題」を解決していること。面接官も「なるほど、そういう課題があるのか」と興味を持ちやすいし、「ChatGPTに聞いて作りました」とは絶対に出てこない題材なので、差別化になります。

筆者のキャリアを例に、具体的なアイデアを挙げてみます。

Web制作会社の経験から：

  • クライアントフィードバック一元管理ツール：制作会社あるあるですが、クライアントからの修正指示ってSlack、メール、電話、チャットワーク…とバラバラに飛んでくる。「あの修正ってどこに書いてあったっけ？」と探し回ることが日常茶飯事。これを一元管理できるツールがあれば、制作現場の人には「分かる！」と刺さる
  • レガシーサイト自動検知ツール：Web制作の営業って、「まだホームページがスマホ対応してない会社」を探してアプローチすることが多い。古い・レガシーなサイトを自動で検知して営業リストを作るツールがあれば、「この人、制作会社の営業現場を分かってるな」と思ってもらえる

医療系の経験から：

  • 問診情報ダッシュボード：患者さんの問診情報って、紙やPDFでバラバラに管理されていることが多い。これを見やすく整理するダッシュボードは、医療系に応募するなら「お、現場を分かってる」となる
  • 診療記録から給与自動計算ツール：医師の給与計算って、診療記録をもとに複雑な計算をする必要があるが、これが手作業だと本当に大変。自動化ツールがあれば、医療事務の人は泣いて喜ぶ

あなたの前職でも、「これ面倒だな」「もっと効率化できないかな」と感じていたことがあるはず。それがそのまま題材になります。

9. 自分の課題を解決するツール【筆者おすすめ】

日常で「こんなのあったら便利」と思ったものを形にするアプローチです。

これは筆者が最もおすすめする題材選びの方法です。

おすすめの理由：

  • 制作モチベーションが維持しやすい：自分が使うから、完成させたくなる
  • 「なぜ作ったか」が自然に語れる：実体験ベースなので、面接で説得力がある
  • 完成後も使い続けることで改善が進む：実際に使うと「ここが不便」が見つかり、アップデートのネタになる
  • 面接で熱意を持って説明できる：自分ごとだから、語れることが多い

例えば、「読んだ本の感想を記録したい」「毎日の習慣をトラッキングしたい」「複数のSNSの投稿を一括管理したい」など、日常の小さな不満がアイデアの種になります。

10. ポートフォリオサイト自体

自分のスキルや作品を紹介するサイトです。

  • サイト自体がスキルの証明になる
  • デザイン、アニメーション、パフォーマンス最適化など、こだわりポイントを作りやすい
  • 一度作れば、作品が増えるたびにコンテンツを追加できる

筆者コメント：ポートフォリオサイト「だけ」では弱いですが、プロダクトと組み合わせると効果的です。サイト自体をNext.jsで作り、Vercelでデプロイして、パフォーマンスにこだわった話ができると「フロントエンドを理解している」という印象になります。

題材選びの3つの基準

どの題材を選ぶか迷ったら、以下の3つの基準で判断してください。

  1. 実用性：実際に使われる場面が想像できるか
  2. 説明しやすさ：面接で「なぜ作ったか」を語れるか
  3. 技術の証明：狙う職種で求められるスキルを含んでいるか

評価されるポートフォリオの5つの条件

題材を決めたら、次は「どうすれば評価されるか」を押さえておきましょう。

1. 動作すること（最重要）

当たり前に聞こえるかもしれませんが、これが最も重要です。

  • デプロイされていて、誰でもアクセスできる状態にする
  • 「ローカルでは動くんですが…」は論外
  • リンク切れ、エラー画面が出ないか、提出前に必ず確認する

2. コードが読みやすいこと

GitHubでソースコードを公開する以上、コードの品質も見られます。

  • インデントが揃っている
  • 変数名・関数名が分かりやすい（意味のある命名）
  • 適切なコメントがある（過剰でなく、必要な箇所に）
  • ファイル・フォルダ構成が整理されている

3. 制作意図が明確なこと

「なぜこれを作ったか」を説明できることが大切です。

  • README.mdに背景・目的を記載する
  • 「チュートリアルをやったから」ではなく、自分なりの理由があると良い
  • 課題→解決策→実装という流れで説明できると説得力が増す

4. ユーザー視点があること

技術的なことだけでなく、使う人のことを考えているかも評価ポイントです。

  • 見やすい・使いやすいUI
  • レスポンシブ対応（スマホでも崩れない）
  • エラー時の適切なメッセージ表示
  • ローディング状態の表示

5. 独自性があること

チュートリアル丸写しでは評価されません。

  • 自分なりの工夫・追加機能がある
  • 「〇〇のチュートリアルをやりました」で終わらない
  • 検索すれば同じものが大量に出てくるものは避ける

【採用側の本音】ポートフォリオで本当に見ているポイント

ここからは、採用側の視点を深掘りします。

筆者自身、採用面接に同席した経験があります。そこで感じた「採用側が実際に見ているポイント」を正直に共有します。

最初の30秒で見ること

採用担当者は、他の業務をしながら多くのポートフォリオを見なければなりません。1人にかけられる時間は限られています。

だからこそ、最初の30秒で判断されると思っておいた方がいいです。

  1. デプロイされているか
    • URLをクリックして動かなければ、その時点で終了
    • 「ローカルでは動きます」は論外
  2. READMEの第一印象
    • スクリーンショットがあるか
    • 日本語が読みやすく整理されているか
    • 「何のアプリか」が3秒で分かるか
  3. 最終コミット日
    • 半年以上前だと「もう触ってないのか」と思われる
    • 定期的にメンテナンスしている印象を与えることが大事

コードを見る場合のチェックポイント

正直、コードまで詳しく見る採用担当者は多くありません。でも、見る人は以下をチェックしています。

  • 変数名が適切か
    • data1、temp、hogeなどの意味不明な変数名はNG
    • 何を格納しているか分かる命名になっているか
  • ファイル構成が整理されているか
    • 1ファイルに500行以上詰め込んでいないか
    • 適切にコンポーネント分割されているか
  • チーム開発を意識しているか
    • .env.exampleがあるか（環境変数の管理）
    • .gitignoreが適切に設定されているか
    • READMEにセットアップ手順が書いてあるか

正直、ここまでは見ない

未経験者に対して、以下のことはあまり期待していません。

  • テストコードの網羅性：あれば加点だが、なくても減点しない
  • パフォーマンス最適化：動けばOK
  • CI/CDの設定：あれば「お、分かってるな」とは思うが必須ではない
  • 複雑な設計パターン：シンプルに動くコードの方が好印象

面接で聞かれる「技術選定の理由」

最後に、面接で高確率で聞かれる質問があります。

「なぜこの技術を選んだの？」

これに答えられないと、「使ったことがあるだけで理解していない」と判断されます。

❌ 悪い回答例
「勉強のために使いました」
「流行っていたからです」

✅ 良い回答例
「このアプリはSPA（シングルページアプリケーション）として作りたかったので、
Reactを選びました。状態管理はシンプルな構成なので、
Redux等は使わずuseStateで十分と判断しました」

技術選定には「理由」を持っておくこと。これが未経験者でも「考えて作れる人」という印象を与えます。

ポートフォリオの作り方【6ステップ】

ここからは、実際にポートフォリオを作る手順を解説します。

ステップ1：題材を決める

前章で紹介した題材から、自分に合ったものを選びます。

  • 自分のスキルレベルに合ったものを選ぶ（背伸びしすぎない）
  • 狙う職種・案件で求められる技術を含める
  • 興味を持って取り組めるテーマを選ぶ

ステップ2：設計する

いきなりコードを書き始めず、まず設計をします。

  • 機能一覧を書き出す：何ができるアプリなのかを明確にする
  • 画面設計（ワイヤーフレーム）を作る：紙やFigmaで画面の構成を決める
  • データベース設計（必要なら）：どんなデータを保存するか整理する

設計を先にやっておくと、実装中の迷いが減ります。

ステップ3：実装する

設計ができたら、実装に入ります。

  • GitHubでバージョン管理：最初からGitを使う習慣をつける
  • こまめにコミット：機能単位でコミットし、履歴を残す
  • README.mdを整備：実装と並行して、READMEも書き進める

ステップ4：デプロイする

ローカルで動くようになったら、デプロイして公開します。

  • フロントエンドのみ：Vercel、Netlify、GitHub Pagesなど
  • バックエンドあり：Render、Railway、Herokuなど
  • デプロイ後、必ず動作確認を行う

ステップ5：説明文を整備する【重要】

実装して満足しがちですが、説明文の作り込みこそ差がつくポイントです。

README.mdに以下を記載します。

  • 概要・目的：何のためのアプリか、なぜ作ったか
  • 使用技術：言語、フレームワーク、ライブラリ、インフラなど
  • 機能一覧：何ができるかを箇条書きで
  • 工夫したポイント：技術的な挑戦、UXへの配慮など
  • 制作期間：どのくらいの時間をかけたか

筆者の体験から言えること：

正直、コードまで事細かに確認してくれる採用担当者は少ないです。

READMEや説明文が「この人は何を考えて作ったのか」を伝える第一印象になります。ここを丁寧に整備しておくと、書類選考・面接での評価が変わります。

ステップ6：ポートフォリオサイトにまとめる

作品が完成したら、一覧できる場所にまとめます。

  • 自作のポートフォリオサイト：自分でHTML/CSS/JSで作る
  • GitHub：READMEを整備して、リポジトリをそのまま見せる
  • Notion：手軽にまとめられる

プロフィール情報（経歴、スキル、連絡先）も忘れずに記載しましょう。

筆者のポートフォリオ例：

参考として、筆者のポートフォリオページを紹介します。

https://koutaroinoue-log.com/portfolios/mates-for-engineer/

ただし、正直これでも内容は薄めです。もっと膨らませた方がよいでしょう。

制作背景、苦労した点、学んだこと、今後の改善予定など、熱量が伝わる情報を追加すると差がつきます。採用担当者は「この人と一緒に働きたいか」を見ています。熱意が伝わる説明文は武器になります。

【参考事例】実際に評価されたポートフォリオ3選

「実際にどんなポートフォリオが評価されているのか？」という疑問に答えるため、未経験から内定を獲得した人のポートフォリオ事例を紹介します。

事例1：ShiftHub（シフト管理アプリ）

飲食店やアルバイト先でのシフト管理を効率化するWebアプリです。

概要

  • スタッフとマネージャーの2つのログイン方式
  • スタッフ：シフト提出・確定シフト確認
  • マネージャー：提出シフトの確認・編集・確定
  • 店舗ごとのスキル登録・管理機能

技術スタック

  • フロントエンド：React、Tailwind CSS
  • バックエンド：Ruby on Rails
  • インフラ：AWS、Docker、GitHub Actions（CI/CD）
  • 認証：JWT

なぜ評価されたのか

  1. 実用性がある：「シフト管理が面倒」という現場の課題を解決している
  2. フロント・バック分離：モダンなアーキテクチャを採用
  3. CI/CDまで実装：チーム開発を意識した構成

作者はこのポートフォリオで自社開発企業を含む複数社から内定を獲得しています。

事例2：HayabusaTrip（旅行プラン共有サービス）

「旅の準備をもっとシンプルにしたい」というコンセプトの旅行計画共有サービスです。

概要

  • わずか3ステップで旅行計画を作成・共有
  • Google認証によるログイン
  • 観光スポット情報の管理
  • Twitterシェア機能

技術スタック

  • フロントエンド：Next.js、TypeScript
  • バックエンド：Ruby on Rails
  • インフラ：AWS（ECS Fargate、RDS）、Vercel
  • CI/CD：GitHub Actions、Docker

なぜ評価されたのか

  1. ユーザー体験への配慮：デフォルト値やプリセット機能でユーザーの手間を削減
  2. モダンな技術選定：Next.js + TypeScriptという現場で使われる構成
  3. 本番レベルのインフラ：AWSでのデプロイまで完結

事例3：筆者のレシピ共有サイト

筆者が未経験時代に作成したポートフォリオです。

概要

  • ユーザーがレシピを投稿・共有できるサービス
  • 応募先企業の技術スタックに合わせて実装

なぜ評価されたのか

  1. 応募先の技術スタックに合わせた：「この会社で働きたい」という意思表示になった
  2. 独学で完成させた：「自分で調べて手を動かせる人」という印象を与えた
  3. コードベースで会話ができた：面接でソースコードを見ながら技術的な会話ができた

3つの事例に共通するポイント

これらの事例から、評価されるポートフォリオの共通点が見えてきます。

  1. 「誰の、どんな課題を解決するか」が明確
    • シフト管理の煩雑さ、旅行計画の面倒さ、レシピ共有の需要
  2. 技術選定に理由がある
    • 「なぜReact？」「なぜAWS？」に答えられる
  3. 完成度が高い
    • 中途半端に機能を詰め込むより、1つの機能を作り込んでいる

参考記事：

【実例】筆者のポートフォリオ体験談

ここで、筆者自身のポートフォリオ体験を紹介します。

作ったもの：レシピ共有サイト

完全な業界未経験、しかも学生時代にインターン応募をしたときに作りました。

ポイントだったのは、応募先の会社が使っている技術スタックと同じ構成で作ったこと。

「この会社で働きたい」という意思表示にもなるし、入社後に即戦力として動けることの証明にもなると考えました。

結果：かなり詳しくコードを見てもらえた

正直、職歴はゼロ。アピールできるのはポートフォリオしかない状態でした。

そのおかげか、面接ではソースコードをかなり詳しく見てもらえたんです。「ここはなんでこう書いたの？」「この設計にした理由は？」と、コードベースで会話が進みました。

職歴がない分、「この人はコードでどういう思考をするのか」を直接見せられたのが大きかったと思います。

評価されたポイント：完全独学という熱意

特に刺さったのは「これを独学で作った」という点でした。

応募先が技術志向の強い会社だったこともあり、「教材をなぞっただけじゃなく、自分で調べて手を動かせる人だ」という印象を持ってもらえたようです。

結果、未経験・学生という不利な条件でも参画させてもらえました。

振り返って思うこと

「職歴がない＝ポートフォリオでしか勝負できない」という状況が、逆に武器になったケースだと思います。

変に経歴を盛ろうとせず、「コードで見てもらう」という姿勢が評価につながりました。

未経験の方には、「ポートフォリオは履歴書の代わりになる」と伝えたいですね。

【反省】作っておけばよかった/作らなくてよかった

筆者自身の後悔と反省を正直に共有します。

作っておけばよかった：「自分が本当に困っていること」を解決するツール

当時の自分は「ポートフォリオ＝技術力を見せるもの」と思い込んでいました。

だから、使う予定もないToDoアプリとか、誰向けか分からないブログシステムを作っていたんです。

でも面接で「なんでこれ作ったの？」と聞かれたとき、「勉強のためです」としか言えなかった。会話が全然盛り上がらなくて、気まずい沈黙が流れたのを覚えています。

後から気づいたんですが、たとえば：

  • 「毎月の生活費をExcelで管理してたけど面倒だったから作った」
  • 「彼女との予定共有がLINEだとごちゃごちゃするから作った」

こういう、自分ごととして語れるものの方が圧倒的に面接で刺さるんですよね。

技術的にはシンプルでも、「課題→なぜ自分で作ろうと思ったか→どう解決したか」というストーリーがあるだけで、印象がまったく違います。

作らなくてよかった（というか無駄だった）：Twitterクローン

記事冒頭でも触れましたが、Twitterクローンを作った経験があります。

3週間かけて作ったのに、面接ではほぼスルー。採用側からすると「チュートリアルをやった人」という認識だったのでしょう。

この経験から学んだこと：

  • クローンアプリは「学習」には最適だが「ポートフォリオ」には向かない
  • 同じ3週間を使うなら、規模は小さくても「自分だけの課題」を解決するアプリを作るべきだった
  • 面接官は「同じようなクローンアプリ」を何十個も見ている

クローンアプリを作った経験は無駄ではありません。技術力は確実についています。でも、ポートフォリオとして見せるものと学習のために作るものは分けて考えた方がいいです。

ポートフォリオ作成でよくある失敗5選

筆者が見てきた「これはマズいな…」という実例を紹介します。これを避けるだけで、評価されるポートフォリオに近づけます。

1. スコープが大きすぎて中途半端

「SNSクローン作りました！」と言うものの、機能がログインとタイムラインだけ。

SNSって、フォロー機能、通知、DM、検索、画像投稿…と機能が膨大なので、全部作ろうとすると絶対に終わりません。結果、「ログインできて、投稿が見れるだけ」の半端なものが出来上がる。

それなら最初から小さいアプリを完成させた方がマシです。

2. 技術スタック盛りすぎ問題

「React + TypeScript + GraphQL + Docker + Kubernetes で作りました！」

一見すごそうに見えますが、面接で「なんでKubernetes使ったの？」と聞かれて答えられない人がほとんど。

なぜこれがマイナスになるのか、面接官の心理を解説します。

Kubernetesは本番環境で数十〜数百のコンテナを管理するためのツールです。個人開発で1つのアプリを動かすだけなら、明らかにオーバースペック。

面接官が「なんでKubernetes使ったの？」と聞くのは、純粋な質問ではありません。「この人は技術選定の理由を説明できるか」を試しているのです。

「勉強のために使いました」は正直な回答ですが、「勉強のためにオーバースペックな技術を選ぶ人」という印象を与えます。

正解の技術選定とは：

❌「とりあえず全部入りで作りました」

✅「この規模ならVercelで十分ですが、
    将来的にスケールする想定でDockerも用意しました。
    Kubernetesは学習コストと運用コストを考えて、
    今回は採用しませんでした」

規模に応じた選定理由を語れることが重要です。「使ったことがある」と「なぜ使ったか説明できる」は全然違います。

3. 解決する課題がない「技術デモ」

天気APIを叩いて表示するだけのアプリ。為替レートを表示するだけのアプリ。

技術的にはAPIを叩く練習にはなりますが、面接官からすると「で、誰が使うの？」となります。

技術デモとプロダクトの違いは「課題」があるかどうか

❌ 技術デモ
「天気APIで天気を表示するアプリを作りました」
→ 「それ、Yahoo!天気でよくない？」

✅ プロダクト
「朝の準備時間を短縮したくて、
    今日の天気・気温・花粉情報を一画面で見れるアプリを作りました。
    毎朝3つのアプリを開く手間がなくなりました」
→ 「なるほど、自分の課題を解決したんだね」

同じ天気APIを使っていても、「課題」があるかどうかで印象がまったく違います。

4. ポートフォリオサイトだけ（プロダクトがない）

自己紹介サイトは綺麗に作ってあるけど、肝心のプロダクトがない。

これ、意外と多いんです。「ポートフォリオ作りました！」と言われて見てみると、自己紹介とスキル一覧があるだけ。

例えるなら、料理人の履歴書は立派だけど、料理のサンプルがない状態。採用側は「この人が何を作れるのか」が見たいんです。

5. 「勉強のため」で作ったクローンアプリ

TwitterクローンやInstagramクローンなど、有名サービスの模倣は学習には最適です。

でも、ポートフォリオとしては弱い。

なぜなら、採用側からすると「あ、チュートリアルやったんだな」で終わってしまうから。検索すれば同じようなものが大量に出てきます。

クローンアプリは学習には良いけど、ポートフォリオとしての差別化にはならない。筆者自身も同じ失敗をしています（詳しくは前章の【反省】を参照）。

未経験者向けQ&A

よくある質問にまとめて回答します。

Q: 模写サイトはポートフォリオに載せていい？

A: サブとしてはOKです。ただし、メインはオリジナル作品にしましょう。

模写は「この技術を学んだ」という証拠にはなりますが、「自分で考えて作れる」ことの証明にはなりません。

Q: 何個作ればいい？

A: 完成度の高い作品が1つあれば十分です。

数を揃えるより、1つを深掘りした方が評価されます。

ただし、デザイナーやHP制作者の場合は、デザインの幅を見せるために複数パターンあった方がよいケースもあります。

Q: どのくらいの期間で作れる？

A: 簡単なものなら2週間〜1ヶ月程度です。

ただし、しっかりプロダクト開発をするなら3ヶ月は見ておいた方がよいでしょう。

設計→実装→デプロイ→説明文整備まで含めると、思った以上に時間がかかります。

Q: 実務経験がなくても評価される？

A: 評価されます。

採用側が見ているのは「伸びしろ」と「学習姿勢」です。

未経験でも、自分で課題を見つけて解決しようとする姿勢が見えれば、プラスに評価されます。

Q: デザインセンスがないけど大丈夫？

A: 大丈夫です。

UIライブラリ（Tailwind CSS、Material UI、shadcn/uiなど）を活用すれば、デザインセンスがなくてもそれなりに見栄えの良いUIが作れます。

エンジニアとして評価されるのは、デザイン力より「動くものを作れるか」「コードが読みやすいか」です。

【補足】そもそもポートフォリオは本当に必要なのか？

ここまで作り方を解説してきましたが、最後に正直な話をしておきます。

ポートフォリオは「絶対に必要」とは言い切れません。

「ポートフォリオなしでもエンジニアになれる」という意見

ポートフォリオに対して懐疑的な意見も存在します。

  • 以前はポートフォリオなしで入社した人も多い：10年以上前にエンジニアになった人の中には、ポートフォリオを提出せずに採用された人も少なくない
  • 企業によっては重視しない：人柄やポテンシャルを重視する企業では、ポートフォリオより面接での印象が大事
  • SES企業など未経験OKの求人では必須でない：研修制度が整っている企業では、入社後に育てる前提で採用する
  • 「ポートフォリオ商法」への批判：スクールやインフルエンサーが「ポートフォリオ必須」と煽り、未経験者をターゲットにしているという指摘もある

これらの意見には一理あります。ポートフォリオ作成に何ヶ月もかけて、肝心の就職活動が遅れてしまっては本末転倒です。

ポートフォリオが有効な場面

一方で、ポートフォリオが有効に働く場面も確実に存在します。

  • 自社開発・受託開発企業への転職：書類選考で他の候補者と差がつく
  • 副業・フリーランス案件への応募：実績がない段階で「何ができるか」を示す唯一の手段
  • クラウドソーシングでの受注：提案文だけでは伝わらないスキルを証明できる

結論：目指す道によって判断しよう

結局、ポートフォリオが必要かどうかは、あなたが目指す道によります。

有効なケース：自社開発企業、Web系企業、副業・フリーランス

なくても問題ないケース：SES企業、ポテンシャル採用、現場経験優先

ポートフォリオを作ることを決めているなら、この記事の内容を参考に進めてください。

まとめ：まず1つ、オリジナル作品を作ろう

この記事のポイントをまとめます。

  • 題材選びのポイント：実用性、説明しやすさ、技術の証明
  • 筆者おすすめは「自分の課題を解決するツール」：モチベーションが続き、熱意を持って語れる
  • 数より質：完成度の高い作品が1つあれば十分
  • 説明文の作り込みが差をつける：コードより先にREADMEが見られる
  • 70%で公開する：完璧を求めすぎて完成しないのが一番もったいない

まずは1つ、オリジナル作品を完成させることから始めましょう。

最初の1つは、架空店舗のLP作成がおすすめです。HTML/CSS/JavaScriptの基礎があれば作れますし、実際の案件に近い形式なので実践的です。

完璧を目指さず、70%で公開する。そこからがスタートです。

この記事をシェア