セキュリティエンジニアの職務経歴書｜インフラ経験の書き換え例文とスキルシートの作り方

セキュリティ転職の書類で落ちる人の多くは、経験が足りないのではなく、経験が「インフラの言葉」のまま書かれているだけです。

「インフラエンジニアからセキュリティ職へ」で「業務のセキュリティ翻訳」と呼んだ作業を、この記事では例文レベルまで具体化します。コピペして自分の経験に合わせて書き換えられる形にしてあります。

大原則: 嘘は書かない。視点を変える

翻訳とは、盛ることではありません。同じ事実を「セキュリティ管理の構成要素」として言い直すことです。あなたがやってきた運用業務は、情報セキュリティ管理の教科書に載っている統制活動そのものです。それを教科書側の言葉で書く。それだけです。

翻訳例文10選

元の書き方(インフラの言葉)	翻訳後(セキュリティの言葉)
サーバーのパッチ適用を担当	脆弱性情報の収集・影響評価とパッチマネジメントプロセスの運用
アカウントの作成・削除	入退社に伴うアカウントライフサイクル管理、最小権限の原則に基づくアクセス制御
ファイアウォールの設定変更	通信要件のリスク評価とファイアウォールポリシー管理
障害対応・復旧作業	インシデント発生時の初動対応、影響範囲特定、復旧、再発防止策の立案
監視ツールでのアラート対応	イベントログの監視・分析とエスカレーション判断
バックアップ運用	事業継続を目的としたバックアップ・リストア体制の運用(可用性の担保)
手順書の作成・整備	運用の標準化とヒューマンエラー低減のためのドキュメント統制
OS・ミドルウェアのバージョンアップ	EOL管理を含む構成管理と技術的負債のリスク低減
委託先ベンダーとのやり取り	委託先管理(外部委託におけるセキュリティ要求事項の調整)
社内からの問い合わせ対応	利用部門へのセキュリティ啓発とルールの浸透支援

ポイントは、右側の語彙がすべて求人票の「業務内容」欄に出てくる言葉だということです。書類を読む側は求人票の言葉であなたの経歴を探します。同じ言葉が書いてあれば見つかる、なければ見つからない。それだけの仕組みです。

職務要約の書き方(冒頭3行が勝負)

職務経歴書の冒頭には3〜4行の職務要約を置きます。型はこうです。

インフラエンジニアとして◯年間、サーバー・ネットワークの構築運用に従事。脆弱性管理、アクセス制御、インシデント対応など、セキュリティ運用の基盤となる業務を実務で経験してきました。現在は情報処理安全確保支援士の学習を通じてセキュリティ管理の体系的な知識を補強しており、これまでの実務基盤を活かしてセキュリティ専門職への転身を志望しています。

構造は「①実務の土台(年数+領域)→②その中のセキュリティ要素→③補強している知識→④志望の一貫性」。未経験だと謝るのではなく、準経験者として名乗るのがこの型の狙いです。

スキルシートの書き方

職務経歴書とは別に、スキルシート（技術要素の一覧）を求められることがあります。ここでインフラ経験者がやりがちなのが、サーバー・ネットワーク製品だけを並べることです。

セキュリティ職に応募するなら、同じ経験をセキュリティの分類で並べ直すと伝わり方が変わります。

よくある書き方	セキュリティ職向けの並べ直し
OS：Windows Server, RHEL	OS堅牢化：Windows Server / RHEL のセキュリティ設定、パッチ管理
ネットワーク：Cisco, FortiGate	ネットワークセキュリティ：FW/UTMのポリシー設計・運用（FortiGate）、セグメント分離
監視：Zabbix, CloudWatch	ログ管理・監視：Zabbix/CloudWatchによる異常検知、ログ保全
クラウド：AWS	クラウドセキュリティ：IAM権限設計、セキュリティグループ管理、CloudTrail運用
その他：AD運用	ID・アクセス管理：Active Directoryの権限設計、棚卸し、退職者アカウント管理

中身は同じです。並べる軸をセキュリティに変えるだけで、書類選考の通過率が変わります。

「実績がない」と思ったときの探し方

セキュリティ専任でないと「書ける実績がない」と感じますが、たいていの場合あるのに気づいていないだけです。次の質問に一つでも当てはまれば、それは実績です。

• 脆弱性の通知を受けて対応したことはあるか → 「脆弱性情報の影響調査と対応判断」
• アカウントの棚卸しをしたことはあるか → 「アクセス権限の棚卸しと不要権限の削除」
• 取引先のチェックシートに回答したことはあるか → 「取引先セキュリティ要求事項への回答・対応」
• 障害対応の手順を作ったことはあるか → 「インシデント発生時のエスカレーションフロー整備」
• ログを見て原因を特定したことはあるか → 「ログ分析による事象の切り分け」
• バックアップの設計をしたことはあるか → 「事業継続を考慮したデータ保全設計」

重要なのは、やった事実を膨らませないことです。「対応した」を「主導した」に書き換えるのは誇張ですが、「対応した」を正確な業務名で書くのは翻訳です。この線は守ってください。

数字の入れ方

セキュリティの実績は数値化しにくいですが、減らしたものなら測れます。

• 「アカウント棚卸しにより、不要権限◯件を削除」
• 「チェックシート回答の標準化により、1件あたりの対応時間を◯時間削減」
• 「手順書化により、担当者以外でも初動対応が可能な体制に」

件数・時間・人数のどれかに落とせば、読み手が価値を判断できます。

やってはいけない書き方3つ

1. 業務の羅列: 「サーバー運用、NW運用、ヘルプデスク、その他」──何ができる人か伝わりません。翻訳表の言葉で「何を統制してきたか」に変換する
2. 触った製品名の列挙だけ: 製品名は書いてよいですが、「その製品で何のリスクを下げたか」がなければカタログです
3. 盛る: 「セキュリティ責任者として」など実態を超える肩書は面接で必ず崩れます。翻訳と誇張は別物です

仕上げのチェックリスト

• 求人票の「業務内容」の単語が、自分の職務経歴書に3つ以上登場するか
• 各業務に「規模感」(台数、ユーザー数、チーム人数など差し支えない範囲の数字)が入っているか
• インシデント・障害の経験が「対応して終わり」でなく「再発防止まで」書けているか
• 職務要約だけ読んで「セキュリティに向かっている人」だと分かるか

まとめ

• 書類で落ちる原因の多くは経験不足ではなく「翻訳不足」
• 求人票の言葉で自分の経験を言い直す。嘘は1文字も要らない
• 冒頭の職務要約で「準経験者」として名乗る

書類が通り始めたら、次は年収レンジの相場観を持って面接に臨んでください。自分の値札を知らないまま面接に行くのが一番もったいない。

書類が整ったら、次はどのエージェント経由で応募するかです。事業会社・SIer・コンサルなど狙う入口ごとの選び分けはエージェントの選び方にまとめました。

書類が通ったら、次は志望動機です。同じ「事実ベース」の考え方で書く方法をセキュリティ転職の志望動機の書き方（例文3パターン）にまとめました。

---

この記事は業界一般の情報と筆者個人の経験に基づくものであり、特定の組織の見解ではありません。