ポートフォリオは何を作ればいいか【2026年】評価されやすい作品の考え方

未経験からのエンジニア転職では、多くのスクールでポートフォリオ（自分で作ったアプリやWebサイトの実績物）の制作が課題になります。ただし「何を作ればいいか分からない」という悩みは、当サイトが掲載している複数のスクールの挫折しやすいポイントとしても共通して挙げられています。この記事では、ポートフォリオが重視される理由と、テーマ選びの考え方を整理しました（2026年9月確認）。

なぜポートフォリオが重視されるのか

未経験からの転職では、実務経験がない代わりに「実際にコードを書いて何かを作れるか」を示す材料が必要になります。ポートフォリオは、カリキュラムをこなしただけでは伝わらない、自分で考えて形にする力を見せる手段です。多くのスクールが転職支援の一環としてポートフォリオ制作をカリキュラムに組み込んでいるのは、採用側が実際に重視している材料だからです。

「何を作ればいいか分からない」という悩みは共通の壁

当サイトが掲載しているスクールの中には、ポートフォリオ制作の段階でつまずきやすいと明記しているところが複数あります。たとえばRUNTEQの挫折しやすいポイントには「ポートフォリオ制作の段階で、何を作ればよいか自分で決める必要があり、方向性が定まらず時間だけが過ぎる」という記述があります。カリキュラムの課題をこなす段階と違い、ポートフォリオはテーマ選びから自分で決める必要があるため、多くの受講生が最初につまずく関門になっています。決められた課題を順に解く力と、何を作るかを自分で決める力は別物なので、ここで手が止まるのは学習が足りないからとは限りません。

避けた方がいいポートフォリオの作り方

• チュートリアルをそのまま模写しただけのもの。書籍や動画教材のチュートリアルは学習として有効ですが、そのまま提出すると「教材をなぞっただけ」と見なされやすくなります
• 既存の有名サービスの完全コピー。Twitter風、Instagram風のクローンアプリはよく見かけますが、機能面で差別化しないと「よくあるもの」として埋もれてしまいます
• 機能を詰め込みすぎて未完成のまま提出するもの。多機能を目指して時間切れになるより、少ない機能でも実際に動くものを完成させる方が評価されやすい傾向があります

評価されやすいポートフォリオの要素

• 自分で企画した背景・課題設定が説明できる。「なぜこれを作ったのか」「誰のどんな課題を解決するのか」を自分の言葉で説明できると、単なる練習作品との違いが伝わります
• 実際に動く状態で公開されている。ソースコードだけでなく、実際にアクセスして動作を確認できる状態（デプロイ済み）であることが重要です
• 技術選定の理由を説明できる。使った言語・フレームワークを「なぜ選んだか」まで説明できると、技術理解の深さが伝わります
• README等で開発の工夫点が分かる。GitHubのREADMEに機能一覧、工夫した点、今後の改善点を整理しておくと、採用担当者が短時間で内容を把握しやすくなります

評価されやすいポートフォリオ・されにくいポートフォリオ

スクールごとのポートフォリオ支援の違い

ポートフォリオ制作へのサポートの手厚さは、スクールによって差があります。FJORD BOOT CAMPは、公式の就職支援でポートフォリオと推薦文を企業へ提出するところまでサポートしており、提携企業約40社への就職実績を公式サイトで公表しています。カリキュラムの中でポートフォリオ制作の位置づけがどうなっているか、完成後のレビュー体制があるかは、スクール選びの段階で確認しておくと安心です。テーマ選びで手が止まりそうだと自覚している人ほど、教材の量より、企画の段階で相談できる相手がいるかを重く見て選ぶほうが合っています。

ポートフォリオ制作で行き詰まったときの進め方

• テーマが決まらないときは、身近な困りごとをリストアップする。「家計簿をつけるのが面倒」「読んだ本を記録したい」など、自分の生活の中にある小さな課題から発想する
• 完璧を目指さず、まず最小限の機能で完成させる。一通り動く状態を作ってから機能を追加していく方が、途中で挫折しにくくなります
• メンターや講師に早い段階で企画を相談する。方向性が大きくずれる前にフィードバックをもらうことで、手戻りを減らせます
• 他の受講生・卒業生の作品を参考にする（コピーはしない）。どんなテーマ・機能が評価されているかの傾向をつかむ材料になります

採用担当者は具体的に何を見ているか

エンジニア採用を担当してきた立場からの解説によると、未経験者の自主制作物で見られている観点は大きく4つに整理できます。プログラマとしての適性（コメントの書き方など丁寧な仕事ぶり）、論理的思考力（条件分岐やロジック設計が適切か）、自走能力（教材にない機能を自分で調べて実装できるか）、継続性（スクール卒業後もコードを書き続けているか）の4点です。

この視点では、避けたほうがよい題材としてTwitter・Instagram風のクローンアプリ、HTML/CSSのみの静的サイト、教材の丸写し、著作権上問題のある画像・バナーの無断使用が挙げられています。逆に、業務システム系（勤怠管理・シフト管理・在庫管理など）は、ユーザー側と管理画面側の両方を作ることで条件分岐が自然に増え、実務に近い複雑さを表現しやすいという指摘もあります。ソースコードへのリンクに加えて、実際に動作を確認できる公開URLをセットで示すことも推奨されています。

ただし、これは特定の採用担当者・エージェントの見解であり、すべての企業に共通する統一基準ではありません。応募先企業の職種・技術スタックによって重視するポイントは変わるため、参考情報として捉えてください。

2026年、GitHubの「コミット数」だけでは評価されにくくなっている

代わりに重視されるようになってきているのが、次のような点だと解説されている。

• READMEが「技術の物語」になっているか。使用技術の羅列だけでなく、「何の課題をどう解決したのか」という背景・意図が書かれているか
• テストやドキュメントが整備されているか。動くだけでなく、保守性やコード品質への意識が示されているか
• PRやIssueでのやり取りの痕跡があるか。オープンソースへの貢献や、他者とのコミュニケーションの跡が実務適性の材料として見られる

未経験からの転職では、いきなりオープンソース貢献のハードルは高いため、まずはREADMEを「技術スタックの箇条書き」で終わらせず、企画の背景・工夫点・今後の改善案まで文章で説明する形にするだけでも、単なるコミット数の多さより伝わりやすい材料になります。草を毎日生やすことに気を取られるより、READMEに書ける中身を一つずつ増やしていくほうが、学んだ時間がそのまま説明の材料として残るので割に合います。

スクール公式サイトは、ポートフォリオをどう位置づけているか

ここまでの話を、実際のスクール公式サイトの記載と照らしてみます。2026年10月20日に確認した公式トップページでは、2校とも「自分で企画したサービスを作る」ことを学習の最終盤に置いていました。

どちらも「リリースがゴール」という点が共通しています。ソースコードだけを渡すのではなく、URLを開けば触れる状態まで持っていく。前半で挙げた「デプロイ済みであること」は、スクール側のカリキュラム設計とも一致する考え方です。一方で、RUNTEQ公式は卒業生の就職先企業の声としてポートフォリオ（Webアプリ）のクオリティについて好意的に述べた感想も掲載していますが、これは企業側の個別の意見です。ポートフォリオを出せば内定が出ると読める情報ではありません。

企画の決め方：生活の困りごとから「機能」まで落とし込む

「身近な困りごとから発想する」と言われても、そこから何を実装するかが決まらないと手が動きません。次の順で考えると、テーマを機能の単位まで落としやすくなります。以下は当サイトで整理した考え方の一例で、特定のスクールの公式手順ではありません。

1. 困りごとを1文で書く。「冷蔵庫の中身を忘れて同じ食材を買ってしまう」のように、誰が・何に困っているかを具体的にする
2. その困りごとを減らす最小の操作を決める。上の例なら「食材を登録する」「賞味期限が近い順に並べて見る」の2つで足りる
3. 登録・一覧・編集・削除（CRUD）に当てはめる。Webアプリの基本操作に分けると、必要な画面とデータの持ち方が見えてくる
4. 最後に1つだけ、自分で調べないと作れない機能を足す。外部APIとの連携、画像のアップロード、検索の絞り込みなど。教材にない部分を自力で実装した経験が、面接で話せる核になる

この表の題材は、あくまで考え方の練習用です。大切なのは題材そのものより、「なぜその機能が必要か」を自分の言葉で説明できる形に落とせているかどうかです。冒頭の避けたい例にあった既存サービスのクローンも、困りごとが自分の中にあって機能を絞る理由を語れるなら別の話になりますが、最初の1本としては上の手順のほうが企画の説明を組み立てやすいはずです。

READMEに何を書くか：GitHub公式の説明から考える

READMEの書き方に唯一の正解はありませんが、GitHubの公式ドキュメント（2026年10月20日確認）には、READMEが通常含む情報として次の5点が挙げられています。

• このプロジェクトが行うこと
• このプロジェクトが有益な理由
• このプロジェクトの使い始め方
• このプロジェクトに関するヘルプをどこで得るか
• このプロジェクトのメンテナンス者とコントリビューター

同じドキュメントには、READMEは「多くの場合、リポジトリへの訪問者が最初に目にするアイテム」だとも書かれています。つまり応募先の担当者がリポジトリを開いたとき、最初に読まれる可能性が高いファイルです。ポートフォリオ用に読み替えると、次のような構成になります。

これに加えて、ポートフォリオなら「工夫した点」と「今後の改善案」を1段落ずつ入れておくと、前半で触れた「READMEが技術の物語になっているか」という観点を満たしやすくなります。ログインが必要なアプリでは、採用担当者が登録の手間をかけずに触れるよう、テスト用のアカウントを用意しておくのも一つの方法です。パスワードなど公開してよい範囲かは、そのアプリに本物の個人情報が入っていないことを確かめてから判断してください。

面接で説明できるようにしておきたいこと

ポートフォリオを出すと、書類選考や面接で内容を聞かれることになります。どの会社が何を聞くかは一定ではありませんが、完成した作品を見返すときのチェックとして、次の問いに自分の言葉で答えられるか確認しておくと安心です。

• なぜこのテーマにしたのか。ほかの案は考えたか
• 一番時間がかかった部分はどこで、どう解決したか
• 教材に載っていない機能を、何を調べて実装したか
• データの持ち方（テーブル設計）をなぜその形にしたか
• もう1か月あったら、どこを直すか
• AIコーディングツールを使った場合、どの部分をどう使い、生成されたコードを自分でどう確かめたか

最後の問いは、先に触れたコミット数の話ともつながります。RUNTEQ公式は、AI駆動開発のカリキュラムを学ぶことで自分のオリジナルWebアプリにAIを組み込めるようになる、と案内しています。AIをアプリの機能に組み込むのと、AIにコードを書かせるのは別の話ですが、どちらの場合も「何をどこまで自分で理解して作ったか」を説明できることが前提になります。AIツールの使用自体を禁じている応募先もあり得るので、応募先の募集要項や選考ルールがあれば先に確認しておいてください。使ってよい場面なら、AIを使ったこと自体を隠す必要はありません。どこまで自分で読んで確かめたかを具体的に話せるほうが、かえって信頼につながると考えます。

ポートフォリオに関するよくある質問

何個作ればいいですか

スクールや目指す職種によりますが、1つのポートフォリオを丁寧に作り込む方が、複数を中途半端に作るより評価されやすい傾向があります。時間に余裕があれば、異なる技術・テーマの作品を2つ用意するという考え方もあります。

チュートリアル通りに作ったものは使えませんか

学習の記録としては有効ですが、転職活動用のメインのポートフォリオとしては、独自の企画や機能を加えて差別化することをおすすめします。チュートリアルはあくまで基礎を身につける手段と位置づけるとよいです。

デザインにも力を入れるべきですか

職種によります。Webデザインも含めたポジションを目指す場合は見た目も重要ですが、バックエンド中心のエンジニア職を目指す場合は、機能面や設計の妥当性がより重視される傾向があります。

作成中に「これでいいのか」不安になったらどうすればいいですか

メンターや講師など、第三者に早めに見てもらうことをおすすめします。一人で抱え込んで完成を待つより、途中段階でフィードバックをもらう方が、方向性の修正がしやすくなります。

ポートフォリオの制作にはどれくらいの期間がかかりますか

テーマの規模やスクールのカリキュラムによって大きく異なります。各スクールの公式サイトで、ポートフォリオ制作にあてられる期間の目安を確認してください。

GitHubに公開する必要がありますか

必須ではありませんが、採用担当者がコードの中身を確認できる状態にしておくことは一般的に有利に働きます。README等で内容を分かりやすく整理しておくことをおすすめします。

コミット数を増やすためにこまめにコミットした方がいいですか

コミット回数そのものを増やすことよりも、1つ1つのコミットの内容が分かりやすいか、READMEで開発の意図が説明できているかの方が重視される傾向にあります。AIコーディングツールの普及で大量のコミットを短時間で作ることも技術的には可能になったため、コミット数の多さだけをアピール材料にするのは避けたほうがよいでしょう。

テストコードは書いた方がいいですか

必須ではありませんが、書けるとコード品質や保守性への意識を示す材料になるという指摘があります。学習段階でテストまで手が回らない場合は、まずREADMEで「なぜこの機能を作ったか」を丁寧に説明することを優先し、余力があればテストに取り組むという順序でも構いません。

デプロイ（公開）はどこでやればいいですか

スクールによってカリキュラムで使うサービスが決まっていることが多いため、まずは受講しているスクールの手順に従うのが確実です。独学の場合は、無料枠のあるホスティングサービスが複数ありますが、無料枠の条件（停止までの時間、データベースの容量など）は変更されることがあります。公開前に各サービスの公式ページで現在の条件を確認し、アクセスしたときに起動が遅くなる場合はREADMEにその旨を書いておくと、動かないと誤解されにくくなります。

ポートフォリオに載せてはいけないものはありますか

他人の著作物である画像・ロゴ・文章の無断使用は避けてください。実在の企業や店舗のデータをスクレイピングで集めたものを公開するのも、利用規約や権利の面で問題になり得ます。APIキーやパスワードをソースコードに直接書いたままGitHubへ公開するのも危険です。環境変数で管理し、公開リポジトリにはサンプルの設定ファイルだけを置くのが一般的です。

転職活動中に更新を続けたほうがいいですか

完成後も、READMEの改善や小さな修正、動作確認を続けておくと、リンクが切れて動かないという事態を避けられます。採用担当者が見るのは応募した時点のリポジトリです。応募前に公開URLが開けるか、テスト用アカウントでログインできるかを、毎回確かめてから出すようにしましょう。

ポートフォリオができたあとに読んでおきたい記事

ポートフォリオは作って終わりではなく、応募先選びや転職活動の進め方とセットで考える材料です。当サイトの関連記事のうち、制作後の場面で役立つものを挙げます。

• SES企業への就職はやめた方がいいのか：自社開発企業は選考でポートフォリオを重視する傾向があるため、就職先の傾向を公表しているスクールを選ぶ視点をFAQで整理しています
• 卒業後に転職できなかったらどうするか：書類選考の通過率が低いときにポートフォリオの完成度や説明の仕方を見直す、という対処を扱っています
• プログラミングスクールの転職支援を独自採点：キャリアアドバイザーや求人紹介など、転職支援の中身をスクールごとに並べた比較です
• 30代・40代未経験からエンジニア転職は可能か：年代ごとの転職の現実を公表データから考えた記事です

まとめ

ポートフォリオは、実務経験がない未経験からの転職において、自分で考えて形にする力を示す重要な材料です。「何を作ればいいか分からない」という悩みは多くの受講生が経験する共通の壁で、自分の生活の中にある課題から発想する、早めにフィードバックをもらうといった進め方が有効です。スクールによってポートフォリオ制作へのサポート体制も異なるため、申し込み前に確認しておくことをおすすめします。

参考：RUNTEQ公式サイト（runteq.jp、学習の流れ・Webアプリ開発の案内、2026年10月20日確認）、FJORD BOOT CAMP公式サイト（bootcamp.fjord.jp、最終課題・チーム開発の案内、2026年10月20日確認）、GitHubドキュメント「リポジトリのREADMEファイルについて」（2026年10月20日確認）。このほか、各スクール公式サイトの情報、エンジニア採用担当者による解説記事（note.com掲載の個人ブログ、2026年9月確認）、GitHubの評価軸に関する解説記事（2026年9月確認）。特定の採用担当者・エージェントの見解であり、企業共通の統一基準ではない点に留意してください。

あわせて読みたい関連記事

スクール選びで、あわせて確認しておきたい記事です。

• 転職保証つきスクールの比較（RUNTEQを含む）
• FJORD BOOT CAMP（フィヨルドブートキャンプ）の評判は？料金と挫折しやすいポイントを調べました
• プログラミングスクールで挫折する人の共通点【2026年】6つのパターンと対策
• レバテックルーキーとは？新卒エンジニア就活の使い方【2026年】