はじめに｜職務経歴書がなかなか書けない方へ
転職活動を始めると、最初に手が止まりやすいのが職務経歴書ではないでしょうか。
「何を書けばいいのか分からない」
「これで伝わるのか不安」
「職務要約や自己PRがうまくまとまらない」
私自身も、転職活動を始めた当初はまったく同じように悩んでいました。
ネットで調べると、職務経歴書の書き方やテンプレートはたくさん出てきます。
ただ、実際には「自分の場合はどう書けばいいのか」が一番難しかったです。
この記事では、私自身が転職活動の中で試行錯誤しながら整理していった内容をもとに、
・職務要約
・職務経歴
・経験、スキル
・資格
・自己PR
をどのように考えて書いていたのかをまとめます。
私は職務経歴書のプロではありませんが、だからこそ、
「最初にどこでつまずいたか」「どう考えると書きやすくなったか」を、実体験ベースでお伝えできると思っています。
これから職務経歴書を作る方や、すでに書いてはいるもののしっくりきていない方の参考になれば嬉しいです。
まずは「職務要約」から書くのがおすすめ
特に最初に着手しやすいのが、職務要約です。
職務要約は、これまでどのような業務を経験してきたのかを、時系列で短くまとめるパートです。
最初にここを書くことで、自分自身の経歴を整理しやすくなりますし、後続の「職務経歴」や「自己PR」にもつなげやすくなります。
また、読み手にとっても、最初に経歴全体の流れを把握できるため、
「どんな経験をしてきた人なのか」を短時間で理解してもらいやすい部分だと思います。
例えば、
・どんな案件で、どの領域に携わってきたのか
・開発工程を中心に経験を積んできたのか
・上流工程まで広がっているのか
・リーダー経験やマネジメント経験があるのか
といったキャリアの流れが一目で伝わるようにまとめるイメージです。
一見すると簡単な要約に見えますが、私が転職活動時に調べた中では、
学歴や過去の所属企業名、職務要約などをもとに、まず経歴全体の印象を確認されることが多いようでした。
特に職務要約は最初に読まれやすいため、ここに自分の強みや実績を簡潔に入れておくことが重要だと感じました。
そのため、職務要約は単なる経歴の要約ではなく、
「自分のどこを評価してほしいのか」を最初に伝える場だと考えた方が良いと思います。
例えば、
・何億円規模、何人月規模の案件だったのか
・何名のチームをまとめていたのか
・何年間その業務に携わっていたのか
といった数値が出せるなら、できるだけ入れた方が伝わりやすいです。
もし数値で表現しづらい場合でも、
・どのような関係者と関わっていたのか
・どのような状況で
・何を課題と捉えどう解決したのか
といった観点を入れることで、要約の説得力はかなり変わってくると思います。
私の場合は、リーダー経験を強みとして見てもらいたかったため、職務要約でもその点が伝わるように意識しました。例えば、あくまで一例ですが、以下のような書き方です。
〇名のチームを統括し、〇人月規模のプロジェクトを○○工程まで予定通り完了。
チームマネジメントに加え、基本設計やレビューにも参加し、〇部門や△部門との調整も担当。
マネジメントと開発の両面からチームを支援した。
このように、単に「リーダーをしていました」と書くよりも、
どの規模で、何を担い、どう動いていたのかまで伝えた方が、読み手にイメージしてもらいやすくなります。
逆に、NGになりやすいのは、以下のような抽象的な書き方です。
リーダーとしてチームをまとめました。
設計やレビューも担当しました。
これでも間違いではありませんが、
規模感や役割の重さが伝わりにくく、印象に残りづらいと感じました。
なお、私は職務経歴書のプロではないため、内容をブラッシュアップしていく段階では、
AIや転職エージェントに添削してもらうことをおすすめします。
自分では伝わっているつもりでも、第三者に見てもらうことで、
・何を強みとして出すべきか
・どこが分かりづらいか
・どこをもっと具体化した方がよいか
がかなり見えてきます。
まずは完璧を目指すのではなく、
職務要約から書き始めて、自分の強みを言語化していくことから始めるのが良いと思います。。
職務経歴は「何をしてきたか」と「何ができるか」が伝わるように書く
職務要約で全体像を書いたら、次は職務経歴です。
ここでは、これまで担当してきた案件や業務を時系列で詳しく書いていきます。
ただし、単に業務内容を並べるだけでは、読み手に強みが伝わりにくいと感じました。
私自身も最初は、
・基本設計を担当
・開発を担当
・テストを担当
のように、業務をそのまま並べる書き方をしていました。
ですが、それだけだと「何をやっていた人か」は分かっても、
「何ができる人か」までは伝わりにくいと思います。
そのため、職務経歴では少なくとも以下のような内容を意識して書いていました。
・プロジェクト概要、規模
・担当工程
・自分の役割
・実際の業務内容
・工夫したこと、達成したこと、成果や評価されたこと
例えば、
基本設計、詳細設計、テストを担当
だけで終わらせるよりも、
基本設計からテストまでを担当し、レビューや関係者調整にも関わった
のように書いた方が、自分の役割や立ち位置が伝わりやすくなります。
また、職務経歴で強みとして伝えられるのは、
・担当工程の広さ
・特定の言語や技術領域での経験
・レビューや品質改善への関わり
・不具合調査や障害対応を通じた安定運用への貢献
・チーム内での調整や推進の役割
など、さまざまあると感じました。
例えば、
Javaを用いた業務システム開発において、詳細設計から結合テストまでを担当。
実装だけでなく、不具合調査やレビュー対応にも継続的に関わり、品質向上に貢献。
あるいは、
保守開発案件にて、既存機能の改修や障害対応を担当。
問い合わせ対応や原因調査を通じて、安定運用に貢献。
といった書き方であれば、単なる作業の列挙ではなく、
どのような場面で価値を出していたのかが伝わりやすくなります。
また、チームをまとめる立場にあったのであれば、
・何名規模のチームだったか
・どこまで管理していたか
・どの部門と調整していたか
なども入れた方が、規模感や責任の重さが伝わりやすいです。
さらに、職務経歴は面接でかなり深掘りされる部分でもあります。
そのため、職務要約や自己PRとつじつまが合うように書いておくことも重要だと感じました。
例えば、職務経歴書では「上流工程を経験してきた」と書いているのに、
面接で詳しく聞かれたときに説明が曖昧だと、説得力が弱くなってしまいます。
そのため、「書類に書いたことを、面接でも自分の言葉で説明できるか」
を意識しておくと良いと思います。
職務経歴は長くなりやすいですが、
全部を細かく書くよりも、
・何を経験したのか
・どんな役割だったのか
・何を強みとして見てほしいのか
が伝わる形にすることが大切だと思います。
経験・スキルは「見てすぐ分かる形」で整理する
経験・スキル欄については、職務要約や自己PRのように文章で工夫するというより、
事実を分かりやすく整理して書くことが大切だと思います。
ここでは主に、
・言語
・フレームワーク
・OS / DB
・クラウド
・ツール
・業務領域
・マネジメント経験
などをまとめていました。
例えば、
・言語：Java、SQL、Python
・DB：Oracle、PostgreSQL
・クラウド：AWS
・ツール：Git、Jira、Backlog
・経験領域：販売管理、在庫管理、会計
・マネジメント経験：〇名チームの進捗管理、レビュー対応
といったように、カテゴリごとに整理して並べるだけでもかなり見やすくなります。
この欄では、無理に良く見せようとするよりも、
実際に使ったことがあるもの、経験したことがあるものを正直に書くことが大切だと感じました。
また、職務経歴に書いている内容とズレがないようにしておくことも重要です。
面接で聞かれたときに説明できないと、逆に印象が悪くなってしまうこともあると思います。
そのため、経験・スキル欄は盛るのではなく、
見た人が一目で分かるように整理することを意識すれば十分だと思います。
資格欄はシンプルに事実を整理する
資格欄については、経験・スキル欄と同様に、
余計に盛らず、取得している資格を分かりやすく整理して書くことが大切だと思います。
例えば、
・基本情報技術者
・応用情報技術者
・AWS Certified Solutions Architect – Associate
・簿記2級
といったように、取得した資格をそのまま記載すれば十分です。
もし資格取得年月まで書けるフォーマットであれば、
取得時期も合わせて書いておくと整理されて見えやすいと思います。
また、資格欄については、無理に数を多く見せようとするよりも、
実際に取得しているものだけを正確に書くことが大事だと感じました。
なお、資格がどこまで評価されるのか、実務経験と比べてどの程度意味があるのかについては、
私自身も転職活動の中で考えることが多かったため、別の記事で整理したいと思っています。
ここではあくまで、資格欄は事実をシンプルに記載するパートと考えておけば十分だと思います。
自己PRは「すごいこと」より「何を強みとして伝えたいか」を整理する
自己PRは、職務経歴書の中でも一番悩みやすい部分だと思います。
私自身も、ここが一番難しいと感じました。
というのも、職務経歴や経験・スキルは事実を書けばある程度形になりますが、
自己PRは自分の強みを自分の言葉でまとめる必要があるからです。
そのため、最初からきれいに書こうとするよりも、まずは
・自分はどんな場面で価値を出してきたのか
・何を強みとして見てほしいのか
・これまで周囲からどんな役割を期待されてきたのか
を整理するところから始めるのが良いと思います。
私が自己PRを書くときに意識していたのは、
職務要約や職務経歴で書いた内容とつながる強みを書くことです。
例えば、
・業務の吸収力
・課題解決力
・仮説思考力
・調整力
・推進力
といったように、エンジニアとしてどんな価値を出せるのかを、経験と結びつけて書くことを意識していました。
ただ、これらを単に並べるだけでは弱く、
実際の業務の中でどう発揮してきたか、どう評価されていたかまで書くことが大切だと思います。
例えば、業務の吸収力であれば、
新しい業務領域や技術に関わる際も、短期間でキャッチアップし、早い段階で実務に入れるよう意識してきた。実際に、新しい案件や業務を任されることも多く、立ち上がりの早さは強みの一つだと感じている。
課題解決力であれば、
不具合対応や業務課題に対して、原因を整理しながら解決策を考え、関係者と連携しながら改善につなげてきた。実際に、原因調査や整理が必要な場面で相談を受けることもあり、課題を落ち着いて整理する力は評価されていたと思う。
仮説思考力であれば、
仕様が曖昧な場面や課題が複雑な場面でも、現状を整理しながら仮説を立て、確認と修正を繰り返しながら前に進めてきた。要件が固まりきっていない場面でも、まず整理して進める役割を担うことが多かった。
といった形です。
このように、自己PRでは
「自分は〇〇力があります」と言い切るだけでなく、業務の中でどう発揮してきたかまで伝えることが、説得力を持たせるうえで重要だと感じました。
また、自己PRに書く強みは、職務経歴とつながっていることも大切です。
例えば、保守開発や障害対応の経験が多いのであれば課題解決力や安定運用への貢献が自然ですし、上流工程や顧客折衝に関わっているのであれば、仮説思考力や調整力の方がしっくりきます。
そのため、自己PRは無理に“すごそうな言葉”を使うよりも、
これまでの経験から自然に出てくる強みを、エンジニアとしての価値に言い換えていく
イメージで書くのが良いと思います。
まずは完璧な自己PRを作ろうとするのではなく、
「自分はどんな場面で価値を出してきたのか」を振り返るところから始めるのがおすすめです。
さいごに
職務経歴書は、転職活動の中でも特に手が止まりやすいものだと思います。
私自身も、最初は何を書けばよいのか分からず、かなり悩みました。
ただ、実際に転職活動を通して感じたのは、
最初から完璧なものを作ろうとしなくてよいということです。
まずは、
・職務要約で経歴の流れを整理する
・職務経歴で役割や成果を書き出す
・経験、スキルや資格を分かりやすく整理する
・自己PRで自分の強みを言語化する
といった形で、一つずつ形にしていけば十分だと思います。
また、職務経歴書は一度作って終わりではなく、
見直したり、添削してもらったりする中で少しずつ良くしていくものだと感じました。
私自身も、AIやエージェントに見てもらいながら修正を重ねることで、
少しずつ「伝わる形」に近づけていった感覚があります。
まずは完璧を目指すのではなく、
いったん書いてみること、自分の経験を言葉にしてみることから始めるのがおすすめです。
この記事が、少しでも職務経歴書を書く際の参考になれば嬉しいです。
コメント