IT・テック職の履歴書：どの職種でも使える書き方（2026 年版）

テック職の履歴書（CV）についての助言の多くは、ソフトウェアエンジニア向けに書かれ、そのままほかのテック職にも使い回されています。プロダクトマネージャー、データアナリスト、UX デザイナー、SRE、システム管理者、QA エンジニアは、同じ応募サイトから応募し、同じ採用担当者に選考されますが、読み手はページごとに違う証拠を探しています。このガイドでは、テック職全般で通用する書式を説明したあと、職種ごとに見ていきます。スキルのセクションで何が変わるか、どのリンクを入れるか、どの数値が評価されるか、そしてそれぞれの短い架空の例です。

ここで扱うのは、外資系企業や海外への応募で使う英文レジュメの形式です。日本の職務経歴書を書くときにも、成果と数値の示し方はそのまま応用できます。

仕事でソフトウェアを書いているなら、ソフトウェアエンジニアの履歴書ガイド のほうが合っています。以下の節は、エンジニアリングの周辺の職を扱います。

テック職の履歴書は何が違うのか

テック業界の採用担当者は、ほかを読む前に、ツールと成果で選考します。求人は技術スタック、プラットフォーム、手法を挙げており、最初の読みでは、あなたのページにその言葉があるかを確かめます。採用責任者による 2 回目の読みでは、それを使って何かをしたかを確かめます。テック職の履歴書がうまくいくのは、どちらの読みも短く済むときです。スキルのセクションが 5 秒で 1 回目に答え、職歴の箇条書きが数値で 2 回目に答えます。

2 つ目の違いは、文書の外にある証拠です。デザイナーのポートフォリオ、アナリストのノートブック、SRE のオープンソースの Terraform モジュール、誰でも登録できる PM のプロダクトは、どれも形容詞より重みがあります。履歴書の役割は、それらを指し示すことです。

テック職向けの履歴書の書式

書式は職種に関係なく同じなので、一度決めてしまいます。

• 最初の 8〜10 年は 1 ページ。 説明すべきプロダクトやシステムが多いシニアなら 2 ページ。
• 新しい順。 現職を先頭に。日付を隠す職能別の履歴書は、空白期間についての質問を招きます。
• セクションの順番： 連絡先、サマリー（任意、2 行）、スキル、職歴、プロジェクト、学歴、資格。強いポートフォリオを持つデザイナーやアナリストは、キャリアの初期であれば、プロジェクトを職歴より上に移せます。
• 連絡先はページの本文に、名前、都市、メール、電話番号、リンクを。Word のヘッダー領域には置きません。パーサーがそこを読み飛ばすことがあります。
• リンクはテキストで、アイコンだけにしない：linkedin.com/in/name、github.com/name、name.design。コピー＆ペーストしても残るようにします。
• テキストベースの PDF。 画像として印刷するのではなく、エディターから書き出します。一度すべて選択してプレーンテキストのエディターに貼り付け、すべてのセクションが順番どおりに出てくるか確かめてください。
• 応募フォームから提出するものは、標準的なフォント、10〜11 ポイント、1 段組み。 人にメールで送る PDF なら 2 段組みでも構いません。
• 米国への応募では写真なし、生年月日はどこにも書かない。日本の履歴書と違い、英文レジュメには写真を貼らないのが基本です。
• ファイル名： Firstname-Lastname-Resume.pdf。

スキルのセクションの語彙は、求人を映すべきです。求人内容から用語を取り出して置く方法は 履歴書のキーワードガイド にあります。このページはそれが済んでいる前提で、各職種でページが何を証明すべきかに集中します。

職種別のテック職の履歴書の例

以下の例はすべて架空です。人物、会社、数値は、強い項目の形を示すために作ったものです。日本語に訳していますが、英文レジュメでは英語で書きます。

プロダクトマネージャー

読み手が知りたいのは、何をリリースしたか、誰が使ったか、何を作るかをどう決めたかです。弱い PM の履歴書は責任を並べ（「ロードマップを担当」）、強い履歴書は方法を添えて成果を並べます。

スキルのセクション： ディスカバリーの手法（インタビュー、アンケート、ユーザビリティテスト）、実験のツール（A/B テストのフレームワーク、Amplitude や Mixpanel などの分析）、自分でクエリを書けるなら SQL、開発管理のツール（Jira、Linear）、そして業界の知識（決済、医療、B2B SaaS）。テクニカル PM の求人でない限り、プログラミング言語は書きません。

リンク： LinkedIn と、一般の人が見られるならプロダクトそのもの。プロダクト哲学についての Medium の記事より、ローンチについての短い公開の振り返りのほうが価値があります。

数値： 導入、アクティベーション、継続率、売上、リリースまでの時間、削った範囲、一緒に働いたチームの規模。

例（架空）： シニアプロダクトマネージャー、Lumen Ledger（B2B の請求書 SaaS）、2024 年〜現在

• 請求書のリマインダー機能をディスカバリーからローンチまで担当。最初の四半期に 1,200 の有料アカウントが利用し、それらのアカウントの支払い遅延は 18% 減少。
• 32 件の顧客インタビューと回答 400 件のアンケートで 2026 年のロードマップの優先順位を付け、開発開始前に予定範囲を 3 分の 1 削減。
• アクティベーションの指標（7 日以内に最初の請求書を送信）を定義し、オンボーディングの改善で 41% から 56% に向上。
• PRD を書き、エンジニア 6 名とデザイナー 1 名で 2 週間のスプリントを運営。12 か月で 11 回リリース。

データアナリストとデータサイエンティスト

読み手はまず SQL を、次にデータウェアハウスと BI のツールを、そして分析が意思決定を変えたかを探します。データサイエンスの職では、モデリングのライブラリが加わり、モデルの指標とデプロイの経緯を探します。

スキルのセクション： 方言付きの SQL（BigQuery、Snowflake、Postgres）、使っているライブラリ付きの Python または R（pandas、statsmodels、scikit-learn）、変換と BI のツール（dbt、Looker、Tableau、Power BI）、実験計画、そしてデータサイエンスならモデリング（勾配ブースティング、予測、NLP）とデプロイの基本（Docker、Airflow、MLflow）。

リンク： 整えたノートブックが 1〜2 個ある GitHub、または公開のダッシュボード。

数値： 節約できた金額や時間、変わった意思決定、短縮したレポート作成時間、モデルの性能（AUC、RMSE、precision@k）、そしてモデルが本番で何をしたか。

例（架空）： データアナリスト、Northbank Grocery（ネットスーパー）、2023 年〜現在

• BigQuery 上の dbt モデルをもとに Looker で週次の継続率ダッシュボードを構築。4 つのスプレッドシートを置き換え、月曜のレポート作成を 6 時間から 20 分に短縮。
• 14 都市での差分の差分法により配達枠の価格設定を分析。結果をもとに価格チームがピーク枠の料金を引き上げ、年間推定 31 万ポンドを上乗せ。
• 経理、マーケティング、取締役会の資料が現在共有している「アクティブ顧客」の SQL の定義を作成。
• 勾配ブースティングによる解約モデル（AUC 0.84）を学習させ、週次の引き留めキャンペーンに活用。対象の顧客は対照群より解約が 9% 少ない。

UX デザイナー

重い役割を担うのはポートフォリオなので、履歴書の仕事は読み手にそれを開かせることです。採用責任者は、最初から最後までのプロセス（リサーチ、フロー、プロトタイプ、引き渡し）と、デザインがリリース後に指標を変えた証拠を探します。

スキルのセクション： デザインツール（Figma、プロトタイピング）、リサーチの手法（ユーザビリティテスト、インタビュー、アンケート）、システムの仕事（デザインシステム、コンポーネントライブラリ）、アクセシビリティ（WCAG 2.1 または 2.2）、そして読み解いている分析ツール（Mixpanel、Hotjar）。フロントエンドの知識（HTML/CSS、React の基本）を 1 行入れると、プロダクトチームには役立ちます。

リンク： ポートフォリオの URL を、名前の横の一番上に。パスワードなしで開けるようにするか、応募時にパスワードを伝えます。Dribbble や Behance は、そこにある作品が最新の場合にだけ加えます。

数値： タスクの完了率、コンバージョン、作業時間、問い合わせの件数、アクセシビリティ監査の結果、ほかのチームによるデザインシステムの採用。

例（架空）： プロダクトデザイナー、Harbor Health（患者向けアプリ）、2023 年〜現在 · ポートフォリオ：harborwork.example

• 予約の流れを 9 画面から 4 画面に再設計し、リリース後 1 か月で完了率が 63% から 81% に向上（Mixpanel）。
• 3 ラウンドで 18 回のユーザビリティセッションを実施し、その結果を 2 つのチームが現在使う Figma のコンポーネントライブラリにまとめた。
• エンジニアリングと協力してアクセシビリティの改善を行い、46 画面が WCAG 2.1 AA の監査に合格。

DevOps と SRE

この履歴書は、重点がインフラ、信頼性、コストに移っているものの、ソフトウェアエンジニアの履歴書に最も近い読まれ方をします。読み手は、クラウドプロバイダー、オーケストレーションとインフラのコード化のツール、そしてオンコールの経験があるかを探します。

スキルのセクション： クラウド（運用したサービス付きの AWS、GCP、Azure）、Kubernetes と Helm、Terraform または Pulumi、CI/CD（GitHub Actions、GitLab CI、Argo CD）、オブザーバビリティ（Prometheus、Grafana、Datadog）、スクリプト（Python、Bash、Go）、Linux、ネットワークの基本、障害管理。

リンク： 保守している Terraform モジュール、Helm チャート、オペレーターのある GitHub。

数値： デプロイ時間、デプロイ頻度、変更失敗率、平均復旧時間、SLO の達成状況、週あたりの呼び出し、インフラのコスト。

例（架空）： サイトリライアビリティエンジニア、Quillpay（決済）、2022 年〜現在

• 手作業で構築した EC2 ホストから EKS へ、Terraform と Helm で 40 のサービスを移行。デプロイ時間は 45 分から 6 分に、月間の計算コストは 22% 削減。
• 決済 API（SLO 99.95%）のオンコールを担当。アラートのしきい値と 3 つの繰り返し起きる障害の原因を直し、呼び出しを週 31 回から 8 回に削減。
• カナリアデプロイと自動ロールバック付きの GitHub Actions のパイプラインを構築し、変更失敗率を 14% から 4% に低下。
• 障害対応のプロセスを作り、1 年で 26 回の非難しない振り返り（ポストモーテム）を主催。復旧時間の中央値は 71 分から 24 分に短縮。

IT サポートとシステム管理者

読み手はまず環境（Windows か Linux か、Microsoft 365 か Google Workspace か、オンプレミスかクラウドの ID か）を、次に規模（ユーザー、拠点、チケット）を、そして作業をこなすだけでなく減らしたかを確かめます。

スキルのセクション： OS とディレクトリサービス（Windows Server、Active Directory、Entra ID）、端末管理（Intune、Jamf）、オフィススイート、ネットワーク（VLAN、DHCP、DNS、ファイアウォール）、スクリプト（PowerShell、Bash）、チケット管理（Jira Service Management、ServiceNow）、フレームワーク（ITIL）。資格はほかの多くのテック職より重要で、CompTIA、Microsoft、Cisco、クラウドの基礎資格は独立したセクションに入れます。

リンク： LinkedIn で十分です。DevOps に移りたいなら、PowerShell や自動化のスクリプトのある GitHub が役立ちます。

数値： サポートしたユーザーと拠点の数、完了したチケット、当日解決率、稼働率、展開にかかった時間、端末ごとのセットアップ時間、変更前後のセキュリティインシデント。

例（架空）： IT システム管理者、Castell Logistics（従業員 600 名、4 拠点）、2022 年〜現在

• 600 ユーザーの Microsoft 365、Intune、Active Directory を管理。年間約 2,400 件のチケットを完了し、当日解決率は 94%。
• 全アカウントに MFA と条件付きアクセスを 8 週間で展開。アカウント侵害のインシデントは、その後 1 年で四半期 5 件からゼロに。
• 手作業のノートパソコンのセットアップを Autopilot のイメージに置き換え、新入社員の準備を 3 時間から 30 分に短縮。

QA とテストエンジニア

読み手はまず自動化を、次にテスト設計を、そしてあなたのテストが顧客より先に問題を見つけた証拠を探します。手動テストだけの QA の履歴書でも面接には呼ばれますが、スキルのセクションにフレームワークの名前があれば、リストの上に上がります。

スキルのセクション： 言語付きの自動化フレームワーク（Playwright、Cypress、Selenium と TypeScript、Python、Java）、API テスト（Postman、REST Assured）、パフォーマンス（JMeter、k6）、テスト管理（TestRail、Xray）、CI との連携、データ確認のための SQL、そして持っているなら ISTQB（日本では JSTQB）。

リンク： 小さくてもサンプルのテストスイートのある GitHub は、テストの組み立て方を示します。

数値： テストの数とカバレッジ、スイートの実行時間、検出したリグレッション、リリース前に見つけた不具合、節約した手動の回帰テストの時間、リリース後に漏れた不具合。

例（架空）： QA エンジニア、Brightlane（エドテック）、2023 年〜現在

• 決済と教室の操作フローにわたる Playwright の E2E スイートをゼロから 420 テストまで構築。CI で 11 分で実行され、1 年で 37 件のリグレッションを止めた。
• 決済の移行のテスト計画を作り、リリース前に 23 件の不具合を発見。その中には注文の 3% に影響する通貨の端数処理のバグがあった。
• ケースの 60% を自動化し、重複を削除して、手動の回帰テストを 3 日から 1 日に短縮。

どのテック職でも使えるスキルのセクションの書き方

カテゴリーごとにまとめて行にラベルを付け、求人が重視する順に並べます。Snowflake を使う会社に応募するデータアナリストは SQL と Snowflake から始め、同じアナリストが Python 中心の研究チームに応募するなら pandas と statsmodels から始めます。4〜6 行が一般的です。

面接で話せるものを書いてください。採用担当者は一覧をテストしませんが、採用責任者は最もなじみのなさそうな項目を選んで質問してきます。一度しか使ったことのないツールは、スキルのブロックではなく、文脈付きでプロジェクトの箇条書きに入れます（「Grafana で概念実証を構築」）。

ツールごとの経験年数（「Python（5 年）」）はほとんど役に立たず、害になることもあります。読み手が箇条書きを読まずに、その数字を求人の要件と比べてしまうからです。

コードをリリースしない職の数値

エンジニアリング以外のテック職では、数値を見つけるのに苦労することがあります。あきらめる前に、次の源を試してください。

• 時間。 週あたりに節約した時間、サイクルタイム、解決までの時間、リリースまでの時間。ほとんどの職で、何かが速くなったことは測れます。
• 規模。 ユーザー、アカウント、チケット、画面、サービス、拠点、都市。規模は、どの大きさの問題を扱ってきたかを読み手に伝えます。
• 率。 完了率、コンバージョン率、解決率、失敗率、導入率。変更前と変更後のペアが最も強い形です。
• 金額。 加えた売上、削ったコスト、避けた支出。経理が承認していない数字なら「推定」と書きます。

数値が存在しないなら、範囲を書きます。「アプリの 46 画面」「エンジニア 6 名のチーム」「4 拠点」。範囲は形容詞に勝ります。

テック職の履歴書テンプレートで見るべき点

テック職のテンプレートには、ラベル付きの行を入れられるスキルのブロック、職歴の横に置けるプロジェクトのセクション、そして PDF に書き出したときのきれいなテキスト層が必要です。テキストボックスやレイアウト用の表で作った装飾は、パーサーが順番どおりに読まないので、損になることがあります。

Resume Matcher は、自分の AI モデルを使い、自分のマシンで動かす無料のオープンソースのアプリ（Apache 2.0）で、アップロード先のウェブサイトではありません。ビルダーには 7 つのテンプレート（Single Column、Two Column、Modern、Modern Two Column、LaTeX 風、Clean、Vivid）があります。どれもヘッドレスの Chrome ブラウザが本物のウェブページのテキストから印刷したテキストベースの PDF を書き出すので、すべての単語を選択でき、2 段組みのレイアウトでも読み取り順では本文が先に来ます。A4 か US Letter、余白、間隔、文字サイズを設定し、明朝系・ゴシック系・等幅のフォントを選び、職種に合わせてセクションをドラッグして並べ替えられます。たとえばデザイナーならプロジェクトを職歴の上に置けます。プレビューと調整項目の一覧は PDF テンプレートのページ（英語）にあります。

どこから入手したテンプレートでも、どこかに送る前に一度コピー＆ペーストのテストをしてください。

テック職の履歴書によくある失敗

• 職歴のセクションより長いスキル一覧。 求人が求めるもの、説明できるものに絞ってください。
• 成果ではなく責任。 「オンコールのローテーションを管理」と「呼び出しを週 31 回から 8 回に削減」の違いです。
• パスワードが必要な、または未完成のサイトにつながるポートフォリオのリンク。
• どこにでも使い回すサマリー。 応募ごとに書き直した 2 行か、なしにします。
• すべての求人に同じページ。 決済の会社向けと医療の会社向けの PM の履歴書は、スキルのセクションを共有すべきではありません。写しを 1 つずつカスタマイズする方法は 求人内容に合わせて履歴書をカスタマイズする方法 にあります。

よくある質問

テック職の履歴書とソフトウェアエンジニアの履歴書は違いますか？ 書式は同じです。違うのは読み手が探すもので、PM は成果とディスカバリーで、SRE は信頼性とコストで、デザイナーはポートフォリオで選考されます。ソフトウェアエンジニアには、プロジェクトとオープンソースについて独自の慣習があります。ソフトウェアエンジニアの履歴書ガイド を参照してください。

テック職の履歴書の長さは？ 最初の 8〜10 年は 1 ページ。プロダクトやシステムの経歴が長いシニアなら 2 ページを使えます。

ポートフォリオは必要ですか？ デザイナーは例外なく必要です。アナリストと QA エンジニアは、小さな GitHub があると有利です。PM やシステム管理者はなくても構いませんが、公開のプロダクトやスクリプトのリポジトリがあって損はありません。

ソフトスキルは書くべきですか？ 求人が挙げているものだけを、一覧ではなく箇条書きで示してください。「26 回の非難しない振り返りを主催」のほうが、その言葉そのものよりもコミュニケーション力を証明します。

このガイドが役に立ったら、GitHub の Resume Matcher にスターを付けてください。開発しているのは Saurabh Rai です。GitHub、X、LinkedIn でフォローできます。