理学療法士の職務経歴書の書き方｜採用担当が見るポイントと例文
ショクレキ代行
ショクレキ代行
Webエンジニアの職務経歴書の書き方｜書き方のコツと通過率を上げる方法
ショクレキ代行
📌 この記事でわかること
- 採用担当者がWebエンジニアの職務経歴書で本当に見ているポイント
- スキルシートの正しい書き方（技術スタックの整理と習熟度の見せ方）
- プロジェクト経歴の書き方（規模・役割・成果の伝え方）
- フロントエンド・バックエンド・フルスタック別の書き分け方
- 書類が通らないWebエンジニアに共通する失敗パターン
- 経験年数別（若手・中堅・ベテラン）のアピールポイントの違い
「スキルはあるはずなのに、なぜか書類で落ちる」「職務経歴書に何を書けばいいかわからない」Webエンジニアの転職活動でよく聞く悩みです。GitHubのコードは充実していても、職務経歴書の書き方がわからず損をしているエンジニアは少なくありません。
書類が通らない原因のほとんどは、技術力の問題ではなく「経験の見せ方」にあります。採用担当者に「この人は何ができる人か」が伝わる書き方ができていないケースがほとんどです。使った技術名を並べるだけでは、実務で活かせるかどうかは判断できません。
この記事では、Webエンジニアが転職活動で使える職務経歴書の書き方を、スキルシートの整理方法からプロジェクト経歴の書き方まで、具体的に解説します。
採用担当は何を見ている？
Webエンジニアの採用担当者が職務経歴書で確認しているのは、主に次の3点です。
| 観点 | 内容 |
| どんな技術スタックを業務で使ってきたか | 言語・フレームワーク・インフラ・ツールの実務経験の有無と習熟度を確認している |
| どんな規模・役割のプロジェクトを経験しているか | チーム人数・担当フェーズ・サービスの規模（MAU・売上・ユーザー数）を見ている |
| 技術をどう使って成果を出してきたか | パフォーマンス改善・バグ削減・開発速度向上など、数字と工夫がセットで書かれているかを確認している |
よくある失敗（書類が通らない人に共通する3つのパターン）
パターン①：技術スタックを羅列するだけで終わっている
「使用言語：JavaScript、TypeScript、Python、PHP…」と並べるだけでは、採用担当者には何もわかりません。業務で実際に使ったのか、学習レベルなのか、習熟度はどの程度なのかが見えないためです。スキルシートには技術名だけでなく、業務経験の有無・使用期間・習熟度の目安を添えることが重要です。
パターン②：プロジェクト経歴が「担当しました」で終わっている
「要件定義からリリースまで担当」「Webアプリケーションの開発を担当」といった記述では、実際に何をしたかが伝わりません。採用担当者が知りたいのは、チーム規模・自分の役割・使用技術・工夫した点・成果です。これらがセットで書かれていないと、経験の深さが判断できません。
パターン③：規模感が一切わからない
「ECサイトの開発」と書いてあっても、個人開発なのか20人チームなのかで評価はまったく変わります。プロジェクトのチーム人数・期間・売上規模・ユーザー数など、規模感を示す数字は必ず入れましょう。
書き方のポイント｜Webエンジニアならではの伝え方
ポイント①：スキルシートは「業務経験あり」と「学習中」を明確に分ける
業務で使ったことのない技術でも、学習中・個人開発で使用中であれば記載してOKです。ただし「業務経験あり」と混在させるのはNGです。「業務外で使用中」「現在学習中」と明示した上で、GitHubのリポジトリURLを添えると説得力が増します。
ポイント②：プロジェクト経歴は「規模・役割・技術・成果」の4点セットで書く
プロジェクト経歴の基本項目は、プロジェクト概要（何のためのサービスか）・チーム規模と自分の役割・担当フェーズ（設計・実装・レビュー・運用）・使用技術・工夫した点と成果の5つです。この情報が揃っていれば、採用担当者はエンジニアとしての実力を具体的にイメージできます。
ポイント③：数字で語れる改善実績を必ず入れる
Webエンジニアの実績は「レスポンスタイムの改善」「テストカバレッジの向上」「バグ件数の削減」「デプロイ頻度の向上」など、数字で表現できるものが多くあります。「レスポンスタイムを平均2.3秒から0.7秒に改善」「テストカバレッジを15%から72%に引き上げ」のように、施策前後の数字をセットで書くことで実力が一気に伝わります。
Webエンジニアならではの悩みに答える
「SESや客先常駐経験が長く、社名・案件名が書けない場合はどうすればいい？」
守秘義務がある場合、クライアント名や案件名は伏せて構いません。「大手金融機関向け社内業務システム（ユーザー数約1,000名規模）の開発に参画」「toB向けSaaSサービス（契約企業数約500社）のバックエンド開発を担当」のように、業種・規模・システムの性質で代替することで、採用担当者は経験の内容を十分に判断できます。
「個人開発・OSSへの貢献は職務経歴書に書いていい？」
積極的に書くべきです。個人開発やOSSへの貢献は、業務外でも技術を追いかける姿勢の証明になります。GitHubのURLを添えて「個人開発：○○（技術スタック・概要・月間利用者数など）」と記載しましょう。スター数・フォーク数・コントリビューション数など、規模感を示す数字があればセットで書くと説得力が増します。
例文
例①：フロントエンドエンジニア（経験2年・若手）
BtoC向けメディアサービスを運営する自社開発企業（従業員数約150名）のフロントエンドチーム（6名）に所属。月間PV約500万のサービスの新機能開発・UI改善を担当。
【業務内容】
・新機能のフロントエンド実装（React・TypeScript）
・既存UIのパフォーマンス改善・リファクタリング
・デザイナーとの仕様調整・Figmaを使ったデザインレビュー
・GitHub ActionsによるCI/CDパイプラインの整備補助
・コードレビュー（チーム内2〜3名分を担当）
【実績】
・Core Web Vitalsの改善施策を主担当として実施し、LCPを4.2秒から1.8秒に短縮
・画像の遅延読み込み・不要なバンドルサイズの削減によりページ読み込み速度を約40%改善
・UIコンポーネントのStorybook整備を推進し、デザイナーとの認識齟齬によるやり直しを月平均3件から0件に削減
【主な取り組み】
Core Web Vitalsの改善はLighthouseを使って問題箇所を特定し、LCP・CLSそれぞれの原因を切り分けて優先順位をつけて対応した。画像最適化だけでなく、レンダリングブロッキングリソースの排除とCSSのクリティカルパス最適化を組み合わせることで、数値の改善を実現した。Storybookの導入は自分が主導し、コンポーネントの仕様書として活用する運用ルールをチームに提案・定着させた。
自己PRでのアピールポイント
パフォーマンス計測ツールを使って問題を特定し、優先順位をつけて改善するサイクルが習慣になっている。デザイナーとの連携を円滑にする仕組みづくりにも積極的に関与してきた経験を、次の職場でも活かしていきたい。
例②：バックエンドエンジニア（経験5年・中堅）
BtoB向けSaaSサービスを展開する自社開発企業（従業員数約300名）のバックエンドチーム（8名）に所属。契約企業数約800社・月間APIリクエスト数約5,000万件規模のサービスのバックエンド開発・運用を担当。
【業務内容】
・REST API・GraphQL APIの設計・実装（Python / FastAPI）
・データベース設計・クエリ最適化（PostgreSQL）
・AWSインフラの構築・運用（ECS・RDS・ElastiCache・SQS）
・Terraformを使ったインフラのコード管理
・コードレビュー（チーム内4〜5名分を担当）・新機能の技術設計
・DatadogによるAPM監視・アラート設計
【実績】
・主要APIのレスポンスタイムを平均850msから180msに改善（N+1クエリ解消・Redisキャッシュ導入による）
・DB負荷の高いバッチ処理をSQSを使った非同期処理に移行し、ピーク時のDB CPU使用率を85%から35%に削減
・テストカバレッジを8%から65%に引き上げ、リリース後の本番障害件数を月平均5件から1件以下に削減
【主な取り組み】
レスポンスタイムの改善はDatadogのAPMでボトルネックを特定し、クエリレベルでのN+1問題を優先的に解消した。ElastiCacheの導入では、キャッシュの更新タイミングと整合性の設計を丁寧に行い、キャッシュ起因の不整合をゼロに維持した。テストカバレッジの引き上げは、新規コードへのテスト必須化をチームルールとして提案し、既存コードは影響範囲の広いユーティリティ関数から優先的にテストを追加していく方針で進めた。
自己PRでのアピールポイント
計測→特定→改善のサイクルを実務で繰り返してきた経験がある。パフォーマンス改善・インフラ設計・テスト整備まで幅広く担ってきた対応範囲の広さを、次の職場でも活かしたい。
例③：フルスタックエンジニア・テックリード（経験10年・ベテラン）
toCサービスを複数展開するスタートアップ（従業員数約80名）にて、Webエンジニアチーム（10名）のテックリードとして開発全体を統括。MAU約50万人のサービスのアーキテクチャ設計から開発プロセス改革まで担当。
【業務内容】
・サービス全体のアーキテクチャ設計・技術選定の意思決定
・フロントエンド（Next.js・TypeScript）・バックエンド（Go）の実装・コードレビュー
・AWSインフラ設計・運用（EKS・RDS Aurora・CloudFront）
・エンジニア10名のテクニカルマネジメント（1on1・コードレビュー・技術相談）
・採用面接への参加（技術面接を月3〜5件担当）
・四半期ごとの技術ロードマップの策定・経営陣への報告
【実績】
・マイクロサービス化によりサービスの月間デプロイ回数を4回から約60回に向上
・障害発生時の平均復旧時間（MTTR）を120分から15分に短縮（オンコール体制とRunbook整備による）
・エンジニア採用を主導し、1年間でチームを5名から10名に拡大。入社後3ヶ月以内の早期離職率ゼロを維持
・技術負債の解消プロジェクトを推進し、レガシーコードのリプレイスを6ヶ月で完了（影響範囲：全APIエンドポイントの約40%）
【主な取り組み】
デプロイ頻度の向上は、モノリスからのマイクロサービス化と並行して、GitHub ActionsによるCI/CDの完全自動化・ステージング環境の整備・フィーチャーフラグの導入をセットで進めた。MTTRの短縮はアラートの閾値を「業務影響ベース」で再設計し、Runbookの整備によってオンコール担当者が初動対応を自律的に行える体制をつくったことが大きい。採用面接では技術力だけでなく「チームに貢献できるか」の観点を重視し、コードレビューのロールプレイを面接に組み込む独自の評価フローを設計した。
自己PRでのアピールポイント
技術の実装から、アーキテクチャ設計・チームマネジメント・採用・経営層への報告まで幅広く担ってきた。「エンジニアチームが最大限に力を発揮できる環境をつくる」ことを常に意識しており、テックリード・EMとして次の職場でも貢献したい。
書き方ステップ
① これまでのプロジェクトをすべて書き出す（期間・チーム規模・担当フェーズ・使用技術・自分の役割を一覧化する。アピールになるかはこの段階では考えなくてOK）
② 数字になるものを探す（レスポンスタイム・テストカバレッジ・デプロイ頻度・バグ件数・MAU・売上規模など、プロジェクトに紐づく数字を洗い出す。正確な数値でなくても「約○%」「○分の1」程度で十分）
③ スキルシートとプロジェクト経歴を対応させる（スキルシートに書いた技術が、どのプロジェクト経歴と対応しているか確認する。スキルシートにあってプロジェクト経歴に出てこない技術は「本当に使えるの？」と思われるリスクがある）
④ 業務内容は簡潔に、掘り下げは「実績」「主な取り組み」で行う（業務内容の箇条書きは「担当した」レベルで簡潔に書いてOK。その代わり「実績」「主な取り組み」のブロックで工夫・判断・成果を具体的に掘り下げる）
NG例 → 改善例｜通らない書き方の直し方
失敗①：技術スタックの羅列で終わっている
失敗②：プロジェクト経歴が「担当しました」で終わっている
失敗③：規模感がまったく書かれていない
失敗④：自己PRが抽象的で終わっている
経験年数別アドバイス
経験3年未満（若手・担当者）
実績の大きさより「どう考えて動いたか」が評価のポイントです。「なぜその実装方法を選んだか」「コードレビューで指摘されたことをどう改善したか」「個人開発で何を作り何を学んだか」など、思考プロセスと学ぶ姿勢を書くことが重要です。
経験3〜10年（中堅・専門担当）
技術の深さ・設計力・チームへの貢献が評価の軸になります。「主導した改善施策の数字」「コードレビューで担当した人数・件数」「技術選定への関与」など、個人の技術力とチームへの影響の両方を書きましょう。特定領域の専門性（パフォーマンス・セキュリティ・インフラなど）があれば積極的にアピールしてください。
経験10年以上（ベテラン・リーダー層）
アーキテクチャ設計・技術選定の意思決定・チームマネジメント・採用への関与が最大のアピールポイントです。「チーム人数・デプロイ頻度・障害件数の改善」など、組織全体の技術力を高めてきた実績を中心に書きましょう。直近3〜5年のプロジェクトを重点的に記載し、古い情報は概要にとどめることが読みやすさのポイントです。
よくある質問
Q. 職務経歴書にGitHubのURLを載せるべきですか？
積極的に載せるべきです。特に個人開発・OSSへの貢献がある場合は、コードの実力を直接見てもらえる最強の補足資料になります。ただしリポジトリが整理されていない場合は逆効果になることもあるため、READMEの整備とコードの可読性を確認してから載せましょう。
Q. SES・客先常駐経験が長いと不利ですか？
書き方次第で十分に評価されます。複数の現場・業種・チームを経験しているSES経験者は、環境適応力・異なる開発文化への対応力・短期間でのキャッチアップ力が強みになります。経歴の多さをネガティブに捉えず、経験の幅として整理しましょう。
Q. 使ったことのある技術をすべてスキルシートに書いていいですか？
業務経験のある技術と学習中の技術は明確に分けて記載してください。「業務経験あり」「個人開発で使用」「現在学習中」の3段階で整理するとわかりやすくなります。
Q. フリーランス経験は職務経歴書にどう書けばいいですか？
フリーランスとして受注したプロジェクトを、正社員時代と同じフォーマット（概要・チーム規模・使用技術・成果）で書きましょう。クライアント名が書けない場合は「業種・規模・システムの概要」で代替してください。
Q. 職務経歴書はA4何枚が適切ですか？
エンジニアの職務経歴書は、スキルシート込みで3〜4枚が目安です。プロジェクト数が多い場合は、直近3〜5件を詳しく書き、それ以前は概要のみとするとバランスがよくなります。
まとめ
- 採用担当者は「技術スタック・プロジェクト規模・役割・成果」をセットで見ている
- スキルシートは「業務経験あり」と「学習中」を明確に分けて書く
- プロジェクト経歴は「概要・チーム規模・担当フェーズ・使用技術・成果」の5点セットで書く
- レスポンスタイム・テストカバレッジ・バグ件数など、数字で語れる改善実績を必ず入れる
- GitHubのURLを添えると実力の証明として有効
- 経験年数に応じて「学ぶ姿勢と行動量」「技術の深さとチームへの貢献」「アーキテクチャ設計とマネジメント」を使い分ける
Webエンジニアの経験は正しく書けば必ず評価されます。まずはこれまでのプロジェクトとそこから出せる数字を書き出すところから始めてみてください。
人事・採用担当として1,000名以上の面接、30社の採用支援に携わった経験をもとに、職務経歴書の作成代行・添削を行っています。
採用側での経験をもとに、評価される書類づくりをサポートしています。「経験はあるのに書類で落ちる」という方に特に支持をいただいています。
これまでのご支援数は370名以上。製造・IT・金融・医療・サービス業など、幅広い業界・職種に対応しております。
職務経歴書の書き方にお悩みの方は、お気軽にご相談ください！
