2026.04.14 2026.04.24

バックエンドエンジニアの職務経歴書の書き方｜例文つきで徹底解説

ショクレキ代行

📌 この記事でわかること

採用担当者がバックエンドエンジニアの職務経歴書で本当に見ているポイント
レスポンスタイム・スループット・可用性など「パフォーマンス数字の出し方」
API設計・DB最適化・インフラ・マイクロサービスなど業務別の書き方
書類が通らないバックエンドエンジニアに共通する失敗パターン
経験年数別（若手・中堅・ベテラン）のアピールポイントの違い
NG例・改善例つきで今日から使える書き方を解説

「実装もAPI設計もDB最適化もやってきたのに、職務経歴書でうまく伝えられない」「技術スタックを並べるだけでいいのか迷っている」バックエンドエンジニアの転職活動でよく聞く悩みです。複雑なバックエンド処理を設計・実装し、パフォーマンスを改善してきた経験は確かな実力なのに、それを採用担当者に伝わる書き方ができていない方がほとんどです。

書類が通らない原因の多くは、「何をしたか」は書けていても「どんな規模のサービスで・どんな技術的課題を解決し・どんな成果を出したか」が伝わっていないことにあります。採用担当者はバックエンドエンジニアの職務経歴書を通じて「スケーラブルなシステムを設計・実装できる人か」「パフォーマンスと品質を両立できるか」を判断しています。

この記事では、バックエンドエンジニアが転職活動で使える職務経歴書の書き方を、具体的な例文・NG例・経験年数別のアドバイスとあわせて解説します。

採用担当は何を見ている？

バックエンドエンジニアの採用担当者が職務経歴書で確認しているのは、主に次の3点です。

観点	内容
どんな規模・トラフィックのサービスを担当してきたか	MAU・DAU・月間リクエスト数・DB規模・チーム人数など、サービスの規模感を確認している
技術的な課題をどう解決してきたか	パフォーマンス改善・スケーラビリティ対応・可用性向上・セキュリティ対応など、技術的な解決策と成果を見ている
技術スタックの使いこなした実績があるか	言語・フレームワーク・DB・ミドルウェア・インフラと「どのプロジェクトで・どう使ったか」の対応関係を確認している

ポイント

採用担当者の視点：「バックエンドエンジニアの職務経歴書で評価が高いのは、サービスの規模感と技術的な問題解決の両方が書いてある人。『レスポンスタイムを○msから○msに改善した』や『月間○億リクエストを処理するAPIを設計した』という具体性があると、実力のイメージが一気につかめる」

よくある失敗（書類が通らない人に共通する3つのパターン）

パターン①：サービスの規模感が一切わからない

「ECサイトのバックエンド開発を担当しました」という記述では、採用担当者には何も伝わりません。「月間流通総額約5億円・MAU約30万人のECサイトのバックエンド開発チーム（5名）に参画」という情報があるだけで評価が大きく変わります。

パターン②：「実装しました」で終わっていて技術的な工夫が見えない

「REST APIの設計・実装を担当しました」という記述では、技術力が判断できません。「月間約5億リクエストを処理するREST API（Python/FastAPI）を設計・実装。N+1クエリの解消とElastiCacheによるキャッシュ導入で、95パーセンタイルレスポンスタイムを850msから180msに改善した」のような記述が評価されます。

パターン③：技術スタックの羅列で「使える」かどうかが判断できない

「Python・Go・Java・PostgreSQL・MySQL・Redis・AWS・GCP・Docker・Kubernetes…」と並べるだけでは、実務で使えるレベルかどうかが判断できません。技術とプロジェクト・技術的な成果の対応関係を書くことが重要です。

注意

「守秘義務があってサービスの詳細を書けない」という方へ：サービス名・クライアント名は伏せて構いません。「toB向けSaaSサービス（契約企業数約800社・月間APIリクエスト数約5,000万件）」のように、業種・規模・性質で代替することで採用担当者には十分伝わります。

書き方のポイント｜バックエンドエンジニアならではの伝え方

ポイント①：サービス規模とアーキテクチャを冒頭に明記する

「MAU約50万人のBtoCサービス（日次バッチ処理：約2億レコード）のバックエンドチーム（6名）に所属。Go言語を使ったマイクロサービス化と、PostgreSQL・Redisを組み合わせたデータ層の設計・実装を担当」のように、サービス規模・使用技術・自分の役割を冒頭に書きましょう。

ポイント②：パフォーマンス改善は「施策前→施策後」の数字で書く

バックエンドエンジニアの実績は「レスポンスタイム（P95）を850msから180msに改善」「スループットを500rpsから2,000rpsに向上」「DBのクエリ実行時間を平均3.2秒から0.4秒に短縮」のように、パフォーマンス指標の改善前後をセットで書くことで実力が伝わります。

ポイント③：技術選定の判断理由を書く

バックエンドの設計・技術選定において「なぜその技術・アーキテクチャを選んだか」の判断理由を書くことで、技術的な思考力が伝わります。「高トラフィック時の水平スケーリングを考慮してステートレスなREST API設計を選択」「既存のRDBMSへの書き込み負荷を軽減するためRedisキャッシュを導入」など、トレードオフを意識した判断を書きましょう。

バックエンドエンジニアならではの悩みに答える

「SESや客先常駐が多く、サービスの詳細を書けない案件が多い」

SESや客先常駐での就業経験がある方は、守秘義務を守りながら「業種・サービス規模・担当したアーキテクチャ・使用技術・成果」で記述しましょう。「大手金融機関向けWebAPIサービス（月間リクエスト数約5,000万件）のバックエンド開発に参画。Java（Spring Boot）でAPIを設計・実装し、レスポンスタイムを P95で500msから120msに改善した」のような形式で書けば十分伝わります。

「フロントエンドも少しやっているが、バックエンド専門でアピールしたい場合は？」

バックエンドへの転職を目指す場合は、バックエンドの実績を前面に出し、フロントエンドの経験は「補足的なスキル」として記載しましょう。スキルシートでも「メインスキル（バックエンド）」と「サブスキル（フロントエンド）」を明確に分けることが重要です。

例文

例①：バックエンドエンジニア（経験3年・若手）

BtoB SaaSサービス（契約企業数約500社・月間APIリクエスト数約2,000万件）を運営する自社開発企業のバックエンドチーム（5名）に所属。Python/FastAPIを使ったAPI開発・DB最適化を担当。

【業務内容】
・REST API設計・実装（Python/FastAPI）
・データベース設計・クエリ最適化（PostgreSQL）
・Redisを使ったキャッシュ設計・実装
・AWSインフラの運用補助（EC2・RDS・ElastiCache）
・テストコードの作成（pytest・カバレッジ維持：70%以上）
・GitHub ActionsによるCI/CDパイプラインの整備補助

【実績】
・メインAPIのレスポンスタイム（P95）を改善：820ms→150ms（N+1クエリ解消・Redisキャッシュ導入）
・重いバッチ処理の非同期化（Celery・Redis）により、DB負荷のピーク時CPU使用率を85%→30%に削減
・テストカバレッジを20%から72%に引き上げ、リリース後の本番障害件数を月平均4件から0件に削減
・API仕様書の整備（OpenAPI）を主導し、フロントエンドチームとの開発効率を向上

【主な取り組み】
レスポンスタイムの改善はDatadog APMでボトルネックを特定し、N+1クエリの解消を最優先に実施した。PostgreSQLのクエリプランを分析し、結合条件に適切なインデックスを追加することで単体クエリの実行時間を3.2秒から0.2秒に短縮した。さらに読み取り頻度の高いデータをRedisにキャッシュすることでDBへの負荷を大幅に削減した。テストカバレッジの引き上げは新規コードへのテスト必須化をチームルールとして提案し、既存コードは影響範囲の広いユーティリティ関数から優先的に対応した。

自己PRでのアピールポイント
パフォーマンス計測→ボトルネック特定→改善のサイクルが習慣になっている。DB最適化・キャッシュ設計・非同期処理の実装経験を次の職場でも活かしていきたい。

例②：バックエンドエンジニア・テックリード（経験7年・中堅）

BtoC向けフードデリバリーサービス（MAU約150万人・月間注文数約500万件）のバックエンドチーム（8名）でテックリードとして勤務。マイクロサービス化・パフォーマンス改善・チームマネジメントを担当。

【業務内容】
・マイクロサービスアーキテクチャの設計・移行主導（モノリスからの分割）
・Go言語を使ったAPI設計・実装（注文・配達・決済マイクロサービス）
・AWSインフラ設計・運用（EKS・RDS Aurora・ElastiCache・SQS）
・コードレビュー（チーム全員分）・技術設計のレビュー・承認
・障害対応の統括・ポストモーテムの実施
・採用面接への参加（技術面接・月2〜3件）

【実績】
・モノリスからマイクロサービスへの段階移行を主導。月間デプロイ頻度を4回→約60回に向上
・ピーク時（夕食注文集中時）のAPIレスポンスタイム（P99）を改善：3,200ms→350ms
・障害MTTR（平均復旧時間）を90分→12分に短縮（Runbook整備・オンコール体制の最適化）
・決済サービスの可用性：99.99%を6ヶ月間維持（SLO達成）

【主な取り組み】
マイクロサービス化はリスクの高い「一度に全部移行」ではなく、独立性の高いサービス（通知・分析）から段階的に分割するアプローチを採用した。各マイクロサービスの境界を「ビジネスドメイン」単位で定義し、サービス間の依存関係を最小限に設計した。ピーク時のレスポンスタイム改善はプロファイリングで注文確定APIのボトルネックが「在庫確認のN+1リクエスト」にあると特定し、バッチリクエスト方式に変更することで劇的に改善した。MTTRの短縮はアラートの閾値を「業務影響ベース」で再設計し、Runbookの整備によって誰でも初動対応できる体制をつくった。

自己PRでのアピールポイント
マイクロサービス設計・パフォーマンス改善・チームマネジメントを経験してきた。「技術的な意思決定の根拠を明確に示す」スタイルと、SLO達成への責任感を持ちながらチームを動かしてきた経験を次の職場でも活かしたい。

例③：バックエンドアーキテクト・エンジニアリングマネージャー（経験13年・ベテラン）

SaaS企業（ARR約50億円・エンジニア50名体制）のエンジニアリングマネージャーとして勤務。バックエンドチーム12名のマネジメントと、システム全体のアーキテクチャ設計・技術戦略の立案を担当。

【業務内容】
・バックエンドチーム12名のマネジメント（採用・評価・育成・1on1）
・システム全体のアーキテクチャ設計・技術スタック選定の意思決定
・技術的負債の特定・解消計画の策定・推進
・SREチームとのSLO設定・信頼性設計の連携
・採用技術面接・エンジニア候補者の評価
・四半期ごとの技術ロードマップ策定・経営陣への報告

【実績】
・システム全体の可用性を99.5%から99.95%に向上（SREチームとのSLO策定・運用改善）
・技術的負債の解消プロジェクトを主導：レガシーコードのリプレースにより、デプロイ失敗率を8%→0.5%に削減
・マルチテナントアーキテクチャへの移行を主導し、新規企業の導入時間を平均2週間→2日に短縮
・バックエンドチームの採用・育成により1年間でチームを7名から12名に拡大。入社後3ヶ月の離職率ゼロを維持

【主な取り組み】
マルチテナント化は既存のシングルテナント設計（企業ごとに独立したDB・アプリ）から共有インフラでの論理分離への移行を段階的に実施した。データ分離・認証・権限管理の設計を慎重に行い、テナント間のデータ漏洩リスクをゼロに維持した。技術的負債の解消は「ビジネスへの影響度」×「解消コスト」でスコアリングしたロードマップを経営陣に提示し、優先順位の合意を得た上で着手した。採用強化では技術面接のルーブリック（評価基準）を整備し、面接担当者によるブレを最小化することで採用の質と速度を向上させた。

自己PRでのアピールポイント
バックエンドの実装からアーキテクチャ設計・エンジニアリングマネジメントまで幅広く担ってきた。「システムの信頼性とエンジニアの生産性を同時に高める」視点を持ち、次の職場でもEM・アーキテクトとして貢献したい。

書き方ステップ

① これまでのプロジェクトを「サービス規模・使用技術・技術的課題・成果」で書き出す

② 数字になるものを探す（レスポンスタイム・スループット・可用性・デプロイ頻度・MTTR・テストカバレッジ・DBクエリ実行時間など）

③ スキルシートと業務経歴を対応させる（スキルシートに書いた技術が、どのプロジェクトでどう使ったかを確認）

④ 技術選定の判断理由（なぜその技術を選んだか・どんなトレードオフを考慮したか）を書く

NG例 → 改善例｜通らない書き方の直し方

失敗①：サービスの規模感がない

ECサイトのバックエンド開発を担当しました。APIの設計・実装を行いました。

改善後

月間流通総額約5億円・MAU約30万人のECサイトのバックエンドチーム（5名）に参画。Python/FastAPIでカート・決済APIを設計・実装。N+1クエリ解消・Redisキャッシュ導入でP95レスポンスタイムを820msから150msに改善した。

失敗②：技術スタックの羅列で終わっている

Python・Go・Java・Spring Boot・FastAPI・PostgreSQL・MySQL・Redis・AWS・Docker・Kubernetes・Kafka・Elasticsearchを使ってきました。

改善後

【Go】フードデリバリーサービスの注文・配達マイクロサービスのAPI設計・実装（MAU約150万人・月間500万注文）。ピーク時P99レスポンスタイムを3,200msから350msに改善。【Python/FastAPI】SaaS API設計（月間2,000万リクエスト）。N+1解消・Redisキャッシュ導入でP95レスポンスタイム820ms→150msを達成。

失敗③：技術的な工夫が見えない

API開発・DB設計・パフォーマンス改善を担当してきました。最適化にも取り組みました。

改善後

Datadog APMでボトルネックを特定し、注文確定APIのN+1リクエスト（在庫確認が1注文ごとに個別リクエスト）をバッチリクエスト方式に変更。APIレスポンスタイム（P95）を820msから150msに改善し、DBのCPU使用率をピーク時85%から30%に削減した。

失敗④：可用性・信頼性への取り組みが書かれていない

システムの運用・保守も担当していました。障害対応にも取り組んできました。

改善後

決済サービスのSLO（可用性99.99%）を6ヶ月間維持。MTTR（平均復旧時間）を90分から12分に短縮（Runbook整備・オンコール体制の最適化・アラート閾値の業務影響ベース再設計）。ポストモーテムの仕組みを整備し、同種障害の再発をゼロに維持した。

経験年数別アドバイス

経験3年未満（若手・担当者）

「担当したサービスの規模・使用技術・パフォーマンス改善の実績」が評価のポイントです。大きな実績がなくても「N+1クエリを発見して解消した」「テストカバレッジを引き上げた」など、自分が主導した改善を具体的に書くことで技術力が伝わります。

ポイント

GitHubのURLを職務経歴書に添えましょう。コードの品質・コミット頻度が実力の証明になります。個人開発がある場合は特に有効です。

経験3〜10年（中堅・専門担当）

「サービス規模とアーキテクチャ設計の経験」「テックリードとしてのコードレビュー・技術設計への関与」「パフォーマンス改善・可用性向上の具体的な実績」が評価の軸になります。技術選定の判断理由と、チームへの貢献（コードレビュー・育成）を書くことで差別化できます。

経験10年以上（ベテラン・リーダー層）

アーキテクチャ設計・エンジニアリングマネジメント・技術戦略の立案・SLO設計が最大のアピールポイントです。「チーム人数・システム可用性・デプロイ頻度・MTTR改善」など、組織全体の開発・運用力を高めてきた実績を中心に書きましょう。

よくある質問

Q. バックエンドエンジニアからフルスタックエンジニアへの転職は可能ですか？

バックエンドの深い知識はフルスタックエンジニアとして最大の強みになります。フロントエンドの学習状況（React・TypeScriptの個人プロジェクト・GitHubのリポジトリ）とあわせてアピールしましょう。

Q. 言語を変えて転職（JavaからGoなど）する場合の書き方は？

現在の技術経験を前面に出しながら「新しい言語への移行経験または学習実績（個人プロジェクト・GitHubリポジトリ）」を補足として書きましょう。「言語は変わっても、設計思想・パフォーマンスチューニングの考え方は共通している」という姿勢を伝えることが重要です。

Q. レスポンスタイムなどの数字を正確に覚えていない場合はどうすればいいですか？

「P95レスポンスタイムを約80%改善」など変化率での表現で十分です。「約」をつけて概数で記載してください。

Q. 個人開発の経験は職務経歴書に書いていいですか？

積極的に書くべきです。業務以外での技術への積極的な取り組みは、エンジニアとして高く評価されます。GitHubのURLとともに「使用技術・サービスの概要・MAU・技術的な工夫」を記載しましょう。

Q. 職務経歴書はA4何枚が適切ですか？

スキルシート込みで3〜4枚が目安です。プロジェクト数が多い場合は直近3〜5件を詳しく書き、それ以前は技術スタックの記載にとどめる構成が読みやすくなります。

まとめ

採用担当者は「サービス規模・技術スタックの使用実績・パフォーマンス改善の数字・技術選定の判断理由」をセットで見ている
サービス規模（MAU・月間リクエスト数・DBのデータ量）を必ず冒頭に書く
パフォーマンス改善は「施策前→施策後」の数字をセットで書く
技術選定の判断理由（なぜその技術を選んだか）を書くことで技術力の深さが伝わる
可用性・信頼性（SLO・MTTR・ポストモーテム）への取り組みは積極的に記載する
経験年数に応じて「実装力と改善実績」「アーキテクチャ設計とテックリード」「マネジメントと技術戦略」を使い分ける

バックエンドエンジニアの経験は正しく書けば必ず評価されます。まずはサービス規模・技術的な課題・改善の数字を書き出すところから始めてみてください。