職務経歴書を書こうとして、製品名と担当期間だけが並んでしまうことはありませんか。採用側が知りたいのは、その環境で自分が何を担当し、どこまで判断・実施したかです。
この記事では、職務要約、案件、スキル、自己PRの役割を分けます。私が未経験で応募したときと、ネットワークエンジニアとして働いたときの例も、担当の範囲が伝わる書き方へ整理します。
要約・案件・スキル・自己PRで、書くものを分ける
要約は主な経験と希望する担当を短く伝える欄です。案件欄では仕事の目的と自分の担当、スキル欄では扱った技術と経験の種類、自己PRでは応募先で使える行動を説明します。
同じ製品名を各欄で繰り返すより、それぞれの欄で相手に何を伝えるかを決めます。提出先の指定様式があれば、その項目へ合わせてください。
| 欄 | 書く内容 | 避けたい書き方 |
|---|---|---|
| 職務要約 | 主な領域、担当、強み、次に希望する仕事 | 時系列を全部繰り返す |
| 職務経歴・案件 | 対象、工程、役割、作業、成果物、結果 | チームの仕事と自分の仕事が混ざる |
| スキル・資格 | 何を実務・検証・学習で行ったか | 製品名だけを並べる |
| 自己PR | 一つの行動と、応募先で再現する強み | 性格や熱意だけを説明する |
まず直近の案件を一つ書き、その内容から要約を作ると、抽象的な強みだけになりにくくなります。
未経験の応募でも、前職の実際の作業を探す
私が30歳・業界未経験で応募したとき、前職にはWEB制作会社、薬局の広報部でのWEBマーケティング、副業のアフィリエイトの経験がありました。インフラの専任職ではありませんでした。
当時の仕事の多くはIllustratorやWordPressでしたが、レンタルサーバーの管理サポート、ドメインやDNSの設定、不具合への対応など、実際に行った作業を整理しました。
| 前職の仕事 | 書類で前に出した内容 |
|---|---|
| レンタルサーバーの管理サポート | ドメイン設置、DNS設定、コマンドでのSSL設置、qmailの不具合対応 |
| 顧客システムのPHP修正 | 実施した内容とブランクを明記 |
| WEB制作・SEO・アクセス解析 | ITに近い仕事として、担当した範囲を記載 |
| 販促物・撮影・SNS | 事実として残し、応募先に関係する作業の後へ配置 |
| 当時の書き方 | 今なら加える内容 |
|---|---|
| 貢献したいという熱意が中心 | 前職で行った作業と、入社後に使える行動 |
| ブランクの長さを強調 | 不足を認識したうえで、何を学び直し検証したか |
| 一から学びたいと記載 | すでに進めた学習、失敗、確認した結果 |
この書類で二社へ応募し、二社目で内定が出ました。具体的なサーバー作業が役立ったのではないか、というのは私自身の振り返りです。採用理由を断定するものではありません。
今なら熱意だけでなく、行った作業と現在の学習も書きます。IT実務がない方も、記録、調整、手順遵守、異常報告など、前職で実際に取った行動を探してみてください。
担当工程のチェックと、自分の判断は分ける
私が2020年4月から2022年8月までSI企業で働いた案件には、印刷会社の設定変更、金融機関の更改、オフィスの新設・移設などがありました。同じネットワークの仕事でも担当は違います。
印刷会社ではパラメータ修正、config作成、ポート、VLAN、経路、ACLの変更を担当しました。ただし、変更内容を決めたのは自分ではありません。リーダーの指示のもとで実施した範囲として書きます。
| 案件 | 担当工程 | 自分と他担当の分担 |
|---|---|---|
| 印刷会社のネットワーク設定変更 | 詳細設計、構築・設定 | リーダーの指示のもとで実装。変更内容の調整は他担当者 |
| 金融機関のネットワーク更改 | 要件定義、基本設計、詳細設計、構築・設定 | 検証担当から入り、構築展開ではPLとして工程管理と顧客対応。運用設計は別チーム |
| グループ企業のオフィスネットワーク | 要件定義、基本設計、詳細設計、構築・設定 | PLとして要件確認、提案、ベンダー見積・発注、構築管理。管理とレビューが中心 |
金融機関の更改はISDNからデータコネクトへの移行で、運用設計は担当していません。オフィスの案件では本社・営業所の新設や移設に伴う調整もあり、設定操作だけが主担当ではありませんでした。
案件全体が設計から運用まで含む場合も、自分が担当した工程だけを示します。兼務の期間は重複して経験年数へ足さないようにしましょう。
案件には、対象・役割・作業・成果物を書く
案件の目的と体制を書いたら、自分が調べたこと、作ったもの、変更したこと、確認したことを続けます。「Ciscoの運用」だけより、どの状態をどの方法で確認したかが分かる書き方にします。
商用の実務、研修、個人検証、学習は分けます。製品を触った経験だけで、設計や障害対応を担当した意味にしないようにします。
| 項目 | 記入するもの |
|---|---|
| 期間 | 年月、兼務、担当した段階 |
| 概要 | 業界、用途、変更や構築の目的 |
| 規模・体制 | 確認できる台数や対象範囲、人数、役割 |
| 技術環境 | 機器、OS、サービス、管理ツール |
| 担当工程 | 監視、調査、変更、構築、試験、設計など |
| 業務・成果物 | 自分が行った作業と作成・更新した資料 |
| 結果 | 何を確認して完了とし、何が改善したか |
| 伝わりにくい記載 | 具体化した書き方の例 |
|---|---|
| Ciscoの運用保守 | リンク・VLAN・経路を確認し、影響と出力を整理して上位担当へ連携 |
| Linuxの構築 | 設計済みの値でOSとWebサービスを設定し、手順修正、試験、証跡取得を担当 |
| AWSを使用 | 監視設定を調査し、変更案と試験を作成。レビュー後の適用・通知確認を担当 |
| Terraform経験 | 既存コードの修正、planの差分確認、レビュー反映を担当。新規設計は未経験 |
表の書き方は例なので、自分が行った作業へ置き換えます。未経験の作業を加える必要はありません。担当した範囲を具体化するほうが、面接で説明しやすくなります。
顧客名や内部システム名を出せない場合は、業界、用途、工程で説明します。内部IPや認証情報を載せなくても、自分の役割は言葉で伝えられます。
結果と自己PRは、確認できる行動から書く
結果は売上の数字だけではありません。手順に中止条件を加えた、台帳と実機の差を直した、改善案が採用されたなど、確認できる変化を書けます。
時間や件数を使うなら、対象、期間、計測条件、自分の寄与を説明できるものにします。チーム全体の成果を、自分一人の実績として書かないようにします。
- 冒頭で主な領域と担当が分かる。
- 各案件に自分の役割、作業、成果物、結果がある。
- 担当した工程だけを示し、判断者を区別している。
- 実務・個人検証・学習を分けている。
- 数字、年月、兼務、取得資格を事実と照合した。
- 顧客の秘密情報、内部IP、認証情報を含めていない。
- 応募先が求める仕事との一致を前半で確認できる。
- 面接で各項目を自分の言葉で説明できる。
自己PRも「責任感があります」だけでなく、事実と仮説を分けて報告した、変更前後を同じ条件で確認した、といった一つの行動を使います。その行動を応募先でどう使うかへつなげます。
直近の案件を、対象・担当・成果物・結果の四行へ書いてみてください。そこから書類を整え、面接でも同じ経験を説明できるようにしましょう。
確認に使った公式資料
