エンジニアの書類選考では、技術力そのものより「何をどこまで担当したか」が見られます。同じプロジェクトでも、書き方次第で伝わる情報量はまったく変わります。ここでは構成と、各項目の書き方を整理します。
全体の構成
職務経歴書は、上から順に読まれるとは限りません。最初の10行で興味を持たれなければ、その先は読まれないと考えて構成してください。
推奨する構成は、職務要約（サマリ）、技術スタック、プロジェクト経歴、保有資格、自己PRの順です。要約を冒頭に置くことで、全体像が先に伝わります。
分量は2〜3ページが目安です。すべての案件を書く必要はなく、応募先に関係の深いものを選んで詳しく書くほうが効果があります。
技術スタックの示し方
技術名を羅列するだけでは、どこまで使えるのかが伝わりません。使用歴の長さと習熟度を分けて示してください。
例えば「業務で3年以上使用」「業務経験あり」「個人開発で使用」の3段階に分けると、読む側が判断しやすくなります。
触ったことがある程度の技術を並べすぎると、かえって信頼を落とします。面接で深掘りされて答えられないと、他の記載も疑われます。
プロジェクト経歴の書き方
プロジェクトごとに、規模・役割・課題・打ち手・結果の5つを書くと、読む側が理解しやすくなります。
規模は、チームの人数、開発期間、対象システムのユーザー数などで示します。役割は「バックエンド開発」だけでなく、設計に関わったか、レビューを担当したか、後輩の指導をしたかまで書きます。
課題と打ち手は、この書類で最も重要な部分です。「レスポンスが遅かった」という課題に対して、何を調べ、何を変えたのか。技術的な判断の根拠が伝わると、面接での話も広がります。
書くべきは「何を作ったか」ではなく「どんな判断をしたか」です。
成果を数字で示す
成果は、可能な限り数字で書いてください。「パフォーマンスを改善」ではなく「一覧APIの応答時間を平均1.2秒から0.3秒に短縮」と書くと、規模感が伝わります。
数字が出せない場合は、変化の内容を具体的に書きます。「手作業だったリリース手順を自動化し、作業時間を1回あたり2時間から10分に短縮」といった形です。
守秘義務がある場合は、具体的な数値を伏せて「◯割改善」「約◯倍」のように相対値で書きます。書けない理由を面接で説明すれば問題ありません。
書類以外で見せられるもの
コードを公開している場合は、そのリンクを添えると効果があります。ただし、更新が止まっているものや、完成度の低いものを出すと逆効果になることもあります。
公開できるコードがない場合でも、技術記事や登壇資料があれば同じ役割を果たします。理解を言葉にできることは、それ自体が評価の対象です。
業務のコードは公開できません。個人開発や学習用のリポジトリで、設計の意図をREADMEに書いておくと、伝わりやすくなります。
提出前の最終チェック
- 冒頭の要約だけで、経験の全体像が伝わるか
- 技術スタックの習熟度を段階で示しているか
- プロジェクトごとに、規模・役割・課題・打ち手・結果が揃っているか
- 成果を数字か、具体的な変化で書いているか
- 守秘義務に触れる情報を書いていないか
- 応募先に関係の薄い案件を削り、関係するものを詳しく書いているか
- 誤字と、技術名の表記ゆれがないか
よくある質問
- 職務経歴書は何ページが適切ですか。
- 2〜3ページが目安です。すべての案件を書くより、応募先に関係の深いものを選んで詳しく書くほうが効果があります。
- 成果を数字で書けない場合はどうしますか。
- 変化の内容を具体的に書いてください。「手作業だったリリースを自動化し、1回2時間から10分に短縮」のような書き方であれば伝わります。
- 公開できるコードがありません。
- 技術記事や登壇資料でも同じ役割を果たします。理解を言葉にできること自体が評価の対象です。
この記事について
- 作成・確認
- 仕事比較ガイド編集部（yoin studio）
- もとにした情報
- 官公庁など公的機関が公表している資料と、各転職サービスの公式サイトで確認できた内容。数値や制度に触れる場合は、確認できた範囲を明示し、断定的な表現を避けています。
- 編集の方針
- 出所を確認できない数値は掲載していません。口コミは引用元と参照日を明示しています。詳しくは編集方針をご覧ください。
- 最終更新日
- 2026年6月19日
内容に誤りを見つけられた場合は、お問い合わせよりご連絡ください。確認のうえ速やかに訂正します。