学業で作ったものを残す。授業と卒業研究を、履歴書に書ける成果物に育てる【フェーズ2-3｜ITエンジニアの卵に贈る、就活の書】

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

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

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

　ITエンジニアの卵に贈る、就活の書・フェーズ2-3の記事です。前回のフェーズ2-2では、強いポートフォリオの作り方（公開と質、そして第三者の目利き）をお話ししました。今回はフェーズ2「作る」の実践各論11本のうちの1本目です。テーマは、学業で作ったものを、履歴書に書ける成果物に育てる、です。

　学業は、みなさんが学校生活で最も長い時間を割いている活動です。授業、レポート、演習、卒業研究や卒業制作。その膨大な時間から生み出されるものを、就活の場面でそのまま差し出せる形で残せるかどうか。ここは、エンジニアの卵にとって、大きな分岐点になります。

　なお、この記事では便宜上「授業」「卒業研究」という言い方をします。高専の特別研究も、専門学校の卒業制作も、まったく同じ扱いです。独学で情報系を学んでいる人は、自分で学んだ範囲を「授業」と読み替えてください。

この記事のポイント

• 学業と就活を対立させる必要はありません。授業と卒業研究そのものを、履歴書に書ける成果物として設計するのが、いちばん効率のよい道です。

• 卒業研究の欄を1〜2行で済ませるのは損です。テーマ、背景と目的、手法、成果物のURL、指導教員名で4〜6行を書き、面接で15〜20分語れる形にします。

• 成績はもう変えられなくても、成果物は今日から作れます。過去の成績表は、これから作るものの前提条件にはなりません。

1. なぜ、学業を実践各論の1本目に置いたか

　フェーズ2「作る」の実践各論を組み立てるとき、私は迷いなく学業を1本目に置きました。理由が3つあります。

　1つ目は、学業がすべての土台だからです。フェーズ2-1でお話ししたとおり、ソフトウェアエンジニアリングは、広い知識体系に支えられています。要求分析、設計、構築、テスト、アーキテクチャ、セキュリティ。どれも、独立した専門領域です。

　この体系の土台は、情報系の基礎科目にあります。データ構造、アルゴリズム、計算量、コンピュータアーキテクチャ、オペレーティングシステム、ネットワーク、データベース、離散数学、ソフトウェア工学。大学でも、高専でも、専門学校でも、名前は違っても似た内容を扱います。GitHubを育てるにも、技術ブログを書くにも、ハッカソンで戦うにも、この土台が効いてきます。

　2つ目は、学業で作ったものは、そのままポートフォリオになるからです。フェーズ2-2で扱った強いポートフォリオの3条件（公開されている、意図が追える、公開してよい質）を思い出してください。授業の課題、演習で書いたコード、卒業研究の実装は、少し手を入れれば、どれもこの3条件を満たす形で公開できます。

　3つ目は、学業と就活を対立させる必要がないからです。「就活のためにポートフォリオを作らなきゃいけない、でも授業も卒論も忙しい」。この二重の負荷に悩む学生さんを、よく見かけます。私からの提案は、その対立をやめよう、ということです。授業と卒業研究そのものを、履歴書に書ける成果物として設計する。これが、限られた学生時代の時間を、いちばん効率よく使う道です。

2. 学業を丁寧に見ている会社は、実際にある

　学業を丁寧にやり切った学生を、選考で正面から扱う会社は、実際にあります。

　フェーズ2-1で、募集要項や選考プロセスの実例をいくつか挙げました。情報系の基礎知識を応募資格や歓迎スキルとして明示する会社。コンピュータサイエンスや数学の問題を、書類選考のあとのコーディングテストで問う会社。学んだ内容そのものが、そのまま選考の入口になっている例です。

　これは、一部の会社だけの話ではありません。企業側の大きな流れとしても、同じ方向が示されています。経団連が2025年11月10日に公表した「労働移動の積極的な推進」実現に向けたアクションプラン。その「学修歴の活用」の項に、採用時における成績証明書・マイクロクレデンシャルの活用が挙げられています。マイクロクレデンシャル（microcredential）とは、学位より小さい単位の認定です。特定のスキルや知識を身につけたことを証明します。

　学修歴を、より正面から評価に取り入れていく。企業側から、そういう方向が示されている、ということです。

　ひとつ、先回りしておきます。この記事で「学業」と言うとき、それは情報系の学科にいることを指していません。情報系以外の学科から、あるいは独学からエンジニアを目指す人が不利になる、という話でもありません。その読み替え方は、7章で丁寧に扱います。

3. 授業を、履歴書に書ける成果物に育てる

　まず、授業からいきましょう。

　授業でやったことをそのまま提出して単位を取って終わり、というだけでは、履歴書には書けません。授業を成果物に育てるには、次のような一手間を加えます。

3-1. 演習・課題を、GitHubの Public リポジトリで残す

　情報系の授業では、演習として実装課題が出されます。ソート、探索、グラフ探索。DBMSやコンパイラの部分実装、OSのシステムコール、ネットワークプロトコルの実装、機械学習アルゴリズムのスクラッチ実装。授業の系統によって、内容は変わります。

　これらの課題を、GitHub の Public リポジトリに、READMEを整えて公開します。TypeScript、Python、Go、Rust などで書き直す形も、選択肢です。授業の言語がCやJavaでも、それをそのまま公開してもよいですし、後で書き直したバージョンを並列で公開してもよいです。

　READMEには、フェーズ2-2で紹介した6要素を、短くていいので添えます。背景と目的、使用技術、技術選定の理由、こだわりのポイント、直面した課題と解決策、今後の展望。この6つです。

　たとえば、こんな1文でかまいません。「授業の課題として実装した◯◯アルゴリズム。授業ではCで書いたが、TypeScriptでも書き直し、両者の計算量を比較した」。これが加わるだけで、単なる授業課題が、あなた自身の意図と学びを持つ成果物に変わります。

　GitHubアカウントの整え方、READMEの書き方、GitHub ActionsやDependabotの活用。こうした運用の細かな話は、フェーズ2-5に集約しています。あわせてお読みください。

3-2. 講義ノートを、技術ブログに再構成する

　授業で学んだ概念を、自分の言葉で技術記事に書き直す。これは、学業を成果物に変える最も強い方法の一つです。プラットフォームは、Qiita、Zenn、はてなブログ、Medium、独自ドメインの静的サイト。誰でも読める形で置ける場所なら、どこでもかまいません。

　「Bツリーとハッシュインデックスの使い分け」「TCP輻輳制御アルゴリズムの比較」「動的計画法の考え方を、実装例で丁寧に追う」。授業で扱った概念を、初めて学ぶ人にも読める形に書き直す。それだけで、あなた自身の理解が段違いに深まります。同時に、その記事は公開された成果物として残ります。

　演習レポートを、そのまま技術記事にする、という手もあります。レポートの内容はそのままに、読者を「授業の教員」から「同じ分野に興味を持つエンジニア」に想定し直して書き直します。図やコードスニペット、参考文献リンクを丁寧に整えると、成果物としての強度が一段上がります。

3-3. 授業で使ったコードを、モダンなツールで書き直す

　もう一段深い活かし方として、授業で書いたコードを、いま現場で使われているツールで書き直す、という取り組みがあります。

　たとえば、授業で書いた小さなCLIツールを、Rust で書き直す。授業で作った Web アプリを、Next.js + TypeScript + Vercel の構成で公開し直す。授業で組んだデータベースクエリを、PostgreSQL の実インスタンスに投げて、実行計画を EXPLAIN で読む。無料枠のあるサービス（Neon、Supabase など）で試せます。

　もう一手間として、演習コードに Jest や pytest でユニットテストを書き足すという選択肢もあります。ソフトウェアテストは、授業で深く扱われないことが多い分野です。演習の答え合わせをテストコードという形で残しておくと、README を読んだ人に、動くことの根拠を示せます。GitHub Actions で自動実行するところまで持っていければ、なお強い記録になります。

　こうした書き直しは、授業で得た概念的な理解を、実際の道具で動く形に落とし込む作業です。現場のエンジニアが、日々の仕事で自然にやっている思考の型でもあります。

4. 卒業研究を、履歴書に書ける成果物に育てる

　授業と並ぶ、あるいはそれ以上の重みを持つのが、卒業研究です。卒業研究は、多くの学生にとって、学生時代でいちばん長い時間、いちばん深い集中を注ぐプロジェクトです。これを履歴書に書ける成果物に育てないのは、あまりにもったいない。

4-1. 実装は、GitHubで公開する

　卒業研究の実装コードを、GitHubの Public リポジトリで公開します。ただし、公開してよいかどうかは、研究室によって違います。企業との共同研究や、未発表の成果を含む場合はとくにそうです。公開してよいか、いつから公開してよいかは、必ず指導教員に確認してください。

　README には、研究の背景、目的、手法、実装、実験結果、考察、今後の課題を、卒業論文の要旨をベースに整理します。論文のPDFへのリンク、実験データの一部（公開可能な範囲で）、再現手順、動作環境も添えます。

　技術スタックは、いま現場で使われているものを選ぶと、成果物の強度が上がります。機械学習系なら Python + PyTorch、Web系なら TypeScript + Next.js、というように。研究テーマに応じて、選択の幅は広く取れます。

　リポジトリをプロフィールREADMEでピン留めする方法、Releasesタグの打ち方、公開日の合わせ方。こうしたGitHubの運用の詳細は、フェーズ2-5にまとめています。

4-2. 学会・研究会で発表する

　卒業研究のもう一つの大きな出口が、学会や研究会での発表です。フェーズ2-2で扱った「第三者が目利きした場所に、あなたの名前が載る」の代表格が、学会での発表です。

　情報処理学会（IPSJ）、電子情報通信学会（IEICE）、人工知能学会（JSAI）。研究テーマに応じて、投稿先の学会は複数あります。

　学会と聞くと、修士や博士の世界に思えるかもしれません。実際には、研究会や全国大会には、学部生や高専生の発表を歓迎する場が用意されています。学生セッションやポスターセッションを設けている学会もあります。まずは指導教員に、「学生セッションに出せる内容でしょうか」と聞いてみるところからです。投稿の締切や参加費は学会ごとに違うので、公式サイトで確かめてください。

　発表の実績は、学会のプログラムや予稿集に、あなたの名前として残ります。これは、自分で公開した作品とは重みの違う、第三者が目を通した実績です。

　加えて、発表スライドを Speaker Deck や Docswell に公開しておく。それだけで、フェーズ2-2で扱った公開の3条件を満たす成果物が、もう1つ増えます。

　卒業研究は、卒論の提出だけで終わってしまうケースが多い、というのが私の実感です。ここでもう一歩だけ、学会・研究会の学生セッションやポスター発表に持ち込むという選択肢を、頭の隅に置いてみてください。この一歩で、卒業研究は、履歴書に一段強く書ける成果物に育ちます。

4-3. 研究の記録を、技術ブログにする

　卒業研究のプロセスを、技術ブログとして書き残すという方法もあります。研究の背景を短く整理した記事。実装で使ったライブラリの解説記事。実験でぶつかったデバッグの記録。研究1本から、複数の技術記事が生まれます。

　こうした記事の書き方は、フェーズ2-8「技術ブログで、学びを言語化する」で丁寧に扱います。ここでは、卒業研究は、技術ブログの豊かな素材でもあるということだけ、頭の隅に置いてください。

5. 成績表と、学修歴の意味

　もう一つ、避けずに触れておきたい話題があります。成績表です。

　2章で紹介した経団連のアクションプランには、成績証明書とマイクロクレデンシャルの活用が明記されています。学修歴が採用の場面で、より正面から評価されていく流れです。

　スキルそのものについては、厚生労働省の委託調査に、注目したい傾向が出ています。「IT・デジタル人材の労働市場に関する研究調査事業報告書」（令和5年度）です。最終学歴を問わず、ITスキルのレベルが高いほど、転職後に賃金が上がった人の割合が増える、という傾向です。

　つまり、賃金を動かしているのは、学歴そのものではなく、身についたスキルのほうだ、ということになります。学校の名前でも、成績の点数でもなく、身についたもの。これが、報告書の数字が示している方向です。

5-1. すでに成績が決まってしまった人へ

　ここまで読んで、「もう最終学年が近い。過去の成績は、いまさら変えられない」と思った人がいると思います。

　過去の成績は、たしかに変えられません。ですが、成果物は、今日から作れます。そして、書類選考でも面接でも、話せる量は成果物のほうが圧倒的に多い。成績表は点数しか語りませんが、成果物は、あなたが何を考えて何を選んだかを語ります。

　単位を落とした科目があっても、レポートを流した学期があっても、それはこれから作るものの前提条件にはなりません。残りの期間で、演習課題を1つGitHubに公開し、卒業研究をやり切る。それだけで、履歴書に書ける中身は変わります。

　そのうえで、これから履修する科目については、単位を落とさず、レポートを流さず、卒業研究に本気で向き合う。これは、就活のためだけではありません。エンジニアという専門職（プロフェッション）として生涯続く、知識体系の土台を築く行為です。

6. 卒業研究の欄を、1〜2行で終わらせない

　もう1つ、就活の場面での卒業研究の重みについて、正直な話をしておきます。多くの学生さんは、履歴書やエントリーシートの「卒業研究テーマ」の欄に、1〜2行だけタイトルを書いて済ませています。これは、非常にもったいない書き方です。

　卒業研究をきちんと読む会社の書類選考の担当者は、タイトルだけを手がかりに、次のような観点でその学生を読み解こうとします。ここから先は、私が採用の現場で見てきた実感です。

• 研究テーマの選び方：与えられたテーマをそのまま受け取ったか、自分で問いを立てて選んだか

• 研究の技術領域：応募先の業務との重なり、あるいは面接で対話できる素材があるか

• 手法の選び方：定番の手法を丁寧に運用したか、新しい手法に挑戦したか、複数の手法を比較したか

• 実装の深さ：手を動かした形跡があるか、既存ライブラリを組み合わせただけか

• 学会・研究会での発表実績：第三者の目利きを通したか

• 共同研究の姿：企業や他大学との共同研究に参加したか

　これらの観点への答えが、履歴書の1〜2行では、まったく伝わりません。卒業研究の欄には、少なくとも4〜6行分の情報を書き入れてください。目安として、次のような要素です。

• 研究テーマ（1行）

• 研究の背景と目的（1〜2行）

• 使用した手法・技術スタック（1行）

• 主要な成果と、それを示すGitHubリポジトリのURL・学会発表実績・技術ブログ記事へのリンク（1〜2行）

• 指導教員名と研究室名（1行）

　実際に書くと、こうなります。よくあるのは、この書き方です。

　これを、4〜6行にすると、こうなります。

　同じ研究でも、後者なら、面接官は「なぜその3手法を選んだのですか」と聞けます。前者では、何も聞けません。書類選考の担当者に、質問の入口を渡す。これが、4〜6行書く目的です。

　これに、面接では卒業研究について15〜20分は語れる準備をしておいてください。研究テーマの選定理由、手法の選択根拠、実装で詰まった箇所、実験の設計、結果の考察、次に発展させたい方向。これらを自分の言葉で語れる学生さんは、面接の場で強く評価されます。

　技術面接では、卒業研究の中身に踏み込んだ対話が展開されます。「なぜその手法を選んだのか」「他の手法と比べたときのトレードオフは」「実験の再現性はどう担保したのか」。この対話は、応募者が研究を通じて何を学び、それを実務でどう活かせるかを、面接官が測る場でもあります。フェーズ4-5の技術面接で扱う「対等な技術対話」の入口が、卒業研究の対話にあります。

7. 情報系以外から、エンジニアを目指す人へ

　2章で先回りした話を、ここで扱います。情報系ではない学部・学科・コースに所属していて、エンジニアを志望している人の話です。

　文学部、経済学部、法学部、社会学部、心理学部。工学部の他学科（機械、電気電子、化学、材料など）、農学部、医学・薬学・看護、教育学部。専門学校の非情報系コースも同じです。エンジニアを目指す人の中に、こうした情報系以外からの人は、確かにいます。私も、何人も会ってきました。

　情報系以外の学部からエンジニアを目指す道は、決して不利ではありません。むしろ、情報系だけでは得られない専門領域の知識を持ち込める、という強みがあります。

　金融の実務を理解している、経済学部出身のエンジニア。法律とプライバシー保護を理解している、法学部出身のエンジニア。ユーザー行動を理解している、心理学部・社会学部出身のエンジニア。医療の現場を知っている、医学・薬学・看護出身のエンジニア。フィンテック、リーガルテック、ヘルスケア、教育テック。特定の業務領域に深く踏み込む会社にとって、こうした人は貴重です。

　情報系以外の学部から就活を歩む場合、本記事の「学業を成果物に育てる」の実践は、次のように読み替えます。

• 自分の専門領域を、エンジニアリングの側から読み直す：経済学部の学生さんなら、計量経済学の実習で書いたコードをPythonで書き直し、GitHubに公開する。心理学部の学生さんなら、SPSSでやった実験データの解析を、Pythonのpandasで再実装する

• 卒業研究のテーマを、実装を含む形に設計する：文学部で言語学の研究をするなら、コーパス解析のスクリプトを自分で書く。社会学部で社会調査をするなら、データ収集と解析のツールを自分で作る。指導教員と相談して、研究の一部として実装を含める形が組めれば、卒業研究がそのままポートフォリオになります

• 自分の専門と情報系の交差点を、技術ブログで書き残す：「経済学部生がデータサイエンスを学び始めた記録」。情報系の学生さんには書けない、あなただけの記事になります

• 情報系の基礎科目を、自分で埋める：情報系の授業を副専攻や単位互換で取る。Coursera・edX・MITのOpenCourseWareで補う。放送大学の情報コースで学び直す

　情報系以外から就活を歩む人が不利になる場面は、実は多くありません。専門領域の知識と、情報系の基礎を自分で埋めた証拠。この2つを並べれば、書類選考の担当者に伝わります。2つの領域をまたげる学生を、意識的に採用している会社もあります。

　ただし、「情報系でなくても大丈夫です」という話ではありません。情報系の学生が4年かけて授業で通る範囲を、授業の外で自分で埋めるのですから、必要な時間はむしろ増えます。上に挙げた4つ目、基礎科目を自分で埋める作業が、いちばん重い。そこを飛ばして専門領域の話だけを持っていくと、技術面接で止まります。楽な道として選ばないでください。強いのは、両方を持っている場合だけです。

8. 学業の重みが分かる会社は、どこに表れるか

　ここで、会社の側の話をします。学業で積み上げたものを、どう受け止める会社なのか。

　学び続ける環境を持つ会社は、学生時代の学業と研究の重みを、正面から受け止めていることが多い、と感じます。たとえば、こんな形で表れます。

• 学会発表の実績を、募集要項の加点要素として明示している

• 大学院進学者を、積極的に採用している

• 社会人になってからの学び直しを、制度として支援している

• 社員がカンファレンスや学会に登壇するのを、業務として支援している

• オウンドメディアで、社員が学術的な知見と実務をつなぐ記事を書いている

　学業と研究への向き合い方が、いちばん短く出るのは、面接で卒業研究の話に入ったときの、相手の顔です。手法の話に踏み込んでくるか、「なるほど」で終わるか。4年かけたものを2分で流されるか、15分聞かれるか。ここは、募集要項を10回読むより早く分かります。

8-1. 提出させることと、読むことは、別の話です

　もう一つ、選考の過程で観測できることがあります。成績証明書の提出を求めることと、それを読むことは、別の話です。次の4つは、みなさんが選考のなかで確かめられます。

• 「成績証明書を提出してください」と求められたのに、面接で成績の中身にも卒業研究にも、一度も触れられなかった

• 卒業研究について聞かれたが、質問が「テーマは何ですか」で終わり、手法にも結果にも入らなかった

• エントリーシートに研究室名や指導教員名を書く欄があるのに、その分野の話ができる面接官が、最後まで出てこなかった

• 「学部・学科は問いません」と書いてありながら、選考では情報系の基礎知識だけを問う筆記が出る

　これらが重なっているなら、成績証明書は提出を求める慣行として残っているだけで、読む担当がまだ決まっていない、と考えるのが自然です。

　これは、時間の計算の話でもあります。1通の成績証明書を開いて、履修科目とその会社の業務を突き合わせる。ここに10分から20分かかります。100人が応募すれば、20時間から30時間。「念のため出させておく」だけなら、0分で済みます。

　だから、みなさんが学業を丁寧に積み上げたことは、読む会社では確実に効きます。読まない会社では、効きません。そして、効かなかったとしても、積み上げたものの値打ちが減るわけではありません。次の会社では効きます。

9. 履歴書に書けるようになる、具体的な形

　ここまでの話を、履歴書に書ける形に落とし込むと、次のような1行になります。

• 「大学の情報系カリキュラムで、データ構造、アルゴリズム、OS、DB、ネットワークを履修。演習で実装したBツリーインデックスを、TypeScriptで再実装した成果物をGitHubで公開（URL）」

• 「卒業研究として、◯◯手法の改良を実装。情報処理学会全国大会の学生セッションでポスター発表。実装コードはGitHubで公開（URL）、発表スライドはSpeaker Deckで公開（URL）」

• 「機械学習の授業課題として、Transformer をPyTorchでスクラッチ実装。Attention の可視化を含めた技術記事をZennで公開（URL）」

　授業や研究の内容を、そのまま埋もれさせない。少しの一手間で、公開された成果物として履歴書に書ける形にする。それが、本記事の中心的な提案です。

まとめ

　本記事では、学業で作ったものを、履歴書に書ける成果物に育てるお話をしました。要点は次のとおりです。

　学業は、フェーズ2「作る」の1本目です。情報系の基礎は、他のすべての各論の土台になります。

　授業を成果物に育てる方法は、3つ挙げました。演習や課題をGitHub Publicで残す。講義ノートを技術ブログに再構成する。現場で使われるツールで書き直す。卒業研究についても、3つです。実装をGitHubで公開する。学会や研究会の学生セッションで発表する。研究プロセスを技術ブログにする。

　成績と学修歴も軽視できません。経団連は、成績証明書の活用をアクションに掲げています。厚労省の調査が示しているのは、学歴そのものではなく、身についたスキルのほうが効くという傾向です。そして、成績はもう変えられなくても、成果物は今日から作れます。

　次のフェーズ2-4では、この学業の土台をさらに広げる話として、技術書を、血肉にするというお話をします。読んで、作って、書き残す3拍子で身につけていく、という内容です。

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

　学業と就活の間で板挟みになる感覚を持つ学生さんが、たくさんいます。その対立は、いったん解いてしまってかまいません。学業の時間は、就活とは別の時間ではなく、就活で差し出せるものを作っている時間そのものです。

　学生時代の授業で扱う概念は、社会人になっても、そのまま実務で顔を出します。BツリーもTCP輻輳制御も動的計画法も、あの日の授業で会った顔と同じ顔で、いまも目の前に現れます。もっと丁寧にやり切っておけばよかった、と何度も思い返しました。

　今週、なにか一つ、始めてみてください。今学期の演習課題を、READMEを添えてGitHubに1つ公開する。授業で学んだ概念を、Zennに1本記事にする。卒業研究の学生セッション投稿を、指導教員に相談してみる。どれか1つで、本記事の1歩目です。過去の成績が何点だったかは、この1歩とは関係がありません。

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

次の記事は、フェーズ2-4「技術書を、血肉にする。読んで、作って、書き残す3拍子で身につける」です。

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

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

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

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

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

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

#エンジニア就活 #卒業研究 #授業 #学業 #大学生 #産学連携 #エンジニアの卵に贈る就活の書

関連記事・参考文献等

本記事で引用した統計・法令・規範

• 「労働移動の積極的な推進」実現に向けたアクションプラン（日本経済団体連合会）

• IT・デジタル人材の労働市場に関する研究調査事業報告書（厚生労働省）

シリーズ関連

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

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

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

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