「職務経歴書の書き方を知りたい！」
「自己PRでアピールすることがない…」
Findyでエンジニアの方の転職活動サポートを行っているユーザーサクセスメンバーが、エンジニアの職務経歴書の書き方やポイントについて解説します。
自己PRの書き方やNGな職務経歴書の例なども紹介していますので、ぜひ最後までお読みください。
相馬 遥香
2021年7月にFindyにジョイン。2021年に国家資格キャリアコンサルタントを取得。
※Findyでは主に自社開発のWeb企業の掲載が多いため、企業によっては傾向が異なる場合がございます。あらかじめご了承ください。
Webエンジニアが職務経歴書を書く前に知っておいてほしいこと
職務経歴書の書き方をご紹介する前に、前提となる考え方を共有します。
職務経歴書に限らず、選考における採用担当者の最大の関心事は「候補者が企業に入社した場合に、ミスマッチなく働けて、活躍（成長）できるかどうか」です。
職務経歴書で「ミスマッチなく働けて、かつ活躍（成長）できる」ことを伝えるためには、主に下記2つの項目をわかりやすく記載しなければなりません。
会社の方針やカルチャーと自身の志向性があっているか
強みやこれまでの実績によって会社の課題を解決できるか
難しいのは、要件を満たしているかを職務経歴書上のどこで判断するかは、企業ごとに異なるということ。
例えば、文化・カルチャーとのマッチ度合いを重要視している企業であれば、職務経歴書の「自己PRや志望動機（やりたいこと）」などから人間性や志向性をチェックする傾向があります。
またこれからエンジニア組織をグローバル化していく方針を掲げている企業では、英語力の有無を確認されるため、職務要約などで英語力をアピールできるとベターです。
ミスマッチなく働けて、かつ活躍（成長）できるかどうかは「選考を通過するため」という観点でも重要ですが、転職後に不幸にならないようにする意味合いでも重要なため、内容はしっかり練りましょう。
職務経歴書に「何を書くか」だけでなく「どう書くか」も大事
職務経歴書上では、「何を書くか」だけでなく「どう書くか」も重要なポイントの一つ。
採用担当者が一人の書類選考にかけられる時間には限りがあります。
そのため採用担当者が読んで瞬間的に「この人に会ってみたい！」と思わせられるような職務経歴書を作成しなければなりません。
また職務経歴書は書類選考後の選考プロセスでも面接官が事前情報として参照するため、職務経歴書の記載がわかりにくいと、その後の選考プロセスでもマイナスに影響してしまう可能性もあります。
これらの背景から、職務経歴書の記載内容を整理してわかりやすくすることはもちろん、志望度が高い企業であれば、記載方法や内容を多少調整するのがベターと言えるでしょう。
Findyではユーザーサクセス面談を実施しており、職務経歴書の添削も行っています。
選考を受ける企業が重要視している箇所の伝達や、わかりやすい記載をするためのアドバイスも行っていますので、ぜひお気軽にご相談ください！
項目別のWebエンジニアの職務経歴書の例と書き方
ここからは職務経歴書の項目ごとに、具体的な書き方をご紹介します。
※職務経歴書の記載例・フォーマットは記事の最下部でご紹介しているため、興味のある方はぜひご覧ください。
職務要約
職務要約は自分自身のキャリアを200〜400字程度の文章で端的にまとめます。
これまで4年間に渡り、バックエンドエンジニアとしてシステム開発に従事しています。
1社目では、求人サイトサービスのAPI新規・保守開発を行いました。主に開発（詳細設計、実装、テスト、リリース作業）を担当。開発初期は他社から引き継いだコードが散乱していたため、Docker Composeを使った開発環境に置き換えて統一し、開発スピードを上げることに成功しました。
2社目ではファインディ株式会社に入社後、Findyの開発・運用（バックエンド・インフラ中心）に従事。プロダクトマネージャーと協力してロードマップの策定・推進もしました。
職務経歴が長く経験が多岐に渡る場合は、まんべんなく書こうとすると冗長な印象を与えてしまうため、応募する職種で求められているであろう職務・実績に絞って記載することをおすすめします。
職務経歴
職務経歴欄には、勤務先の企業名や業務内容、実績などを企業ごと・プロジェクトごとに記載します。
採用担当者は現在のスキルセットに関心が高いケースが多いので、直近の経歴が一番上に来るように記載することをおすすめしています。
職務経歴欄では、候補者が入社後に活躍してくれそうかどうかを「異なる環境でその人がどう振るまってきたか」から判断しています。
そのため担当業務や経験年数だけを記載するのではなく、「どんな環境で、どんな課題があり、何を実行して、どんな結果になったのか」まで記載することが重要です。
▼よくある職務経歴の記載例
| 期間 | 2021年4月〜2022年6月 | |
| 職種 | バックエンドエンジニア | |
| 役割 | メンバー | |
| 仕事内容 | 求人サービスのシステム開発 | |
| チーム規模 | 20人 | |
| プロジェクト詳細・担当業務・主な実績 |
▼担当業務
| |
| 利用技術 | PHP、Laravel、GraphQL、Docker、GitHub、SendGrid、Terraform、MySQL、AWS |
例えば上記のような記載だと、採用担当者が「どの程度その技術に関して理解があるのか」「課題に対してどのような工夫をするのか」を判断できません。
1年のみの経験で大きな実績を残した人もいれば、5年経験していても技術理解が浅いというケースもあり得ます。
そこでFindyでは「STAR」というフレームワークの活用をおすすめしています。
▼STARのフレームワーク
- Situation（どんな環境で）
- Task（どんな課題があって）
- Action（何を実行して）
- Result（どんな結果を出したか）
フレームワークに沿って記載をした例が下記です。
| 期間 | 2021年4月〜2022年6月 | |
| 職種 | バックエンドエンジニア | |
| 役割 | メンバー | |
| 仕事内容 | 求人サービスのシステム開発 | |
| チーム規模 | 20人 | |
| プロジェクト詳細・担当業務・主な実績 |
▼担当業務
▼詳細
開発初期は他社から引き継いだコードが散乱しており、開発者ごとのローカル環境に依存した環境となっており、開発者同士差分が起きて開発がままならない状況でした。 GraphQLの導入にあたり、以前のプロジェクトでの知見を活かし、ドキュメントが充実しているLighthouseを選択し、開発を行いました。 | |
| 利用技術 | PHP、Laravel、GraphQL、Docker、GitHub、SendGrid、Terraform、MySQL、AWS |
また実績部分は可能な限り数値で表すことも大切です。
例えば「キャッシュヒット率●割→×割にした」や、「APIレスポンス速度を●ms→×msにできた」など、具体の数値がわかると採用担当者の理解が進みやすくなります。
（ただしエンジニアの仕事は数値化が難しいケースもあるため、可能な限りで問題ありません。）
なお全ての職歴でSTARのフレームを使って記載してしまうと、職務経歴書全体が長くなり過ぎてしまうため、特にアピールしたい項目のみに絞りましょう。
言語経験・スキル
「言語経験・スキル」には、経験した言語とその年数をまとめます。
◼︎言語経験・スキルの記載例
| カテゴリ | 種別 | 経験年数 |
|---|---|---|
| プログラミング言語 | Ruby | 2年 |
| PHP | 1年 | |
| フレームワーク | Ruby on Rails | 2年 |
| Laravel | 1年 | |
| クラウド | AWS | 3年 |
| DB | SQL Server | 3年 |
採用担当者は言語ごとの経験年数から、応募者のスキル感をおおまかに把握しています。
（経験年数で全てを判断することはできませんが、全体感を把握するという意味合いでは経験年数も参考にされます。）
なお経験年数が1年未満で自信がなく、かつ今後も取り組みたくない言語であれば、言語経験として記載しなくても問題ありません。
自己PR
自己PRはアピールしたい内容を200〜300文字程度で2〜3つ記載します。
開発スピードの意識を高く持っています。
例えば、レビューへのレスポンスを依頼しても反応がなかなか返ってこない場合、モチベーションの低下にもつながってしまいます。
そのためレビューのレスポンスを早くすることで、開発スピードが上がり、試行錯誤できる余地も増えるため、より洗練されたものができるようになると考えています。
●●の開発では、複数箇所の修正を一つのプルリクエストで作っていて、レビューが返ってくるまでに1日以上かかっていました。先輩社員からレビューしやすいようにPRの単位を小さくするようにアドバイスを受けて改善をし、数十分から数時間でレビューを返してもらえるようになりました。
このプロジェクト以降、スピードの意識がつき、求人サイトサービスシステムではメンバーにPRを小さくすること、レビューへの意識を上げることを伝え、開発スピードの向上に繋げることができています。
「この会社には〜〜な課題（方針）があって、それを自身の〜〜〜という経験やスキルで貢献できる」という内容を整理できると、採用後の活躍イメージがわきやすくなります。
例えば、ファインディ株式会社では、バリューの一つに「チームワーク」が存在し、チームで働くことが求められていそうな会社だと判断できます。
そのため自己PR欄でも技術的な強みだけでなく、チーム外の人と協力して結果を出したエピソードなどがあるとよりよくなります。
こうした企業ごとの課題や方針を把握するためには、求人票の内容に加えて以下の方法が有効です。
- HPやインタビュー記事など対外的に出ている情報のチェック
- カジュアル面談での課題ヒアリング
ユーザーサクセス面談では、これまでの経験・エピソードから「〜〜なポイントをPRできそう」というアドバイスもできるため、お気軽にご相談ください。
志望動機・この先やりたいこと
志望動機は必ず書かなければいけないわけではありません。
「今までの〜の経験を活かして新規立ち上げに携わりたい」など、やりたいことが自己PRや企業の課題・方針とも結びついていると好印象を与えやすくなります。
一方で自分に矢印が向きすぎるような一方的な内容だと、「主張が強すぎる」「協調性がない」という印象を与えてしまう可能性もあるため注意が必要です。
登壇実績・資格・技術ブログ
登壇実績や資格、技術ブログ等も志望動機と同様、特筆してアピールをしたいことがある場合のみ記載で問題ありません。
もし記載をする場合は、「いつ・どんなイベント（資格）に登壇（取得）したのか」がわかるように、箇条書き等で記載をしましょう。
こんな職務経歴書はNG？エンジニアが気をつけるべきポイント
職務経歴書でマイナス評価を受けないために注意すべきポイントをまとめました。
長すぎる職務経歴書は読まれづらい？3〜4ページにまとめる
冒頭でもお伝えしたとおり、採用担当者は日々多くの職務経歴書をチェックしています。
あまり長すぎると最後まで読んでもらえないだけでなく、「見る側の視点を加味できない」と判断されてマイナスの評価につながってしまうこともありえます。
明確な基準はありませんが、目安として3〜4ページ以内には収めるようにしましょう。
経歴が長い場合はアピールする箇所の優先順位を決めます。
職務経歴書は職務やスキルを伝える目的がメインのため、技術・スキルに関する内容を優先して書くようにしましょう。
職務経歴書の誤字脱字はNG！
職務経歴書の誤字・脱字はエンジニアの場合、特に厳しくチェックされます。
採用担当者によっては、「職務経歴書で誤字・脱字をするということは、プログラミングでミスをしやすい人なのではないか」という判断をするケースもあります。
ご自身で見直すことはもちろん、可能であれば第三者にみてもらって確認することをおすすめします。
- 職務経歴書で大事なのは、「自分が企業に入社した場合に、ミスマッチなく働けて、活躍（成長）できるかどうか」を採用担当者に伝えること
- 「何を書くか」だけでなく「どう書くか」も重要で、内容の整理は必須
- 企業の課題や方針を企業HPやインタビュー記事から把握して、自身の経験や強みと紐づける
職務経歴書に困ったらFindyユーザーサクセスにご相談ください
ここまででエンジニアの職務経歴書の書き方やポイントについてお伝えしてきました。
「職務経歴書に書く内容が思い浮かばない…」「添削して欲しい」という方はぜひユーザーサクセス面談をご利用ください。
初回の面談では職務経歴書を全く埋めていなくても構いません。
これまでのご経験をヒアリングしながら、一緒に職務経歴書を作成していきましょう。
またFindyのユーザーサクセスチームでは、職務経歴書の添削や求人紹介などのほかにエンジニアのキャリアに関する相談も受け付けています。
どんなに些細なご相談でも構いませんので、ぜひお気軽にご参加ください！
エンジニアの職務経歴書の見本・フォーマット
20××年×月×日
氏名：〜〜〜〜
◼︎職務要約
これまで4年間に渡り、バックエンドエンジニアとしてシステム開発に従事しています。
1社目では、求人サイトサービスのAPI新規・保守開発を行いました。主に開発（詳細設計、実装、テスト、リリース作業）を担当。開発初期は他社から引き継いだコードが散乱していたため、Docker Composeを使った開発環境に置き換えて統一し、開発スピードを上げることに成功しました。
2社目ではファインディ株式会社に入社後、Findyの開発・運用（バックエンド・インフラ中心）に従事。プロダクトマネージャーと協力してロードマップの策定・推進もしました。
◼︎職務経歴
| 2022年〜現在 ファインディ株式会社 |
|---|
|
事業内容：エンジニア向けの転職サービス 資本金：22億5764万円（2023年11月時点） 従業員数：182人 上場：非上場 |
| 期間 | 2022年7月〜現在 | |
| 職種 | バックエンドエンジニア | |
| 役割 | メンバー | |
| 仕事内容 | エンジニア向け転職サービスの開発・運用 | |
| チーム規模 | 30人 | |
| プロジェクト詳細・担当業務・主な実績 |
▼担当業務
スクラムが回っていない状況でしたが、プロジェクト状況を押さえて、ボトルネック解消や開発プロセスを整えることで安定的にリリースができるようにしました。 | |
| 利用技術 | Ruby on Rails、MySQL、Docker、AWS、Docker、GitHub、Datadog、Sentry、Terraform、BigQuery |
| 2020年4月〜2022年6月 株式会社●● |
|---|
|
事業内容：〜〜サービス 資本金：●億円（2023年11月時点） 従業員数：200人 上場：非上場 |
| 期間 | 2021年4月〜2022年6月 | |
| 職種 | バックエンドエンジニア | |
| 役割 | メンバー | |
| 仕事内容 | 求人サービスのシステム開発 | |
| チーム規模 | 20人 | |
| プロジェクト詳細・担当業務・主な実績 |
▼担当業務
▼詳細
開発初期は他社から引き継いだコードが散乱しており、開発者ごとのローカル環境に依存した環境となっており、開発者同士差分が起きて開発がままならない状況でした。 GraphQLの導入にあたり、以前のプロジェクトでの知見を活かし、ドキュメントが充実しているLighthouseを選択し、開発を行いました。 | |
| 利用技術 | PHP、Laravel、GraphQL、Docker、GitHub、SendGrid、Terraform、MySQL、AWS |
| 期間 | 2020年4月〜2021年3月 | |
| 職種 | バックエンドエンジニア | |
| 役割 | メンバー | |
| 仕事内容 | ECサービスのシステム開発 | |
| チーム規模 | 10人 | |
| プロジェクト詳細・担当業務・主な実績 |
▼担当業務
短期間ではあるものの、サービスのリーダーとして方向性や戦略、進捗管理なども担当しました。 | |
| 利用技術 | Ruby on Rails、MySQL、AWS、Nginx/Unicorn、GitHub、CircleCI、Hubot、Vagrant/Chef |
◼︎言語経験・スキル
| カテゴリ | 種別 | 経験年数 |
|---|---|---|
| プログラミング言語 | Ruby | 2年 |
| PHP | 1年 | |
| フレームワーク | Ruby on Rails | 2年 |
| Laravel | 1年 | |
| クラウド | AWS | 3年 |
| DB | SQL Server | 3年 |
◼︎自己PR
開発スピードの意識を高く持っています。
例えば、レビューへのレスポンスを依頼しても反応がなかなか返ってこない場合、モチベーションの低下にもつながってしまいます。
そのためレビューのレスポンスを早くすることで、開発スピードが上がり、試行錯誤できる余地も増えるため、より洗練されたものができるようになると考えています。
●●の開発では、複数箇所の修正を一つのプルリクエストで作っていて、レビューが返ってくるまでに1日以上かかっていました。先輩社員からレビューしやすいようにPRの単位を小さくするようにアドバイスを受けて改善をし、数十分から数時間でレビューを返してもらえるようになりました。
このプロジェクト以降、スピードの意識がつき、求人サイトサービスシステムではメンバーにPRを小さくすること、レビューへの意識を上げることを伝え、開発スピードの向上に繋げることができています。
以上
