インフラエンジニアの職務経歴書の書き方 ― 企業側の読み方から逆算する実践ガイド

記事1との役割分担：チェックの次は「どう書くか」

先に、この記事と記事1の分担をはっきりさせます。記事1「インフラエンジニアの職務経歴書で、企業が見ているのに書いていない項目」は、抜けている項目を照らすチェックリストです。担当範囲・規模感・役割・技術と判断・成果とトラブル対応。自分の書類を開いて、足りない場所を特定するところまでがあちらの仕事です。

この記事はその先です。足りないと分かった場所を、実際にどういう文で書くのか。フォーマットの型、プロジェクト単位の書き方、書き換えの実例までを全部並べ、最後に完成形の見本を書類そのものの形で置きます。

順番は、記事1で「抜け」を確認してから、この記事で「書き直す」。逆でも構いません。書きながら抜けに気づく人もいます。

書類選考で企業が実際にやっていること

先に結論を置きます。書類選考は「良い経歴を探す作業」ではありません。「判断材料が足りない書類を落とす作業」です。

採用側は限られた時間で多くの書類を見ます。全員を面接に呼ぶわけにはいかないので、書類の段階で「面接で確かめる価値があるかどうか」を決める。ここで使われる材料は、書類に書かれていることだけです。書いていないことは、好意的に解釈してもらえません。「書いていない＝やっていない・できない」と受け取られる。これが現実です。

だから、経歴は申し分ないのに書類で落ち続ける、ということが起きます。落ちた理由は実力不足ではなく、やっていたことが書類に載っていないこと。支援の現場で添削に力を入れていたのは、まさにここです。添削でやるのは経歴を新しく作ることではなく、本人が当たり前にやってきたのに書いていなかったことを、企業が判断できる形に置き直すことでした。

もう1つ押さえておくのは、視線の動き方です。細かく見る企業が多い一方で、最初の数十秒で「読み進めるか」の当たりがつく、というのが現場の感覚です。最初に読まれる場所で判断材料が出ていなければ、後ろの力作まで辿り着いてもらえません。だから書き方の話は、フォーマットの順番そのものから始めます。

全体の構成：標準フォーマットの型

職務経歴書の型は、大きく5つのブロックで組み立てます。順番にも意味があります。読み手が「この人は何者か」を最短で掴める順に並べるのが原則です。

ブロック1：職務要約（目安：全体の冒頭、3〜5行）

自分は何をやってきた人間かを、最初の数行で言い切る場所。詳しくは次の章で扱います。ここが弱いと、後ろの職務経歴が読まれないまま終わることがあります。

ブロック2：活かせる経験・知識（目安：箇条書き5〜10行）

担当フェーズ（設計・構築・運用など）、扱った技術領域、環境の種類を、転職先で活かせる順に並べます。網羅ではなく「この人と話す価値」を作る場所です。応募先ごとに並べ替えていいブロックは、実はここです。

ブロック3：職務経歴（目安：全体の6〜7割）

本編。会社ごと・プロジェクトごとに、期間／体制／担当範囲／役割／成果を書きます。書き方は後の章で詳しくやります。分量配分で一番厚くするのはここです。逆に言えば、ここが薄い書類は要約や自己PRでどれだけ飾っても通りません。

ブロック4：保有資格・スキル（目安：表形式で簡潔に）

資格は取得年月と正式名称。スキルは技術名と経験年数・レベル感を添える。後の章で扱う通り、資格とスキルは「あること」自体より、職務経歴とつながっているかどうかが読まれます。

ブロック5：自己PR（目安：5〜10行）

強みを1つに絞り、職務経歴の中の事実で裏づける場所。「コミュニケーション能力が高いです」のような、根拠のない自己評価は書かない。強み→それが表れた場面→転職先でどう活かす、の3点セットで書きます。

書式の基本

• 全体はA4で2〜3枚が目安。経験が長い人でも、古い経歴は圧縮して直近10年ほどに厚みを持たせる
• フォントサイズや罫線の装飾に凝る必要はない。読み手は中身しか見ていない
• 日付（作成日）は最新のものに更新する。古い日付のまま出回っている書類は、それだけで「使い回し」に見える

職務要約の書き方：最初の3行で決まる

職務要約は、書類全体の「表紙」です。採用側はここで、この書類を読み進めるかどうかをほぼ決めています。逆に言えば、要約の3行で「面接で確かめたい点」が1つでも浮かべば、後ろの職務経歴はちゃんと読んでもらえます。

型：対象 × フェーズ × 規模 ＋ 判断の実績

要約に最低限入れるのは次の4要素です。

1. 何の領域のエンジニアか（サーバー／ネットワーク／クラウド／社内SEなど）
2. どのフェーズをどこまで持ったか（監視・運用中心なのか、設計・構築までなのか）
3. 規模感（台数・拠点数・ユーザー数・チーム人数のうち書けるもの）
4. 判断したことの実績（切り分けの方針決め、手順書の作成、更改の主担当など「決める側」の経験）

文例を2つ置きます。どちらも創作の例です。

2つの例に共通しているのは、年数・領域・フェーズ・規模の4要素が最初の数行で揃っていることです。逆に、要約でありがちな失敗は「責任感が強く、真面目に業務に取り組んでまいりました」のような性格の話から始めること。採用側が知りたいのは人柄ではなく、判断材料です。

職務経歴の書き方：プロジェクト単位で「判断」を書く

職務経歴は、プロジェクト（または担当業務のまとまり）単位で書きます。1プロジェクトにつき、次の6点を1セットにするのが型です。

工程（フェーズ）との接続

このサイトのフェーズマップ（工程マップ）で整理した通り、インフラの仕事は 監視 → 運用 → 保守 → 構築 → 設計 → 要件定義 と、上に行くほど判断と責任の範囲が広がります。職務経歴で「担当フェーズ」を書くときは、この階段のどこにいたかを正確に書いてください。

大事なのは、上に盛ることではなく、今いる段での判断を書き切ることです。監視・運用の人でも、切り分けの判断を自分でしていたなら、それは構築の書類にも通じる材料になります。逆に、構築を担当していても「手順書通りに設定した」だけでは、判断の材料になりません。フェーズの名前ではなく、各段で何を判断したかが読まれています。

5点を各プロジェクトでどう書くか

記事1のチェックリスト（担当範囲／規模感／役割／技術と判断／成果とトラブル対応）を、プロジェクト単位の文に落とすとこうなります。

• 担当範囲：「運用保守」ではなく「○○系システムの運用保守。うち障害対応と定常メンテナンスを担当、監視は別チーム」のように、境目まで書く
• 規模感：台数・拠点数・ユーザー数は「約」を付けてよい。書かないことが一番損をする
• 役割：チームの中での立ち位置と、誰に指示を出し・誰の判断を仰いだか
• 判断：「なぜその方法を選んだか」「切り分けで何を根拠に結論を出したか」。1プロジェクトに最低1つは入れる
• 成果・後始末：数字が出せるものは数字で。出せない場合は「手順化した」「属人化を解消した」のような状態の変化で書く

添削で言い換えが一番効くのは、この「判断」の部分です。業務名と担当範囲は事実の列挙ですが、判断はその人しか書けない部分だからです。

Before/After：書き換え例3パターン

型だけでは手が動かないので、書き換えの実例を3つ置きます。すべて創作の例です。記事1の例（サーバー運用保守の書き換え）とは別のパターンを用意しました。

パターン1：運用保守（定常運用・監視寄り）

違いは、対象システム・体制・規模が具体的になり、「対応していた」だけだった業務に判断（棚卸しと整理の実施）と後始末（手順書化）が加わったことです。

パターン2：構築（ネットワーク更改）

「参加した」から「何を担当し、何を判断し、どう終えたか」へ。規模（拠点数・期間）と、トラブル予防という判断の痕跡が入っています。

パターン3：障害対応

障害対応で企業が見ているのは「頑張った」ではなく、混乱の中で何を判断したかと、後始末までやったかです。「努めました」「心がけました」のような努力の表現は、判断材料になりません。

3パターンに共通する書き換えの原則は1つ。新しい実績は1つも発明していない。本人がやってきたことを、企業が判断できる形に置き直しただけです。

なお、落ちる書類には共通する書き方の癖があります。業務名の羅列、曖昧な文末、盛った表現。この3つは、後の「やってはいけない書き方」の章でまとめて扱います。

領域別の書き分け：企業が見るポイントの違い

同じ「インフラエンジニア」でも、領域によって企業が先に見る項目は変わります。自分の領域の観点を外すと、書いているのに評価されない、ということが起きます。

サーバー系

台数と環境の種類（物理／仮想／OSの内訳）に加えて、設計・構築にどこまで関わったか。手順通りの作業と、方式を決めた経験は必ず分けて書く。パッチ適用や更改の判断（やる・やらない・時期）を自分で決めた経験があれば、それは強い材料です。

ネットワーク系

拠点数と構成の規模、更改・移行に触れたかどうか。運用中心の経歴でも、障害時の切り分け範囲（どこまでを自分の判断で切り分けたか）が書かれているかで評価が変わります。回線やベンダーの調整役をやった経験は、設計寄りの評価につながります。

クラウド系

オンプレ時代の判断経験とつなげて書くのが原則です。クラウドの製品名を並べるだけの書類は、現場の判断力が伝わりません。「なぜその構成にしたか（コスト／可用性／運用負荷のどれを優先したか）」まで書く。移行プロジェクトなら、移行方式の選定に関わったかどうかが分かれ目です。

社内SE系

ユーザー数と拠点数、そして「一人でどこまで持ったか」。技術の深さより、ベンダー調整・社内各部門との折衝・予算や更改計画の整理といった、情シスとしての守備範囲の広さが読まれます。ヘルプデスクの件数ではなく、問い合わせを減らすためにやった仕組み化を書く。

スキルシートとの違いと、資格の書き方

スキルシートと職務経歴書は、読まれ方が違う

SESや派遣の現場で使うスキルシートは「何ができるか」の一覧です。技術とレベルの表が中心で、それで成立します。一方、事業会社やSIerの中途採用で出す職務経歴書は「何を判断してきたか」を読む文書です。スキルシートの体裁のまま職務経歴書を出すと、技術名は並んでいるのに担当範囲と判断が見えず、記事1で言う「抜け」の状態になります。

両方を求められた場合は、職務経歴書を本体として書き、スキルシートはその要約として揃える。内容が食い違うと、それだけで信頼を落とします。

資格は「判断材料」として位置づける

資格の欄で企業が見ているのは、資格の数ではありません。

• 業務とのつながり：構築の仕事をしてきた人がネットワークやクラウドの資格を持っていると、経歴の裏づけになる。経歴と無関係な資格の羅列は材料にならない
• 取得の時期：直近で取り続けている人は「今も伸びている」材料になる。10年前の資格だけが並ぶと逆効果になることもある
• 書き方：正式名称と取得年月を正確に。勉強中・取得予定は、その旨を分けて書けば問題ないが、取得済みと並べて紛らわしくしない

資格がない人は、その分、職務経歴の「判断」の厚みで勝負するしかありません。逆に資格が強い人は、資格欄を厚くするより、職務経歴で「その知識をどこで使ったか」を書くほうが効きます。

資格ごとの効き方と、書類・面接での活かし方は、資格マップに整理しました。取る順番の判断にも使えます。

やってはいけない書き方

盛る（事実の発明・水増し）

一番やってはいけないこと。関わっていない工程を関わったように書く、規模を大きく見せる、他人の実績を自分のものにする。面接で根拠を聞かれた瞬間に崩れますし、運よく入社できても現場で詰みます。

指導のときの約束は「嘘はついちゃいけない。でも魅力的に見せる言い回しは使っていい」。線はここです。

曖昧な文末

「〜を担当していました」「〜に努めました」「〜を行いました」で文を終える癖。曖昧な文末は、謙虚さではなく「判断材料を出さない人」に読まれます。事実の範囲で言い切る。「担当した範囲はここまで」と区切って言い切ることは、嘘とは違います。

業務名の羅列

「サーバー運用、ネットワーク監視、ヘルプデスク……」と業務名だけを並べた書類。読み手は、その人がどの規模で・どこまで判断したのかを一切掴めません。業務名は見出しに過ぎず、中身は担当範囲と判断で書くものです。

守秘への配慮を怠る

顧客名・システムの詳細な構成・障害の内部事情など、守秘に触れる情報は書きません。ただし守秘は「書けない理由」にはなりません。固有名詞を外し、規模と自分の役割だけを書く。「約200台規模」「金融系システム」のような抽象度なら、守秘を守りながら判断材料は出せます。逆に、守秘を理由に何も書いていない書類は、企業側からは「材料なし」として処理されます。

仕上げの自己点検チェックリスト

書き上げたら、提出の前にこの順で読み直してください。軸は指導のときの問い、「自分が面接官だったら、この書類の人を面接に呼ぶか？」です。

1. 職務要約の3行だけで、「何の領域で、どのフェーズを、どの規模でやってきた人か」が分かるか
2. 各プロジェクトに、期間／体制・規模／担当フェーズ／技術／役割と判断／成果・後始末の6点が揃っているか
3. 「判断したこと」が、1プロジェクトに最低1つは書かれているか
4. 規模感（台数・拠点数・ユーザー数・人数）が、書ける範囲で入っているか。「約」で構わない
5. 文末が「〜しました」で言い切れているか。「努めました」「心がけました」が残っていないか
6. 面接で根拠を聞かれても説明できない文が、1つもないか
7. 資格・スキルが職務経歴の内容と食い違っていないか
8. 守秘に触れる固有名詞・内部情報が混ざっていないか
9. 作成日が最新になっているか
10. 声に出して読んで、「面接に呼ぶ理由」が書類の中に見つかるか。見つからなければ、そこが書き足す場所

10番が最終関門です。呼ぶ理由が見つからない書類は、企業側の席でも同じ結論になります。

逆に、強い書類には共通点があります。要約で何者かが言い切れていること。各プロジェクトに判断が書かれていること。文末が言い切れていること。その状態が、このチェックリストを全部通した姿です。

完成形の見本：サンプル職務経歴書（全文例）

ここまでの型を全部使った「完成形」を1つ置きます。これまで説明したことを、実際の書類の形にするとどうなるかを見るための見本です。箇条書きの解説ではなく、書類そのものの形で置きます。

※ この見本は創作です。人物・経歴・数値はすべて架空のもので、実在の人物・企業ではありません。

この見本で見てほしいのは、文章の上手さではありません。メソッドの5点――担当範囲・規模感・役割・技術と判断・成果とトラブル対応――が、要約・経験ブロック・経歴表・自己PRのすべてに通っていることです。逆に言えば、5点が入っていれば、派手な実績がなくても書類はここまで戦える形になります。

自分の書類と見比べて、欠けているブロック・欠けている点から直してください。直し方の詳細は、ここまでの章に戻れば全部書いてあります。

まとめと、次の動き

まとめます。職務経歴書は経歴の記録ではなく、企業に判断材料を渡すための文書です。落ちる理由の大半は実力ではなく、書くべきことが書かれていないこと。書き方の型は、要約で「何者か」を言い切り、プロジェクト単位で担当範囲・規模感・役割・技術と判断・成果とトラブル対応を揃え、最後に面接官の目で読み直す。この3点です。

次にやることの導線です。

• 抜けている項目を先に特定したい人は、記事1のチェックリストに戻る
• 自分がどのフェーズにいて、次にどの段を狙うべきかは、フェーズマップ（工程マップ）で確認する
• 書類が整ったら、面談を「市場価値を測る」場として使う。測り方の記事「転職しない、という結論も正解だ」に続けます

書類は一度書いて終わりではありません。面談で得た反応が、次の書き直しの材料になります。