結論：未経験のポートフォリオは「小さなWebアプリ1本」をGitHub管理→デプロイ→READMEで公開までやり切れば形になる
30代会社員・未経験で「作品がない」と悩むとき、最短で評価につながるのは大作ではなく“小さなWebアプリを1つだけ公開まで”です。採用側や依頼側が見たいのは、機能の多さよりも「作って動かし、他人に説明できるか（README）」「公開して見せられるか（デモURL）」「改善できるか（TODO整理）」という実務の基礎力です。
この記事のゴールは、あなたが今週末〜2週間で「動くURL」を作り、ポートフォリオに載せられる状態にすること。やることは次の4つに固定します。
- ①作るものを小さく決める（MVP）
- ②GitHubで管理する（コミット履歴を残す）
- ③デプロイしてURLを持つ（誰でも触れるデモ）
- ④READMEで説明する（工夫点・学び・手順）
なぜ「小さなWebアプリの公開」がポートフォリオとして強いのか
未経験のポートフォリオで詰まる原因は、スキル不足というより「完成の定義が曖昧」なことです。SNSや記事を見ると、立派なアプリやフルスタック開発が目に入りますが、会社員が限られた時間でそれを真似すると、途中で要件が膨らんで終わりません。
小さなWebアプリ公開が強い理由は3つあります。
- URLで一瞬で伝わる：採用側は環境構築せずに動作確認できる
- 技術の幅が自然に出る：UI、状態管理、入力バリデーション、エラー対応などを“必要最低限”で見せられる
- 仕事の進め方が見える：README、コミット、デプロイ、改善TODOまで含めて「再現性」を示せる
つまり、未経験が狙うべきは「すごい機能」ではなく“公開までやり切る力”です。ここからは、やり切るための選び方と手順を具体化します。
まずは「何を作るか」：未経験におすすめの小さな成果物3パターン
最初の1本は、バックエンドや認証を詰め込みすぎない方が成功率が上がります。公開まで最短で到達しやすい順に、次の3パターンから選ぶのがおすすめです。
パターンA：静的アプリ（最短・おすすめ）
ブラウザ内（localStorageなど）で完結し、サーバー不要で公開できるタイプです。例：習慣トラッカー、買い物リスト、学習ログ、ポモドーロタイマー＋履歴。
パターンB：BaaSでログインあり（2本目向き）
Supabase/Firebaseなどを使ってログイン＋DB保存。実務感は出ますが、詰まりどころも増えるので「CRUDだけ」など1機能に絞るのがコツ。
パターンC：簡易API自作（余裕があれば）
Node/ExpressなどでAPIを用意し、フロントから叩く構成。学びは大きい一方、最初の1本だと重くなりがちなので、公開経験を積んだ後が安全です。
結論：最初はパターンAで“公開まで”を経験し、2本目以降で認証やDBに広げるのが最短ルートです。
【具体例】未経験が作りやすい「習慣トラッカー」を2週間で公開する設計
例として、ポートフォリオ映えしつつ未経験でも完成しやすい「習慣トラッカー」を作ります。ポイントは“説明できる工夫点が自然に生まれる題材”を選ぶことです。
- できること：習慣の追加／達成チェック／連続達成日数の表示
- 保存：localStorage（ログイン不要）
- UI：スマホ前提（ボタン大きめ、一覧見やすく）
- 公開：Cloudflare Pages / Netlify / GitHub Pages /（個人非商用なら）Vercel など
この題材がちょうど良いのは、UI（一覧・入力・状態）とロジック（日付処理・連続記録）が混ざり、READMEに書ける「工夫点」が作りやすいからです。未経験のポートフォリオは、完成物そのものより“どう考えて作ったか”が伝わるほど強くなります。
公開までのロードマップ：GitHub→デプロイ→README→デモの順に固定する
「作る」だけで止まるとポートフォリオになりません。最初から、公開までの道筋を固定しましょう。
- Step1：GitHubにリポジトリ作成（READMEの骨組みを先に書く）
- Step2：MVPを作る（最低限動く状態：追加・一覧・チェック）
- Step3：保存（localStorage）と簡単なエラー処理を入れる
- Step4：UIを整える（スマホ対応、入力エラー、分かりやすい表示）
- Step5：デプロイしてURLを作る（早めに1回通す）
- Step6：READMEを採用側向けに仕上げ、スクショ/GIFでデモを見せる
ポイントは、後半に回しがちな「公開」を前倒しすることです。公開＝機能だと思って、最初の週に一度デプロイを通すと、終盤の詰まりが減ります。
GitHub運用のコツ：コミット履歴を“学習の証拠”に変える
未経験のGitHubは「コード置き場」で終わりがちですが、ポートフォリオでは進め方が見られます。難しいことは不要で、次の3点だけ守ると“仕事感”が出ます。
- READMEを先に作る：「何を作るか」「機能」「公開URL（後で追記）」「今週のTODO」を書く
- 小さくコミットする：機能追加・バグ修正・UI調整・README更新も分けて残す
- Issue/TODOで改善点を残す：未完成でも「次に何をするか」が言語化できると強い
コミットメッセージは凝らなくてOKです。例：「Add habit input」「Fix localStorage parse」「Update README」。大事なのは、あなたが小さく作って検証しながら進められることを見せることです。
デプロイ先の選び方：最短はOK。ただし無料プランの「商用利用」だけは先に確認する
静的アプリなら、GitHub Pages / Cloudflare Pages / Netlify などで公開しやすいです。Next.jsなども含めて手軽に公開したいならVercelが候補になります。
| 用途 | 候補 | 向いているケース |
|---|---|---|
| 静的サイトを最短で公開 | GitHub Pages | HTML/CSS/JSやViteのビルド成果物などをサクッと公開したい |
| 静的サイトを高速に公開 | Cloudflare Pages | 無料でも扱いやすく、公開までが早い。将来的に商用でも運用しやすい |
| 静的〜小規模Webを公開 | Netlify | UIが分かりやすく、デプロイ導線がシンプル |
| Next.js等を楽に公開 | Vercel | 個人学習・ポートフォリオ用途で“早く動くURL”を作りたい |
重要な注釈（リスクヘッジ）：Vercelは利用規約・ガイドライン上、無料のHobbyプランが「個人・非商用」用途に限定される旨が明記されています。ポートフォリオとして公開するだけなら問題になりにくい一方で、アプリにアフィリエイト広告を貼る／クライアントワークで運用する／収益目的にする、といった商用要素が入る可能性があるなら、有料プランや他サービス（例：Cloudflare Pages、Netlify等）を検討してください。
- Vercel 利用規約（Hobbyはpersonal/non-commercialの旨）：https://vercel.com/legal/terms
- Vercel Hobbyプランの説明（non-commercialの旨）：https://vercel.com/docs/plans/hobby
- Vercel Fair Use（商用はPro/Enterpriseが必要の旨）：https://vercel.com/docs/limits/fair-use-guidelines
- Netlify Freeプラン（商用デプロイ可能の説明）：https://www.netlify.com/blog/introducing-netlify-free-plan/
どのサービスも無料枠・制限・規約は更新されることがあります。公開前に必ず公式ページを確認し、「今の用途（非商用か、将来収益化するか）」に合う選択をするのが安全です。
デモの見せ方：URL＋スクショ2枚＋GIF（5秒）で“触る前に伝える”
採用担当や依頼者は忙しいので、URLを開く前に「何ができるか」を把握したいです。だから、ポートフォリオとしてはデモの“入口”を用意するだけで評価が上がりやすくなります。
- スクショ：トップ画面＋操作後（例：追加後の一覧）の2枚
- GIF：「追加→チェック→保存」の流れを5〜8秒
- 短い動画：30秒〜1分でOK（声なしで十分）
「動画やGIFってどう作るの？」で止まる人が多いので、最短の手段も置いておきます。
- Mac：画面収録は「Shift + Command + 5」
- Windows：Snipping Tool（切り取りツール）で録画/キャプチャ、またはXbox Game Barなど
- 手軽なGIF：Gyazo GIFなど、操作→共有が早いツールを使う
凝った編集は不要です。大事なのは「動く」「使い方が分かる」を短時間で伝えること。これだけで、未経験でも“作って終わりじゃない”印象になります。
READMEの書き方：テンプレを埋めるだけで「作った理由」と「学び」が伝わる
READMEは技術メモではなく、初見の人向けの説明書です。未経験ほどREADMEが薄くなりがちですが、逆にここを整えると一気に強くなります。下のテンプレをそのまま埋めてください。
※READMEはMarkdown（マークダウン）記法で書きます。見出しは「#」、画像は  で表示できます。
# アプリ名（例：Habit Tracker） ## 概要 「何を解決するアプリか」を1〜2文で。 ## デモ - 公開URL： https://xxxx - スクリーンショット： -  -  - GIF/動画（任意）：URL ## 機能 - 習慣の追加 - 達成チェック - 連続達成日数の表示 - localStorageで保存 ## 使用技術 - React（Vite） - TypeScript（任意） - CSS（Tailwind等でもOK） ## 工夫した点（3つ） - 入力バリデーション（空欄/重複） - 日付処理（同日の二重カウント防止 など） - スマホで触りやすいUI（ボタン・余白） ## 苦労した点と学び - 何に詰まったか → どう調べて解決したか ## セットアップ ```bash npm install npm run dev ``` ## 今後の改善 - 並び替え - データのエクスポート - ダークモード 特に「工夫した点」「苦労した点と学び」は、未経験でも必ず書けます。ここを書ける人は、実務でも伸びます。
よくある失敗5選と回避策：未経験が“公開まで”辿り着くために
失敗1：作るものが大きすぎて終わらない
回避策：MVPを3機能に絞り、まず公開。ログインやDBは2本目でOK。
失敗2：ローカルだけで満足して公開しない
回避策：最初の週に1回デプロイ。公開は最後の儀式ではなく、途中で通す。
失敗3：READMEが薄く、何ができるか分からない
回避策：テンプレを埋める。最低でも「概要・デモURL・機能・工夫点3つ」は必須。
失敗4：コミットが少なく“作った証拠”が薄い
回避策：小さくコミットする。「README更新」も立派な成果。
失敗5：無料プランの規約・制限を見ずに運用してしまう
回避策：ポートフォリオ用途は多くの場合問題になりにくいですが、将来収益化やクライアントワークに使う可能性があるなら、無料プランの商用利用可否を事前に確認し、必要なら移行前提で選ぶ（Vercel Hobbyは非商用前提など）。
まとめ：小さな成果物は「公開」と「説明」でポートフォリオになる
未経験のポートフォリオは、豪華な作品集よりも「小さなWebアプリを公開までやり切った1本」が強いです。GitHubで管理し、デプロイしてURLを持ち、READMEで工夫点と学びを説明できれば、作品として十分成立します。
デプロイ先は、静的ならGitHub Pages / Cloudflare Pages / Netlify、フレームワーク込みならVercelなどが候補になります。ただし、無料プランは“個人・非商用前提”などの条件が付くこともあるため、将来収益化する可能性があるなら最初から商用利用しやすい選択肢を検討すると安心です。
次にやること（3ステップ）
- ステップ1：静的アプリ（ログインなし）でテーマを1つ決め、READMEにMVP機能を3つ書く
- ステップ2：2〜4日でMVPを作り、1回デプロイしてURLを手に入れる
- ステップ3：READMEテンプレを埋め、スクショ2枚＋GIF（5秒）＋工夫点3つ＋改善TODOを追加する
