企業は職務経歴書を、こう読んでいる
求職者を担当するCAの席と、企業を担当するRAの席。両方に座って分かったのは、書類選考は「良い経歴を探す作業」ではなく「判断材料が足りない書類を落とす作業」だということです。採用側は限られた時間で多くの書類を見ます。読んで分からないことは、面接で確かめる前に「書いていない＝できない・やっていない」と受け取られがちです。
だから添削でやっていたのは、経歴を盛ることではありませんでした。本人が当たり前にやってきたのに、書いていなかったことを拾い上げること。支援の現場で力を入れていたのも、まさにここです。
読み直しの作法は1つだけです。書き上げたら、「自分が面接官だったら、この書類の人を面接に呼ぶか？」と声に出して自問してください。呼ぶ理由が書類の中に見つからなければ、それが書き足す場所です。
書かれていない項目チェックリスト
とくに抜けがちなのは、次の5項目です。自分の職務経歴書を開いて、1つずつ照らしてください。
1. 担当範囲（どこからどこまでを自分が持ったか）
- 「サーバー運用保守」とだけ書いていないか
- 監視だけか、障害対応までか、設計・更改まで持ったのかが分かるか
- 一人で持った範囲と、チームで分担した範囲の境目が書かれているか
企業が見たいのは業務名ではなく責任の範囲です。「運用保守」の4文字では、監視オペレーションの人なのか、障害の切り分けと恒久対応まで担った人なのかを判断できません。
2. 規模感（台数・拠点数・ユーザー数・チーム人数）
- サーバーやネットワーク機器の台数の目安が書かれているか
- 拠点数、利用ユーザー数、チームの人数が書かれているか
- 常駐先・自社など、環境の置かれ方が伝わるか
規模感のない実績は、読み手の中で一番小さい想像に寄ります。台数や人数は、守秘に触れない範囲で構いません。「約」「〜規模」で十分です。書いていないこと自体が損をします。
3. 役割（指示を受けて作業したのか、設計・調整までしたのか）
- 手順書通りに作業したのか、手順書を作る側だったのかが分かるか
- 顧客や他ベンダーとの調整役を担った場面が書かれているか
- 後輩への指示出しや、切り分けの方針決めなど「判断したこと」が書かれているか
同じ「構築経験」でも、設計を決めた人と、決まった設計を組んだ人では市場価値が違います。企業はそこを見ています。
4. 使った技術と、その技術で何を判断したか
- 製品名・技術名の羅列で終わっていないか
- その技術を「なぜ選んだか／どう切り分けたか」まで書かれているか
- クラウドなら、オンプレ時代の判断経験とつなげて書かれているか
技術名は検索キーワードとしては必要です。ただし採用側が知りたいのは、道具の名前よりも、道具を使って下した判断の方です。
5. 成果とトラブル対応（件数ではなく、影響範囲と自分の動き）
- 障害対応を「対応しました」で終えていないか
- 影響範囲（全社・拠点・サービス単位）と、その中での自分の動きが書かれているか
- 再発防止や手順化など、対応の「後始末」まで書かれているか
障害対応の件数を誇る必要はありません。企業が見ているのは、混乱の中で何を判断し、どう立て直したかです。
書き換えの型：嘘はつかない。でも、言い切る
チェックで引っかかった箇所は、次の型で書き換えます。指導のときの約束は「嘘はついちゃいけない。でも魅力的に見せる言い回しは使っていい」。事実はそのままに、文の形だけを強くします。
弱い例：「サーバーの運用保守を担当していました。」
言い切る例：「拠点向けサーバー群の運用保守を担当。障害時は一次切り分けから復旧判断までを担い、手順化した対応フローで夜間対応の属人化を解消した。」
違いは3点です。範囲が具体的（何のサーバー群か）、役割が言い切られている（判断まで担った）、後始末まで書かれている（手順化）。どれも新しい実績を発明していません。本人がやってきたことを、企業が判断できる形に置き直しただけです。
「しっかり言い切ること」。曖昧な文末は、自信のなさではなく「材料不足」に読まれます。
直す順番：全部を一度に直さない
チェックで引っかかった項目が多くても、直す順番は決まっています。最初に担当範囲と規模感。この2つは、読み手が「この人の仕事の大きさ」を掴むための土台で、ここが空だと後の項目も評価されません。次に役割と判断したこと。最後に成果と後始末。1項目ずつ、事実を確認しながら埋めてください。記憶が曖昧な箇所は、盛るのではなく「約」「〜規模」の幅を持たせて書く。それが守秘と正直さの両方を守る書き方です。
もう1つ、職種によって「企業が先に見る項目」は少しずつ違います。
- ネットワーク系：拠点数と構成の規模、更改や移行に触れたかどうか。運用だけでも、障害時の切り分け範囲が書かれているかで評価が変わります。
- サーバー・クラウド系：台数と環境の種類に加えて、設計・構築にどこまで関わったか。手順通りの作業と、方式を決めた経験は分けて書きます。
- 社内SE系：ユーザー数と拠点数、そしてベンダーや社内各部門との調整役を担った場面。技術の深さより「一人でどこまで持ったか」が読まれます。
共通しているのは、どの職種でも「業務の名前」ではなく「範囲と判断」で読まれていることです。
盛らないための、最後の線引きチェック
書き換えが進むと、つい文が大きくなります。提出前に、次の3つで最終確認をしてください。1つでも引っかかったら、その文は戻します。
- その文は、面接で根拠を聞かれても、実際にやったことで説明できるか
- 「主導した」「改善した」と書いた箇所は、自分が判断した場面を具体的に言えるか
- やっていない技術・関わっていない工程が、読めば関わったように受け取られる書き方になっていないか
この線引きを守る限り、言い切ることは嘘にはなりません。むしろ企業側は、言い切れる書類の人を面接に呼びたがります。曖昧な書類は「自信がない人」ではなく「判断材料を出さない人」に見える。それが書類選考の現実です。
書類が通る状態になったら、次にやること
書類を整えたら、やみくもに応募しないでください。数を打つほど1社への対策が薄くなり、面接で落ちる転職活動になります。応募は本命5社程度に絞る。この進め方を、紹介求人の仕分けの記事で続けます。
なお、書類の添削と求人紹介は、エージェントの面談で受けられます。登録先の選び方は比較ページにまとめました。登録は広く、面談までは行く。応募だけを絞る、がこのサイトのやり方です。