エンジニアの転職に成果物は必要か｜経験者の実績の示し方

経験者のエンジニアの転職では、GitHub のリポジトリやポートフォリオのような成果物を用意していなくても、多くの求人に応募できます。Offers に掲載されたエンジニア職の正社員求人を見ると、応募の条件の中心は実務経験で、書類選考で読まれるのは職務経歴書に書いた業務の実績です。成果物は、その実績を裏づける材料や、歓迎条件と技術選考で評価を上積みする材料として使います。

求人票の必須条件・歓迎条件・選考の流れを数え、成果物がどこで求められているかを確かめました。そのうえで、業務の実績を成果物として示す方法と含める内容、守秘義務と著作権の線引き、面接での説明の仕方をまとめています。

エンジニア転職の成果物は業務の実績と公開できる制作物の2種類

エンジニアの転職でいう成果物は、仕事で設計・開発・運用したシステムや改善の実績と、GitHub に公開したコード・技術ブログ・OSS（オープンソースソフトウェア）への貢献・個人開発のアプリといった社外に公開できる制作物の2種類です。経験者の選考で材料の中心になるのは前者の業務の実績で、職務経歴書に書いて示します。

ポートフォリオは、成果物を選んで説明を添え、読み手が見渡せるようにまとめた資料のことです。デザイナーの転職では作品集として提出するのが一般的ですが、エンジニアの場合は職務経歴書のプロジェクトの記述や GitHub のプロフィール、技術ブログの記事一覧がその役割を担います。言葉の意味と分野ごとの使い分けは「ポートフォリオとは」で扱っています。

エンジニア職の求人で成果物の提出を必須とするものは少ない

Offers に掲載されたエンジニア職の正社員求人1,765件のうち、必須条件の欄で成果物や社外へのアウトプットに触れる求人は1.3%でした。数字で「3年以上」のように実務経験の年数を書く求人は51.1%あり、応募の条件の中心は成果物ではなく実務経験です（Offers（株式会社overflow）調べ・エンジニア職の正社員求人 n=1,765・2026年10月集計）。

出所: Offers（株式会社overflow）調べ・エンジニア職の正社員求人・2022年3月〜2026年9月掲載 n=1,765・2026年10月集計。

必須条件で成果物に触れる求人の多くは発信の姿勢を書いている

エンジニア職の必須条件の欄で成果物や発信の語に当たった23件を読むと、14件は「情報発信を積極的に行う」「技術的な情報発信が得意な方」のように、発信への姿勢や習慣を書いたものでした。

成果物の提出そのものに触れるのは同じ会社の2件だけで、実務経験がない応募者に制作物の提出を求めるものと、経験年数や内容によってはポートフォリオを求めることがあるとするものです。実務経験のあるエンジニアが、応募の時点で成果物を出すよう条件づけられる求人はまれだと言えます。

必須条件のGitHubの多くは開発で使った経験を指す

必須条件に GitHub の語が出てくるエンジニア職の求人は4.4%（77件）でした。GitHub Actions と GitHub Copilot の製品名を除いて書き方を分けると、56件は「GitHubの利用経験」「Githubを用いた開発経験」のように GitHub を開発の道具として使った経験を求め、そのうち46件は「Git/GitHubを利用したチーム開発経験」のようにチームや複数人での開発、コードレビュー、開発フローまで書いていました。

残る21件のうち15件は GitHub Actions（テストやデプロイを自動で回す仕組み）や GitHub Copilot（AI によるコードの補完）といった製品を挙げるもので、公開しているコードを見せる意味で GitHub を挙げる求人は3件でした。個人のアカウントにコードが並んでいなくても、プルリクエストでのレビューやブランチの運用など、チームでの開発の進め方を職務経歴書に書けば、GitHub を使った開発経験の条件に応えられます。

デザイナー職の求人とは成果物の扱いが違う

求人票の本文（タイトル・求人概要・必須条件・歓迎条件・開発内容）に「ポートフォリオ」の語が出てくる求人は、デザイナー職で22.4%あるのに対し、エンジニア職では0.5%でした（Offers（株式会社overflow）調べ・デザイナー職 n=134・エンジニア職 n=1,765・2026年10月集計）。エンジニア職で当たった8件には、製品名や、事業・資産運用の説明に出てくる語が4件含まれ、応募者の作品集の意味で使う求人に絞ると1,765件のうち4件（0.2%）です。

デザイナーの転職では作品集の提出を選考の前提に置く求人が一定数ありますが、エンジニアの転職で同じ前提を置く求人はまれです。同じ IT 職の転職でも、デザイナー向けの「ポートフォリオは必須」という助言をそのままエンジニアに当てはめる必要はありません。

公開できる成果物は歓迎条件と技術選考の材料になる

公開できる成果物は、必須条件ではなく歓迎条件と技術選考で評価の材料になります。エンジニア職の求人の歓迎条件で成果物や発信の語が出てくるのは3.9%で、内訳は OSS や技術コミュニティへの貢献が3.1%、技術ブログ・登壇などの発信が2.0%でした（Offers（株式会社overflow）調べ・n=1,765・2026年10月集計）。

歓迎条件の書き方は「OSSの公開、コントリビュートの経験」「技術ブログ・登壇等、外部へのアウトプット経験」のように具体的で、40社の求人に見られました。応募先の歓迎条件にこうした項目があるなら、該当する活動を職務経歴書の末尾にまとめて URL を添えておくと、読み手がその場で確かめられます。

選考で技術力を確かめる手段はコーディングテストが多い

選考の流れの欄にコーディングテストや技術課題を書くエンジニア職の求人は12.0%で、成果物の提出や共有に触れる求人の1.3%を大きく上回ります。応募者の技術力は、提出された成果物より、選考の中で解いてもらう課題で確かめる企業が多いということです。

選考の流れで成果物に触れる23件（7社の掲載）のうち18件は「GitHub等ソースコードがわかるものがあればご共有ください」のような任意の書き方で、そのうち2件は「ポートフォリオ（GitHubリポジトリ等）が充実している場合、技術テストをスキップします」としていました。選考の中で提出を求めるのは4件、実務未経験の応募者に限って求めるのは1件で、23件のうち14件は同じ1社が2つのアカウントで載せた求人です。公開できる成果物がない人は課題で、ある人は成果物で、同じ技術力を示せる求人もあります。

選考の流れと歓迎条件の書き方は求人ごとにまちまちなので、応募先ごとに確かめるのが確実です。Offers Jobs では、エンジニアの正社員求人を、必須条件・歓迎条件から選考の流れまで含めて確かめられます。

業務の実績は職務経歴書で成果物として示す

経験者のエンジニアが示す成果物の中心は、職務経歴書に書く業務の実績です。プロジェクトごとに「目的と規模」「自分の役割」「使った技術と選んだ理由」「課題と打ち手」「結果」の5つをそろえて書けば、採用する側は応募者に何を任せられるかを判断できます。

職務経歴書の全体の構成とフォーマットは「エンジニアの職務経歴書の書き方」を参考にしてください。

役割は自分が決めた範囲で書く

役割は「開発を担当」のような一語で済ませず、チームの構成と、その中で自分が決めた範囲・決めなかった範囲で書きます。チームで作ったシステムをそのまま書いても、どこまでが本人の仕事なのかは読み手に伝わりません。設計、実装、レビュー、運用、他職種との調整のように工程ごとに関わりを書き分けると、担当範囲の広さと深さの両方が見えてきます。

数値を出せない成果は変化の向きと比較で示す

社外に出せない数値は、実数の代わりに、前後の比較や変化の向きで示します。「リリースの頻度が週単位から日単位になった」「障害の件数が前の半期より減った」のように書けば、規模を明かさずに成果の大きさを伝えられるはずです。数値を出せない理由を一言添えておくと、面接で深掘りされたときにも説明がぶれません。

業務の成果物を社外に見せるときは守秘義務と著作権を確かめる

業務で作ったコードや設計書を、そのまま GitHub やポートフォリオに載せるのは避けてください。著作権法の「職務著作」の定め（第15条）では、会社の企画のもとで社員が職務として作った著作物のうち、公表するなら会社の名義で公表するものは、契約や就業規則に別の定めがない限り会社が著作者になります。プログラムは公表されないことが多いため、会社の名義で公表するという要件を満たす必要がありません（文化庁「著作権テキスト －令和7年度版－」）。

会社の情報の扱いにも注意が要ります。経済産業省は、営業秘密として法的に保護される条件に、秘密として管理されていること、事業活動に有用であること、公然と知られていないことの3つを挙げています（経済産業省「秘密情報の保護ハンドブック」・最終改訂2024年2月）。

同じハンドブックは、転職者が持ち込む情報に転職元の秘密情報が混ざるおそれを、受け入れる企業の側のリスクとして挙げています。その一方で、転職者が転職元企業で身につけた技能やノウハウは基本的に利用を制約されない、とも説明しています。職務経歴書や面接で伝えるべきなのは前職の資料やコードではなく、そこで身につけた設計の考え方や課題の解き方です。

業務の成果物は固有の情報を伏せて書き直す

業務の成果物を見せるときは、社名・サービス名・顧客の情報・公開前の機能・非公開の数値を外し、構成図や処理の流れを一般化して描き直します。在籍中の会社がプレスリリースや技術ブログで公開している情報なら、その URL を添えて実績を裏づける材料にできます。判断に迷う情報は、就業規則や秘密保持の誓約書で扱いを確かめてから使ってください。

公開できる成果物は実務の延長で選ぶ

公開できる成果物をこれから作るなら、応募先の仕事に近い題材を、実務で身につけた技術の延長で選びます。業務で解いた課題を一般化した小さなライブラリやツール、使っている OSS への不具合の修正、設計の判断を書いた技術ブログの記事は、業務の実績と結びつけて説明でき、職務経歴書の記述の裏づけにもなる題材です。

職種ごとのポートフォリオの作り方は「エンジニア転職で差がつくポートフォリオの作り方」が詳しい内容です。

GitHubのリポジトリはREADMEで読み手を案内する

リポジトリを開いた人が最初に読むのは README（リポジトリの入口に置く説明のファイル）なので、冒頭で何のためのコードかと、どこを読めばよいかを示しておきます。目的、使った技術とその理由、設計で迷った点と判断、テストの書き方、動かし方の順に並べておけば、コードの全体を読まなくても技術力が伝わります。テストや CI（コードを変更するたびに自動でテストを回す仕組み）を整えておくと、品質への意識も示せるでしょう。

面接では成果物を課題と判断の順で説明する

面接で成果物を説明するときは、背景、課題、比べた選択肢、選んだ理由、結果、次に同じ課題に当たったら変えること、の順に話すと、技術の深さと判断の筋道が伝わります。説明の途中では「なぜその技術を選んだのか」「ほかの案ではなぜだめだったのか」と深掘りされることが多いので、選ばなかった案とその理由まで言葉にしておきましょう。

応募先の必須条件と歓迎条件に書かれた技術や経験に近い成果物から順に説明すれば、その会社で任せられる仕事と結びつけて聞いてもらえます。技術的な質問への準備は「エンジニア面接の技術質問攻略法」も参考にしてください。

エンジニアの転職と成果物の要点

Offers の求人票を数えると、エンジニア職で必須条件が成果物や発信に触れる求人は1.3%にとどまり、実務経験の年数を書く求人は51.1%です。成果物は歓迎条件（3.9%）と、コーディングテスト・技術課題（12.0%）を含む技術選考で評価の材料になります（Offers（株式会社overflow）調べ・n=1,765・2026年10月集計）。

経験者のエンジニアが最初に整えるべきなのは、業務の実績を目的・役割・技術・課題・結果の5つで書いた職務経歴書です。公開できる成果物は、守秘義務と著作権に触れない範囲で、実務の延長に作れば十分でしょう。応募先を選ぶときは求人票の必須条件・歓迎条件・選考の流れを並べて読み、どの成果物を前に出すかを決めておくと準備の手戻りが減ります。Offers Jobs では、エンジニアの正社員求人の条件と選考の流れを確かめられます。