エンジニアの転職ポートフォリオは何を公開できる？

作品を作り始める前に、応募先の提出方法を確認します。URLが必要なのか、資料や技術課題でよいのかを聞きましょう。公開作品が全企業で必須とは限りません。

メルカリは、経歴の役割や実績を簡潔に伝える書類を案内しています。技術課題で実装を確認する選考も説明しています。S6この一社の案内を、全企業の提出条件には広げません。

守秘義務のある実務成果物は、会社名を消すだけで公開しません。公開可否が不明なら、社内規程や契約と管理担当者への確認が先です。代わりに、自分で用意したデータと環境による自主制作を検討します。

手元の資料提出前に確認すること公開できない場合の準備
勤務先のコード・設計書権利者、社内規程、公開許可経歴書で許された担当範囲を説明
顧客データを使う画面個人情報、顧客情報、画面内の値自作のサンプルデータで別に制作
自主制作外部素材と依存コードの利用条件権利を確認できる素材へ変更
チュートリアルの成果物元教材の利用条件、自分の変更箇所学習例と明記し独自部分を分ける

この表は公開前の確認用で、個別の権利を認定するものではありません。GitHubも、公開することとライセンスの付与を区別しています。S4他人のコードを含む場合は、自分だけの判断で利用条件を変更しません。

職務経験は、作品の数で置き換える必要はありません。実務の説明は職務経歴書の整理へ分けます。公開できる範囲の経験と、自主制作で試した範囲を別欄にしてください。

エンジニアの転職ポートフォリオで判断をどう伝える？

完成画面だけでなく、何のために作り、何を判断したかを示します。応募先の仕事と接点がある作品を選び、説明の順番をそろえましょう。採用される作品数や機能数に、共通の基準は置きません。

GitHubのREADMEは、プロジェクトの目的や始め方を伝える場所です。S1転職用では、それに自分の担当範囲と検証結果を加えると整理できます。次の構成は編集部の記入例で、企業の指定書式ではありません。

説明する欄自分の事実を入れる内容避けたい混同
目的誰のどんな作業を助けるか思いついた機能を並べるだけ
担当範囲自分が設計・実装・確認した部分チーム全体を個人の成果にする
技術判断比較した案、採用理由、制約技術名だけで経験を示す
動かし方必要環境、設定例、確認手順自分の端末だけで動く説明
検証と残件確かめた条件、未対応の動作未測定の性能や利用者数を足す

例えば、通信エラーを再現したなら、入力と期待した結果を記します。修正後に同じ条件で確認した結果を添え、未確認の環境も残します。学習環境の検証を、本番運用の経験とは書かないでください。

文章は「［目的］のために［機能］を作りました」から始められます。続けて「［制約］から［方法］を選び、［条件］で確認しました」と記します。空欄は実際に行った作業で埋め、架空の改善率を加えません。

GitHubのプロフィールでは、READMEや固定表示する作品を選べます。S5応募先には、最初に見てほしい作品と説明箇所を短く伝えましょう。表示の工夫そのものが、選考通過を保証するわけではありません。

エンジニアの転職ポートフォリオを提出前にどう確認する？

公開前は、現在のファイルだけでなく変更履歴も点検します。設定ファイル、画面画像、ログに実際の認証情報が残っていないか確認します。会社や顧客のデータを検証用として持ち出さないでください。

GitHubは、公開するとActionsの履歴やログも見えると説明しています。S2後で非公開へ戻しても、既に作られた公開フォークは非公開になりません。公開してから削除すればよい、という進め方は避けます。

確認箇所自分で行う確認未解決ならどうするか
ファイルと履歴キー、個人情報、会社情報を点検公開を保留し管理担当へ確認
外部素材出典、利用条件、必要な表示を確認権利を確認できるものへ替える
起動手順別の作業環境で手順を試す必要な設定と未対応環境を追記
公開URL閲覧権限とリンク先を確認応募先と許可された共有方法を相談
説明と実物担当範囲、機能、検証結果を照合実装していない説明を修正

認証情報を公開した場合は、ファイルの削除だけで対応を終えません。GitHubは、認証情報の失効や更新を最初の対応に挙げています。S3組織の情報なら管理担当へ報告し、指示に沿って対応してください。

提出時は、作品の目的、見る場所、未対応事項を短く添えます。閲覧にアカウントが必要なら、応募先が利用できるかを先に確認します。相手に実際の個人情報や決済情報を入力させるデモは避けましょう。

作品の説明がそろったら、求人の必須経験と改めて照合します。相談先を探す場合は正社員の対象条件比較を使えます。応募中なら、新しい登録より現在の担当者へ提出方法を確認してください。