resume-builder

履歴書／CVビルダー — ハーバード基準とATSのベストプラクティス

概要

このスキルは、Harvard Career Servicesのガイドライン、r/EngineeringResumesコミュニティのベストプラクティス、最新のATS（応募者追跡システム）に関する知見に基づき、専門的で高水準の履歴書を作成します。人間の採用担当者（履歴書を5～20秒で確認します）とATS解析システムの両方に最適化された履歴書を作成します。

履歴書の作成に着手する前に、関連するリファレンスファイルを読んでください：

• references/format-and-structure.md — ページレイアウト、フォント、間隔、セクションの順序
• references/bullet-writing-guide.md — XYZ／STARの公式、行動動詞、定量化
• references/ats-and-keywords.md — ATSに関する事実と誤解、キーワード戦略
• references/common-mistakes.md — 避けるべきこと、アンチパターン

---

クイック判断フレームワーク

ユーザーのリクエスト	対応
「ゼロから履歴書を作成して」	全工程で作成：情報収集 → 構成 → 執筆 → 書式設定 → 提出
「既存の履歴書を改善／最適化して」	現状を分析 → 問題点を特定 → 箇条書きを書き直す → 書式を整える
「求人情報に合わせて履歴書を調整して」	求人情報からキーワードを抽出 → ユーザーの経験と照合 → 対象を絞った箇条書きに書き直す
「履歴書をレビューして」	チェックリストに照らして監査 → 具体例を添えて明確なフィードバックを提供
「複数のバージョンを作成して」	ベースとなる履歴書を作成 → バリエーションを作成（1ページ、2ページ、言語別バージョン）
「ATSに適した形式にして」	書式の準拠状況を確認 → 解析しやすい構成にする → 関連キーワードを自然に追加

---

基本プロセス

ステップ1：情報を収集する

執筆を始める前に、以下を収集します：

1. 職歴のすべて — 役職、会社名、勤務地、在籍期間、および各社の事業内容とユーザーが構築したシステムの分野・業界背景
2. 技術スキル — 言語、フレームワーク、データベース、ツール、クラウド、アーキテクチャパターン
3. 学歴 — 学位、教育機関、在籍期間
4. プロジェクト — 個人、学業、オープンソース
5. 希望する市場 — 米国／海外（英語）、LATAM／スペイン（スペイン語）、または両方
6. 希望する職種 — 応募する職種の種類
7. ページ数の希望 — 1ページ（ジュニア／ミッドレベル）、2ページ（経験6年以上のシニア）、または柔軟に対応

重要：各職務の分野・業界背景を必ず確認してください。「Webアプリケーションを開発した」と「カード発行、決済リンク、取引処理を扱うフィンテックの与信管理システムを開発した」の違いは、ありきたりな履歴書と説得力のある履歴書の違いです。必ず次の点を確認します：

• どのような業界／分野でしたか？（フィンテック、リーガルテック、ヘルスケア、物流、セキュリティなど）
• どのようなデータを扱いましたか？（機微な個人情報、金融情報、法務情報、医療情報）
• エンドユーザーは誰でしたか？（B2B、B2C、社内、政府機関）
• ビジネスへの影響は何でしたか？

ステップ2：履歴書を構成する

Harvard Career Servicesとr/EngineeringResumesが推奨するセクションの順序に従います：

1. Name & Contact Information (centered)
2. Technical Skills (for engineering/tech roles — put skills FIRST)
3. Professional Experience (reverse chronological)
4. Projects & Contributions (if relevant)
5. Education (at bottom for experienced professionals)

スキルを最初に置く理由： 技術職では、採用担当者や採用マネージャーは特定の技術を探します。スキルを冒頭に置くことで、最初の5秒で必要な情報を提示できます。ハーバードは見出しを「重要度順」に並べることを推奨しています。エンジニアにとって、スキルは最初に目を通す際に最も重要な項目です。

学歴の配置： ハーバードは学生の場合、学歴を最初に置きます。経験が3年以上ある専門職の場合は、学歴を最後に移動します。職務経験のセクションが中心になります。

ステップ3：内容を書く

詳細なガイドについては、references/bullet-writing-guide.mdを読んでください。主な原則は次のとおりです：

すべての箇条書きはXYZの公式に従う必要があります：

「[Z]を行うことで、[Y]という指標で測定された[X]を達成した」

または簡潔に：行動動詞 + 実施内容 + 技術的背景 + ビジネスへの影響

書き換え例：

• 悪い例：「Webアプリケーションの開発を担当」
• 良い例：「ReactとNestJSを使用し、ヘキサゴナルアーキテクチャとDDDに基づいて構成された、与信管理、カード発行、取引処理向けのフィンテックWebアプリケーションを開発」

ステップ 4：書式を整えて納品する

詳しいガイドについては、references/format-and-structure.md をお読みください。docx スキルを使って Word 文書を作成します。主な仕様は次のとおりです。

• フォント： 本文は Calibri 10.5pt、氏名は 16pt、セクション見出しは 11.5pt
• 余白： 上下左右すべて 0.75 inches
• 行間： 13pt
• 書式： 1 段組み、レイアウト用の表は使用しない、画像なし
• ファイル形式： 編集用の .docx と、送信・アップロード用の .pdf

ステップ 5：PDF に変換する（必須）

必ず .docx 版と .pdf 版の両方を納品してください。 .docx は後から編集するための形式、.pdf は応募先への送付用です。

PDF 変換のルール：

• LibreOffice を使って変換します：python scripts/office/soffice.py --headless --convert-to pdf resume.docx
• PDF がテキストベースであることを確認します（スキャン画像ではないこと）。テキストを抽出するには、pdftotext resume.pdf - を実行します。テキストが出力されれば、ATS で解析できます。
• ページ数が想定どおりであることを確認します： pdfinfo resume.pdf
• 抽出したテキストに氏名と重要な内容が正しく含まれていることを確認します（切り捨てや文字コードの問題を検出できます）。
• PDF は、受信者の OS、Word のバージョン、インストール済みフォントにかかわらず、書式を正確に保持します。
• 最新の ATS（Greenhouse、Workday、iCIMS、Lever など）では、.docx と .pdf のどちらも使用できます。

PDF が重要な理由：

• 受信者の Word のバージョン、OS、インストール済みフォントによって、.docx の表示は異なる場合があります。
• PDF なら、採用担当者に作成したとおりの内容を確実に見てもらえます。
• 多くの求人応募サイトでは、PDF が指定されています。
• ATS は、テキストベースの PDF を .docx と同様に解析できます。

---

言語に関するガイドライン

英文履歴書の場合

• 能動態を使い、人称代名詞（「I」「my」「we」）は使いません。
• すべての箇条書きは、力強い動詞で始めます（参考ファイルを参照）。
• 米国向けの職種には、アメリカ英語のスペルを使います。
• 職種名は、業界標準の形式にします。

スペイン語の履歴書の場合

• 同じ構成と原則を維持します。
• プロフェッショナルなスペイン語を使い、口語表現は避けます。
• 業界で標準的な技術用語は英語のままにします（例：「backend」「frontend」「DevOps」「SOLID」「CQRS」）。
• 箇条書きは、スペイン語の動詞で始めます（Desarrolle、Implemente、Lidere、Disene、Construi、Optimice、Arquitecte）。

バイリンガルで作成する場合

両方の言語で作成する場合、直訳にならないようにしてください。それぞれの言語で自然に読める表現にしつつ、同じ情報と成果が伝わるようにします。

---

納品前チェックリスト

納品前に、すべての履歴書でこのチェックリストを確認してください。

書式：

• 氏名が途切れずに1行に収まっている（最大16pt）
• 1列レイアウトで、レイアウトに表を使わず、グラフィックやアイコンを使っていない
• フォントはCalibriまたはArialで、本文は10.5pt以上、文字色は黒
• 余白のバランスが取れている（詰め込みすぎず、余白が多すぎない）
• 日付にはハイフン（-）ではなくエンダッシュ（–）を使い、前後にスペースを入れている
• 日付が右揃えで、箇条書きが日付より右にはみ出していない
• URLはプレーンテキストで記載している（色や下線を付けず、「Email:」などの接頭辞やhttps://www.を含めない）

内容：

• 人称代名詞（I、my、we、our）を使っていない
• すべての箇条書きが、力強い過去形の動作動詞で始まっている
• 箇条書きの末尾にピリオドを付けていない（箇条書きは文ではない）
• すべての職務経験で、業務領域（業界、システムの種類、データの機密性）を説明している
• 可能な限り数値で実績を示している（「eight」ではなく「8」のように数字を使う）
• 各職務の説明とスキル欄にテクノロジーを記載している
• 不要な動詞（spearheaded、orchestrated、utilized、leveraged）を使っていない
• 過剰な形容詞や副詞（excellent、innovative、strategically）を使っていない
• セクション名が標準的な形式（「Experience」、「Skills」、「Projects」、「Education」）になっている
• 日付の形式が統一され、現職には「Current」や「Now」ではなく「Present」を使っている
• 各セクション内が新しい順になっている
• スペルや文法に誤りがない
• 社内用語や、関係者以外には分からないプロジェクト名だけを使っていない

納品：

• 最終版の.docxからPDFを生成している
• PDFがテキストベースである（pdftotextでテキストを抽出できることを確認済み）
• PDFのページ数が想定どおりである
• すべてのハイパーリンクが機能し、職業上ふさわしいページを参照している
• .docxと.pdfの両方をユーザーに納品している