エンジニア職務経歴書の書き方

読者は採用担当と現場エンジニアです。最初の2ページで、どの領域のどの役割の人かが分からないと、後段の成果は読まれません。職種名、担当工程、自分で決めた範囲を先に書いてください。

職務要約

経歴の時系列ではなく、今応募する職種に直結する経験を3〜5行で圧縮した段落です。

STAR

Situation（状況）、Task（役割）、Action（自分の行動）、Result（結果）の順で1案件を説明する型です。

確認できる数字

自分で測った、チケットやログで残っている、上司と共有した指標など、面接で出典を言える量です。

書かない情報

未公開の仕様、顧客名、個人が特定できる記録、社内の未発表数字、他社比較で得た非公開情報です。

マイクロサービス化を推進、だけでは何をした人かが分かりません。案件は全部列挙せず、応募職種に効くものを2〜4件選び、各件をSTARで埋めます。長いプロジェクトでも、役割が変わった地点で段落を分けます。

本文に言語を並べると熟練度が見えません。表で、業務で使った期間の目安と、自分で設計したか既存コードを直したかを分けます。期間は概数で構いません。分からなければ空欄にします。

処理件数を大幅に改善、は検証できません。件数が言えるなら、計測期間と計測方法も同じ行に書きます。言えないなら、数字の行ごと削除します。他媒体の平均年収や市場シェアを自分の実績にしてはいけません。

• 数字の分母と期間を、面接で1分で説明できる
• 個人の成果とチームの成果が混ざっていない
• 顧客や社内向け資料の非公開指標を転記していない
• 他媒体の平均年収や市場シェアを自分の実績にしていない
• 約を使う場合も、根拠の置き場がある

守秘義務は退職後も残ることがあります。顧客の正式名称、未発表機能、個人が特定できる記録は書きません。汎用的な表現、たとえば大手小売、決済連携、社内向け管理画面、に置き換えます。迷ったら出さない方が安全です。情報の取り扱いはIPAの公開ガイドで組織側の観点も確認できます。

• 顧客名

  契約で禁止されていなくても、公開情報でないなら業界カテゴリにします。

• 障害の詳細

  権限設計を見直した、まで。再現手順や未公開の不具合は書かない。

• ソースコード

  社内リポジトリの抜粋は貼らない。公開してよい個人リポジトリだけ別紙にする。

• 年収と評価

  現職の報酬や人事評価ランクは職務経歴書に不要です。条件交渉は別タイミングです。

1つの長期プロジェクトでも、役割が変わっていれば段落を分けます。逆に、短い改修を10件並べると深さが分かりません。応募職種のよくある1日に近い案件を厚くします。

1. 01
   時系列の骨格を作る

   所属、期間、職種名を年表にします。空白期間があるなら事実を短く書き、創作しません。

2. 02
   応募軸で案件を選ぶ

   バックエンド応募ならAPIとデータ、運用寄りの応募なら障害と監視を残します。関係ない華やかな案件は削ります。

3. 03
   各案件にSTARを1セット

   SituationからResultまで4文以上あるか確認します。Actionがチームで対応だけなら、自分の手を追記します。

4. 04
   技術表と本文を突き合わせる

   本文に出てこない技術を表に残さない。表だけ詳しい状態は不信感になります。

同じ原本を全社に送ると読まれません。原本は1つ持ち、1枚目の要約と先頭案件だけ差し替えます。エージェント経由でも、原本の責任は自分にあります。

• 事業会社向けは、利用者と業務制約を厚くする
• 受託寄りの応募は、担当工程と契約上の切れ目を書く
• マネジメント応募は、人数より何を決めたかを書く
• 専門職応募は、設計判断と障害対応を厚くし、会議の話は薄くする

誤字より先に、出してはいけない情報と数字を見ます。次に、面接で10分話せる案件が2つかを確認します。話せない行は削ります。

• 連絡先と希望職種が1枚目にある
• PDFで開いても表が崩れない
• ファイル名に社外秘の案件名を入れてない
• GitHubやブログは公開してよいものだけリンクしている

• スキルシートだけ送る

  言語の習熟度表は補助です。STARのないスキルシートは、何をした人かが残りません。

• 全部の案件を同じ分量にする

  古い案件は1行で十分です。直近と応募軸に紙面を使います。

• コミュニケーション能力で埋める

  会議の回数ではなく、誰と何を決めたかを書きます。

職務経歴書は面接の台本ではありませんが、面接で初めて出す事実を書類と矛盾させないことが信頼です。条件の最終確認は応募先の公式情報と面談で行ってください。

実装だけを書くと、シニア採用では判断が見えません。レビューで何を止めたか、リリースで何を見送ったかを1件入れると、責任の取り方が伝わります。止められなかった判断も、当時の制約を書けばSTARになります。

SREの公開資料は、障害対応の話し方の参考になります。自社の数字を、公開事例の数字に置き換えないでください。自分の現場で観測できた範囲だけを職務経歴に載せます。

担当者が要約を短くする過程で、STARのActionが消えることがあります。推薦文と原本を並べ、自分が説明できない修飾語を戻してください。技術領域に詳しい担当でも、あなたの1日は知りません。

1. 01
   原本の差分を見る

   削られた文が、面接で聞かれやすい判断かどうかを確認します。判断が消えていたら戻します。

2. 02
   職種名の揺れを止める

   エンジニア、メンバー、リーダーが混在すると読み手が迷います。社内呼称と、応募職種での言い換えを1行で注記します。

3. 03
   提出形式を揃える

   PDF、ファイル名、顔写真の要否は案内に従います。不要な顔写真や現住所の詳細は、求められていないなら最小にします。

選考が進むたびに全文を書き直す必要はありません。落ちた面接で説明が詰まった案件だけを直します。直した日付をファイル名か冒頭に残すと、古い版を送る事故を減らせます。

• 四半期に一度、技術表の関わり方を見直す
• 異動や役割変更があったら、段落の切れ目を増やす
• 公開ポートフォリオのリンク切れを確認する

職業の呼び名は厚生労働省のjob tagでも確認できます。社内だけの職種名しか無いときは、近い公開職種名を括弧で添えると、エージェントと採用側の翻訳が楽になります。ぴったり一致しない場合は、無理に寄せず、作業内容を優先してください。

採用側は、全行を同じ速度では読みません。1枚目の要約で職種が取れない書類は、技術表がいくら正しくても後回しになります。逆に、要約だけが上手で案件のSTARが空だと、面接で初めて中身を聞くことになり、時間が溶けます。書類の役割は、面接の質問を具体にすることです。質問が抽象のまま終わる書類は、まだ原本ではありません。

受託と事業会社では、同じ実装でも評価される切り口が違います。受託では契約範囲と担当工程、事業会社では利用者と継続運用が見られやすいです。原本を1つ持つ方針は変えず、1枚目と先頭案件だけを応募先の切り口に寄せます。全部の案件を毎回書き換えると、数字の根拠がずれます。ずらさないために、確認できる数字は別メモに出典を残してください。出典が無い数字は、その場で消します。

チームの人数、売上、ユーザー数は、自分が測ったものでない限り載せない方が安全です。公開されている範囲でも、面接で計測方法を聞かれたときに答えられないなら、職務経歴の成果としては弱いです。代わりに、自分が変えた手順、残したチェック、止めたリリース、直した権限を書いてください。地味でも、再現できる仕事はエンジニア採用では追いやすいです。華やかさより、翌日の自分が同じ判断をできるかが書類の質です。

提出後に気づいた誤りは、次の面接の冒頭で訂正して構いません。黙って矛盾を残す方が損です。ただし、出せない情報を後から足すことはしません。足りないのは事実の精度であり、秘密の量ではありません。エージェントが急かしても、原本の最終責任は自分にあります。職種理解の補助にjob tagを使い、試験の正式名称にIPAを使い、出せない情報の判断に公開セキュリティガイドを使ってください。いずれも年収や合格を保証する資料ではありません。

ファイル名に案件名や顧客名を入れない、PDFで表が崩れない、1枚目に連絡先がある。この3つは中身より先に見られます。中身では、面接官が10分深掘りできる案件が2つあるかが本体です。2つ未満なら、案件を増やすより、既存のSTARのActionを厚くします。10件の薄い案件より、2件の厚い案件の方が、形式が違う面接でも転用できます。コーディング面接では技術表の深さ、行動面接では失敗の時系列、設計面接では制約の切り方に、同じ原本から枝を出せます。

エージェントの添削は、業界用語の翻訳には使えます。翻訳結果を自分が説明できないなら、元の文に戻します。英語版が必要な応募だけ英訳し、日本語に無い成果を英語だけに足しません。資格は正式名称と取得年月を別欄に置き、成果の代わりにしません。IPAの試験は出題範囲が公開されているので、学習範囲の説明には向きます。合格そのものが、障害対応や設計判断の証明にはなりません。公開してよいポートフォリオだけをリンクし、リンク切れを提出前に確認してください。

更新は、落ちた面接で詰まった案件だけを直すのが基本です。全文を毎回書き直すと、確認できる数字の出典がずれます。ずれた数字は、次の面接で信頼を削ります。役割が変わった四半期だけ、段落の切れ目を増やす。技術表の関わり方は、設計したか運用したかが変わるときだけ直す。この運用にすると、原本が面接のたびに別人になりません。別人になった書類は、どの経路で出しても、読み手の最初の疑問を増やします。疑問を減らすことが、ページ数の議論より先です。

• 面接で話す案件と、書類の先頭案件が一致している
• 技術表にだけある技術が、本文のSTARに一度は出る
• 確認できない人数、売上、改善率を消した
• 提出先ごとに1枚目だけ差し替え、数字の出典は共通メモにある

職務経歴書の書き方は、完成した人の話ではなく、次の面談までに1案件を厚くする作業です。秘密を足して厚くする必要はありません。自分の動詞と、観測できた変化と、決められなかった制約を足してください。それが面接対策の入力になり、エージェントの初回資料になり、求人票を読むときの照合先になります。条件の最終確認は、応募先の公式情報と面談と、必要なら労働条件の書面で行います。書類はその前段の地図です。