履歴書・職務経歴書のポイント

IT 未経験から就職を目指すとき、応募書類で最初に悩むのが「何を、どこに書くか」です。この記事では、履歴書と職務経歴書の役割の違いを整理したうえで、前職の職務経歴、個人開発、GitHub、資格、学習履歴の書き方の判断材料をまとめます。時間をかける順で言うと、書き直す価値が一番大きいのは前職の欄です。職歴がまだない場合、説明のいる空白がある場合は 書ける職歴がないとき、何を積むか を先に読んでください。

扱うのは中途採用の応募書類です。既卒や第二新卒も含みます。在学中で新卒採用のエントリーシートを書く場合は、様式も評価される項目も別になります。

履歴書と職務経歴書は何が違うか

応募書類には大きく2種類あります。

履歴書 は、氏名、連絡先、学歴、職歴、免許・資格、志望動機などの基本情報をまとめる書類です。厚生労働省が公表している履歴書様式例がベースになっています。

職務経歴書 は、経験、スキル、強みの詳細を伝えるための書類です。履歴書と違い、形式が自由なので、書く内容や構成を自分で組み立てます。

公的な整理で見ると、次のように役割が分かれます。

未経験から IT を目指す場合、履歴書だけでは伝えきれない情報が多くなります。個人開発で何を作ったか、どんな技術を使ったか、GitHub にどんなコードがあるかは、職務経歴書側で補う方が整理しやすいです。

厚生労働省は 2021 年に履歴書様式例を改訂し、性別欄を任意記載にするなどの変更を行いました。応募先から指定がなければ、この様式例を参考にするのが無難です。

未経験 IT 志望者が書く内容の全体像

履歴書と職務経歴書で書く内容をざっくり分けると、次のようになります。

履歴書に書くもの

• 氏名、連絡先、学歴、職歴
• 取得済みの免許・資格
• 志望動機（短くまとめる）

職務経歴書に書くもの

• 前職の業務内容（IT 以外でも書く）
• 個人開発・制作物の概要
• 使用技術、担当範囲
• GitHub や成果物の確認先
• 学習履歴の要約
• 自己 PR

この中で分量も手間も一番かかるのが前職の業務内容です。IT の実務経験がない場合でも省略せず、むしろここを中心に据えます。書き方は次の節にまとめます。個人開発と学習の成果は、そのあとに別の節として置くと読みやすくなります。

前職の職務経歴をどう書くか

職歴がまだない場合、または職歴に説明のいる空白がある場合は、この節の前半がそのままは使えません。何を積むか、職歴欄に何を書くかは 書ける職歴がないとき、何を積むか にまとめています。先にそちらを読んでください。

未経験の応募書類で、書き直して一番差が出るのは前職の欄です。個人開発や資格より先に、ここに時間を使います。

以下は採用データではなく、未経験枠の選考が育成を前提にしていること、応募者が多く絞り込みが減点法になること、業務システムが、それが扱う業務の上に作られることから導いた推論です。当てはまり方には応募先ごとに幅があります。

未経験採用は育成を前提にした枠なので、入社時点のプログラミング能力で順位が決まるわけではありません。一方で応募者は多く、読み手は限られた時間で候補を絞ります。そこで手がかりになるのは、仕事の場で何かを任され、成立させた記録があるかどうかです。IT の実務経験がない応募者にとって、その記録があるのは前職の欄だけです。

学習が不要という話ではありません。学習の記録は「この分野を本当にやる気があるのか」を確かめる材料として読まれます。書くものが何もない状態では話が始まりませんが、そこを超えて積み増しても、前職の欄ほど大きくは動きません。「もっと勉強してから応募する」と後ろにずらし続けるより、超えた分の時間を前職の言語化に回すほうが、書類全体としては強くなります。どこまで来たら学習側は十分かは どこまで学べば応募していいか にまとめています。

業務の一覧にしない

前職の欄でよくあるのが、担当していた業務を並べただけの書き方です。

• レジ業務、品出し、接客を担当

これは「何をしていたか」の説明であって、「何ができる人か」は伝わりません。同じ職場の同じ役割の人が、全員この一文になります。書き分けたいのは次の 3 点です。

• 担当範囲: 何を任されていたか。人数、件数、金額など、規模が言えるとなお良い
• 自分で判断して動いたこと: 指示された作業ではなく、自分で問題を見つけて手を打った部分
• 結果: それで何が変わったか。数字が出せなければ、変わった状態を書く

3 点目が書けない場合は、2 点目が「指示されたことをやった」で止まっていることが多いです。別の場面を探すと見つかることがあります。それでも結果が言えないなら、担当範囲と自分の判断の 2 点だけで書いてかまいません。書けない結果を作るよりは、2 点で止めるほうが安全です。

書類の言葉に翻訳する

3 点の形に直すと、同じ経験でも見え方が変わります。IT と無関係な職種でも成り立ちます。

次の 3 件は、書き方の形を見るための例です。自分が実際にやったことに置き換えてください。 記録していない件数や、確認できない結果は書きません。後半の「書類そのものと食い違う書き方」のとおり、確かめられない数字は、書いた本人の信頼のほうを削ります。

小売（店舗スタッフ）

• 前: レジ業務、品出し、接客を担当
• 後: 担当売場の発注を任され、欠品の多かった商品の発注点を見直して、月あたりの欠品件数を減らした

製造（ライン作業・検査）

• 前: 製品の組立および検査を担当
• 後: 新人への引き継ぎが口頭のみで作業のばらつきが出ていたため、工程を写真つきの手順書にまとめ、以降の教育に使われた

介護（施設職員）

• 前: 入居者様の介護業務全般
• 後: 申し送りの記入漏れが続いていたため、記録のフォーマットを項目式に変えて統一し、夜勤帯への引き継ぎ漏れが減った

後者はどれも、担当範囲・自分の判断・結果の順で並んでいます。前職での役職や業界の知名度は関係ありません。任された範囲で自分から動かした部分が見えるかどうかで、同じ経験の見え方が変わります。

前職で回していた業務を、応募先が扱っているなら効く

上の 3 点は、応募先がどこでも成り立つ書き方です。それとは別に、応募先が作っているシステムが、自分の前職で回していた業務を扱っている場合だけ効く材料があります。業務そのものを知っていることです。効くのは会社の知名度でも業界の一致でもなく、その業務を担当していたかどうかのほうです。同じ業界にいても、職種が違えば届きません。

作るものによって、前提になる業務知識は決まっています。

書くのは「何をしていたか」に加えて、その業務の何が分かるかです。

• 前: 賃貸物件の仲介業務を担当
• 後: 賃貸仲介として、申込から契約、更新、解約までの手続きを担当。重要事項説明の記載事項と、更新時に発生する事務を把握している

後者は、賃貸管理システムを作っている会社が読むと、説明しなくても通じる範囲が分かります。

この材料には適用条件があります。 応募先が作るシステムが、自分の回していた業務を扱っていなければ、書いても読み手の判断材料になりません。3 点の形はどこでも効くので、そちらを先に書き、業務知識は応募先が合ったときに足してください。求人票から何を作っている会社かを読む方法は 求人票のどこを読むか にまとめています。

「書きすぎない」との関係

前職を長く書くと IT への志向が伝わらない、という注意を目にすることがあります。問題は分量そのものではなく、応募先に伝わる形になっているかどうかです。上の 3 点で書かれた前職の欄は、長くても読み手の判断材料になります。逆に、業務の一覧をそのまま長く書くと、判断できない情報が積み上がります。

削る対象は、応募先に置き換えて読めない部分です。業界特有の手順の細部、扱っていた商品名の列挙、社内でしか通じない略称などが該当します。

職歴欄に書けるものがないとき

職歴がない場合や、説明のいる空白がある場合も、職歴欄を空白のままにはしません。職業訓練の受講歴、空白期間の一行説明、日付の残る学習の記録が書けます。

ただしこれらは、前職の実績の代わりになるものではありません。答えている問いが違い、こちらは「その期間に何をしていたか」を説明する材料です。

書き方と、記録の作り方は 書ける職歴がないとき、何を積むか にまとめています。この節の続きはそちらにあります。

個人開発・制作物の書き方

職務経歴書に個人開発の節を設けるのは自然な構成です。ただし、個人開発を企業での実務と同じように書くのは避けます。あくまで「個人開発」「学習成果」として区別して記載します。

書くときに意識したいのは、「何を学んだか」よりも「何を作ったか」を中心にすることです。

弱くなりやすい書き方

• Java を学習しました
• Spring Boot を勉強しました

伝わりやすい書き方の方向

• ToDo 管理 API を Java + Spring Boot で作成し、CRUD 操作と入力チェックを実装した
• 問い合わせフォームを HTML / JavaScript / Java サーブレットで作成し、DB への保存を実装した

1件ごとに、次の項目を書くと整理しやすいです。

• 制作物の名前と概要: 何を作ったか
• 使用技術: Java、Spring Boot、HTML、SQL など
• 担当範囲: API 設計、画面、DB 設計、テストなど
• 期間: おおよその制作期間
• 確認方法: GitHub の URL やデモ画面の有無

GitHub の載せ方

GitHub の URL を書類に載せるとき、URL だけを書いて終わりにすると、相手が何を見ればよいか分かりません。「どのリポジトリの、何を見てほしいか」をセットで書くことで伝わりやすくなります。

職務経歴書の個人開発欄で、制作物の説明と一緒に GitHub の URL を載せるのが自然な形です。履歴書側では、志望動機欄で IT 志望の理由と制作物に短く触れ、詳細は職務経歴書に記載している旨を添える程度で十分です。

GitHub のリポジトリを見せる前に、次の点を確認しておくと印象が変わります。

• README が整備されているか: プロジェクトの概要、セットアップ手順、主な機能が書かれていると、相手は開かずに判断できます
• 動く状態になっているか: ビルドが通らない、起動しないリポジトリは逆効果になりかねません
• 秘密情報が含まれていないか: パスワード、API キー、DB の接続情報がコードに残っていないか確認します
• コミット履歴が残っているか: 作業の過程が見えると、学習の進め方が伝わります

Java / Spring Boot の学習者なら、API の作成、画面の実装、DB 設計、テスト、README の整備といった項目のうち、どこまでできたかを具体的に書けると強みになります。

資格欄の整理

取得済みの資格は、正式名称と取得年月を正確に書きます。

資格欄で注意したいのは、次の 3 点です。

• 応募職種と関連の薄い資格を大量に並べない: 読む側が要点をつかみにくくなります。IT 職種に応募するなら、IT 関連の資格を先に並べ、それ以外は代表的なものに絞る方が読みやすいです。ただし、応募先が作るシステムの扱う業務と重なる資格（簿記、宅地建物取引士など）は、ここでいう「関連の薄い資格」に当たりません。落とさずに残します（未経験からまず目指すIT資格 の「資格が置き換えないもの」）
• 未取得の資格で欄を水増ししない: 受験予定や学習中の内容は、資格欄ではなく自己 PR 欄や学習履歴で補足する方が整理しやすいです
• 経歴から浮いて見える資格には、理由を一行添える: 応募職種と直接つながらない資格や、経歴に対して高度に見える資格は、書いた理由がないままだと読み手の推測で埋められます。なぜその時間を使ったのかを一行足すだけで扱いが変わります

資格の有無だけで評価が決まるわけではありません。資格をどう位置づけて、どこまで取るかの判断は 未経験からまず目指すIT資格 にまとめています。

自己 PR 欄の使い方

自己 PR 欄は、応募職種に関係する強みを短くまとめる欄として使います。長い経歴説明や学習の全記録を書く場所ではなく、職務経歴書の中で一番凝縮したメッセージを置く場所です。

未経験 IT 志望の場合、次のような「行動の証拠がある強み」に寄せると説得力が出やすいです。

• 学習を継続している事実（期間と内容）
• 制作物を公開している事実（GitHub の URL や成果物）
• エラーや不具合に対して自分で調べて対処した経験
• 前職で培った、IT にも通じるスキル（手順書作成、改善提案、顧客対応など）

「何を学んだか」だけでなく「何を作り、どう改善し、何を確認したか」を軸にすると、抽象的になりにくいです。

個人開発や GitHub の詳細は自己 PR 欄で長く書かず、職務経歴書の個人開発欄に回す方が役割分担しやすくなります。

学習履歴の見せ方

学習履歴を書くとき、サービス名や教材名の列挙だけで終わると、相手は内容を判断できません。次の項目を対応づけると使いやすい形になります。

• 学習テーマ: Java の基本文法、Spring Boot での Web アプリ開発、SQL の基本操作など
• 使用技術: 具体的な言語、フレームワーク、ツール
• 成果物: 何を作ったか、どこで確認できるか
• 期間: いつからいつまで学習したか

たとえば、次のような整理ができます。

2025年10月〜2026年3月: Java + Spring Boot で ToDo 管理 Web アプリを個人開発。CRUD 操作、入力チェック、ログイン機能を実装。GitHub で公開。

「コードを読めて、少し直せて、動作確認できて、GitHub に残せる」という粒度まで落とし込めていると、学習の深さが伝わりやすくなります。

避けたい書き方

応募書類でありがちな、伝わりにくい書き方の傾向を挙げます。

誇張する書き方

• 個人開発を「プロジェクトリーダーとして開発を主導」のように書く
• 学習中の技術を「実務レベルで使いこなせる」と表現する

個人開発は個人開発として正直に書いた方が、信頼感につながります。

書類そのものと食い違う書き方

職務経歴書は、経歴を伝える文書であると同時に、その経歴が本当かを読み手が確かめられる唯一のサンプルでもあります。書いた内容と現物がずれたとき、疑われるのは現物ではなく、書いた内容の方です。

• 「編集の仕事をしていた」→ 書類に誤字脱字がある
• 「正確さを重視してきた」→ 日付や社名の表記がばらばら
• 「学習を継続してきました」→ GitHub のコミット履歴が数日で途切れている

痛いのは、書かなければ減点されなかった点です。誤字が数個あるだけなら「粗い」で済みますが、「編集経験あり」と書いた瞬間に「経歴の方が怪しい」に変わります。何かを主張することは、それを検証される状態に自分を置くことでもあります。

直し方は 2 つあります。書類を直して主張に追いつかせるか、主張の方を下ろすかです。時間が限られているなら、下ろす方が安く済みます。「几帳面」と書かなければ、多少の表記ゆれは矛盾になりません。逆に、書いたなら直します。自己 PR 欄に置く強みは、その書類自体で示せるものに絞ると、この食い違いが起きにくくなります。

情報が足りない書き方

• 「Java を使った開発経験あり」だけで、何を作ったか書かない
• GitHub の URL だけを載せて、どのリポジトリを見ればよいか示さない

具体的な制作物や技術の詳細がないと、読み手は判断材料を持てません。

応募先と関連が薄い情報

• IT 職種の応募で、IT と関係のない資格を多数並べる（応募先が扱う業務と重なるものは除く。前の節を参照）
• 前職の業務を、その職場の中でしか通じない言葉のまま書く

前職の経験は削りません。「前職の職務経歴をどう書くか」の 3 点の形に直すと、応募先の読み手にも判断できる情報になります。

公正な採用選考の観点から

厚生労働省は、応募者の基本的人権を尊重し、適性・能力に基づいて選考を行うことを公正な採用選考の基本としています。本籍や家族の状況など、職務遂行に関係しない情報は書く必要がありません。書類に書く内容は、職務に関係する情報に寄せるのが基本です。

ハローワーク・マイジョブ・カードを整理に使う

応募書類をいきなり書き始めると、何を書くか迷いやすくなります。書く前の自己整理に使えるのが、ハローワークの相談支援とマイジョブ・カードです。

ハローワークの支援

ハローワークでは、応募書類の書き方について個別相談やセミナーを受けられます。求人内容に合わせた書き方の助言も受けられるため、応募先が決まってからの相談にも対応しています。

マイジョブ・カード

マイジョブ・カードは、厚生労働省が推進するジョブ・カードをオンラインで作成・管理できるサービスです。次のシートが用意されています。

• 職務経歴シート: 過去の業務内容を整理する
• 免許・資格シート: 取得済みの資格を一覧にする
• 学習歴・訓練歴シート: 学習内容と訓練歴を記録する

就業経験のない方向けの様式や活用ガイドもあるため、IT 未経験でも使えます。ジョブ・カードは自己整理のツールとして使い、整理した内容をもとに履歴書と職務経歴書を書くという流れが効率的です。

厚生労働省はジョブ・カードを「生涯を通じたキャリア・プランニング」および「職業能力証明」のツールと位置づけています。応募書類活用リーフレットも公開されており、ジョブ・カードの内容を応募書類に反映する方法が案内されています。

まとめと次のステップ

この記事のポイントを振り返ります。

• 履歴書は基本情報、職務経歴書は詳細を伝える書類。役割が違う
• 前職の職務経歴に一番時間を使う。業務の一覧ではなく「担当範囲・自分で判断したこと・結果」で書く
• 応募先が作るシステムが、前職で回していた業務を扱っているなら、業務知識そのものが材料になる。重ならなければ出番はない
• 個人開発は「何を作ったか」を中心に、企業実務と区別して書く
• GitHub は URL だけでなく、何を見てほしいかをセットで書く
• 資格は正式名称と取得年月を正確に。学習中の内容は自己 PR や学習履歴で補足する
• 自己 PR は、その書類自体で示せる強みに絞る
• 学習履歴はサービス名の列挙ではなく、成果物と対応づける
• ハローワークやマイジョブ・カードは、書く前の整理に使える

応募書類は一度で完成させるものではなく、学習や制作が進むたびに更新していくものです。最初に手をつけるなら前職の欄で、上の 3 点の形に直すところから始めると、書ける内容が一番増えます。職歴欄に書けるものがない場合は、書ける職歴がないとき、何を積むか から始めてください。手が止まったら、マイジョブ・カードや手元のメモで前職の棚卸しをするのが現実的な進め方です。