職務経歴書の「職務経歴・職務内容（職歴）」の書き方・例文と評価されるポイント

●書く順番

転職経験があり、2社以上に勤務経験がある場合は新しい会社から順に書き、同じ会社の中の職歴は古い順から書きます。

●年表ではない。適切に編集を

職務経歴は年表ではありません。とにかく職歴を全部書いておけば、その中から強みを読み取ってもらえるだろう……と思うのは誤りです。年表のようにメリハリなく書かれていると、読んだ人事担当者は「それで結局、何ができる人なの？」とあなたの強みを理解できません。今のあなたの核となる職歴が目に入るようにし、それ以外のものは適切に省略しましょう。

●数字で客観的・具体的に

これも、あなたが何ができるかをできるだけ正しく伝えるためです。営業職や販売職ではないから数字で表すことができない、という声をよく聞きますが、「数字で表す」というのは派手な売上達成や劇的なシェア奪回のことだけではありません。そんなスタープレーヤーはめったにいないことは企業側も理解しています。コンスタントな仕事ぶりを客観的・具体的に伝えることを考えましょう。

• NG例：営業成績は常にトップクラスです
• 書き換え例：全国300人の営業員の中で、受注金額ランキング14カ月連続でトップ10にいます
• NG例：在庫管理業務をミスなく慎重にやっています
• 書き換え例：在庫管理業務を24カ月ミスなしで担当しています

●意図、実行、結果、に分けてプロセスを書く

どんな仕事をしてきたか分かってもらう場合、数字で表すだけでは不十分です。意図、実行、結果、の3つが伝わるのがベターです。例えば、「売上金額○万円で年間トップでした」とだけ書かれても、どんなプロセスか分からなければ次に同じ結果を出せるかどうか疑問に思われます。たとえ失敗した案件であっても、そこから何を学んで次にどう活かしているかを書いたほうが評価につながることもあります。

●部署の異動

異動によって扱う商材や担当業務が変わった場合は書きますが、組織改編で部署名が変わっただけなら書かなくてよいでしょう。

●プロジェクト

エンジニア系の職種の場合はプロジェクト単位で業務が進むことが多いものです。プロジェクトの人数構成、開発期間、開発テーマ、予算など、規模と難易度がイメージできるように書きましょう。また、プロジェクト内でのあなたの役割も忘れずに。エンジニア以外の職種でも組織横断的なプロジェクトの経験はアピールしたほうがよいでしょう。

●社内用語、業界用語

社内用語を書くのはやめましょう。業界用語も同じ言葉を違う意味で使っている場合もあります。普段、なにげなく使っている言葉が相手に正しく伝わるか冷静に見直してみましょう。例えば、「定期メンテナンスを担当」とだけ書いてそれを人事担当者が読んだ場合、「定期」も「メンテナンス」も言葉としては分かるでしょうが、何の業務のことかは理解できません。ITエンジニアならシステムの見直しのことかもしれませんし、建築技術者なら修理・修繕のことかもしれません。

• NG例：定期メンテナンスを担当
• 書き換え例：既存顧客の契約内容を見直し、最適化した企画を提案
• NG例：部内QM事務局
• 書き換え例：企画部で四半期ごとに行う全体会議の事務局（準備・運営）

●キャリアの長い人

社会人経験が長くなると、年表のようにすべてを書こうとすると膨大な枚数になってしまいます。自分の強みに沿って適度な取捨選択が必要です。職務経歴書の本文は強みに絞って書き、割愛した部分は別添資料にする方法もあります。