ポートフォリオは作品展ではなく、仕事の証拠になる

採用側の不安を一つずつ減らす役割がある

未経験採用では、実務で書いたコードや参加した案件を確認できません。その代わりに、課題を決めたか、基礎技術を使えたか、途中で起きた問題へ対応したか、他人へ説明できるかを成果物から読みます。見た目が豪華でも、起動しない、説明がない、コードを本人が話せない状態では判断材料になりません。反対に、機能が少なくても、目的、動作、コード、READMEが一続きになっていれば、学習した事実を具体的に伝えられます。

作る前に「この職種へ応募する」を決める

フロントエンド志望なのにデータ分析だけを見せても、採用側は画面実装の力を確認できません。バックエンドならAPI、データ保存、認証、エラー処理が中心になります。インフラならクラウド構成、権限、監視、復旧手順が成果物になります。品質保証ならテスト仕様、再現手順、自動テストが使えます。職種が決まっていない時は、求人票を複数読み、共通して出る仕事を見つけます。使用技術より、応募先で毎日行う仕事に近い証拠を選びます。

題材は、身近な困りごとから一つだけ選ぶ

自分が説明できる利用者と場面を選ぶ

題材が思いつかない時は、前職、学校、家庭で繰り返していた手作業を思い出します。営業の訪問記録、店舗の在庫確認、事務の申請管理、学習の進捗記録など、利用者と困る場面を自分の言葉で話せる題材は強くなります。流行しているサービスを真似るより、「誰が、いつ、何に困り、何ができると助かるか」を説明できる方が、機能の理由が伝わります。面接で質問された時も、思いつきではなく、実際の不便から機能を選んだと話せます。

主要な操作を一往復させてから機能を足す

最初から通知、決済、生成AIまで入れると、基本機能が完成しないまま時間が過ぎます。利用者が登録し、データを入力し、後から確認や修正を行う一連の流れを先に完成させます。例えば在庫管理なら、商品登録、入出庫、現在数の確認が動けば中心部分は伝わります。その後、検索、権限、集計などを加えます。追加機能は「技術を使いたいから」ではなく、利用者のどの不便を減らすかで選びます。

完成の基準は、他人が迷わず動かせること

デモURLだけでなく、最初の操作まで案内する

採用側が成果物を開いた時、ログイン方法や試す場所が分からないと、確認はそこで止まります。トップ画面に用途を短く書き、デモ用アカウント、代表的な操作、初期データの有無をREADMEにも載せます。外部公開が難しい場合は、画面録画や画像で一連の操作を示します。提出前には、普段使っていないブラウザやスマートフォンから開き、リンク、ログイン、登録、更新、削除が動くかを確かめます。自分の開発環境で動くことと、他人が試せることは別です。

正常に動く場面だけでなく、失敗時の表示も作る

入力欄を空にした時、同じメールアドレスを登録した時、通信が切れた時、権限がない画面を開いた時にどうなるかを確認します。エラーが画面に出ず固まる状態は、機能数より大きな減点になります。すべての例外へ対応するのではなく、主要な操作で起こりやすい失敗から扱います。入力確認、エラーメッセージ、再試行、権限の違いを用意すると、利用者の操作を想像して作ったことが伝わります。

READMEは、コードを読む前の案内役になる

最初の数行で、何を作ったか分かるようにする

GitHubの公式文書では、READMEはプロジェクトが何を行い、なぜ役立ち、どう使うかを伝える場所とされています。採用向けでは、最初にサービス名、利用者、困りごと、中心機能、デモURLを書きます。その後に使用技術、構成、起動方法、環境変数、テスト方法、工夫した箇所、残っている課題を続けます。画面画像を一枚置くと、コードを開く前に全体を把握できます。技術一覧だけのREADMEでは、作品の目的が伝わりません。

選んだ技術の理由は、比較した結果として書く

「Reactを使いたかったから」だけでは、制作上の判断が分かりません。画面の状態変更が多いため採用した、学習済みの技術で完成を優先した、無料枠で公開しやすいため選んだなど、その作品に合った理由を書きます。別の方法も検討したなら、採用しなかった理由を短く残します。正解を当てることより、制約の中で決めたことが伝わる方が実務に近くなります。後から技術を変えた場合も、変更前の困りごとと結果を書きます。

GitHubは、見てほしい作品へすぐ辿れる状態にする

プロフィールには代表作を前へ出す

GitHubでは、公開リポジトリやGistをプロフィールへ最大六件まで固定表示できます。応募に使う作品を前へ出し、途中で止まった練習用リポジトリより先に見せます。プロフィールREADMEには、目指す職種、学習中の技術、代表作へのリンクを短く書きます。リポジトリ名も「portfolio-1」のような番号だけではなく、何を作ったか分かる名前にします。採用担当が職務経歴書のURLから来た時に、探さなくても代表作へ入れる状態を作ります。

コミット数より、変更の理由が分かる履歴を残す

活動グラフを埋めるために小さな変更を大量に送っても、開発の力は伝わりません。機能追加、修正、テスト、表示変更など、何を変えたか分かる単位でコミットします。メッセージには「修正」だけでなく、「ログイン失敗時の表示を追加」のように内容を書きます。途中で作り直した箇所があれば、なぜ変えたかをIssueやREADMEへ残します。完成画面だけでなく、問題へ対応した履歴があると、学習中の進め方まで確認できます。

AIを使った部分は、隠さず説明できる状態にする

生成コードを採用する前に、自分で読んで動かす

コード生成AIを使うこと自体より、出力を理解せず提出することが問題になります。生成された処理を一行ずつ読み、入力と出力、失敗時の動き、依存するライブラリを確認します。自分の言葉で説明できないコードは、短く書き直すか、理解できる範囲まで学び直します。面接で「なぜこの書き方にしたか」と聞かれた時、AIが出したからでは答えになりません。候補を出す道具として使い、採用した責任は自分が持ちます。

秘密情報と他人の成果物を混ぜない

APIキー、接続文字列、個人情報をリポジトリへ入れないよう、環境変数と除外ファイルを確認します。一度公開したキーは、ファイルを消すだけでなく無効化や再発行も行います。教材やサンプルコードを使った場合は、どこを参考にし、どこを自分で変更したかを書きます。生成AIの出力や外部素材にも利用条件があります。出所が分からないコードを貼り集めるのではなく、自分が説明できる範囲と第三者の権利を守ります。

提出前は、採用側の操作順で確認する

リンクを開いてからコードを見るまでを通しで試す

職務経歴書のURLを開き、プロフィール、代表作、README、デモ、コードの順に移動します。途中でリンク切れ、権限要求、長い説明、起動しないデモがないかを確認します。採用側は制作に何週間かけたかを知りません。最初の数分で何を作ったか分からなければ、深いコードまで到達しにくくなります。友人や学習仲間にURLだけを渡し、説明なしで主要機能へ辿れるか試してもらうと、自分では気づきにくい詰まりを発見できます。

未完成箇所は隠さず、重要度を分けて書く

主要機能が動いていれば、追加したかった機能が残っていても提出できます。READMEに、既知の不具合、今後加えたい機能、今回は扱わなかった理由を分けて書きます。ただし、ログインできない、データが保存されないなど、中心機能の不具合は提出前に直します。「未完成でもよい」と「確認できない状態でよい」は別です。限られた時間でどこまで完成させ、何を後へ回したかが分かると、作業の優先度を決めた事実も伝わります。

作り続けるより、応募で使って反応を得る

職務経歴書には、作品の価値を数行で書く

GitHubのURLだけを置くと、採用側は開く理由を判断できません。作品名、利用者、解決する困りごと、中心技術、自分で工夫した箇所を数行で書きます。例えば「店舗スタッフ向け在庫記録アプリ。入出庫と現在数の確認を実装し、入力失敗時の表示と権限分けを追加」と書けば、見る場所が分かります。フロントエンド応募では画面と状態管理、バックエンド応募ではAPIとデータ処理など、求人に近い箇所を先に出します。

面接では、画面、構成、コードの順で話す

最初に利用者と困りごとを話し、実際の画面で主要な操作を見せます。その後、データの流れや主要なファイルを示し、最後に工夫したコードへ進みます。いきなり細かな実装から話すと、何のためのコードか伝わりません。説明時間が短い場合と長い場合を想定し、要約版と詳細版を用意します。応募後に質問された箇所は記録し、READMEやコードへ反映します。ポートフォリオは完成して終わるのではなく、選考で使って初めて役割を果たします。

大きな作品より採用側が確認できる一つの完成品を作る