エンジニア転職にポートフォリオは必要か|15社を数えて判断する
PRこのページには広告(アフィリエイトプログラム)が含まれます。サービスの掲載順は条件の一致度で決めており、報酬額は含めていません。
実務経験があるのにポートフォリオを作るべきか迷うのは、判断の材料が「作ったほうがいいらしい」という話ばかりで、誰がどこで見るのかが書かれていないからです。作る作業は数十時間かかります。効く場面が分からないまま始めると、転職活動そのものが止まります。
そこで、当サイトが掲載している転職サービス15社について、求人を絞り込む条件に何が並んでいるかを数えました。応募する側が最初にぶつかる入り口だからです。結果を先に書きます。
ポートフォリオや成果物で絞り込める軸は、15社のうち1社もありませんでした。この記事は、その事実を起点に「作るか作らないか」を決めるための整理です。対象は実務経験のあるITエンジニアで、未経験からの転職は前提が変わるため後半で分けて書きます。
求人を絞り込む条件に、成果物の欄は無い
15社の求人検索・スカウト機能を見て、絞り込みの軸として確認できた条件を数えたものが次の図です。

ここで数えているのは「絞り込みの軸があるかどうか」だけです。選考の途中で成果物を見るかどうかは別の話で、公開情報からは分かりません。それでも入り口の作りは、そのサービスが何を人の区別に使っているかを表しています。
台帳の全文を検索しても、「ポートフォリオ」「成果物」という語が出てくるサービスは0社でした。GitHubやリポジトリに触れていたのはFindyの1社だけです。
そもそも「ポートフォリオ」が指すものが4つある
話がかみ合わなくなる原因の多くは、言葉の指す範囲がそろっていないことです。転職の文脈で使われる「ポートフォリオ」には、少なくとも4つの意味があります。
| 指しているもの | 中身 | 経験者にとっての役割 |
|---|---|---|
| 公開したWebアプリ | 自分で企画して作り、動く状態で公開したもの | 移りたい領域の経験が無いときに、その空白を埋める |
| GitHubの公開リポジトリ | コードと、手を入れてきた履歴 | コードを材料にするサービスで、スコアの材料になる |
| 技術ブログ・登壇資料 | 取り組んだ内容を文章にしたもの | 考え方を示せるが、絞り込みの条件にはならない |
| 職務経歴をまとめた資料 | 担当した案件を一覧にしたもの | スキルシートと重なる。作るものではなく整えるもの |
この4つのうち、数十時間かかるのは上の2つだけです。下の2つは書く作業で、すでにある材料を並べ替えるものです。「作ったほうがいい」という助言が上の2つを指しているのか、下の2つを指しているのかで、必要な時間は10倍以上変わります。
この記事で「作る」と書いているのは、上の2つを指します。4つ目の「職務経歴をまとめた資料」は、作るかどうかを迷う対象ではありません。どの経路を通っても必要になるので、先に整えます。
代わりに何で絞り込まれているか
絞り込みの軸として多かったのは、使用言語とスキルでした。15社中7社です。区分の細かさは各社で違います。
| サービス | スキルの区分 |
|---|---|
| テックゴー | スキル154区分。絞り込み軸は職種・スキル・エリア・年収・企業の5つだけ |
| レバテックダイレクト | 約60の職種・90のスキル |
| AIdea Career | 使用言語44種 |
| doda | 言語30種・フレームワーク28種 |
| ギークリー | 言語27種・フレームワーク23種、ほかにクラウド/インフラ・データベース・OS・ネットワーク機器 |
もうひとつ目立つのが担当工程と開発の種類です。担当工程で絞り込めるのは2社で、ギークリーでは「要件定義」が17,665件、ウィルオブテックでは「上流工程」が1,993件と、件数まで表示されます。開発の種類で絞り込めるのは4社。ウィルオブテックは「自社製品/自社サービス」2,000件と「受託」1,640件を別々の条件として持っています。
並べてみると、相手が探しているのは「何を作れる人か」ではなく「どの言語で、どの工程を、どういう開発形態でやってきた人か」だと分かります。これは職務経歴書に書ける情報です。ポートフォリオを作らなくても書けます。
絞り込みの軸には年収帯もあります。ここは件数の差が大きく出る軸で、「1,000万円以上」で数えるとギークリーは11,238件、テックゴーは202件でした(2026年8月時点)。扱う範囲もエリアも違うので優劣の話ではありませんが、年収は、交渉で動く幅より、どの帯を扱う場所を選ぶかで決まる幅のほうが大きいという関係があります。ポートフォリオを作る時間をどこに使うかを考えるときの、もうひとつの材料です。
判断は「作るか」ではなく「どの経路で行くか」から始める
ポートフォリオが読まれる可能性は、応募先の企業よりもどの経路を通るかで大きく変わります。経路は3つの型に分かれます。
| 経路の型 | 相手が最初に見るもの | 成果物の扱い |
|---|---|---|
| 転職エージェント | 職務経歴書・スキルシート | 担当者が読む前提の資料に含まれない |
| スカウト型 | 登録したプロフィールの経歴とスキル | Findyのようにコードを材料にする例がある |
| 求人サイト(自分で応募) | 応募フォームで求められた書類 | 企業が指定したときだけ |
この分かれ方は転職活動の7つの工程でいう工程2、つまり「どのサービスを使うか」を決める段階で確定します。工程2を決める前にポートフォリオを作り始めると、作ったものが読まれない経路を選んでしまうことがあります。
スカウト型の中でも扱いは同じではありません。Findyは直近1年間の公開リポジトリからスキル偏差値を出しますが、レバテックダイレクトは職種とスキルの登録内容で企業と結びつく形で、コードを材料にしていません。同じ「スカウト型」でも、材料が違います。
ポートフォリオが効く3つの場合
0社という数字は「作る意味がない」という意味ではありません。入り口の絞り込みには使われないが、経歴の説明を補う場面はあるということです。補う必要があるのは、次の3つのどれかに当てはまるときです。
① 職務経歴に書けない領域へ移りたい
受託開発のバックエンドから自社サービスのフロントエンドへ、といった移動です。相手の絞り込み条件は「使用言語」なので、希望する言語での経験が職務経歴書に1行も無いと、検索の結果に載りません。この空白を埋める材料として、動くものが役に立ちます。
ただし、埋めるべきなのは空白そのものです。すでに書ける言語で新しく何か作っても、埋まる欄はありません。
② スカウト型を主経路にして、公開できるコードが無い
Findyのようにコードを材料にするサービスを主経路に選んだ場合、材料が無ければスコアが出ません。この場合に作るものは「作品」ではなく材料です。見栄えより、継続して手が入っている履歴のほうが意味を持ちます。
公開リポジトリの読まれ方は経路ごとに違うので、GitHubが実際に見られる場面を先に確認してから決めると、無駄な作り込みを避けられます。
③ 実務の成果を数字でも文章でも出せない
守秘の範囲が厳しく、規模も改善幅も書けない場合です。ただしこれは、本当に書けないのか、書き方を知らないだけなのかを先に分けるべきです。多くは後者です。次の章で扱います。
作らなくていい場合 — 職務経歴書で足りる条件
次の3つがすべて当てはまるなら、ポートフォリオを作る優先度は下がります。
- 希望する職種と言語が、これまでの業務と重なっている
- 主経路をエージェントか求人サイトに置いている
- 担当した工程を、要件定義・設計・実装・テストのどこからどこまでか言葉にできる
3つ目が重要です。相手の絞り込み条件に「担当工程」がある以上、工程を書けること自体が検索に載る条件になっています。作るより先に、職務経歴書で職種区分をどう合わせるかを整えるほうが、同じ時間で効きます。
技術の粒度で見せたい場合は、職務経歴書とは別にスキルシートを用意する形もあります。使った言語とバージョン、担当工程、期間を表にしたもので、相手の絞り込み条件と同じ粒度で並びます。
「業務のコードは出せない」をどう扱うか
受託や業務系の開発では、コードも設計書も外に出せません。これは前提として変えられません。変えられるのは出せる形に言い換える部分です。
| 出せないもの | 出せる形 |
|---|---|
| ソースコード | 使った言語・フレームワークとバージョン、構成の概略 |
| 顧客名・案件名 | 業種と規模(利用者数の桁、データ量の桁) |
| 設計書 | 担当した工程の範囲と、そこで決めたことの種類 |
| 売上や社内の指標 | 変化の方向と桁(処理時間を分の単位から秒の単位へ、など) |
この置き換えをやってみて、それでも欄が埋まらないときに初めて、作る側の検討に入ります。順番が逆になると、書けば済んだことのために数十時間を使うことになります。
自分の空白がどこにあるかを、30分で確かめる
作るか作らないかは、感覚ではなく求人の絞り込み結果で決められます。求人検索は登録しなくても使えるサービスが多いので、その場で確かめられます。
- 希望する条件だけで絞り込む。職種・言語・エリア・年収を、いま希望している条件で入れます。件数を控えます
- 次に、職務経歴書に書ける条件だけで絞り込む。1で入れた条件のうち、実際に業務で使った言語・担当した工程だけに置き換えます。件数を控えます
- 2つの件数を比べる。差が小さければ、いまの経歴で希望の求人に届いています。差が大きければ、その差が空白です
差の中身まで見ると、埋め方が決まります。差が言語で生まれているなら、その言語で作ったものが空白を埋めます。差が担当工程で生まれているなら、作っても埋まりません。工程の経験は個人開発では示しにくく、職務経歴書の書き方を変えるほうが効きます。
差が開発の種類(受託から自社サービスへ、など)で生まれている場合は、両方が要ります。求人側の条件としては開発形態で絞られますが、応募後に問われるのは「その形態で何をしたか」なので、経歴の書き方と成果物の両方が材料になります。
この確かめ方には条件があります。件数を表示するサービスでないと差が測れません。15社のうち、絞り込みごとの件数まで出していたのはギークリー・doda・ウィルオブテック・テックゴーなどでした。求人検索の機能を持たないサービスもあります。
作るなら、相手の絞り込み語彙から逆算する
作ると決めた場合、題材は「作りたいもの」ではなく相手が検索に使っている語から決めます。手順は3つです。
- 主経路に決めたサービスの求人検索を開き、希望する条件で絞り込む
- 絞り込みに使った語(言語・フレームワーク・工程・開発の種類)を書き出す
- そのうち、職務経歴書に書けない語だけを題材にする
件数が出るサービスを使うと、この作業の精度が上がります。ギークリーは「自社内開発メイン 5,757件」「自社サービス保有 19,696件」のように条件ごとの件数を表示し、dodaには「自社開発(自社サービス)」「客先常駐なし」という絞り込みがあります。件数が少ない条件を埋めるために作るのか、多い条件で数を狙うのかで、作るものは変わります。
規模については、実務と同じ桁を目指す必要はありません。空白を埋めるのが目的なので、その言語で設計から実装まで通したことが分かれば足ります。
作ったものをどこに置くか
置き場所は経路で決まります。
- スカウト型が主経路 — 公開リポジトリに置く。読み取りの対象になる形かどうかを先に確認する
- エージェントが主経路 — 職務経歴書に1行のURLとして添える。担当者が開くとは限らないので、本文側で説明が完結している必要がある
- 求人サイトが主経路 — 応募フォームで求められたときだけ出す
どの経路でも共通するのは、リポジトリのREADMEに「何を・どの言語で・どの範囲まで作ったか」を数行で書いておくことです。相手はコードを読む前にここを見ます。ここが無いと、開いた人がすぐ閉じます。
面接で聞かれたときに、何を話すか
成果物について聞かれたとき、相手が知りたいのは完成度ではありません。どこまでを自分で決めたかです。使ったライブラリの選定理由、やらなかったことと、その判断の根拠。この3つが答えられれば、規模は問われにくくなります。
逆に、作っていない場合も答え方は同じ形になります。「作っていません」で止めず、業務でどこまでを自分で決めたかに話を移します。相手が確かめたいのは判断の範囲なので、材料が業務でも個人開発でも成立します。
チュートリアルをなぞったものをそのまま出す形は、この問いに答えにくくなります。決めた箇所が無いためです。作る場合は、途中で自分で決めた箇所を1つ以上残すと、話せる材料になります。
未経験からの転職は前提が違う
ここまでは実務経験がある前提で書いてきました。未経験からの転職では、職務経歴書に書ける開発の経験がないため、成果物が経歴の代わりになります。判断の起点がそもそも違います。
また、扱っているサービスも分かれます。15社のうち未経験や経験の浅い層に言及していたのは8社でしたが、その中には「正社員としての実務経験がない場合、紹介の可能性は低い」と明記しているサービスもあります。当サイトは実務経験のある方の転職を扱っているため、未経験からの進め方はここでは扱いません。
この数え方の限界
「0社」という数字をそのまま「成果物は見られない」と読むと、行き過ぎます。この集計で分かっていることと、分かっていないことを分けておきます。
| 分かること | 分からないこと |
|---|---|
| 求人を探す入り口に、成果物の軸が置かれていない | 選考の途中で、担当者や面接官が見るかどうか |
| 入り口で使われているのは言語・工程・開発の種類 | 非公開求人の条件が同じ形かどうか |
| 公開情報に成果物への言及がほぼ無い | 言及していないサービスが、実際には見ていないかどうか |
調査の条件も書いておきます。対象は当サイトが掲載している15社、確認日は2026年8月25日から9月4日、方法は各社の公式サイトで求人検索とスカウト機能の絞り込み条件を目視で数えたものです。偏りとしては、掲載しているのがITエンジニアの正社員転職を扱うサービスに限られる点があります。ITエンジニア以外の職種や、業務委託を扱うサービスは含みません。
そのうえで、この数字が使えるのは優先順位を決めるときです。入り口に無いものを最初に作るより、入り口にあるものを職務経歴書で満たすほうが先だ、という判断には十分な材料になります。
つまずきやすい点
- 作り始めてから経路を決める — 読まれない経路を選ぶと、作った時間がそのまま余ります。工程2を先に決めます
- すでに書ける言語で作る — 埋まる欄がありません。埋めるのは職務経歴書の空白です
- 完成させようとして終わらない — 空白を埋めるのが目的なので、設計から実装まで通っていれば足ります
- READMEを書かない — 相手はコードより先にここを見ます
- 非公開のまま置く — スカウト型でスコアの材料にする場合、公開されていないものは読み取られません
この進め方が向かない人
この記事は「相手の絞り込み条件から逆算する」という考え方で書いています。次のような場合には合いません。
- 応募先が1社に決まっている — その企業の募集要項が答えです。15社の平均は関係ありません
- 作ること自体が目的 — 学習や趣味として作るなら、転職の条件から逆算する必要はありません
- 未経験からの転職 — 成果物が経歴の代わりになるため、判断の起点が変わります
- すでに完成した成果物がある — 作るかどうかの判断は終わっています。どう見せるかは経路の章を参照してください
- 研究職・データサイエンス寄りの職種 — 論文や実績の出し方が別の慣習になっており、この整理は当てはまりません
よくある質問
実務経験が3年あります。ポートフォリオは作ったほうがいいですか
希望する職種と言語が業務と重なっているなら、優先度は下がります。求人を絞り込む条件は言語・工程・開発の種類で、いずれも職務経歴書に書ける内容だからです。移りたい領域の経験が1行も書けない場合だけ、検討に入ります。
エージェントに「ポートフォリオはありますか」と聞かれました
あれば渡す、無ければ無いと答えるだけで問題ありません。求人の絞り込み条件に成果物の軸が無い以上、紹介の可否がそこで決まる形にはなっていません。聞かれた理由を確かめると、応募先が指定しているのか、担当者が材料を探しているのかが分かります。
GitHubのリポジトリがあれば、ポートフォリオの代わりになりますか
経路によります。コードを材料にするサービスなら、公開リポジトリがそのまま材料になります。エージェント経由では、担当者がリポジトリを開くとは限らないため、職務経歴書の側で説明が完結している必要があります。
どのくらいの規模のものを作れば足りますか
実務と同じ桁を目指す必要はありません。目的は職務経歴書の空白を埋めることなので、その言語で設計から実装まで通したことが分かる規模で足ります。規模を大きくするより、READMEで範囲を説明するほうが読まれます。
古いポートフォリオを載せたままでも大丈夫ですか
スコアの材料にするサービスでは、対象期間が決まっていることがあります。Findyのスキル偏差値は直近1年間の公開リポジトリを対象にしているため、古いものだけではスコアの材料になりません。エージェント経由では期間の指定はありませんが、内容が今の希望と離れていると、説明の手間が増えます。
作る時間がありません。ほかに埋める方法はありますか
業務で扱った範囲を、守秘を守れる形に置き換えて書く方法があります。言語とバージョン、業種と規模の桁、担当した工程の範囲、変化の方向と桁の4つです。これで欄が埋まるなら、作る必要はありません。
まとめ
- 当サイト掲載の15社で、ポートフォリオ・成果物で絞り込める軸は0社(調査日 2026年8月25日〜9月4日・n=15)
- 代わりに絞り込みの軸になっていたのは、使用言語・スキル7社、リモート5社、開発の種類4社、年収3社、担当工程2社
- 相手が探しているのは「何を作れる人か」より「どの言語で、どの工程を、どういう開発形態でやってきた人か」
- 判断は「作るか」ではなく、どの経路で行くかから始める。経路が決まると、読まれるかどうかも決まる
- 作る必要があるのは、職務経歴に書けない領域へ移るとき/コードを材料にする経路で材料が無いとき
- 作らずに済む場合が多い。守秘を守れる形への言い換えを先に試す
- 作るなら、相手が検索に使っている語のうち、職務経歴書に書けない語だけを題材にする
作るかどうかを一人で決めきれない場合は、希望する職種と言語で求人がどれくらいあるかを先に見ると、空白がどこにあるかが分かります。件数が出るサービスなら、その場で確かめられます。
15社の集計は、当サイトが各サービスの公式サイトを確認して作成した記事データベースにもとづきます。各社の確認日は、転職サービス一覧の各ページに「最終確認日」として掲載しています。
関連記事
- Findy(ファインディ)の特徴と向かない人 — 直近1年間の公開リポジトリからスキル偏差値を出すサービス
- ギークリーの特徴と向かない人 — 言語27種・フレームワーク23種、担当工程でも絞り込める
- テックゴーの特徴と向かない人 — 絞り込み軸を5つに絞り、スキルは154区分
次に読む
エンジニアのスキルシートの書き方|使った言語・担当工程・期間を、求人の絞り込み条件と同じ粒度で並べる方法を整理しています。
出典
- テックゴー「求人検索」(スキル154区分・2026年8月28日確認)
- doda「ITエンジニア専門サイト」(言語30種・フレームワーク28種・2026年8月27日確認)
- ギークリー「求人検索」(言語27種・フレームワーク23種・要件定義17,665件・自社内開発メイン5,757件・2026年8月28日確認)
- ウィルオブテック「こだわり条件」(上流工程1,993件・自社製品/自社サービス2,000件・受託1,640件・2026年8月27日確認)
- Findy(ファインディ)(スキル偏差値の対象は直近1年間の公開リポジトリ・2026年8月31日確認)