技術者が書類選考で苦戦する原因の多くは、技術力の不足ではなく「採用側がどこを見ているか」を意識せずに書いている点にあります。この記事では、採用担当者とエンジニア面接官が技術経歴書のどこを最初に読み、何で判断しているかを明示したうえで、スキルの棚卸しから強みの言語化、各項目の具体的な書き方まで解説します。読み終えた後には、自分の技術経歴書を採用側の視点で書き直せる状態を目指しています。
技術経歴書を書く前に知っておくべき、採用側の読み方
Photo by JESHOOTS.COM on Unsplash
採用担当者が最初の10秒で見る3つの箇所
書類選考では、1件あたり数分しか時間をかけられないのが実態です。採用担当者（HR）が技術経歴書を開いて最初の10秒で見る箇所は、経験上ほぼ決まっています。
- 直近の職務内容と期間：現在何をしている人か、在籍期間は適切か
- テクニカルスキル欄の上位3〜5項目：求人票の必須要件と合致するか
- 自己PR欄の冒頭1〜2行：この人の強みが自社の課題解決につながるか
この3箇所で「読む価値がある」と判断されれば全体を精読してもらえますが、そうでなければ次の候補者に移られます。つまり、技術経歴書の冒頭部分と各セクションの最初の数行が、書類選考の通過率を大きく左右します。
技術面接官が確認する「手を動かした範囲」と「意思決定した範囲」
技術面接官（エンジニアマネージャーや現場のシニアエンジニア）が技術経歴書で確認しているのは、その人が何を自分で判断し、何を指示されて実行したかという線引きです。
「Pythonでデータ分析を実施」と書かれていても、それが「既存のスクリプトを実行しただけ」なのか「分析手法の選定から実装・可視化まで設計した」のかでは、評価が180度変わります。採用側が見たいのは後者の「意思決定した範囲」です。
そのため、職務内容欄には「担当業務」だけでなく、自分が判断した技術選定・設計方針・問題解決のアプローチを必ず含めるべきです。これが書かれていない技術経歴書は、「作業者としての経験はあるが、自律的に動ける人かは不明」と判断され、面接に進みにくくなります。
HRと技術面接官、両方に伝わる構造を作る
採用担当者（HR）は「この人が自社の課題を解決できるか」を、技術面接官は「この人が技術的に信頼できるか」を確認します。両者に伝わる技術経歴書の構造は以下です。
- 冒頭で結論：各セクションの最初に「何ができる人か」を一文で示す
- 技術用語＋効果：専門用語の後に「それで何を実現したか」を続ける
- 数値と規模感：影響範囲を定量的に示し、HRにも価値が伝わるようにする
この構造を意識するだけで、書類選考の通過率は大きく変わります。
技術経歴書の項目設計｜何をどの粒度で書くか
Photo by Mediamodifier on Unsplash
テクニカルスキル欄の具体的な項目立て
テクニカルスキル欄は「何ができるか」を最も端的に伝えるセクションです。採用側が求めているのは、スキルの羅列ではなく「実務レベルで使える技術」と「その習熟度」の明示です。
推奨する項目構成：
- 言語・フレームワーク：実務で設計・実装レベルで使用しているものを上位に（例：Python, Django, FastAPI）
- インフラ・ミドルウェア：構築・運用経験のあるもの（例：AWS (EC2, RDS, S3), Docker, Kubernetes）
- データベース：設計・チューニング経験の有無を含めて（例：PostgreSQL（設計・パフォーマンスチューニング経験あり）, MySQL）
- 開発環境・ツール：チーム開発で日常的に使用しているもの（例：Git, GitHub Actions, Terraform）
- その他の専門領域：データ分析、機械学習、セキュリティ等、職種によって追加
各項目には習熟度の定義を添えます。「上級」「中級」という表現ではなく、「設計・実装・レビュー可能」「業務で主体的に使用」「調べながら使用可能」のように行動ベースで記載すると、読み手に正確に伝わります。
職務内容欄に必ず含めるべき4要素
職務内容欄は、技術経歴書の中で最も情報量が多いセクションです。以下の4要素を必ず含めるようにしてください。
- プロジェクト概要と規模：どんなシステム・サービスで、どの程度の規模か（ユーザー数、データ量、チーム人数等）
- 自分の役割と担当範囲：チームの中でどんな位置づけで、どこからどこまでを担当したか
- 技術的な判断と実装内容：どんな技術選定・設計判断をし、何を実装したか（ここが「意思決定した範囲」）
- 成果と影響：その結果、何がどう改善したか（数値・定性的な変化）
この4要素を含めることで、HRには「課題解決能力」が、技術面接官には「技術的な判断力」が伝わります。
活かせる経験・知識・技術欄の使い方
この欄は、職務内容欄で書ききれなかった汎用性の高いスキルや再現性のある強みを記載する場所です。「特定のプロジェクトに限らず、どんな環境でも発揮できる能力」を中心に書きます。
記載例：
- 要件定義から設計・実装・テスト・リリースまでの一貫した開発経験
- 複数チーム（フロントエンド・バックエンド・インフラ）をまたいだ技術的な調整・合意形成の経験
- レガシーシステムのモダナイゼーション（段階的なリファクタリング・技術スタック移行）の実績
- パフォーマンスボトルネックの特定から改善施策の実装・効果検証までの一連の取り組み
この欄を充実させることで、応募先の業種・職種が多少変わっても「この人は適応できる」という印象を持たせることができます。
強みの言語化を始める前に：スキルの棚卸し3ステップ
Photo by Brands&People on Unsplash
ステップ1：技術スキルを「使用頻度×習熟度」で分類する
まず、これまで使ってきた技術・ツール・言語をすべて書き出します。次に、それぞれを「使用頻度（日常的に使う／たまに使う／過去に使った）」と「習熟度（自力で設計・実装できる／調べながら使える／基礎知識がある）」の2軸で分類します。
この作業により、「業務で毎日使っていて、設計レベルで判断できる技術」が明確になります。それが技術経歴書の中核に据えるべき強みの候補です。テクニカルスキル欄の上位3〜5項目は、この「日常的×設計レベル」のゾーンから選んでください。
ステップ2：プロジェクト単位で成果と貢献を洗い出す
過去3〜5年のプロジェクトを1件ずつ振り返り、以下の問いに答えてみてください。
- そのプロジェクトで自分が担った役割は何か？
- 技術的に最も難しかった課題は何か？
- 自分の判断や行動がなければ、どんな問題が起きていたか？
- 最終的にどんな成果が出たか（速度、品質、コスト、期間など）？
「自分の判断がなければ…」という問いは、自分の貢献を可視化するのに特に有効です。この問いに答えることで、「意思決定した範囲」が明確になります。
ステップ3：繰り返し発揮されたパターンを「強みの候補」として抽出する
ステップ2で複数のプロジェクトを振り返ると、「いつも自分がボトルネックを特定して解消している」「設計レビューで問題を早期に発見することが多い」といったパターンが浮かび上がります。このパターンこそが、再現性のある強みです。技術経歴書の自己PR欄や活かせる経験・知識・技術欄で語るべき核心部分になります。
技術者の強みを言語化する5つの戦略
Photo by Ninthgrid on Unsplash
戦略1：STARフレームで技術的貢献をエピソード化する
STARフレームとは、Situation（状況）・Task（課題）・Action（行動）・Result（結果）の4要素でエピソードを構造化する手法です。もともとは面接対策として使われますが、技術経歴書の職務内容欄にも応用できます。
技術者向けの応用例：
「レガシーシステムのバッチ処理が夜間に頻繁にタイムアウトし、翌朝の業務開始に影響していた（Situation）。原因特定と処理改善を担当した（Task）。SQLクエリの実行計画を分析し、インデックス設計を見直すとともに、処理を並列化するよう実装を変更した（Action）。その結果、バッチ処理時間を従来比で約60%短縮し、タイムアウトエラーをゼロにした（Result）。」
この構造で書くと、HRには「問題解決能力がある人」として、技術面接官には「具体的な技術判断ができる人」として伝わります。ActionとResultに「自分の判断」を必ず含めることで、「意思決定した範囲」が明示されます。
戦略2：数値・規模・スコープで技術の影響範囲を可視化する
技術的な成果は数値で表すと説得力が増します。よく使える指標の例を挙げます。
- 処理速度・レスポンスタイムの改善率（例：API応答時間を平均1.2秒から0.3秒に短縮）
- バグ・インシデントの削減件数（例：リリース後のバグ報告件数を月平均15件から3件に削減）
- 対応規模（例：日次アクティブユーザー数50万人規模のサービスを担当）
- チーム・プロジェクト規模（例：エンジニア8名のチームでテックリードを担当）
- 開発期間・工数の短縮率（例：CI/CDパイプライン導入により、デプロイ時間を2時間から15分に短縮）
数値が出しにくい場合でも、「規模感」や「影響範囲」を書くだけで読み手の解像度が上がります。
戦略3：技術スキルを「課題解決能力」として再定義する
「Pythonが使える」という表現は、スキルの存在を示すだけです。採用担当者が知りたいのは「そのスキルを使って何を解決したか」です。
変換例：
- Before：「Pythonを使ったデータ分析が得意」
- After：「Pythonを用いて製造ラインのセンサーデータを解析し、不良品発生の予兆パターンを特定。予防保全の実施により、月間の設備停止時間を約30%削減した」
スキル名を起点にするのではなく、「どんな課題があり、そのスキルでどう解決したか」を起点に書くと、強みとして機能する文章になります。
戦略4：求人票のキーワードと自分のスキルを対応させる
応募先の求人票には、採用担当者が重視しているキーワードが含まれています。自分のスキルと求人票のキーワードを照合し、対応関係を明示することで、書類選考の通過率が上がりやすくなります。
具体的には、求人票に「CI/CDパイプラインの構築経験」とあれば、自分の経験の中から該当する内容を探し、「GitHub ActionsとDockerを用いたCI/CDパイプラインを構築し、デプロイ頻度を週1回から1日複数回に改善した」のように対応させます。ただし、実際に経験していないことを書くのは厳禁です。
戦略5：専門用語と平易な言葉を使い分けて読み手を選ばない文章にする
技術経歴書は、最初にHRが読み、次に技術面接官が読むことが多いです。そのため、専門用語を使いつつも、その意味や効果が文脈から分かるように書くことが重要です。
使い分けの基準：
- 技術用語は使ってよい。ただし、その後に「〜することで○○を実現した」という効果の文を続ける
- 略語（例：CI/CD、ORM、MLOps）は初出時に何を指すか分かる文脈で使う
- 「パフォーマンスチューニング」のような言葉は、具体的な数値や手法とセットで書く
こうすることで、技術面接官には専門性が伝わり、HRには「何を実現した人か」が伝わります。
選考で落ちる技術経歴書の典型パターン
転職相談の現場で繰り返し見る、書類選考で落ちやすい技術経歴書のパターンを挙げます。自分の技術経歴書が該当していないか確認してください。
パターン1：「何をしたか」だけで「何を判断したか」が書かれていない
「〇〇システムの開発を担当」「△△の実装を実施」という表現だけでは、指示されて作業しただけなのか、自分で設計判断したのかが分かりません。技術面接官は「この人は自律的に動けるか」を見ているため、判断の根拠や選定理由が書かれていない技術経歴書は評価が上がりません。
パターン2：技術スキル欄が「できる」「得意」だけで習熟度が不明
「Java：得意」「AWS：使用可能」という表現では、読み手によって解釈が異なります。設計レベルで使えるのか、調べながら使える程度なのかが分からないと、採用側は判断できません。習熟度を行動ベースで定義しないと、スキルマッチの判断すらしてもらえないケースがあります。
パターン3：数値・規模感が一切なく、貢献の大きさが伝わらない
「システムのパフォーマンスを改善した」と書かれていても、それが「1秒が0.9秒になった」のか「10秒が1秒になった」のかでは印象が全く違います。数値がない技術経歴書は、採用側に「本当に成果があったのか」という疑念を持たれやすくなります。
パターン4：直近の職務内容が薄く、過去の経歴だけが詳しい
採用側が最も重視するのは直近の経験です。3年前のプロジェクトが詳しく書かれていても、直近1年の職務内容が1行しかなければ、「今この人は何ができるのか」が伝わりません。職務内容欄は新しいものほど詳しく書くのが原則です。
言語化した強みを磨くための見直しチェックリスト
技術経歴書を書いた後、以下の項目で自己チェックをしてみてください。
- 各エピソードに「課題→行動→結果」の流れがあるか
- 「手を動かした範囲」と「意思決定した範囲」が明示されているか
- 数値・規模・スコープが少なくとも1つ以上含まれているか
- 技術用語の後に「何を実現したか」が続いているか
- 応募先の求人票のキーワードと自分の経験が対応しているか
- 自己PR欄に「再現性」を示す表現があるか
- HRが読んでも「何をした人か」が分かる構成になっているか
- テクニカルスキル欄のレベル感が実態と一致しているか
- 同じ表現・フレーズが複数箇所で繰り返されていないか
- 直近の職務内容が最も詳しく書かれているか
よくある質問（FAQ）
技術スキルのレベル（初級・中級・上級）はどう定義すればよいですか？
「上級」「中級」などの表現は主観的に見えるため、できれば具体的な行動ベースの定義に置き換えることをおすすめします。たとえば「設計・実装・レビューが可能」「業務で主体的に使用経験あり」「個人学習レベル」のように記載すると、読み手に正確に伝わります。どうしてもレベル表記を使う場合は、欄外や備考で定義を補足するのが親切です。
技術的な専門用語は技術経歴書に書いてよいですか？
書いてよいです。ただし、専門用語だけで終わらせず、「その技術を使って何を実現したか」を必ずセットで書いてください。HRが読んでも文脈から価値が伝わる構成にすることで、技術面接官にも専門性が伝わる一石二鳥の書き方になります。
成果が数値化しにくいプロジェクトでも強みを言語化できますか？
できます。数値が出しにくい場合は、「規模感（チーム人数、ユーザー数、システム規模）」「影響範囲（どの部門・どのプロセスに関わったか）」「定性的な変化（レビュー工数の削減、チームの開発フローの改善など）」で代替できます。「数値がないから書けない」と諦めず、影響の大きさを別の角度から表現してみてください。
複数の技術領域にまたがるキャリアの場合、強みはどう絞ればよいですか？
応募先のポジションに最も近い領域の経験を中心に据え、他の領域は「幅広い視点を持つ強み」として補足する構成が有効です。「フロントエンドもバックエンドも経験しているため、API設計の際にUI側の要件を先読みした提案ができる」のように、複数領域の経験を掛け合わせた強みとして表現するのも一つの方法です。
STARフレームとはどのようなものですか？技術経歴書にも使えますか？
STARフレームはSituation（状況）・Task（課題）・Action（行動）・Result（結果）の4要素でエピソードを整理する構造です。もともと面接の回答整理に使われますが、技術経歴書の職務内容欄や自己PR欄にも応用できます。特に「何をしたか」だけになりがちな職務内容欄を「なぜそれをしたか・どんな成果が出たか」まで含めた記述に変えるのに役立ちます。
採用担当者（非エンジニア）と技術面接官（エンジニア）で書き方を変えるべきですか？
1枚の技術経歴書で両方に対応するには、「技術用語＋効果の説明」という構成が有効です。技術用語は技術面接官への専門性のシグナルになり、その後の効果説明はHRへの価値の伝達になります。企業によっては書類選考用と技術面接用に内容を調整することもありますが、基本的には1枚で両方に伝わる構成を目指すのが現実的です。
転職回数が多い技術者は技術経歴書でどう強みを見せればよいですか？
転職回数が多い場合は、各職場での経験を「点」ではなく「線」でつなぐ視点が重要です。「異なる環境でも同じ強みを発揮してきた」という再現性を示すことで、転職回数の多さをキャリアの幅広さとして読み替えることができます。自己PR欄では「複数の組織・技術スタックを経験したことで、環境変化への適応力と技術選定の判断軸が身についた」のように、経験の蓄積として表現するのが効果的です。
「手を動かした範囲」と「意思決定した範囲」はなぜ分けて書く必要があるのですか？
採用側が見たいのは「この人は指示待ちではなく、自分で判断して動けるか」という点です。「Pythonで分析スクリプトを実装した」だけでは、誰かが書いた仕様通りに作っただけかもしれません。一方、「分析手法の選定理由を検討し、Pythonでスクリプトを実装した」と書けば、「技術選定の判断ができる人」として評価されます。この違いが、書類選考の通過率と面接での評価を左右します。
