強いポートフォリオの作り方。公開されていない成果物は、就活では存在していないのと同じです【フェーズ2-2｜ITエンジニアの卵に贈る、就活の書】

【お知らせ】本連載は、2026年9月20日に全記事を全面アップデートしました。

　この記事は本気でITエンジニアになりたい！ という学生さんたちに向けて就活プロセスを伝える「ITエンジニアの卵に贈る、就活の書」シリーズの一本です。シリーズ全体の目次はこちら（扉記事）からご覧いただけます。

　エンジニアを目指す学生のみなさん、こんにちは。クオリティアーツの池田です。

　ITエンジニアの卵に贈る、就活の書・フェーズ2-2の記事です。前回のフェーズ2-1では、なぜ作るのかという土台の考え方をお話ししました。プロフェッションの視座と、企業の募集要項の視座が、同じ方向を指している。だから学生時代のうちに、その方向へ着実に一歩を踏み出しておいてほしい、という話でした。

　今回はその続きです。では、どう作れば強いポートフォリオになるのか。あわせて、せっかく積んだものを自分で台無しにしてしまう名乗り方についても、ひとつ書きます。この記事は、実践各論11本（フェーズ2-3〜フェーズ2-13）すべてを貫く共通軸として、書きます。GitHubを育てるときも、技術ブログを書くときも、勉強会で発表するときも、長期インターンを積むときも、この記事で扱う原則が同じ形で活きてきます。

この記事のポイント

• 公開されていない成果物は、就活では存在していないのと同じです。条件は、公開されていること、意図を追えること、公開してよい質であることの3つ。

• 自分で置いた作品と、第三者の目利きを経て名前が載った場所とでは、信用の重さが違います。登壇者一覧、学会の採録リスト、貢献者欄などです。

• 語るなら、やったことと、その証跡で語ってください。自分で付けた「学生エンジニア」のような一語は、迎える側には落とし穴です。

1. そもそもポートフォリオとは何か

　ポートフォリオという言葉は、就活の場面では、あなたが学生時代に作った経験を、束ねて見せるための道具を指します。

　公開したコード。書いた技術ブログ。勉強会で登壇したときのスライド。ハッカソンの成果物。長期インターン先で担当したプロジェクト。コミュニティ運営のクレジット。こういった一つ一つが、ポートフォリオを構成する部品です。

　多くのIT企業は、書類選考や一次面接の前に、候補者の名前とハンドルネームを検索します。私自身、面接する側の立場で候補者の名前を検索したことは、数え切れないほどあります。

　世界に見える形で成果物が置かれていれば、それが口頭の説明よりも雄弁に、あなたを語ってくれます。動くコード。積み上がった変更の履歴。書かれた記事。公開されたスライド。

　序章-1で語ったプロフェッションの視座から見ると、ポートフォリオは、単なる就活のツールではありません。自分が積み上げてきた学びと実践を、公衆に対して開いておくという、プロフェッションとしての自然な態度そのものです。

　就活のためだけの一時的な化粧ではありません。生涯続く自己研鑽の記録が、外から見える形で残っている状態のことです。

　そして、これは書類選考に直結します。書類選考は、その企業の人と実際に会えるかどうかを決める、最初の関門です。ここで企業側が見るのは、履歴書とエントリーシートの文字だけではありません。名前で検索して出てくる、成果物の総体を見ます。

　手元のパソコンにどれだけ素晴らしいものを溜め込んでいても、検索して出てこなければ、企業側から見ると存在していないのと同じです。ここが、大きな分岐点になります。

2. 強いポートフォリオの3つの条件

　ここから本題です。強いポートフォリオには、次の3つの条件があります。

1. 公開されていること

2. 見に来た人が意図を追えること

3. 公開してよい質になっていること

　一つずつ、順に見ていきます。

2-1. 条件1：公開されていること

　公開されていない成果物は、就活の場面では存在していないのと同じ、というのが本記事の入口です。

　公開の場所は、次のような世界標準のプラットフォームを使います。名前で検索したときに、すぐたどり着ける場所です。

• GitHub：コード、README、コミット履歴、リポジトリ一覧、Contributions グラフ

• 技術ブログ：Qiita、Zenn、はてなブログ、Medium、独自ドメインの静的サイト

• スライド共有：Speaker Deck、Docswell、SlideShare

• プロダクトの公開：Vercel、Netlify、GitHub Pages、Cloudflare Pages、独自ドメイン

• プロフィールの集約：個人ポートフォリオサイト、Wantedly、LinkedIn、X（旧Twitter）のプロフィール

　大切なのは、あなたの本名またはハンドルネームで、世界のどこからでも検索してたどり着けること。GitHubの Public リポジトリだけがあって、他の場所からリンクが張られていない状態だと、企業側の検索で見つかるまでに手間がかかります。プロフィールを集約する1つのランディングページから、各成果物にリンクが伸びている構造がおすすめです。個人ポートフォリオサイトはそれ自体は凝った作りである必要はありません。GitHub Pages の1枚のHTMLでも十分機能します。

　学生時代のみなさんに、ささやかなお願いを一つ。匿名アカウントと就活アカウントの整合を、早めに整えておいてください。GitHub のハンドルネームと、Zenn の表示名と、X のアカウント名が、同じ人物のものだと分かるようにしておく。この一手間だけで、企業側があなたに辿り着きやすくなります。

2-1-1. 実機がないと動かないものを作っている方へ

　ここまでの公開先は、画面の中で完結するものを前提に並べました。組込み、制御、ロボット、計測、ハードウェアが絡む成果物は、事情が違います。コードをGitHubに置いても、読む側の手元に同じ機材がなければ、動かせません。

　ただし、公開しなくてよい、という話ではありません。公開の形が変わるだけです。次の3つを足してください。

• 動いている様子の、短い動画。READMEには動画やGIFを埋め込めます。30秒で足ります。画面の中で完結しないものは、これがないと、何も伝わりません

• 何をどうつないだかが分かる1枚。配線図、ブロック図、使った部品の一覧、ピンの割り当て。手書きをスキャンしたものでも構いません

• なぜその構成にしたかの説明。なぜそのセンサーか。なぜその制御周期か。技術選定の理由を見る目は、Webでも組込みでも同じです（次の2-2で扱います）

　もう一つ、読む側が再現できるかどうかが効きます。手に入りやすいボード（Arduino、Raspberry Pi、ESP32、M5Stackなど）で組んだものは、同じ部品さえあれば、読んだ人が自分で動かせます。実機がなくても動く形（シミュレータやエミュレータで動かせる構成、あるいはハードに触る部分を切り離した設計）にしておくと、さらに敷居が下がります。この切り離しができていること自体が、設計の力の証拠になります。

　この作業は、楽ではありません。動画を撮り、配線図を描き、部品表を起こす。コードを書くより手間がかかる日もあります。それでも、やらなければ、その成果物は就活の場面では存在していないのと同じです。ここは、画面の中で完結する成果物と、条件が同じです。

　なお、研究室や企業の機材を使って作ったものは、公開してよいかを先に確かめてください。これは組込みに限らない話で、フェーズ2-3とフェーズ2-13で扱っています。

2-2. 条件2：見に来た人が意図を追えること

　公開されているだけでは、まだ強いポートフォリオになりません。見に来た人が、あなたの意図と過程と学びを追える形になっていることが、次の条件です。

　具体的には、それぞれの成果物に、次のような言葉が添えられていること：

• 背景と目的：どんな問題意識で作ったか、何を解決したかったか

• 使用技術：どんな技術スタックで実装したか

• 技術選定の理由：なぜその技術を選んだか

• こだわりのポイント：どこに時間をかけたか

• 直面した課題と解決策：ぶつかった壁と、どう乗り越えたか

• 今後の展望：次にやりたいこと

　この6つは、私が学生さんに勧めている形です。フェーズ2-1で並べた各社の募集要項に共通していたのは、何を作ったかだけでは足りないということでした。企業が見ようとしているのは、なぜそれを作り、どう考え、何を学んだのかまで含めた全体です。

　これは、序章-1で語ったプロフェッションの姿と、はっきり重なります。エンジニアは、動くコードを納める職人であると同時に、自分の判断と成長に責任を持つ専門職です。何を、なぜ、どう作ったのかを言葉にできる人は、就活の場面だけでなく、社会人になってからのプロフェッションの現場でも、強く必要とされます。

　書く場所は決まっています。コードなら README、技術ブログなら記事の本文、スライドなら説明欄。この6要素を、短くてもいいので言葉にしておく。これだけで、成果物の受け取られ方が大きく変わります。

2-3. 条件3：公開してよい質になっていること

　3つ目は、質の話です。ここは、入口で、はっきりお伝えしておきたい部分です。

　公開されているからこそ、その中身が問われる。動かないコード、READMEのない断片、他人のチュートリアルの写経がそのまま残っている放置リポジトリ、意図が読み取れない古い実験。こういうものは、あることでかえって減点材料になり得ます。

　学生時代の作品ですから、完成度そのものは高くなくてかまいません。世界を驚かせるプロダクトを作る必要も、企業の本番システムに耐えるコードを書く必要もありません。ただし、次のことは押さえておいてほしい：

• 動くこと：READMEに書かれた手順で、他人の環境でも動くこと

• コードが読めること：命名、コメント、ファイル構成が、他人が読める形になっていること

• 他人の作品との違いを、自分の言葉で説明できること：チュートリアルの写経でも構いません。自分がどこを変え、なぜ変えたかを説明できれば、自分の作品として意味を持ちます

　もう一つ、付け加えておきたい観点があります。壊れていないかを確かめる仕組みの痕跡です。テストコードや、自動で検査する設定のこと。

　ソフトウェアテストや品質保証は、学校の授業で深く扱われることが少ない分野です。だからこそ、ユニットテストを1つ書く、自動検査を1本回す。この痕跡がポートフォリオにあると、採用側のエンジニアの目に、はっきり残ります。

　就職してからは、テストと品質は現場でもっとも重視される要素の一つになります。学生のうちにその視点を持っていたという事実は、入社後の最初の数か月で、そのまま効いてきます。フェーズ2-4で、テストと品質保証を学ぶための技術書とJSTQBのシラバスを紹介しています。

　公開する前に、一度、他人の目で自分の成果物を見直す。この一手間は、すべての各論で共通します。

　公開してよい質にどう仕上げるかは、各論でも繰り返し扱います。写経の位置づけはフェーズ2-4、リポジトリの整え方はフェーズ2-5、ハッカソンの成果物の後処理はフェーズ2-6です。

　なお、過去に勢いで公開したものの、いま見返すと質が低いと感じるリポジトリや記事が、誰にでもあります。消す以外の選択肢を置いておきます。READMEを整えて、成長の過程として位置づけ直す。アーカイブ状態にする（読めるが、更新していないことが明示される状態）。非公開にする。

　過去の作品と正直に向き合い、いまの自分にとって公開してよい形に整える。この作業自体が、プロフェッションとしての第一歩でもあります。

3. そしてもう一段。第三者が目利きした場所に、あなたの名前が載る

　ここまでの3つの条件は、あなた自身が管理する場所での公開についての話でした。強いポートフォリオには、さらにその上の段階があります。

　自分のアカウントに、自分で置いた作品。そして、他人のページに、目利きを経て自分の名前が載っている実績。この2つでは、企業から見た信用の重さが、まったく違います。後者は、学会、カンファレンス、コミュニティ、公開されているコードのプロジェクトなどです。

　自分のGitHubに自分でリポジトリを公開するのは、意志があれば誰でもできます。けれど、次のような場所に自分の名前が載るためには、第三者の目を通ります。

• カンファレンス・勉強会の登壇者ページ（connpass、Doorkeeper、公式サイトのプログラム欄）

• Speaker Deckなどのスライド共有サービスの、カンファレンス公式アカウントに集約された発表一覧

• 学会の論文誌・技術発表会のプログラム、採録リスト

• OSSプロジェクトのContributors欄、Changelog、リリースノートの謝辞

• 技術系書籍の共著者・共訳者リスト、雑誌記事の執筆者クレジット

• コミュニティ・技術者団体の運営メンバー・実行委員リスト

• ハッカソン・コンテストの入賞者ページ、主催団体の受賞者アーカイブ

　これらの場所に名前が載るには、第三者による評価を通ります。登壇の公募（CFP、Call For Proposals）に通る。査読を通る。コミュニティの管理者に認められる。コンテストで審査を通る。どれも、自分では決められません。

　自分で「これは価値があります」と主張する公開と、第三者が「この人と、この作品を、私たちの場に載せる価値がある」と目利きした結果としての掲載。後者は、あなたの言葉ではなく、他人の言葉で、あなたの実績を語ってくれます。

　学生時代のみなさんに、いま持ってほしい視座は、この一つです。公開する場所を自分のアカウントの中だけに閉じない。

　この先の各論で扱う活動は、実は第三者の目利きが働く場所に、自分の名前を残す機会そのものです。フェーズ2-6のハッカソン、フェーズ2-8の技術ブログ、フェーズ2-9の勉強会での発表、フェーズ2-11の長期インターン、フェーズ2-12のコミュニティ運営。この視点で、つなぎ直してみてください。

4. 「学生エンジニア」は落とし穴です。中身がない人も、増えてきた人も

　3章では、他人が目利きした場所に名前が載ることの重さをお話ししました。その裏返しの話を、ここでひとつ。

　中身がない人は、肩書に頼ります。そして中身が増えてきた人は、思わず自慢したくなります。どちらも、同じ失敗です。

4-1. 名乗りではなく、証跡で語る

　「テニスサークルの主将でした」。「バイトリーダーでした」。

　この2つの文が、能力について何も言っていないことは、みなさん自身がよく知っているはずです。自分が採用担当だったらどう読むかを想像すれば、すぐに分かります。

　ただし、主将もバイトリーダーも、少なくとも誰かが任せたという事実はあります。選挙で選ばれたか、店長が指名したか、経緯はどうあれ、自分以外の誰かが関わっています。

　では、誰も任せていない名乗りは、どうでしょうか。「学生エンジニアです」は、役職ですらありません。自分で決めて、自分で書いた一語です。

　語るなら、やったことと、その証跡で語ってください。実績は自己申告でも成立しますが、証跡は自己申告では成立しません。リポジトリのURL、マージされたPull Requestの番号、登壇したイベントのプログラムページ、採録された論文誌の号。これらは、誰かが確かめられます。確かめられるから、証跡です。

　これは意見を述べるときも同じです。「〇〇は筋が悪いと思います」ではなく、「〇〇を使って△△を作ったとき、ここで詰まりました」。後者には証跡があります。

　同じことを言った人がいます。

　田中芳樹『銀河英雄伝説』第1巻「黎明篇」第八章「死線」。老提督アレクサンドル・ビュコックが、口のうまい若い士官に向けて言った言葉です。

　序章-1で、エンジニアはプロフェッションだとお話ししました。プロフェッションは、名乗るものではなく、引き受けるものです。そして序章-2で書いたとおり、日本ではエンジニアという名乗りに、資格や承認の関門がありません。入社した日から、誰でも名乗れます。

　肩書で大きく見せることと、プロフェッションを引き受けることは、別の問題です。そして厄介なことに、引き受けていないときほど、肩書に頼りたくなります。

4-2. 積んだ人にも、同じことが起きます

　ここまでは、まだ何も積んでいない人の話に見えたかもしれません。でも、この節がいちばん伝えたいのは、そこではありません。

　ポートフォリオが溜まってくると、見せたくなります。これは自然なことです。半年前には何もなかったのに、いまは並べられるものがある。誰かに知ってほしいと思うのは、当たり前の気持ちです。

　ただ、中学生が高価な服を着ても、服の価値は服のものです。着ている人のものにはなりません。

　差し出すのと、掲げるのは、違います。

• 差し出す：「これを作りました。見てもらえますか」。判断は相手に委ねている

• 掲げる：「これだけ作りました」。もう答えを決めていて、判断を委ねていない

　同じGitHubのURLでも、この2つは別のものです。差し出すのは対等で、掲げるのは対等ではありません。フェーズ3で扱う「双方のポートフォリオが対等に接続する」という形と、まったく同じ構造です。

　もうひとつ。数は、開かれた1本には勝てません。20本並べても、読む側が開いた1本のREADMEが薄ければ、そこで終わります。逆に言えば、差し出すものは1本でかまいません。

4-3. 肩書を書くな、ではありません

　この節で問うているのは、中身の量ではありません。飾ろうとしたか、差し出そうとしたか。その一点です。

　だから、肩書を書くなという話ではありません。バイトリーダーの経験なら、こう書けます。

　役職名は、状況を示す1行として括弧の中にあるだけです。あとは全部、行動と結果です。読む側が確かめられる形になっています。肩書を書くな、ではなく、肩書で止まるな、ということです。

　もうひとつ、はっきりさせておきます。事実の報告は、自慢ではありません。「JaSSTでLTしてきました」「初めてのPull Requestがマージされました」「ISUCONに出て、最下位でした」。こういう報告は、どんどん書いてください。主語がやったことであるうちは、飾りにはなりません。飾りになるのは、主語が自分への評価に変わったときです。「LTしてきました」と「LTするレベルの学生エンジニアです」の差が、そこにあります。

4-4. 迎える側は、その一語をどう読むか

　ここは序章-3の1-3で、正面から書きました。要点だけ引きます。その一語は能力を1文字も伝えないのに、プロフィールの先頭にある。だから読む側は、印象を作るために置かれたと読みます。そして、肩書で語るタイプだと判断されます。やることは、消すだけです。主催者が付けた名称（「学生エンジニア部門で入賞」など）は、第三者の目利きを経た実績なので、そのまま書いてかまいません。

　この記事で足すのは、その先です。消したあと、空いた場所に何を置くか。ここまでの3章で書いてきた、公開・質・第三者の目利きを通った証跡です。4-1の書き換え例を、もう一度見てください。肩書が消えた行には、読む側が確かめられる事実が入っています。名乗りを消すことと、証跡を増やすことは、同じ作業の裏表です。

　最後にひとつ。この失敗は、学生のものではありません。「俺は部長だぞ」。この言い方をする人に、社会に出ると何度も会います。役職で語る人は、40代にも50代にもいます。見分けるための物差しは、フェーズ4-2でお渡しします。そして同じ物差しが、相手にも自分にも向きます。

　信用されないのは、みなさんではありません。その一語です。

5. 束ねて、小さく始める

　他人が目利きした場所の話と、自分で貼るラベルの話。この2つを踏まえたうえで、最後に束ね方と始め方です。

　GitHubのリポジトリ、技術ブログ、スライド、登壇履歴、インターン先での成果物、コミュニティ運営のクレジット。これらがバラバラに散らばっている状態と、1つの入口ページに集約されている状態では、企業側の受け取り方が違います。集約の方法は、シンプルで構いません。静的な1枚のページでも、Notionの公開ページでも足ります。

　そのページに並べるのは、次の4つです。

• 自己紹介（技術的な関心事、いま学んでいること）

• 主要な成果物へのリンク（プロダクト、コード、技術ブログ、スライド、登壇履歴）

• 経歴（学業、インターン、コミュニティ活動、受賞歴）

• 各種サービスへのリンク（GitHub、Qiita、Zenn、Speaker Deck、Xなど）

　エントリーシートやレジュメの1行目に、このURLを書けるようにしておく。これが、このフェーズを通じて目指す姿です。

5-1. READMEを、実際に書き換えてみる

　条件2で挙げた6要素は、実際に書いてみるとイメージが変わります。よくある形と、書き換えた形を並べます。

　まず、よくある形。

　これを、6要素で書き換えると、こうなります。

　長く見えますが、1つの成果物につき10分あれば書けます。そして、この違いが書類選考で効きます。前者からは何も分かりません。後者からは、何に困っていて、何を選び、どこで詰まり、どう直したかが分かります。面接で聞かれたときに話す内容も、ここにもう書いてあります。

5-2. 今週できる、小さな第一歩

　強いポートフォリオを、いきなり完璧な形で作る必要はありません。小さな第一歩から始めて、各論を歩きながら、少しずつ育てていくのが自然です。

• GitHub のアカウントを作り、プロフィールREADMEを1つ書く：これだけで検索でヒットするようになります

• 技術記事の投稿サイトにアカウントを作り、直近で学んだことを1本記事にする：写経の記録でも、授業のレポートの要約でも、はじめの1本として意味を持ちます

• 既存のリポジトリを1つ選んで、READMEを6要素で書き直す：5-1の形です。1つ10分

• プロフィールを1つのページに集約する：静的なHTML1枚でも構いません

• アカウント名を揃える：GitHub、技術ブログ、SNSが同一人物と分かるようにする

　今週、この中から1つだけ、始めてみてください。その1歩が、各論すべてを歩く土台になります。

6. 公開と質と第三者の目利きを、会社の側も見ている

　最後に、ひとつ。これは会社を見るときにも、そのまま使えます。

　エンジニアが育つ環境を持つ会社は、多くの場合、会社自身が公開と質と第三者の目利きを実践しています。技術発信を長年続けている。社員のカンファレンス登壇を会社として支援している。OSS活動の時間を業務内で認めている。社内と社外の勉強会のスポンサーを続けている。社員の技術書の執筆や翻訳を後押ししている。

　みなさんが自分に課そうとしている基準を、その会社は自分に課しているか。ここは、はっきり書きます。公開も、質も、第三者の目利きも、学生には求めるのに、会社としては何ひとつ外に出していない。そういう会社が、実際にあります。学生には20時間かけて作ったものを出させて、自分たちは1本も出さない。非対称です。

　もちろん、受託中心で守秘義務の範囲が広い会社のように、出したくても出せない事情はあります。その場合でも、事情を説明できるかどうかは残ります。聞いたときに理由が返ってくる会社と、質問の意味が伝わらない会社があります。この見方は、フェーズ3「接続する」でそのまま使うことになります。

まとめ

　本記事では、「作る」の各論すべてを貫く共通軸として、強いポートフォリオの作り方をお話ししました。要点は次のとおりです。

　ポートフォリオは、自分が積み上げてきた学びと実践を公衆に対して開いておくという、プロフェッションとしての自然な態度です。強いポートフォリオの3つの条件は、公開されていること、見に来た人が意図を追えること、公開してよい質になっていることです。

　さらにもう一段深めるなら、第三者の目利きが働く場所に自分の名前が載ることを目指します。カンファレンス登壇、学会採録、OSS Contributors、書籍クレジット、コミュニティ運営、コンテスト入賞などがその場所です。

　その裏返しとして、自分で付けた名乗りの話もしました。語るなら、やったことと、その証跡で語ること。実績は自己申告でも成立しますが、証跡は自己申告では成立しません。中身がない人は肩書に頼り、中身が増えてきた人は思わず自慢したくなる。問われているのは中身の量ではなく、飾ろうとしたか、差し出そうとしたか、その一点です。

　バラバラの成果物は、1つのページに集約して束ねます。そして、5-2に小さな第一歩を5つ挙げました。今週、あの中から1つだけ始めてみてください。

　次のフェーズ2-3からフェーズ2-13まで、この土台の上に、実践各論11本を1本ずつ掘り下げていきます。学業、技術書、GitHub、ハッカソン、時間設計、技術ブログ、勉強会での発表、IT企業でのバイト、長期インターン、社外コミュニティ、大学における研究。

　それぞれの各論で、フェーズ2-1の「なぜ作るのか」と、本記事の「公開と質と第三者の目利き」が、繰り返し姿を見せます。

　そして、このフェーズの締めくくりのフェーズ2-14では、これらを点・線・面、そしてその先の立体という視座で束ね直します。

エンジニアの卵のみなさんへ、エール

　「公開する」ということに、必要以上に構えないでください。強いポートフォリオは、いきなり完璧な形で立ち上がるものではありません。小さな一歩を、公開してよい質で残す。それを、各論を歩きながら、少しずつ積み上げていく。この繰り返しの中で、あなたのポートフォリオは、自然に強くなっていきます。

　「まだ未熟なコードを世界に晒すのが恥ずかしい」「もっと勉強してからにしよう」。公開の前で止まる方に、私は何人も会ってきました。そのためらいは、自然な気持ちです。

　そのうえで、育てる側から見てきて言えることがあります。未熟なうちから公開の場に立った人ほど、その後の育ちが速い。他人の目に晒されることで、次に何を学ぶべきかが見え、他のエンジニアからの助言が届き、同じテーマに関心を持つ仲間と出会う。公開は、あなた一人の作業ではなく、世界のエンジニアたちとの対話の始まりです。

　4章で名乗りの話をしましたが、あれは発信を控えろという意味ではまったくありません。むしろ逆です。差し出す形でなら、いくらでも出してください。「これを作りました。見てもらえますか」。この一言がついていれば、それは飾りではなく、対話の始まりです。

　今週、なにか一つ、公開してみてください。それが、1歩目です。

　一緒に歩きましょう。ボン・ボヤージュ。素敵な旅を。

次の記事は、フェーズ2-3「学業で作ったものを残す。授業と卒業研究を、履歴書に書ける成果物に育てる」です。

この連載を読むにあたって

　事実の確認について。 法令・統計・制度の記述は、一次情報にあたって確認し、出典のリンクを各記事の末尾に置いています。それでも、誤りが混じっている可能性は、ゼロではありません。数字と法令は、リンク先の原典で確かめてから使ってください。確かめる手間ごと、この連載がお渡ししたいものです。

　調査の時点について。 記事中の法令・統計・制度は、2026年9月15日時点で確認したものです。法令は改正され、統計は毎年更新されます。読んでいる時点との差は、ご自身で埋めてください。

　生成AIの利用について。 この連載は、調査と推敲に生成AIを使っています。

　最後は、ご自身で判断してください。 就職活動は、みなさんの人生の大きな選択です。この連載がお渡しするのは、判断の物差しであって、判断そのものではありません。物差しを当てるのは、みなさん自身です。

　そして、一人で抱えないでください。 相談先があります。大学のキャリアセンター。新卒応援ハローワークは全国56か所にあり、すべて無料で、専任の就職支援ナビゲーターが担当者制でついてくれます。労働条件のことは、総合労働相談コーナー（都道府県労働局や労働基準監督署などに全国378か所）でも相談できます。

#エンジニア就活 #ポートフォリオの作り方 #公開 #セルフブランディング #就活生 #採用広報 #エンジニアの卵に贈る就活の書

関連記事・参考文献等

• 新卒ITエンジニア 新卒研修シラバス

• 新卒エンジニア、観察ノートを開く（上巻）　観察を、始める

• 新卒エンジニア、観察ノートを開く（中巻）　両輪を、回す

• 新卒エンジニア、観察ノートを開く（下巻）　道を、選び取る