インフラエンジニアの職務経歴書・スキルシートの書き方と記入例

インフラエンジニアの職務経歴書では、OSやクラウドの名称に加え、対象環境で何を任され、どこまで判断したかを書きます。「Linux、AWS、運用保守」と並べるだけでは、手順の実行、障害調査、設定変更、設計のどこを担当したかが伝わりません。

この記事では、インフラの案件欄を具体化します。書類全体の構成や職務要約、所属会社と配属先の区別は、職務経歴書の基本と完成サンプルを参照してください。

案件欄は環境・担当範囲・判断・貢献に分ける

台数や構成の詳細は、公開可能な範囲で記載します。対象台数が分からない場合に概数を作る必要はありません。チームが管理する全台数を、そのまま自分が構築した台数として書かないようにします。

運用保守の記入例：一次対応と改善を分ける

以下の例はすべて説明用の想定例です。実在する応募者・顧客の経歴やTECH4Uの実績ではありません。

案件欄の記入例

アラート対応時に、監視履歴とOSログを照合して発生時刻と影響範囲を整理した。既存手順では確認先が分かりにくかったため、確認するログと連絡先を追記した。リーダーのレビュー後に改訂版をチームで使用した。恒久対策の設計と本番設定の変更は別の担当者が行った。

「障害を解決した」とまとめず、自分が切り分けて引き継いだ範囲を示しています。対応時間を測定していないなら「何％短縮した」とは書かず、手順の変更が採用された事実を伝えます。

サーバー構築の記入例：設定値の決定者を明確にする

構築経験では、用意された設計書に従った作業と、自分で設定を検討した作業を区別します。

Linuxサーバーの更改に伴う構築・動作確認を担当。承認済みのパラメータシートに基づいて設定し、設定値の照合とサービス起動を確認した。検証環境で既存手順どおりに動作しない項目を調査し、差分と再現条件を設計担当者へ報告した。修正方針の承認後、手順書を更新して再検証した。

この例の担当工程は構築・検証です。設計担当者へ確認した経験を、「基本設計を担当」と広げて書く必要はありません。自分で候補を比較して設定案を作成した場合には、その対象、選んだ理由、レビューの受け方を追加できます。

AWSなどのクラウドも同様です。サービス名に続けて、構築、権限設定、監視設定、運用のどこを担当したかを書きます。画面で状態を確認した経験と、構成や設定を決めた経験を分けると、採用担当者が任せられる範囲を判断できます。

ネットワーク更改の記入例：確認項目と切り戻し条件を示す

ネットワークでは、製品名とコマンド操作の経験だけでなく、何を確かめて作業を進めたかを記載します。

拠点ネットワーク機器の更改で、事前検証と切り替え当日の確認作業を担当。現行設定と新機器向け設定を比較し、差分を設計担当者へ確認した。疎通確認の対象と記録欄を手順書に整理し、当日は作業責任者の指示で確認を実施した。切り戻しの判断は作業責任者が行った。

切り替えを主導していない場合でも、事前に不明点を確認し、当日の確認漏れを防ぐ準備をした経験は説明できます。顧客のIPアドレス、構成図、認証情報を記入例の根拠として添付する必要はありません。

実務・学習・資格を別の欄で示す

転職先で使いたい技術を学習している場合は、実務経験の欄と分けます。たとえば、業務ではオンプレミス環境を運用し、個人でクラウド環境を構築したなら、次のように整理できます。

個人学習でも、構成を選んだ理由や検証した内容を説明できます。ただし、本番環境の設計経験や顧客への導入実績として扱わないようにします。

TECH4Uの案件選択の説明では、技術領域だけでなく、担当工程、役割、経験できる内容も確認します。応募先が構築担当を求めているなら、構築や検証に関係する案件を詳しく書き、関連性の低い定常作業は要約します。詳述と要約の書き分け、顧客名や数値を公開できない場合の記述は、職務経歴書の記入例で確認できます。