サーバーエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

サーバーエンジニアのスキルシートは、OSを系列とメジャーバージョンで、サーバーを「Web」「DB」「ファイル」などの役割で書き、物理・仮想・クラウドのどれだったか、どの工程を担ったか、障害対応でどこまで追ったかを添えるのが基本です。「Linux、Windows」と並べるだけでは、読み手は案件との重なりを判断できません。

全体の構成はスキルシートの基本、案件で見られるスキルの中身はサーバーエンジニアの案件で求められるスキルで扱っています。ここでは、サーバーの経験をシートにどう書くかに絞って説明します。

OSは「系列とメジャーバージョン」で書く

サーバーの案件では、OSの版が仕事の中身を左右します。古い版から新しい版への移行の案件では、両方の版を扱った経験が直接の判断材料になるためです。

ディストリビューションの系列（RHEL系、Ubuntuなど）とメジャーバージョンまでは書いてかまいません。一方で、参画先の細かいパッチの水準や、ソフトウェアの組み合わせまで書くと、環境を特定される手がかりになることがあります。メジャーバージョンでとどめておくのが無難です。

サーバーは「役割」と「置き場所」で書く

同じLinuxの経験でも、Webサーバーの構築とDBサーバーの運用では、問われる知識が違います。スキル一覧では、扱ったサーバーを役割ごとに書き、それぞれの置き場所と関わり方を添えます。

これは書き方を示すための例です。「物理」「オンプレミスの仮想」「クラウドの仮想マシン」を書き分けると、データセンターでの作業の経験があるか、クラウドへの移行に近い経験があるかが伝わります。

規模は台数と構成の特徴で書く

規模は、正確な台数ではなく、桁でぼかして書けば十分です。

• 「数十台規模の社内基盤。WebとDBは2台ずつの冗長構成」
• 「仮想マシン数百台が動く仮想化基盤の運用」
• 「利用者数千人規模のファイルサーバーとAD」

冗長化の方式やバックアップの方式は、規模と並んで難しさを示す情報です。構成の特徴として一言添えると伝わります。ホスト名、IPアドレス、拠点やデータセンターの名前は書きません。

担当工程は「成果物」と「作業の再現性」で書く

担当工程の欄に「設計・構築」とだけ書くと、自分で書類を作ったのか、他の人が作った手順で作業したのかが分かりません。作った成果物と、作業をどう再現できる形にしたかを書くと、関わりの深さが伝わります。

自動化は「新規に書いた」「既存のコードを修正した」「実行しただけ」で評価が大きく変わります。関わり方をそのまま書きましょう。

移行は「移行元・移行先・方式」で書く

OSの更改や基盤の移行の経験は、サーバーの案件で強い材料になります。次の4点を書くと、移行の案件との重なりがすぐに分かります。

1. 移行元：OSと版、物理か仮想か
2. 移行先：OSと版、仮想化基盤かクラウドか
3. 方式：新しいサーバーを構築して移し替えたか、仮想マシンごと移したか
4. 自分の役割：調査、計画、構築、切り替え当日の作業、切り戻しの準備のどこを担ったか

移行元のサーバーで何が動いているかを調べた経験は、見落とされがちですが評価されやすい部分です。依存関係の調査を担当した場合は、独立した行として書きましょう。

障害対応は「どこまで追ったか」で書く

運用の経験は、「24時間の監視・障害対応」とだけ書くと、定型の作業の印象になりがちです。障害の原因をどこまで追ったかを、段階で書くと伝わり方が変わります。

• アラートを受けて、手順書どおりに再起動や連絡をした
• ログやリソースの状況から、OS・ミドルウェア・ストレージのどこが原因かを切り分けた
• 原因を特定し、設定の変更やパッチの適用で恒久対策を入れた
• 再発防止として、監視項目や手順書を見直した

資格は正式名称と取得年月を書く

資格は、正式名称と取得年月を書きます。Red HatのRHCSAは、試験EX200による実技の試験で、Red Hat Enterprise Linux環境でのシステム管理の力を確かめるものとされています（2026年10月時点の公式ページによる）。実技で評価される資格であることは、面談で補足するとよいでしょう。

Microsoftの「Windows Server 管理者アソシエイト」は、更新しないと期限が切れる認定とされ、オンラインの評価に合格すると更新できると案内されています（2026年10月時点）。有効期限のある資格は、期限もあわせて書いておくと、読み手が状態を判断しやすくなります。LinuC・LPICの書き方はフリーランスにLinuC・LPICは役立つかで扱っています。

例：Microsoft認定: Windows Server 管理者アソシエイト　20XX年X月取得、有効期限20XX年X月

プロジェクト欄の記入例

ここでは、社内基盤のOS更改を担当した場合を想定しています。以下は書き方を示すための架空の例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（8か月程度）
案件概要：流通業向け 社内基盤のOS更改と仮想化基盤への集約
規模・構成：Web・AP・DB・ファイルサーバーなど数十台。WebとDBは冗長構成
体制・立場：インフラ担当5名（自分はメンバー。後半はLinux側の取りまとめ）
担当工程：移行元の調査、詳細設計、構築、試験、移行
移行元→移行先：物理のRHEL系（7）→ 仮想化基盤上のRHEL系（9）
作成した成果物：移行元の調査結果（動いているサービスと依存関係の一覧）、パラメータシート、構築手順書、切り替え手順書と切り戻しの判断基準
使用技術：RHEL系、Apache、ハイパーバイザー、Ansible（OSの初期設定を新規作成）、シェルスクリプト
切り替え当日の役割：夜間の切り替えでLinuxサーバーの作業と動作確認を担当
工夫・成果：移行前後の設定を自動で取得して比べる仕組みを作り、確認の漏れを減らした

この例では、移行元と移行先、作った成果物、当日の役割を独立した行にしています。面談では、依存関係をどう洗い出したか、切り戻しをどんな条件で判断するつもりだったかを聞かれることがあります。答えられる深さで書くことが大切です。

よくある質問

古いOSの経験ばかりですが、書いても不利になりませんか？

不利になるとは限りません。古いOSから新しい環境への移行の案件では、移行元の版を扱った経験そのものが判断材料になります。新しい版を学んでいる場合は、検証環境で試した範囲として分けて書くと、移行の両側を扱える人として伝わります。

運用の経験しかない場合、何を厚く書けばよいですか？

障害の原因をどこまで追ったか、手順書の整備や作業の自動化といった改善に関わったかを厚く書きます。定型作業の一覧より、自分が判断した場面が読み取れるほうが、構築や移行の案件に広げる材料になります。

LinuxとWindowsの両方の経験はどう並べればよいですか？

スキル一覧ではOSごとに行を分け、それぞれ役割と関わり方を書きます。プロジェクト欄では、一つの案件で両方を扱った場合も、どのサーバーで何を担ったかを分けて書くと、深さが伝わります。