インフラエンジニアの職務経歴書｜運用・構築・設計の経験が伝わる書き方

インフラエンジニアの職務経歴書は、「何の技術を使ったか」だけでなく、「どの工程で、どこまで自分が担当したか」を書くと、経験が伝わりやすくなります。

「Linux、ネットワーク、AWSの経験あり」。間違ってはいなくても、これだけでは、監視していたのか、設定を変更していたのか、構成を考えていたのかが分かりません。仕事内容を読み手の想像に任せると、担当した範囲が十分に伝わらないことがあります。

この記事では、監視・運用、構築、設計のそれぞれについて、何を整理し、どう書けばよいかを具体例で紹介します。経験を大きく見せるためではなく、実際にできることを、過不足なく伝えるための書き方です。

本文の記入例・改善例は、書き方を示すためにwhoamiが作成した架空の例です。実在する人物の経歴や採用実績ではありません。そのまま自分の経歴として使わず、実際に担当した内容へ置き換えてください。

インフラエンジニアの職務経歴書は「担当範囲」が出発点

まず確認したいのは、「その案件で、自分は何を任されていたか」です。大規模な更改プロジェクトに参加していても、担当が監視だけなら、設計・構築を担当したことにはなりません。一方、小規模な環境でも、設定案の作成から試験まで任されていたなら、その範囲はしっかり書いてよいものです。

案件の規模を小さく見せる必要も、自分の担当範囲を広げて書く必要もありません。「プロジェクト全体の説明」と「自分の仕事」を別々に書くだけで、かなり読みやすくなります。

「経験あり」を、動作が分かる言葉に変える

たとえば「ネットワーク運用経験あり」より、「監視アラートの受付、ログ確認、障害箇所の一次切り分け、二次対応チームへの引き継ぎを担当」としたほうが、仕事の範囲が見えます。さらに、手順書に沿った作業なのか、自分で調査観点を追加したのかまで分けられると、任され方も伝わります。

書くときの順番は、対象・担当工程・自分の行動・確認方法です。「何を」「どの段階で」「どう扱い」「何をもって完了としたか」を一つずつ埋めてみてください。

技術名は、経験の説明を補うもの

製品名やサービス名は必要ですが、一覧が長ければ伝わるわけではありません。たとえば同じLinux経験でも、ログを読む、アカウントを追加する、構築する、設定方針を決める、では内容が違います。技術名の横に「できる作業」を短く添えましょう。

マイナビ転職エージェントの職務経歴書ガイドでも、環境・規模・工程と、自分の役割を明記することがポイントとして挙げられています。書類を整える際の確認軸として参考になります。出典：マイナビ転職エージェント「インフラエンジニアの職務経歴書」

職務経歴書の基本構成｜まずはこの順番で埋める

いきなり自己PRを書くより、案件ごとの事実を整理してから全体をまとめるほうが進めやすいです。次の構成はwhoamiの整理案です。応募先から指定の書式がある場合は、その書式を優先してください。

1. 職務要約：どの領域で、どの工程を、どのくらい経験したか。
2. 活かせる経験：応募する仕事に関係する得意分野。
3. 職務経歴：勤務先と在籍期間、案件ごとの担当業務。
4. 技術スキル：技術名、使用場面、担当できる範囲。
5. 資格・学習：保有資格と、実務とは区別した学習内容。
6. 自己PR：仕事の進め方が分かる具体的なエピソード。

案件ごとの記入テンプレート

「担当外」は必須項目ではありません。ただ、「設計」と書くと全体設計まで担当したように見える場合などには、「基本設計は上位担当が実施。私は詳細設定の整理と試験項目の作成を担当」と補うと正確です。

職務要約は、最後に短くまとめる

職務要約は冒頭に置きますが、書くのは後でも大丈夫です。案件の棚卸しが終わったら、繰り返し担当してきた仕事と、直近で広がった役割を抜き出します。「幅広く対応してきました」だけではなく、得意な範囲が分かる文章にしましょう。

監視・運用経験の書き方｜「監視だけ」で終わらせない

監視・運用の経験を書くとき、「アラート監視」「問い合わせ対応」だけで終わっていませんか。これでは毎日の仕事の中で、何を確認し、どう動いていたかが見えません。まずは一つの障害対応を思い出し、受付から引き継ぎまでを分解してみましょう。

一次対応でも、確認した情報と引き継ぎ方を書く

アラートを受け付けた後、対象機器、発生時刻、影響範囲、直前の変更を確認していたなら、その事実を書きます。担当したのが連絡だけだったのか、ログ収集や切り分けまで含んでいたのかで、説明は変わります。

この例では、障害原因を最終的に特定したとは書いていません。自分の範囲を明確にしながら、対応の丁寧さを伝えています。「解決した」と言い切れない仕事にも、書けることはあります。

改善実績は、派手な成果でなくてよい

担当者によって確認内容が違っていたため、チェック項目をそろえた。引き継ぎ漏れがあったため、チケットの記入欄を見直した。こうした改善も、実際に取り組んだなら説明できる実績です。ただし、提案しただけなのか、採用されて運用に入ったのかは分けてください。

dodaの運用エンジニア向けガイドでも、トラブル対応や業務上の工夫を具体的に伝えることが重視されています。ここで大切なのは、特別な成果を作ることではなく、自分が考えて動いた場面を探すことです。出典：doda「インフラ系運用エンジニアの職務経歴書」

これから構築へ進みたい人は、職務経歴書を書きながら「設定変更、試験、手順作成のうち、どこを経験できているか」も確認してみてください。具体的な進め方は運用から構築へ進むためのキャリアアップの実践法で整理しています。

構築経験の書き方｜設定投入の前後まで伝える

構築経験では、「機器を設定した」だけでなく、準備、設定、試験、引き継ぎのどこを担当したかを整理します。すべてを担当している必要はありません。自分が行った部分を、工程に沿って書けば十分です。

ネットワーク構築なら、設定根拠と試験の範囲を示す

決められたコンフィグを投入した場合と、自分で設定案を作成した場合は、分けて説明しましょう。VLANや経路設定について、設計書と照合したのか、案を作ってレビューを受けたのか、方式から検討したのか。使った技術が同じでも、担当範囲は違います。

「構築から設計まで一貫して対応」とまとめるより、このように分けたほうが、次の案件で任せられそうな仕事を読み手が判断しやすくなります。

サーバ・クラウド構築でも、サービス名だけにしない

サーバなら、OS導入、ユーザー・権限、監視設定、バックアップ、試験などの担当範囲を整理します。クラウドなら、ネットワーク、権限、計算資源、監視など、どの要素をどう扱ったかを書きます。「AWS環境の案件に参加」だけでは、実際にサービスを操作したかは分かりません。

また、自動化ツールを使った経験も、既存のものを実行したのか、自分で変更したのか、最初から作成したのかを区別します。作成した場合は、実行条件、確認方法、失敗時の対応も説明できるようにしておくと、面接で話がつながります。

設計・上流経験の書き方｜「何を決めたか」を具体化する

設計経験で伝えたいのは、資料を作った事実だけではありません。どんな要求や制約を受け、何を比較して、どの範囲の案をまとめたのかです。設計書の一部を更新した仕事と、構成方式を検討した仕事は、どちらも意味がありますが、同じ表現にまとめないほうが正確です。

要件・制約・比較・合意の順に整理する

たとえば「可用性を考慮した設計を担当」では、判断の中身が見えません。停止できる時間、復旧の目標、既存環境との関係、予算など、実際に検討した条件から書き始めます。そのうえで、候補、比較観点、採用案の理由を説明します。

調整経験は、会議への参加ではなく、整理した論点を書く

「顧客折衝あり」も、よく使われる言葉です。ただ、議事録を作成したのか、要望を聞いたのか、技術的な選択肢を説明したのかでは、経験の意味が変わります。「保守時の停止条件を確認し、未決事項を整理した」など、実際に進めたことを書くと伝わります。

管理経験も同じです。チーム人数だけでなく、進捗確認、作業割り当て、レビュー、課題管理のどれを担ったかを補います。チーム全体の結果を、自分一人で達成したように書かないことも大切です。

スキル・資格・個人学習は、同じ欄に混ぜない

実務で触れていない技術を学んでいるなら、その学習も書いて構いません。ただし、本番環境の実務経験と混ぜると誤解につながります。次のように経験の区分を付けると、自分にも読み手にも分かりやすくなります。

• 実務：業務として担当した内容。レビューや承認の有無も補足する。
• 補助・見学：担当者の作業を支援した範囲、確認した内容。
• 個人学習：学習環境で自分が構築・検証した内容。

「AWSを勉強中」を、検証内容まで具体化する

たとえば「個人学習として、仮想ネットワークとサーバを構築。通信を許可する条件を変えて接続結果を記録した」と書けば、何を試したかが分かります。実務ではないことを明示したうえで、目的、実施内容、確認できたことを添えましょう。

手順どおりに作成しただけなら、そのように書いて大丈夫です。そこから設定を変えて確かめたことがあれば、追加します。「実務未経験」という事実を明記したうえで、学んでいる範囲を説明します。

資格は、取得状況を正確に書く

資格欄は正式名称と取得年月を基本に、更新が必要な資格では現在の状況も確認します。学習中・受験予定と取得済みは分けてください。資格を持っているだけで、その技術の設計や構築を実務で担当できると断定しないことも大切です。

応募先が求める技術について、資格で学んだ知識と実際に経験した作業を並べると、現在地が見えます。足りない経験があるときも、「未経験だが何を検証したか」を説明できれば、会話の材料になります。

応募先と希望年収につなげる｜書類でできること・できないこと

職務経歴書を整えたからといって、年収が必ず上がるわけではありません。書類の役割は、自分の経験を相手が判断できる状態にすることです。そのうえで、応募先の業務、責任、給与条件との対応を確認します。

求人票の言葉に、自分の経験を対応させる

構築担当を募集している求人なら、監視経験だけを長く説明するより、設定変更、検証、試験項目作成など、関連する実績があれば先に伝えます。実績がない項目を埋める必要はありません。「経験あり」「一部経験」「未経験」を自分用メモで分けておくと、応募先との違いが分かります。

複数の求人へ応募するときも、経歴そのものは変えません。変えるのは、冒頭で強調する経験と説明の順番です。同じ仕事を、応募先ごとに違う工程として書いてしまうと、後で説明が合わなくなります。

年収の比較では、担当工程と働く条件もそろえる

希望年収を考えるときは、肩書きだけで相場を比べず、担当工程、勤務地、企業規模なども確認しましょう。whoamiの年収診断では、従業員1,000人以上は＋13.1％、東京は＋10.6％、クラウド実務経験ありは＋10.0％という補正設定を用いています。

これらはwhoamiの診断モデル上の設定であり、その条件へ変えれば同じ割合で昇給するという意味ではありません。また、クラウド資格の取得や個人学習を、クラウドの実務経験と同一視しないでください。出典：whoami年収診断の説明。年収全体の見方はインフラエンジニアの年収を工程別に整理した記事でも解説しています。

提出前に確認したい5つのこと

1．実績の数字に根拠があるか

時間短縮や対応件数を書くなら、いつ、何を対象に、どう数えた数字かを説明できるようにします。比較条件が違う数字を並べたり、測定していない改善率を作ったりしないでください。数字が分からなければ、「確認項目を統一し、引き継ぎの手順を明文化した」のように、確認できる変化を書けば十分です。

2．公開できない情報が含まれていないか

顧客名、内部の構成、接続情報、障害の詳細、非公開の台数などは、そのまま持ち出さないでください。開示できる範囲を勤務先のルールなどで確認し、必要に応じて業種や概数で表現します。AIへ添削を依頼するときも、社内資料や顧客情報をそのまま入力しないことが大切です。

3．面接で一段深く説明できるか

「なぜその設定にしたのか」「自分で決めたのはどこか」「うまくいかなかったときはどうしたか」。書いた経験について、これらを聞かれたときに説明できるか確かめます。答えられない場合は、経験を消す前に、実際の担当範囲と文章が一致しているか見直しましょう。

4．技術名と役割が読み取りやすいか

略語だけを詰め込まず、案件の目的と担当内容が分かる説明を付けます。一方、一般的な製品名をすべて長く解説する必要はありません。技術に詳しい人にも、最初に書類を見る人にも、担当範囲が追えるかを意識してみてください。

5．勤務先・案件・期間が整合しているか

常駐先で働いていた場合は、雇用元と案件先を混同しないように整理します。同じ勤務先で複数案件を経験したなら、勤務先の下に案件を分けると読みやすくなります。履歴書と職務経歴書で在籍期間がずれていないかも、最後に確認してください。

よくある質問

監視しか経験していなくても、職務経歴書に書けますか？

書けます。監視対象、受付後の確認、一次対応、報告・引き継ぎなど、実際の作業を分けてください。経験していない構築業務を追加する必要はありません。仕事の中で工夫したことがあれば、事実の範囲で添えましょう。

スキルシートを、そのまま提出してもよいですか？

応募先の指定によります。指定がなければ、技術の一覧だけで職務要約や担当範囲まで伝わるかを確認してください。案件情報がそろっていても、自分が工夫した点や仕事の進め方が見えない場合は、説明を補う余地があります。

改善効果を数値化できないと、不利ですか？

数値がなければ経験を書けない、ということではありません。問題になっていたこと、自分が変えたこと、確認できた結果を具体的に整理しましょう。根拠のない数字を入れるより、面接で説明できる事実を優先してください。

構築を補助しただけでも「構築経験」と書けますか？

工程名に加えて補助であることと、担当した作業を明記しましょう。たとえば「構築支援として、承認済み手順による設定投入と疎通確認を担当」と書けば、自分の範囲が伝わります。設計や承認まで任されたような表現は避けてください。

職務経歴書は何枚にまとめるべきですか？

応募先の指定を優先します。指定がない場合は、枚数だけにこだわらず、要約で全体像が分かり、必要な案件詳細を追える構成にしましょう。似た定常作業を何度も繰り返すより、役割が広がった点を重点的に書くと整理しやすくなります。

まとめ｜経験を盛るより、担当範囲を具体的にする

インフラエンジニアの職務経歴書でまず見直したいのは、「経験あり」「担当しました」で止まっている部分です。対象、工程、自分の行動、確認方法を加えると、同じ経験でも内容が見えやすくなります。

まずは直近の案件を一つ選び、「自分が作ったもの」「自分が確認したこと」「自分では決めていないこと」を書き出してみてください。一度に全案件をまとめなくても、その一件がほかの案件を整理する土台になります。

経歴を整理したら、今の担当工程で年収をどう捉えるかも確認しておきましょう。仕事の内容と条件を並べると、次に伸ばしたい経験も考えやすくなります。

「whoami」は、ネットワーク・インフラ領域の技術者に特化した求人メディアです。