実践ガイド・学びを仕事に
作った物を「仕事」に変える
— ポートフォリオと自己PR
学んだ先には「就職・受注」というゴールがあります。そこで効くのは資格や経歴より、「何を作ったか(ポートフォリオ)」と「それをどう語れるか(自己PR)」。 この2つは、AIに実装を任せる時代だからこそ、あなたが読めて・直せて・説明できることの証明になります。作り方を具体的にまとめます。
まず前提
未経験は「作った物」で判断される
経験の浅い人を採用・発注する側は、不安です。その不安を消す一番の材料が、実際に動く作品。「できます」と100回言うより、動くURLを1つ見せるほうが強い。
🔎 たとえるなら
料理人の就職と同じです。「料理できます」より、実際に一皿を出すほうが早い。 ポートフォリオは、あなたが出せる「試食の一皿」です。
💡 AIで作ってもいいのか？——はい。今はAIを使えるのが前提の時代です。 大事なのは「AIに任せた部分も、中身を読めて・直せて・説明できる」こと。 そこを見せられれば、むしろ評価されます。
選び方
「小さくても完成・公開」が最強
未完成の大作より、小さくても最後まで作って公開したものが評価されます。 「やり切れる人」だと伝わるからです。まずは1〜3個で十分。
ありがちな失敗
壮大なアプリを作ろうとして、途中で力尽き、動くものが1つも無い。「勉強中です」で止まってしまう。
刺さるポートフォリオ
『行きたい店リスト』『家計メモ』など生活の小さな困りごとを解決する、動く・公開済みのアプリが2〜3個。使ったURLがある。
作品ネタの見つけ方
自分の生活の困りごと
毎日ちょっと面倒なこと(メモ・記録・計算)を自動化する。実感がある分、語りやすい。
既存サービスの小さな模倣
TODOアプリ・天気表示・じゃんけんゲームなど定番。学びの証明に最適。
身近な人の困りごと
家族や友人の『これ面倒』を聞いて作る。使ってもらえると説得力が段違い。
見せ方(1)
READMEは「作品の顔」
GitHubに置いた作品の入口が README(説明書)。ここが空だと、どんな良い作品も伝わりません。 逆にここが丁寧だと、「説明できる人だ」と一目で伝わります。次の型を埋めるだけ。
📋 コピペで使える README テンプレ
# アプリ名 ## これは何？ （一言で。例：行きたいお店を保存できるメモアプリ） ## なぜ作った？ （解決したい困りごと。あなたの動機） ## 使い方 / デモ 公開URL：https://___ （スクリーンショットが1枚あると強い） ## 工夫した点・大変だった点 （ここが一番読まれる。詰まりをどう乗り越えたか） ## 使った技術 React / TypeScript / … など
💡 「工夫した点・大変だった点」が最重要。「AIが出したコードのバグに気づいて、こう直した」のような一節は、 まさに求められる「読める・直せる」力の証明になります。
見せ方(2)
「説明できる」を言葉にする
作れることと、それを言葉で説明できることは別のスキルです。 そして採用・発注側が本当に見たいのは後者。次の3点を、自分の作品について言えるように準備しましょう。
何を・なぜ作ったか
解決したい困りごとと、それをどう解いたか。
どこで詰まり、どう乗り越えたか
エラーや設計の迷いを、どう調べ・AIに相談し・直したか。
次に何を良くしたいか
改善点を言えると『成長できる人』に見える。
弱い自己PR
「プログラミングを勉強しました。頑張ります」——何ができるか、何を作ったかが無く、伝わらない。
強い自己PR
「生活の困りごとを解く小さなアプリを3つ作り公開しました。AIを使いつつ、出たコードは自分で読んで直せます。特に○○のバグを△△と特定して直した経験が自信です」
公開まで
作品を「URLで見せられる」状態に
手元で動くだけでは、まだ「試食の一皿」を出せません。GitHubに置き、Vercelなどで公開してURLにするところまでがセット。 手順の暗記は不要で、詰まったらAIに聞けばOKです。
Gitで記録する
変更をcommitして履歴を残す。壊しても戻せる状態に。
GitHubに置く
リポジトリを作ってpush。READMEもここに。作品置き場になる。
Vercel等で公開
GitHubと連携すると、pushで自動的に世界に公開されURLが出る。
▶ この流れに必要な学び
公開に必要な Git / GitHub は、コースで基礎から学べます。 作品づくりの土台になる言語コースと合わせてどうぞ。