職種で変えるのは3か所だけ
職務要約の一文目、スキル欄の並び順、実績に使う指標。この3つ以外は共通で使い回せます。
職務経歴書を職種ごとにゼロから書き直す必要はありません。経歴という事実は1つで、変えるのは見せ方だけです。
1職務要約の一文目
応募する職種で名乗る。ここで読み手の読み方が決まる
2スキル欄の並び順
求人票で挙がっている技術を上に。項目は変えず順番だけ変える
3実績に使う指標
同じ仕事でも、職種によって「効く数字」が違う
全体の骨格（職務要約 → 職歴 → スキル → 自己PR）はどの職種でも共通です。構成そのものは職務経歴書の書き方ガイドで確認してください。
職種別に書き直すのではなく
「前に出すもの」を入れ替える
職種別の見られ方（一覧）
同じ「開発をしていた」でも、職種によって評価される観点はまったく違います。
| 職種 | 採用側が最も見る点 | 実績に使う指標 |
|---|---|---|
| バックエンド | 設計判断と非機能要件への関与 | p95 / エラー率 / スループット |
| フロントエンド | 状態管理と分割の設計、体験の質 | LCP・CLS / バンドルサイズ / 離脱率 |
| インフラ・SRE | 可用性の設計とコード化、障害対応の型 | 稼働率 / MTTR / コスト / デプロイ頻度 |
| モバイル | リリース運用と端末差異への対応 | クラッシュ率 / 起動時間 / アプリサイズ |
| データ・ML | 基盤の設計と、事業指標への接続 | データ量 / 実行時間 / 鮮度 / 効果 |
| QA・テスト | 品質を仕組みで担保した経験 | 自動化率 / カバレッジ / 不具合の流出 |
| PM・テックリード | 意思決定の質と、チームへの波及 | チーム人数 / リードタイム / 事業KPI |
表の「採用側が最も見る点」が、職務要約の一文目で触れるべき内容です。ここが噛み合っていれば、続きも読んでもらえます。
職種別の書き方と職務要約の例文
各職種の書き出し例です。技術名と数字を自分のものに置き換えて使ってください。
① バックエンド
見られるのは設計判断と、性能・可用性といった非機能要件にどこまで関わったかです。スキル欄は「言語・フレームワーク → データベース → クラウド → ミドルウェア」の順が読みやすくなります。
BtoB SaaSのバックエンドエンジニア（実務6年）。Go / PostgreSQL で認証・権限基盤の設計から運用までを担当し、月間約120万リクエストのAPIでp95を1.8秒→320msに改善しました。障害対応と設計レビューを含め、非機能要件の担保を主に担当しています。
② フロントエンド
状態管理やコンポーネント分割といった設計の考え方と、表示速度・アクセシビリティなど体験の質が見られます。スキル欄は「フレームワーク → 言語 → ビルド・テスト → デザイン連携」の順に。
ECサイトのフロントエンドエンジニア（実務5年）。React / TypeScript で商品検索まわりのリニューアルを設計から担当し、画像の遅延読み込みとバンドル分割によりLCPを4.2秒→1.6秒に改善しました。デザイナーと並走しながら、体感速度に効く箇所から着手する進め方を得意としています。
③ インフラ・SRE
可用性をどう設計したか、それをコードとして再現可能にしているかが中心です。スキル欄は「クラウド → IaC → コンテナ・オーケストレーション → 監視」の順。
SRE（実務7年）。AWS / Terraform / Kubernetes を用いた基盤の設計・運用を担当。監視項目とアラートの棚卸し、手順書の整備により深夜の呼び出しを月8回→1回に削減し、月額インフラ費用も約37%削減しました。SLOの設定と障害の振り返り運用の立ち上げも担当しています。
④ モバイル
端末差異への対応と、ストア審査を含むリリース運用の経験が問われます。スキル欄は「言語 → アーキテクチャ → CI/CD → 計測基盤」の順。
iOSエンジニア（実務4年）。Swift / SwiftUI で会員向けアプリの開発を担当し、起動時間を2.4秒→0.9秒、クラッシュフリー率を98.2%→99.7%に改善しました。CI/CDを整備してリリース間隔を月1回→隔週に短縮しています。
⑤ データエンジニア・機械学習
基盤の設計だけでなく、それが事業の意思決定にどうつながったかまで書けると強くなります。スキル欄は「SQL・Python → データ基盤 → ワークフロー → ML/BI」の順。
データエンジニア（実務5年）。BigQuery / dbt / Airflow で全社のデータ基盤を構築し、日次バッチの実行時間を4時間→45分に短縮。売上指標の集計が翌朝に確認できる状態になり、営業チームの週次の意思決定に使われるようになりました。
⑥ QA・テストエンジニア
個別のテスト経験より、品質を仕組みで担保した経験が評価されます。スキル欄は「テスト設計 → 自動化ツール → CI → 分析」の順。
QAエンジニア（実務6年）。Webサービスのテスト設計と自動化を担当し、Playwrightによる回帰テストを整備してカバレッジを32%→71%に。リリース後の不具合流出を月平均4件→0〜1件に減らし、リリース前の検証時間も3日→半日に短縮しました。
⑦ PM・PdM・テックリード
何を決めたか、その結果どうなったかが主題です。技術の細かさより、意思決定とチームへの波及を書きます。スキル欄は「担当領域 → 進め方（スクラム等） → 技術（読める範囲）」の順。
テックリード（実務8年）。6名チームで会員基盤のリプレイスを技術リードとして推進し、旧システムを無停止で移行しました。レビュー観点の明文化と当番制の導入によりPRの平均マージ時間を3.5日→1日に短縮し、新メンバーが単独リリースできるまでの期間も3ヶ月→6週間に縮めています。
SES・受託でプロジェクト単位に書きたい場合は、スキルシートの書き方の形式が向いています。数字の作り方は実績を数字で書く方法を参照してください。
職種を変えるときの書き方
職種名ではなく「できること」でつなぎます。未経験の職種でも、地続きの経験は必ずあります。
バックエンド → SRE
運用・監視・障害対応の経験が地続き。負荷対策やデプロイ改善の実績を前に出す
フロントエンド → モバイル
画面設計と状態管理の考え方が共通。UIの計測と改善の経験を軸にする
SES・受託 → 自社開発
幅広い環境への適応力と、リリース後の改善に関わった経験を探して前に出す
開発 → PM・PdM
仕様の詰めや優先順位の判断に関わった場面を実績として書く。決めた経験が材料になる
職務要約では現職種で名乗ったうえで、移りたい理由と接続点を1文で示すのが基本です。「◯◯の経験を活かして△△へ」と書けば、読み手は経歴を新しい職種の目線で読み直してくれます。
未経験の領域については、学習した成果物を経歴に加えてください。転職理由そのものの伝え方は転職理由・退職理由の伝え方で解説しています。
応募先ごとの微調整
求人票を読んで、スキル欄の並び順と職務要約の一文目だけを合わせます。所要時間は5分です。
求人票の技術を上へ
募集要項に挙がっている言語・基盤を、スキル欄の先頭に移す。項目自体は増やさない
一文目を課題に寄せる
「レガシー刷新」の募集なら移行経験、「急拡大」なら負荷対策を一文目に置く
実績は動かさない
事実なので順番だけ変える。数字を応募先に合わせて盛るのは論外
自己PRの最後だけ書き換える
「御社の◯◯で活かしたい」の部分。ここが使い回しだとすぐ分かる
このサイトの作成ツールなら、スキル欄も職歴も並べ替えができるので、応募先ごとの調整が短時間で済みます。登録不要・無料で、データはブラウザ内にのみ保存されます。
よくある質問
Q.複数の職種を経験している場合はどう書けばいいですか？
応募する職種を1つ決めて、その視点で並べ替えてください。職務要約の一文目は応募職種で名乗り、スキル欄もその職種で使うものを上に置きます。他職種の経験は消す必要はなく、「フロントエンドも担当した経験があり、API設計時に呼び出し側の都合まで考慮できる」のように、応募職種にとっての強みとして書き換えると効きます。
Q.職種名は求人票に合わせて変えていいですか？
実態と合っている範囲なら問題ありません。同じ仕事でも会社によって「サーバーサイドエンジニア」「バックエンドエンジニア」「アプリケーションエンジニア」と呼び方が違うため、求人票の呼称に寄せた方が読み手はスムーズです。ただし実務内容が伴わない名乗り（実装中心なのに「テックリード」など）は、面接で確認された時に信頼を失います。
Q.スキル欄には何個くらい書けばいいですか？
実務で使ったものだけを、カテゴリごとに5〜8個までが目安です。触ったことがある程度のものまで並べると、本当に使えるものが埋もれます。書くなら「業務利用/学習中」のように習熟度を分けてください。並び順は応募先の求人票で挙げられている技術を上にします。
Q.職種未経験の分野に応募するときはどう書きますか？
未経験の職種でも、共通する部分は必ずあります。バックエンドからSREなら運用・監視の経験、フロントからモバイルならUI設計の経験が地続きです。職務要約では現職種で名乗ったうえで、「◯◯の経験を活かして△△へ移りたい」と意図を明示し、学習した成果物を経歴に加えてください。
Q.テンプレートは職種によって変えるべきですか？
変える必要はありません。読みやすい構成であればどのテンプレートでも通ります。ただしプロジェクト単位で細かく書きたいSES・受託系はプロジェクト欄が多いもの、1社での実績を厚く書きたい事業会社系は職歴ブロックが大きいものが書きやすい、という程度の相性はあります。
