マスター履歴書：作り方と保ち方（開発者向けガイド）

マスター履歴書は、キャリアの完全な非公開の記録です。すべての職歴、プロジェクト、数値、ツールを、どの雇用主も目にしない 1 つのファイルにまとめます。そこからカスタマイズはしますが、それ自体を送ることはありません。開発者には特に必要です。ソフトウェアのキャリアは、2 ページの履歴書（CV）に収まりきらないほどの細部を生み出し、今日削った細部こそが、来月の求人で求められるものだからです。

このガイドでは、マスター履歴書とは何か、なぜ持つべきか、セクションごとの作り方、最新に保つ方法、そしてそこからカスタマイズ版がどう生まれるかを説明します。カスタマイズの手順そのものは 求人内容に合わせて履歴書をカスタマイズする方法 を読んでください。この記事は、その記事が始まるところで終わります。

日本の転職活動に置き換えると、マスター履歴書は「すべてを書き込んだ職務経歴書の原本」のようなものです。応募先ごとの職務経歴書や英文レジュメは、そこから切り出して作ります。

マスター履歴書とは

データベースだと考えてください。履歴書はそのクエリの結果です。マスターはテーブル全体を持っています。4 ページ、6 ページ、あるいは 10 ページにわたる職歴、箇条書き、プロジェクト、登壇、資格、スキルが、それぞれ日付と数値付きで入っています。カスタマイズした履歴書は、1 つの求人のために絞り込んだ、そのテーブルの 1〜2 ページのビューです。

ここから 3 つの性質が導かれます。

非公開。 マスターを読むのはあなただけです。それによって、何を入れるべきかが変わります。失敗した移行と、そこから学んだことについての箇条書きは、カスタマイズ版に入ることはなくても、面接で聞かれるかもしれないのでマスターに入れます。

完全。 マスターは多すぎるくらいでちょうどいいのです。カスタマイズした履歴書が 3 つに絞るところを、職歴ごとに 6〜10 個の箇条書き。実を結ばなかった個人プロジェクト。前のチームしか知らない社内ツール。

安定。 追加はしても、削ることはしません。カスタマイズした履歴書は使い捨てで、マスターが手入れを続けるものです。

学術用の CV とは違います。学術用の CV も長く完全ですが、その形のまま雇用主に送られます。マスター履歴書は作業用の文書で、書式は後回しで構いません。

開発者がマスター履歴書を持つべき理由

記憶は、キャリアが変わるより速く薄れていきます。 プロジェクトから 2 年経つと、「請求サービスに携わった」ことは覚えていても、p99 を 800 ms から 120 ms に縮めたこと、Go と Postgres で動いていたこと、ランブックを書いたことは覚えていません。真っ先に消えるのは数値です。マスター履歴書なら、ダッシュボードを開いているうちにそれを記録できます。

キャリアの方向は分かれていきます。 データの仕事もしてきたバックエンドエンジニアには、次の職として 2 つの道があります。プラットフォームの職に効く箇条書き（オンコール、Kubernetes、コスト削減）と、データの職に効く箇条書き（パイプライン、データウェアハウスのモデリング、dbt）は違います。マスター 1 つに両方を入れておき、カスタマイズ版で片方を選びます。

どのプロジェクトもどこかで役に立ちます。 オープンソースへの貢献、ハッカソン、自宅のホームラボのために書いた Terraform のモジュール。どれもフロントエンドの職に向けた履歴書には合いませんが、別の求人ではそれこそが求められているかもしれません。書き留めていなければ、必要なときに思い出せません。

どの数値にも出どころが必要です。 履歴書の数値は、面接の質問に耐えなければなりません。マスターには「ビルド時間を 60% 短縮」の横に、何を、どこからどこまで、どう測ったかを記録しておきます。カスタマイズ版にその数値が載ったとき、説明できます。

カスタマイズが選択の作業になります。 マスターがあれば、カスタマイズは数分で終わります。合う箇条書きを選び、求人の言葉で言い換え、残りを削るだけです。マスターがなければ、毎回記憶から過去を組み立て直すことになり、そこで履歴書は事実からずれていきます。

どこでも内容がそろいます。 LinkedIn のプロフィール、カスタマイズした履歴書、面接での答えは、日付、役職、数値が一致しているべきです。信頼できる情報源が 1 つあれば、それが自然にそろいます。

マスター履歴書の作り方（セクションごとに）

プレーンな Markdown ファイルを開きます。書式、テンプレート、ページ数の制限はカスタマイズ版のためのものです。マスターに必要なのは構造と網羅性です。

ヘッダー

名前、メール、電話番号、都市、そしてリンク（GitHub、LinkedIn、あれば個人サイト）。カスタマイズ版のあいだで表記がばらつかないように（「+81」が付いたものと付かないものなど）、載せたい正確な形で記録しておきます。

サマリー（キャリアの方向ごとに 1 つ）

応募する可能性のある職の種類ごとに、3 行のサマリーを書きます。バックエンド向け、プラットフォーム向け、データ向けなど。それぞれ、その方向で重視される 2〜3 の強みを挙げます。カスタマイズするときは、いちばん近いものから始めて調整します。

職歴

職歴ごとに、勤務先、役職、勤務地、月を含む期間、そこで使った技術スタックを書きます。続いて、職歴ごとに 6〜10 個の箇条書きを、それぞれ行動と結果の形で書きます。実際に見せる量より多く記録してください。

• 何を作ったか（ツール名を入れて）。
• それで何が変わったか（数値があれば数値で）。
• 規模：ユーザー数、毎秒のリクエスト数、データ量、チームの人数。
• 担当したもの：オンコール、サービス、移行、採用。
• 求人で問われそうな協働：チーム横断の仕事、メンタリング、プロダクトとの連携。

数値のある箇条書きの下には、その数値の出どころを短くメモしておきます。「Grafana のダッシュボード、2025 年 3 月、キャッシュ導入前後の p99。」このメモを見せることはありませんが、面接でありがたみがわかります。

プロジェクト

個人プロジェクト、オープンソースの仕事、ハッカソンの作品、社内ツール。それぞれに名前、リンク、期間、自分の役割、技術スタック、そして自分がしたことと結果についての 2〜3 個の箇条書き。スター数、ダウンロード数、ユーザー数があれば書きます。成果の出なかったプロジェクトも、何を学んだかの 1 行を添えて入れておきます。

スキル（グループ分けと日付付きで）

言語、フレームワーク、インフラ、データ、プラクティスにグループ分けします。それぞれの横に、最後に本格的に使った年をメモします。カスタマイズした履歴書のスキル一覧には、今日面接で聞かれても答えられるものだけを入れるべきで、「最後に使った年」の列がそれを教えてくれます。

学歴と資格

学位と学校、期間、関連すること（卒業研究のテーマ、仕事につながる科目）。資格は発行元と有効期限付きで。

登壇、執筆、コミュニティ

カンファレンスでの登壇、勉強会での発表、反響のあったブログ記事、ポッドキャスト、メンタリングの活動。カスタマイズした履歴書の多くでは省きますが、評価してくれる求人もあります。

変更履歴

いちばん下に、何をいつ追加したかを日付付きで書いておきます。次の更新が楽になり、最後にいつファイルを触ったかが一目でわかります。

マスター履歴書のテンプレート（架空の例）

以下の骨組みで形を示します。人物、会社、数値は架空のものです。日本語に訳しています。

例（架空）：Arjun Mehta、バックエンドエンジニア、ベンガルール

# Arjun Mehta
インド、ベンガルール · arjun.mehta@example.com · +91 98xxx xxxxx
github.com/arjunm-example · linkedin.com/in/arjunm-example

## サマリー
### バックエンド／プラットフォーム
Go と Python で決済・台帳システムに 6 年携わってきたバックエンド
エンジニア。毎秒 4,000 リクエストのサービスを担当し、Finlo でインフラ
費用を 30% 削減。
### データエンジニアリング
6 年のバックエンドの経験に加え、バッチとストリーミングのパイプライン
（Airflow、Kafka、BigQuery）を 3 年構築してきたエンジニア。

## 職歴

### Finlo Payments · シニアソフトウェアエンジニア
ベンガルール · 2023 年 4 月〜現在 · Go、PostgreSQL、Kafka、Kubernetes、GCP
- 台帳サービスを担当（ピーク時毎秒 4,000 リクエスト、下流の利用者 11）。
- 台帳への挿入をまとめ、先行書き込みキューを追加して、書き込みの
  p99 レイテンシーを 410 ms から 95 ms に短縮。
  > 出どころ：Grafana の台帳レイテンシーのダッシュボード、2024 年 6 月、
  > 7 日間の期間。
- ノードプールのサイズを適正化し、バッチ処理をスポットに移して、
  決済用ネームスペースの GCP の費用を 30% 削減（月 18,000 ドルから
  12,600 ドルに）。
  > 出どころ：GCP の請求エクスポート、2024 年第 3 四半期と第 1 四半期の比較。
- 6 つのサービスを Cloud Run から GKE に 4 か月で移行するプロジェクトを主導。
- 決済のオンコールのローテーション（5 週に 1 週）。12 人のエンジニアが
  使う障害対応のランブックを作成。
- ジュニアエンジニア 2 名を指導し、2 人とも 1 四半期以内に最初の本番
  サービスをリリース。
- 自作の再試行の仕組みを Kafka のデッドレターのパターンに置き換え、
  その後 6 か月で二重払い出しをゼロに。
- （多くの履歴書には入れない）台帳を Rust で書き直す検証（スパイク）を
  行い、リリースは見送った。判断の文書を作成。

### Brightcart · ソフトウェアエンジニア
プネー · 2019 年 7 月〜2023 年 3 月 · Python、Django、MySQL、Redis、AWS
- 1 日 20 万件の注文を処理する注文追跡 API（Django REST）を構築。
- 商品検索を MySQL の LIKE クエリから Elasticsearch に移行し、
  検索時間の中央値を 1.2 秒から 90 ms に短縮。
  > 出どころ：Datadog APM、2021 年 11 月。
- データチーム向けに最初の Airflow のパイプラインを構築（DAG 12 本、
  Redshift への夜間ロード）。
- ステージング環境の Terraform を作成（以前は手作業で設定）。
- 2 年間でバックエンド職の候補者 40 人以上を面接。

## プロジェクト
### kafka-replay（オープンソース） · 2024 年〜現在
デバッグのために Kafka のトピックをローカルクラスターで再生する CLI。Go。
GitHub のスター 310、Finlo の 3 チームが使用。
### homelab-terraform · 2022 年
Proxmox のホームラボ用の Terraform モジュール。未完成。Proxmox の API と
Terraform のプロバイダーを学んだ。

## スキル（最後に使った年）
- 言語：Go（2025）、Python（2025）、SQL（2025）、Rust（2024、検証）、
  TypeScript（2022）
- インフラ：Kubernetes（2025）、Terraform（2025）、GCP（2025）、
  AWS（2023）、Docker（2025）
- データ：Kafka（2025）、PostgreSQL（2025）、Airflow（2023）、Redshift
  （2023）、Elasticsearch（2022）、BigQuery（2024）
- プラクティス：オンコール、障害対応のランブック、設計文書、メンタリング

## 学歴
コンピューター工学学士（B.E.）、プネー大学、2015 年〜2019 年

## 登壇と執筆
- 「Ledger write paths at 4k rps」、ベンガルール Go ミートアップ、2024 年 9 月
- ブログ：「Dead-letter queues without the drama」、2024 年（12,000 ビュー）

## 変更履歴
- 2025-09：kafka-replay のスター数、第 3 四半期のコストの数値を追加
- 2025-03：メンタリングの箇条書き、Rust の検証のメモを追加
- 2024-11：2023 年の履歴書と Brightcart のメモからファイルを作成

このファイルには、カスタマイズした履歴書にはないものがあることに注目してください。数値の下の出どころの行、「多くの履歴書には入れない」箇条書き、未完成のプロジェクト、すべてのスキルに付いた最後に使った年、そして 2 つのサマリー。それがマスターの役割です。

最新に保つ方法

マスター履歴書は、更新が面倒になった時点で死んでしまいます。だから更新は小さく、すでに気づいている出来事に結びつけてください。

リリースしたら更新する。 プロジェクトがリリースされたり、数値が動いたりしたら、その週のうちに箇条書きを加えます。今ならダッシュボードに数値がありますが、1 年後にはありません。

バージョン管理に入れる。 非公開の Git リポジトリに置いた Markdown ファイルなら、履歴がただで手に入ります。いつ何を加えたかがわかり、マスターと、そこから作ったカスタマイズ版との差分も取れます。

四半期ごとに見直す。 年に 4 回、15 分。現職の箇条書きを読み、起きたことを加え、最後に使った年を更新します。カレンダーに入れておいてください。

数値と一緒に出どころを記録する。 数値の下に「出どころ：…」と書く習慣は 10 秒で済み、答えられない面接の質問からあなたを守ります。

ブラッグドキュメントを並行して持つ。 Julia Evans の ブラッグドキュメント、つまり仕事でしたことを書き続けるリストの考え方は、マスターを育ててくれます。ブラッグドキュメントは生のままで、マスターは整えたものです。

マスターに薄い項目、たとえば箇条書きが 2 つしかなく数値もない職歴があるなら、Resume Matcher にはそのための強化の機能があります。弱い項目を見つけ、それについて最大 6 つの質問をし、あなたが伝えていない詳細を加えずに、回答から 2〜4 個の新しい箇条書きを書きます。

キャリアトラック：マスター 1 つでは足りないとき

多くの開発者は、マスター 1 つと複数のサマリーで足ります。そうでない人もいます。バックエンドの経歴とデータの経歴で、スキルの一覧、選ぶプロジェクト、サマリーがすべて違うなら、注釈が絡み合った 1 つのファイルより、マスターを 2 つにしたほうがすっきりします。

Resume Matcher はこれを前提に作られています。キャリアの方向ごとに最大 5 件のマスター履歴書を持て、そのうち 1 件をデフォルトに設定できます。カスタマイズ画面はデフォルトをあらかじめ選び、求人が別の方向を求めるときに切り替えます。それぞれのマスターはそれ自体が完全な履歴書で、アップロードした PDF や Word のファイル、または履歴書ウィザードの質問から作られ、標準のレイアウトにないブロックが必要ならカスタムセクションも持てます。

マスターからカスタマイズ版が生まれる仕組み

カスタマイズは、選択と言い回しです。1 つの求人に対して、その要件に合う箇条書きを取り出し、求人の言葉で言い換え、その方向のサマリーを選び、スキルの一覧を求人が重視するものと最近数年で使ったものに絞り、残りを削って 1〜2 ページに収めます。マスターは変わりません。それぞれのステップは、実例付きで カスタマイズのガイド が説明しています。

Resume Matcher では、カスタマイズした履歴書はそれぞれ、元になったマスターを指す別の文書です。モデルがサマリー、箇条書き、スキルへの的を絞った編集を提案し、コードがそれぞれをチェックして、名前、勤務先、役職、日付、学位を固定し、マスターになかった数値を元に戻します。変更前と変更後の差分を確認し、確定するか再生成します。マスターはあなたが書いたままなので、次の求人も同じ完全な元から始められます。保存したカスタマイズ版は編集でき、7 つのテンプレートのどれからでも PDF で書き出せます。

マスターを持ち続けてください。それ以外はすべて、そのビューです。

役に立ったら

この骨組みで記憶からの作り直しが省けたなら、GitHub の Resume Matcher にスターを付けていただけると、ほかの求職者が見つけやすくなります。私、Saurabh Rai は GitHub、X、LinkedIn でフォローできます。