ソフトウェアエンジニア向け履歴書のATS最適化チェックリスト

米国労働統計局は、ソフトウェア開発者の求人が2034年までに17％成長すると予測しており、年間約140,600の新規ポジションが生まれます [1]。しかし、主要な求人サイトにおけるソフトウェアエンジニアの求人1件あたりの応募者数は250名を超え、GreenhouseやLeverを使用する企業では、そのうち人間のリクルーターの画面に到達するのは8％未満です [6]。この関門は人ではなく、ATS（応募者追跡システム）です。ATSはエンジニアや採用担当者が一行読む前に、履歴書のキーワードの完全一致、セクション構造、書式のシグナルを解析します。ATSの審査を通過することは、システムを操作することではありません。これらのシステムが認識するよう設計された構造と語彙で、あなたの実際の資格を提示することです。

本ガイドでは、2026年のソフトウェアエンジニア職のATS審査を通過するための正確なキーワード、書式ルール、セクション別戦略を解説します。

要点

• テック業界のATSプラットフォーム（Greenhouse、Lever、Ashby、Workday）は履歴書の解析方法が異なります — 標準的なセクション見出しを持つ、プレーンな書式の単一カラムの.docxまたは.pdfファイルが、すべてのプラットフォームで最も高い互換性を提供します。
• 完全一致のキーワードは同義語より重要です。 求人票に「React」と書かれているのに履歴書に「ReactJS」と書くと、一部のATSプラットフォームでは一致として認識されません。両方の表記を含めてください。
• 技術スキルセクションはATS上で最も価値のある領域です。 構造化されカテゴリ分けされたスキルリスト（言語、フレームワーク、クラウド/インフラ、ツール）は、箇条書きの中に埋もれたスキルよりも多くのキーワード一致を生成します。
• 定量化されたインパクトは責任の記述に勝ります。 GreenhouseとLeverのATSスコアリングは、測定可能な成果を優先する「スコアカード」基準を重視するようになりました — 「APIレイテンシを40％削減」は「APIパフォーマンスを担当」よりも高いスコアを得ます。
• ファイル形式は重要です。 求人が明示的に.pdfを求めていない限り、.docxで提出してください。LeverとWorkdayは、特にテーブルやマルチカラムレイアウトにおいて、.pdfよりも.docxをより確実に解析します [5]。
• 応募ごとに1つの履歴書を用意してください。 各求人票に合わせてキーワードを調整することで、汎用的な履歴書を提出する場合と比較して、ATSの一致率が30〜50％向上します [5]。

ATSがソフトウェアエンジニアの履歴書を審査する仕組み

すべてのATSプラットフォームが同じように動作するわけではなく、企業がどのシステムを使用しているかによって、履歴書の書式を変える必要があります。

Greenhouse（SaaS企業とスタートアップで主流）

Greenhouseは、ベンチャー支援のスタートアップや中規模〜大規模のSaaS企業で最も一般的なATSです。特定のポジション属性に紐づけられた構造化スコアカードを使用します。リクルーターが解析済みの履歴書を開くと、プログラミング言語、経験年数、学歴、求人票に記載された特定の技術など、事前定義された基準とプロフィールの一致度をGreenhouseが強調表示します [6]。

履歴書への影響： Greenhouseは強力なキーワード抽出を行いますが、情報のカテゴリ分けにセクション見出しを大きく依存しています。「経験」「技術スキル」「学歴」などの標準的な見出しを使用してください。「私が作ったもの」や「マイツールキット」のような創造的な代替案は避けてください。

Lever（中堅テック企業）

LeverはATSとCRMの機能を兼ね備えており、特定のポジションがクローズした後も、あなたの履歴書は長期的な候補者データベースに残ります。Leverの解析エンジンは.pdfと.docxの両方をうまく処理しますが、マルチカラムレイアウトやヘッダー・フッターに埋め込まれたテキストには苦労します。

履歴書への影響： すべてをドキュメント本文に記載してください。氏名、メールアドレス、電話番号をヘッダー/フッター領域に配置しないでください — Leverが解析できない場合があります。単一カラムのレイアウトが最も安全です。

Workday（エンタープライズテック — FAANG、Fortune 500）

WorkdayはAmazon、Google、Salesforceをはじめとする数百の企業の採用を支えています。その解析は積極的で、構造化データ（雇用主名、職種名、日付、学歴）を抽出して内部フィールドにマッピングしようとします。Workdayのパーサーは日付形式と職種名の表記規則に対して非常に厳格であることで知られています。

履歴書への影響： 一貫した日付形式（「2023年1月 – 現在」または「2023年 – 現在」）を使用してください。職種名は明確に記載してください — 「Software Engineer II」であり、「SWE2」ではありません。Workdayのパーサーは認識できない略語を拒否します。

iCIMS（大企業）

iCIMSは、ソフトウェアエンジニアを採用する大規模な非テック企業（銀行、医療、小売）にサービスを提供しています。そのパーサーはGreenhouseやLeverよりも古く、洗練度が低くなっています。必要なスキルの完全一致に大きく依存します。

履歴書への影響： 求人票の正確な表現を再現してください。求人に「Java/Spring Boot」と書かれている場合、その正確な文字列を含めてください — 「Java」と「Spring」を別々に書くだけでは不十分です。

Ashby（新興スタートアップ）

AshbyはSeries A〜Cのスタートアップで急速に採用されています。最も近代的なパーサーの一つを持ち、さまざまな形式をうまく処理しますが、AI駆動の候補者ランキングはキーワード密度と関連性スコアを重視します。

履歴書への影響： Ashbyは、スキルセクションに単に列挙されるのではなく、実際の業務を説明する箇条書きの中でキーワードが文脈とともに現れる履歴書を評価します。スキルセクションと経歴の箇条書きの両方にキーワードを含めてください。

ソフトウェアエンジニアの必須ATSキーワード

これらのキーワードは、O*NETのソフトウェア開発者（15-1252）のタスク分析 [2]、Stack Overflow 2024開発者調査 [3]、および主要プラットフォーム上の500件以上のソフトウェアエンジニア求人の分析 [7][8] に基づいています。

プログラミング言語

ATSのヒント： 該当する場合、正式名称と一般的な略語の両方を記載してください：「JavaScript/JS」「TypeScript/TS」「Golang/Go」。一部のパーサーは片方の形式しか認識しません。

フレームワークとライブラリ

• フロントエンド： React、Next.js、Angular、Vue.js、Svelte、Tailwind CSS
• バックエンド： Node.js、Express、Django、Flask、FastAPI、Spring Boot、Ruby on Rails、ASP.NET
• モバイル： React Native、Flutter、SwiftUI、Jetpack Compose
• データ/ML： TensorFlow、PyTorch、pandas、NumPy、scikit-learn

クラウドとインフラ

• クラウドプラットフォーム： AWS (Amazon Web Services)、GCP (Google Cloud Platform)、Microsoft Azure
• コンテナとオーケストレーション： Docker、Kubernetes (K8s)、ECS、EKS、GKE
• CI/CD： GitHub Actions、Jenkins、CircleCI、GitLab CI、ArgoCD
• IaC： Terraform、CloudFormation、Pulumi、Ansible
• 監視： Datadog、Grafana、Prometheus、New Relic、PagerDuty

データベース

• リレーショナル： PostgreSQL、MySQL、SQL Server、Oracle
• NoSQL： MongoDB、DynamoDB、Redis、Cassandra、Elasticsearch
• データウェアハウス： Snowflake、BigQuery、Redshift

方法論と実践

• Agile、Scrum、Kanban
• テスト駆動開発（TDD）
• CI/CD（継続的インテグレーション / 継続的デプロイメント）
• コードレビュー、ペアプログラミング
• マイクロサービスアーキテクチャ
• REST API / GraphQL
• システム設計
• DevOps、サイト信頼性エンジニアリング（SRE）
• パフォーマンス最適化
• セキュリティベストプラクティス（OWASP）

ATSが追跡するソフトスキル

多くのATSプラットフォーム、特にGreenhouseとAshbyは、ソフトスキルのキーワードも抽出するようになっています [6]：

• 部門横断的な協力
• 技術的メンタリング
• 関係者とのコミュニケーション
• インシデント対応
• 技術文書作成
• スプリント計画
• アーキテクチャの意思決定

ATS審査を通過する履歴書の書式

書式のエラーは、キーワードの欠如よりも多くのATS拒否を引き起こします。以下のルールに従ってください：

ドキュメント構造

• ファイル形式： .docxが推奨、求人が許可していれば.pdfも可。.pages、.odt、画像ベースのPDFは不可。
• レイアウト： 単一カラムのみ。二段組のレイアウトはLever、Workday、iCIMSでの解析を壊します。
• フォント： 標準的なシステムフォント — Arial、Calibri、Helvetica、Times New Roman。本文は10〜12pt、見出しは13〜16pt。
• 余白： 四辺とも0.5インチ〜1インチ。密度を高めるためにより狭い余白でも構いませんが、0.5インチ未満にはしないでください。
• 長さ： 経験5年未満は1ページ、5〜15年は2ページ、出版物や特許の実績が豊富なprincipal/staff+のみ3ページ。

見出しとセクション

ATSの互換性を最大化するために、以下のセクションタイトルを使用してください：

1. [氏名] — 上部に記載、ヘッダー/フッター領域には配置しない
2. 連絡先情報 — メール、電話、LinkedIn URL、GitHub URL（別の行またはパイプ区切り）
3. 職務要約 または 要約
4. 技術スキル または スキル
5. 職務経歴 または 経歴
6. 学歴
7. 資格・認定 （該当する場合）
8. プロジェクト （任意、ジュニアエンジニアやキャリアチェンジ者向け）

避けるべきこと

• レイアウト用のテーブル — ATSパーサーはテーブルをセルごとに読み取り、コンテンツの順序を乱します
• テキストボックス — ほとんどのパーサーにとって見えません
• 画像、アイコン、グラフィック — 完全に無視されます。スキルバーチャートはスペースの無駄です
• 連絡先情報のヘッダー/フッター — LeverとWorkdayはこれらの領域をスキップします
• タブやスペースで作成した列 — パーサーが位置をずらします
• 装飾的な箇条書き文字 — 標準的な箇条書き（•）またはハイフン（-）を使用してください

セクション別ATS最適化

職務要約（3〜4行）

要約はキーワード密度の高い冒頭部分です。ATSプラットフォームは、リクルーターがこのセクションに対して検索を設定するため、集中的にインデックスを作成します。

構成： [経験年数] + [コア専門分野] + [2〜3の主要技術] + [測定可能なインパクト]

例：

Pythonおよび Goによる分散システムとREST API構築に6年の経験を持つソフトウェアエンジニア。モノリシックアーキテクチャからAWS（ECS/Fargate）上のマイクロサービスへの移行を主導し、デプロイ時間を4時間から12分に短縮、システム稼働率を99.97％に向上。React、TypeScript、PostgreSQL、Docker、Kubernetes、GitHub ActionsによるCI/CDに精通。

ATSで機能する理由： Python、Go、REST API、分散システム、マイクロサービス、AWS、ECS、Fargate、React、TypeScript、PostgreSQL、Docker、Kubernetes、CI/CD、GitHub Actionsなど、12以上のマッチ可能なキーワードを含みながら、人間のレビュアーにも自然に読めます。

技術的経歴

各ポジションは以下の構造に従ってください：

Software Engineer | 会社名 | 2022年1月 – 現在

• 職種名は独立した行または明確に区切って記載 — ATSは職種名、会社名、日付を構造化フィールドとして抽出します
• 日付形式： 「YYYY年M月 – YYYY年M月」または「YYYY年 – 現在」
• ポジションごとに3〜6の箇条書き、それぞれ以下のパターンに従う：[アクション動詞] + [構築/実行したもの] + [使用技術] + [定量化された成果]

効果的な箇条書きの公式：

[技術]を使用して[システム/機能]を設計・実装し、[測定可能な成果]を達成。

技術スキルセクション

このセクションはATSキーワードマッチングのために存在します。カテゴリ別のリストとして書式を設定してください：

技術スキル

言語：Python、JavaScript、TypeScript、Go、Java、SQL、Bash
フロントエンド：React、Next.js、HTML5、CSS3、Tailwind CSS、Redux
バックエンド：Node.js、Express、Django、FastAPI、Spring Boot、GraphQL
クラウド・インフラ：AWS（EC2、S3、Lambda、SQS、ECS）、GCP、Docker、Kubernetes
データベース：PostgreSQL、MySQL、Redis、MongoDB、DynamoDB、Elasticsearch
DevOps・ツール：Terraform、GitHub Actions、Jenkins、Datadog、Git、Jira
方法論：Agile/Scrum、TDD、CI/CD、マイクロサービス、ドメイン駆動設計

カテゴリが重要な理由： GreenhouseとAshbyは、カテゴリ分けされたスキルセクションを構造化データとして解析し、ポジション要件のスコアカードに直接マッピングします。構造化されていないカンマ区切りのリストでは、このマッピングが失われます [6]。

学歴と資格

コンピュータサイエンス学士 | 大学名 | 2018年
AWS Certified Solutions Architect – Associate | Amazon Web Services | 2024年

• 学位の正式名称を含めてください — 「コンピュータサイエンス学士」であり、「CS学士」ではありません
• ブートキャンプ卒業生の場合：プログラム名とプロバイダーを記載し、関連するコースワークや卒業制作を追記してください
• 求人に頻繁に登場する資格 [7]：AWS Certified（いずれのトラックでも）、Google Cloud Professional、Kubernetes（CKA/CKAD）、Azure Fundamentals、Terraform Associate

ソフトウェアエンジニアの履歴書がATSで拒否される一般的な理由

1. 略語のみで正式名称を記載していない

履歴書に「K8s」とあるがATSは「Kubernetes」を検索しています。「JS」とあるがパーサーは「JavaScript」を求めています。常に両方を含めてください：「Kubernetes (K8s)」「JavaScript/JS」。これはソフトウェアエンジニアにとって最も一般的な修正可能なATS不合格要因です [5]。

2. 技術を箇条書きの中にしか記載していない

Pythonが「Pythonでデータパイプラインを構築」のような文の中にしか出現しない場合、一部のATSパーサーはそれを独立したスキルとして抽出しません。技術スキルセクション（キーワード抽出用）と箇条書き（文脈スコアリング用）の両方に記載する必要があります。

3. 非標準のセクション見出し

創造的なセクション名はATSの解析を壊します。「経歴」の代わりに「私の歩み」、「スキル」の代わりに「ツールボックス」、「学歴」の代わりに「学習」。パーサーはこれらが何であるかを認識できず、セクション全体をスキップする可能性があります。

4. 経歴の箇条書きに指標がない

Greenhouseのような最新のATSプラットフォームは、リクルーターが特定の基準で候補者を評価するスコアカードを使用しています。数字のない箇条書き — 「アプリケーションのパフォーマンスを改善」 — では評価するものがありません。数字のある箇条書き — 「APIのp95レイテンシを850msから210msに削減」 — はすぐに評価可能です [6]。

5. 二段組またはサイドバーレイアウト

スキル用のサイドバーと経歴用のメインカラムを持つデザイナーの履歴書テンプレートは、ATSにとって致命的です。Leverは両方のカラムを左から右に読み、スキルリストと職務の箇条書きを意味不明なテキストに混在させます。Workdayはサイドバーを完全にスキップする場合があります。

6. 履歴書の内容の代わりにポートフォリオリンクを提出

一部のエンジニアは簡素な履歴書を書き、「詳細はGitHubをご覧ください」と追記します。ATSシステムはリンクをたどりません。関連するすべてのプロジェクト、技術、成果は履歴書自体に記載されていなければなりません。GitHub URLは連絡先情報に含めるべきですが、履歴書の内容を代替するものではありません。

7. 現在のスキルを含まない古い技術スタック

直近のポジションでjQuery、Backbone.js、SVNを記載しているが、求人ではReact、TypeScript、Gitを求めている場合、実際の能力に関わらずATSキーワードマッチスコアは低くなります。直近の職務で異なるスタックを使用していたとしても、要約とスキルセクションでは現在の技術を先頭に記載してください。個人プロジェクトやオープンソースへの貢献は、現在のスタックのキーワード源として有効です。

ビフォー・アフターの例

例1：曖昧なバックエンドの箇条書き → 定量化されたインパクト

ビフォー：

バックエンドサービスに携わり、システムパフォーマンスの向上に貢献しました。

アフター：

Goで受注処理マイクロサービスを再設計し、同期REST呼び出しを非同期のイベント駆動アーキテクチャ（Kafka + gRPC）に置き換えました。注文完了の平均時間を3.2秒から0.8秒に短縮し、ピーク時のトラフィックで4倍のスループット増加に対応しました。

機能する理由： 6つの抽出可能なキーワード（Go、マイクロサービス、REST、Kafka、gRPC、イベント駆動アーキテクチャ）と2つの定量化された成果を含んでいます。元の文にはキーワードも指標もゼロです。

例2：一般的なフロントエンドの箇条書き → 具体的な技術貢献

ビフォー：

ユーザーインターフェースの開発とWebアプリケーションのバグ修正を行いました。

アフター：

顧客ダッシュボード向けにTypeScriptで12の再利用可能なReactコンポーネントを構築し、Next.jsによる遅延読み込みとコード分割を実装して初期バンドルサイズを62％削減（1.8MB → 680KB）、JestとReact Testing Libraryによるユニットテストカバレッジ94％を達成しました。

機能する理由： 8つの抽出可能なキーワード（React、TypeScript、Next.js、遅延読み込み、コード分割、Jest、React Testing Library、ユニットテスト）、具体的な範囲（12コンポーネント）、3つの測定可能な成果があります。

例3：DevOpsの責任 → インフラの実績

ビフォー：

クラウドインフラとデプロイパイプラインを管理しました。

アフター：

GitHub ActionsとArgoCDを使用してCI/CDパイプラインを設計し、GitOpsベースのデプロイをKubernetes（EKS）に実装。リリースサイクルを隔週の手動デプロイから1日15回以上のゼロダウンタイムローリングアップデートによる自動本番デプロイに短縮しました。Terraformで3つのAWSリージョンにまたがるInfrastructure as Codeを管理しました。

機能する理由： 10の抽出可能なキーワード（CI/CD、GitHub Actions、ArgoCD、GitOps、Kubernetes、EKS、Terraform、AWS、Infrastructure as Code、ゼロダウンタイム）、明確なビフォー・アフターの比較、具体的な運用規模があります。

技術スキルセクションの書式設定

技術スキルセクションは、ATSキーワードマッチングにおいて最も重要なセクションです。すべての主要ATSプラットフォームで最大限の抽出を実現する書式設定方法を解説します：

推奨形式（カテゴリ：カンマ区切りリスト）

技術スキル

言語：Python、JavaScript、TypeScript、Go、Java、SQL、Bash
フロントエンド：React、Next.js、HTML5、CSS3、Tailwind CSS、Redux
バックエンド：Node.js、Express、Django、FastAPI、Spring Boot、GraphQL
クラウド・インフラ：AWS（EC2、S3、Lambda、SQS、ECS）、GCP、Docker、Kubernetes
データベース：PostgreSQL、MySQL、Redis、MongoDB、DynamoDB、Elasticsearch
DevOps・ツール：Terraform、GitHub Actions、Jenkins、Datadog、Git、Jira
方法論：Agile/Scrum、TDD、CI/CD、マイクロサービス、ドメイン駆動設計

この形式が機能する理由

1. Greenhouseは各カテゴリをスコアカード属性にマッピングし、リクルーターがスキルカバレッジを一目で確認できるようにします
2. Leverはリスト全体を候補者プロフィールのタグとして抽出します
3. Workdayはこれらのフラットリストに対して完全一致検索を実行します
4. Ashbyはカテゴリラベルと個別のスキルの両方を関連性ランキングに使用します

書式ルール

• 明確な見出しを使用（「技術スキル」または「スキル」） — スキルをサイドバーやテーブルに埋め込まないでください
• 1行に1カテゴリ — すべてのスキルを1つの段落にまとめないでください
• クラウドには括弧で詳細を追記： 「AWS（EC2、S3、Lambda、SQS）」は「AWS」と個別のサービス名の両方の検索に一致します
• 合計30〜50の技術を記載 — 20未満ではATSランキングアルゴリズムに狭いスキルセットとみなされ、60を超えると焦点が定まらない印象を与え、スパムフィルターをトリガーする可能性があります
• 対象ポジションとの関連性順に並べる — 求人票がPythonとAWSから始まっているなら、それらをリストの最初に配置してください
• 習熟度評価やスキルバーは使用しない — ATSは視覚的な習熟度指標を無視し、人間のレビュアーもそれらを意味あるものとは考えません

ATS互換性チェックリスト

応募を提出する前に、このチェックリストを確認してください：

• [ ] ファイル形式が.docxまたは標準的な.pdf（スキャン/画像PDFではない）
• [ ] テーブル、テキストボックス、サイドバー要素のない単一カラムレイアウト
• [ ] 標準的なセクション見出しを使用： 要約、スキル、経歴、学歴
• [ ] 連絡先情報がドキュメント本文にある（ヘッダーやフッターではない）
• [ ] 求人票のすべての技術が履歴書に記載されている — スキルセクションと少なくとも1つの経歴の箇条書きの両方に
• [ ] 主要用語の正式名称と略語の両方を記載： 「Kubernetes (K8s)」「継続的インテグレーション/継続的デプロイメント (CI/CD)」「Amazon Web Services (AWS)」
• [ ] 職種名が明確で標準的： 「Software Engineer」であり、「Code Ninja」や「IC3」のような社内タイトルではない
• [ ] 日付形式がドキュメント全体で一貫している： 「2023年1月 – 現在」または「2023年 – 現在」
• [ ] 各経歴の箇条書きに少なくとも1つの技術キーワードと1つの指標が含まれている（パーセンテージ、件数、時間短縮、規模）
• [ ] 技術スキルセクションがカテゴリ分けされている（言語、フレームワーク、クラウド、データベース、ツール、方法論）
• [ ] ドキュメントのどこにも画像、チャート、アイコン、グラフィックがない
• [ ] 箇条書きに特殊文字がない — 標準的な箇条書き（•）またはハイフン（-）を使用
• [ ] GitHubとLinkedIn URLが完全なハイパーリンク（https://github.com/username、https://linkedin.com/in/username）
• [ ] 履歴書のスペルチェック済み — ATSキーワードマッチングは完全一致であり、「Kubernates」は「Kubernetes」にマッチしません
• [ ] この特定の求人票に合わせて履歴書を調整済み — すべてのポジションに送る汎用バージョンではない

よくある質問

使用したすべてのプログラミング言語を記載すべきですか？

いいえ。技術面接で自信を持って議論できる言語 — 一般的には過去3〜5年間にプロフェッショナルまたは実質的なプロジェクトで使用した言語 — を記載してください。15以上の言語を記載するとプロフィールが希薄になり、ATSのスパム検出をトリガーする可能性があります。Stack Overflow開発者調査によると、プロフェッショナル開発者の中央値は4〜5言語を積極的に使用しています [3]。求人票の言語と、最も強い隣接スキルに集中してください。

ATSシステムはGitHubプロフィールやポートフォリオサイトを読みますか？

ATSプラットフォームは外部リンクをたどったり、サードパーティのサイトをクロールしたりしません。GitHub URLは連絡先情報に含めるべきですが、関連するすべてのプロジェクト、技術、貢献は履歴書自体にも記載されている必要があります。一部のリクルーターは手動でGitHubを訪問しますが、ATSスコアリングは提出したドキュメントからのみ行われます [5]。

経験と対象ポジションの間に技術スタックの不一致がある場合はどうすればよいですか？

求人がReactを要求しているが、職務経験がAngularの場合、ギャップに直接対処してください。Reactでプロジェクトを構築したことがあれば、スキルセクションにReactを含めてください（個人プロジェクト、オープンソース、コースワークも有効です）。プロジェクトセクションに簡単な説明を追記してください：「個人向け家計簿ダッシュボード — React、TypeScript、Node.js、PostgreSQL」。ATSはドキュメント上にキーワードが存在することを必要とします。深い知識を証明するのは面接の場です。

ソフトウェアエンジニアに1ページの履歴書は必須ですか？

経験5年未満のエンジニアにとっては1ページが標準であり十分です。5〜15年以上のシニア、スタッフ、プリンシパルエンジニアの場合、2ページが適切かつ期待されています — 記載すべきシステム、規模、リーダーシップが多くなるためです。重要なのは密度です：すべての行に検索可能なキーワードと測定可能な成果を含めるべきです。内容の薄い1ページの履歴書は、焦点を絞った2ページの履歴書よりもスコアが低くなります。後者の方がATSキーワード密度が高いためです [5]。

CanvaやFigmaなどのデザインツールの履歴書テンプレートを使用すべきですか？

ATS提出用には避けてください。デザインツールのテンプレートは通常、グラフィック上にテキストを重ねた画像の多いPDF、二段組レイアウト、ATSパーサーが確実に抽出できない非標準の書式でエクスポートされます。標準的な書式のプレーンな.docxテンプレートを使用してください。デザインされたバージョンは、対面でのネットワーキングや、採用担当者に直接履歴書を手渡す場合に取っておいてください — ATSを通るオンライン応募には使用しないでください [5]。

参考文献

[1] U.S. Bureau of Labor Statistics. "Software Developers, Quality Assurance Analysts, and Testers." Occupational Outlook Handbook. https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm

[2] O*NET OnLine. "Software Developers (15-1252.00)." https://www.onetonline.org/link/summary/15-1252.00

[3] Stack Overflow. "2024 Developer Survey." https://survey.stackoverflow.co/2024/

[4] GitHub. "Octoverse 2024 — The State of Open Source." https://github.blog/news-insights/octoverse/octoverse-2024/

[5] Jobscan. "ATS Resume Test Results and Keyword Analysis." https://www.jobscan.co/blog/ats-resume-test/

[6] Greenhouse Software. "How Structured Hiring Reduces Bias." https://www.greenhouse.com/blog/structured-hiring

[7] Indeed Hiring Lab. "Tech Job Postings and Keyword Trends." https://www.hiringlab.org/

[8] LinkedIn Economic Graph. "Most In-Demand Skills for Software Engineers." https://economicgraph.linkedin.com/