昨年、バックエンドをやっている同僚を社内推薦したんです。彼の技術は同年代の中では中の上で、アルゴリズムもシステム設計も悪くなかった。ところが、人事の書類選考であっさり落ちてしまいました。彼の履歴書を手に取ってみて、最初の印象は「そんなはずはない」でした。でも、じっくり読み直して問題が見えたんです。彼の履歴書は「できが悪い」のではなく、「技術を知らない人には理解できず、知っている人は読みたいと思わない」という状態だったんです。
一例を挙げます。彼は社内で手がけたプロジェクトについて、こんなふうに書いていました。
Spring Cloud を使用してマイクロサービスアーキテクチャを構築し、既存のモノリシックシステムを再構築しました。これにより、ビジネス間の高い結合度の問題を解決しました。データ層には MySQL + Redis + Elasticsearch の組み合わせを採用し、非同期の疎結合化のためにメッセージキューとして Kafka を使用しました。
技術スタックはよく書けている。でも、この文章を面接官に渡したら、相手の頭の中にはたった一つの疑問しか浮かびません。「あなたは何をしたの？ それで、どうなったの？」 再構築してシステムは速くなったの？ ユーザー体験は変わったの？ ビジネス側は何と言っていたの？ —— 全部書かれていない。
これこそ、エンジニアが履歴書を書くときの共通の病です。私たちは技術の言葉で自分の仕事を説明することにあまりにも慣れすぎている。コードのコメントは他人のために書く。履歴書に書く技術構成も、まるで同僚向けに書いたように見える。でも、実際にあなたの履歴書を最初にふるいにかけるのは、往々にして人事であって技術責任者ではありません。仮に技術面接に進んだとしても、面接官が見たいのは、あなたが技術用語をどれだけ並べられるかではなく、それらの技術を使って一体何を解決したかなのです。
以下、エンジニアの履歴書で最も頻出する5つの問題を、修正前と修正後で見ていきます。
事例1：技術スタックを一行にずらっと並べただけ
背景： アカイくん。Java開発3年目。履歴書の一番目立つ位置に、こんな技術スタックを書いていました。
Java、Python、Go、Spring Boot、MyBatis、MySQL、Redis、Kafka、RabbitMQ、ES、Docker、K8s、Jenkins、Linux……に習熟。
この行は長ければ長いほど、かえって価値が下がります。なぜなら、面接官は技術用語の羅列を見たとき、「全部できるんだ」とは思わず、「一度使っただけ」と「精通している」を混ぜて書いているだけだと感じるからです。さらに重要なのは、あなたがどの領域を得意とし、どこで即戦力になれるのかがまったく見えてこないことです。
そして、エンジニアなら誰でも知っています。同じ技術でも、CRUD を1年書いた人と、パフォーマンスチューニングを1年やった人とでは、まったく別のレベルにある。技術スタックの単なる列挙は、その差をならしてしまうのです。
修正後：
メインスタック： Java / Spring Boot / MySQL（3年、高並行処理のサーバーサイド開発に注力）
サブ： Redis、Kafka、Elasticsearch（独立した選定とチューニングの経験あり）
DevOps： Docker、K8s（日常的に使用、Dockerfile や基本的なデプロイスクリプトを自力で作成可能）
違いは何でしょう？ 元はごった煮だったのが、三層構造に整理されました。面接官は一目で、あなたのコア戦闘力が Java バックエンドにあり、しかも単に業務コードを書くだけではなく、ミドルウェアのチューニング経験があることを把握できます。単に「使ったことがある」レベルの技術は書かなくてもいいし、面接で聞かれたときに話せば十分です。履歴書に載せる技術用語の一つひとつについて、深掘りされても答えられる準備をしておくこと——これがエンジニアの履歴書の鉄則です。
事例2：「実行者」としか書けていなくて、技術的な意思決定が見えない
背景： ショウくん。バックエンド開発5年。これまで2社を経験。彼の職務経歴はどこもこんな感じでした。
ユーザーセンター、注文、決済などのコアモジュールの日常的な開発と保守を担当。要件レビューや技術提案の設計に参加。テストチームと連携して機能検証とリリースを実施。
あなたはこれで、彼の5年目と2年目の違いを見分けられますか？ 見分けられませんよね。この文章は、バックエンドをやっている人なら誰でも書けてしまう。彼は自分自身を「要件を受ける→コードを書く→リリースする」というサイクルを回すだけの実行者として描写してしまっているんです。
でも、ショウくんの実態はまったく違いました。1社目では、ユーザーセンターモジュールの最初のデータベース設計を彼が主導し、データベースシャーディングの提案も彼が出した。2社目では、チームを svn から git へ移行させ、最初の CI/CD パイプラインも構築した。こうしたことは彼の履歴書には一言も書かれていなかった。なぜなら彼は「これって普通の仕事じゃないですか」と思っていたからです。
修正後：
ユーザーセンターのデータベース設計をゼロから主導。ビジネスの成長速度を予測した上で、事前にデータベースシャーディングの計画を立案。2年間でユーザー数50万から600万以上への増加を支え、データベースのクエリ性能に顕著な劣化は見られなかった。
チームの SVN から Git への移行を推進し、Jenkins ベースの初版 CI/CD パイプラインを構築。移行後、コードのコンフリクト率は明らかに減少し、機能のリリースサイクルは隔週から1週間以内に短縮された。
特に重要なのは後半です。これは「私、Jenkins 使えます」ではなく、「私はチームのプロセス上の問題点を見つけ、解決策を提案し、導入まで推進しました」ということを示しています。これこそが、シニアエンジニアと普通のエンジニアの境界線です。面接官が5年経験者の履歴書を見るときに探している核心的なシグナルはまさにこれです。あなたは問題を発見し、解決を推進できるのか。与えられたタスクをただこなすだけではないのか。
事例3：GitHub のリンクをずらっと貼っただけで、何も語っていない
背景： オウくん。フロントエンド経験2年。履歴書の「個人プロジェクト」欄に GitHub のリンクを3つ貼り、その後に一言ずつ説明を添えていました。
React による NetEase CloudMusic 風プレーヤー：リンク
シンプルなブログシステム：リンク
ハッカソンのプロジェクト：リンク
面接官がこんな記述を目にしたら、99%の確率でリンクをクリックしません。理由は簡単です。時間がないから。3つもリンクを渡されても、その中に何が書いてあるのか教えてもらえなければ、存在しないものと同じです。
正直なところ、この3つのプロジェクトの「密度」にはかなりの差があります。NetEase CloudMusic 風プレーヤーは2ヶ月かけて断続的に作り、スターは100以上。ブログシステムは3日で書き上げたもの。ハッカソンのプロジェクトは、2人のバックエンドエンジニアと一緒に作り、彼はフロントエンド全体と一部の UI デザインを担当した。しかし、これらの情報はまったく書かれておらず、3つのプロジェクトが同じ重みの「授業の課題」のように見えてしまっている。
修正後：
React による NetEase CloudMusic 風プレーヤー | 個人プロジェクト | 150+ star
UI デザインからフロントエンド実装までの全工程を独力で完遂。主要機能は再生制御、歌詞の同期スクロール、プレイリスト管理など。React + Redux + Hooks を使用し、NeteaseCloudMusicApi と連携して実際のデータを取得。プロジェクト公開後、技術コミュニティ「掘金（Juejin）」でトップページに推薦され、300以上の「いいね」を獲得。ハッカソン作品「XX」 | 3人チーム | 第2位受賞
フロントエンドのアーキテクチャ設計と全ページの開発を担当。Vue3 + TypeScript を使用し、2日間でプロトタイプからリリースまでの全工程を完遂。プロジェクトの中心的な見どころはリアルタイム協調編集機能で、WebSocket + CRDT を用いて実装。
修正後は、GitHub のリンクがクリックされるかどうかは、もはや重要ではありません。なぜなら、テキストの説明だけでもう、面接官はプロジェクトの難易度、あなたの役割、技術の深さについて判断できるからです。リンクは単なるエビデンスです。
事例4：技術力がビジネスの成果とまったく結びついていない
背景： ロウさん。アルゴリズムエンジニア6年目、ある EC 企業でレコメンデーションシステムを担当。履歴書にはこう書いていました。
レコメンデーションシステムのアルゴリズムのイテレーションを担当（リコール、ランキング、リランキングなどのモジュールの最適化を含む）。深層学習モデルを用いてユーザー行動のモデリングを行い、レコメンデーションの精度を向上させた。A/B テスト基盤の構築に参加。
この文章は、レコメンデーションを担当しているアルゴリズムエンジニアなら誰でも書けます。「レコメンデーションの精度を向上させた」——どれだけ向上したのか？ 精度の定義は何か？ CTR なのか、コンバージョン率なのか、それとも GMV なのか？ 面接官はこれを読んでも、あなたの最適化の効果が一体どれほどの規模感なのか、まったくわかりません。
でも、ロウさんの実際の成果は非常に誇れるものでした。彼はトップページのレコメンデーション CTR を 7.2% から 9.8% に引き上げました。しかも、ユーザー数がほぼ倍増する中でそれを維持したのです。彼が開発した多目的ランキングモデルは、「カート追加率」と CTR のトレードオフをきれいにバランスさせた。しかし、こうしたことは履歴書に一言も書かれていなかった。なぜなら彼は「それはビジネス指標であって、自分の技術的な成果ではない」と思っていたからです。
これこそ最大の誤解です。技術はビジネスに結びついて初めて商業的価値を持ちます。そしてその商業的価値こそが、企業があなたに高い給与を支払う唯一の理由です。「モデルを最適化しました」としか言えないアルゴリズムエンジニアと、「CTR を 2.6 ポイント向上させ、千万人規模のユーザー基盤で安定稼働させました」と言えるアルゴリズムエンジニアとでは、市場価値に少なくとも30%の差がつきます。
修正後：
レコメンデーションシステムの全リンク（リコール→ランキング→リランキング）のアルゴリズムイテレーションを担当。多目的ランキングモデルのバージョンアップを主導し、CTR（7.2% → 9.8%、+2.6pp）とカート追加率のバランスを実現。DAU が倍増して千万人規模になる中、レコメンデーションサービスの P99 遅延を ≤ 80ms に維持。
A/B テスト基盤の指標体系の構築を設計・推進し、実験の分析サイクルを週次から日次に短縮。年間 200件以上のアルゴリズム実験を支えた。
事例5：プロジェクト経験がアーキテクチャ設計書になってしまっている
背景： トウくん。バックエンド4年目。社内向けデータプラットフォームの開発を担当。履歴書のプロジェクト経験には、こう書かれていました。
プロジェクト名： エンタープライズデータ基盤
技術スタック： Spring Boot + Flink + ClickHouse + Kafka
プロジェクト概要： 本プロジェクトはマイクロサービスアーキテクチャを採用し、データ収集層、計算層、ストレージ層、アプリケーション層の4層に分割。データ収集層は MySQL Binlog、API データソース、ファイルアップロードの3方式に対応。計算層は Flink によるストリーミングとバッチの統合を実現し、ストレージ層は ClickHouse をリアルタイム OLAP 分析に使用。
あなたが技術マネージャーだったら、この文章を読んだ第一印象はどうでしょう？ 「これって、御社のアーキテクチャ設計書ですか？」ですよね。
履歴書は技術提案書ではありません。面接官は、あなたのシステムが何層に分かれていて、各層が何と呼ばれているかを知る必要はありません。知りたいのは、あなたがこのプロジェクトで何をし、なぜそれをし、どの程度まで達成したか、です。アーキテクチャ図は面接のときにホワイトボードに書けばいい。履歴書にアーキテクチャのレイヤー分けを書くのは、貴重なスペースの無駄遣いです。
トウくんはこのプロジェクトで、実に多くの「書くべきこと」を成し遂げていました。彼が設計した Binlog 収集の方式は、従来の方式より性能が4倍向上。ClickHouse のマテリアライズドビューを独学で極め、あるコアレポートのクエリ時間を 40秒から 3秒に短縮したのです。
修正後：
エンタープライズデータ基盤 | コア開発者
Binlog リアルタイム収集の方式を再設計し、データ遅延を 5秒から 1秒未満に削減、スループットを 4倍に向上。日次 3億件以上のデータ同期を支える。
ClickHouse のマテリアライズドビュー最適化を独力で実施し、3つのコアレポートのクエリ時間を 40秒超から 3秒未満に圧縮。ビジネス部門の反応は「毎日レポートを待っていた」状態から「いつでも確認できる」に激変。
プロジェクトリリース後、データ取り込みの効率が大幅に改善。新しいビジネスラインのデータソース追加が、従来の3日から半日に短縮された。
3つの文、それぞれが「具体的な課題 → 解決の軌跡」という構造を持っています。面接官は1行目を見れば「この人はパフォーマンス最適化ができる」とわかり、2行目を見れば「既存のツールを使うだけではない」と把握し、3行目を見れば「彼の仕事がチームの効率にまで影響を与えている」と理解します。
エンジニアの履歴書、5つの専用原則
原則1：技術スタックは階層化し、ごった煮にしない
あなたの技術力を3つの階層に分けましょう。メインスタック（これを武器に食べていくもの）、サブ（独立してチューニング経験があるもの）、理解（使えるが深くはないもの）。メインスタックは3つ以内、サブは3～5つ。理解レベルのものは書かなくていい。面接官が知る必要があるのは、あなたの最も硬いスキルです。
原則2：すべての技術的意思決定に「なぜ」と「結果」を答える
悪い例：キャッシュに Redis を使用。
良い例：Redis キャッシュ層を導入し、商品詳細ページのAPI応答時間を 680ms から 45ms に短縮。
「どんな技術を使ったか」ではなく、「どんな課題に対してどんな技術を使い、結果として何が変わったか」。技術は手段にすぎず、問題を解決することこそが価値です。
原則3：定量化できない技術業務はない、視点が見つかっていないだけ
どうしてもパーセンテージの数字が見つからない場合は、視点を変えましょう。
- あなたのシステムはどれだけの同時接続をさばいたか？（ピークQPS）
- あなたのコードはどれだけの人に影響を与えたか？（カバーしたユーザー数/ビジネスライン数）
- あなたが作ったものは毎日どれだけの人に使われているか？（日均リクエスト数/アクティブユーザー数）
- あなたのやったことで、以前と比べてどれだけ速く、どれだけコストが下がったか？（処理時間の変化、コストの変化）
バックエンドの人が「このAPIは毎日800万回呼ばれていて、リリースから半年間ノートラブルです」と言えたら、それでもう十分です。
原則4：GitHub のプロジェクトには説明を書き、リンクだけを置かない
各プロジェクトにつき最低3行の説明を。あなたが何をし、どんな技術を使い、どんなフィードバックや影響があったか。もしオープンソース貢献をしたなら、「XX プロジェクトに PR を送りました」だけで済ませない。どんなバグを修正したのか、コード量はどれくらいか、PR はマージされたのかを書きましょう。
原則5：職務経歴から、あなたがチームでどんな役割を担っていたかが伝わるように
経験2年以下：実行者でも構わないが、どんなモジュールを自力で作り上げたかを書く。
3〜5年：いくつかの技術提案を主導したことが見えるように。
5年以上：技術基盤、プロセス最適化、あるいはメンタリングなどを通じて、チームや事業の方向性に影響を与えたことが見えなければならない。
書き終えたら、エンジニア専用の5つのセルフチェック
- 技術スタックの欄をパッと見て、5秒以内に自分の最もコアな領域が言えるか？
- 職務経歴の中に、「自分が何をしたか → 結果として何が起きたか」という構造になった項目がいくつあるか？
- GitHub のリンクの横に、プロジェクトの見どころと自分の役割が明記されているか？
- 自分の履歴書の中に、具体的な数字を3つ以上見つけられるか？（QPS、ユーザー数、処理時間、効率改善率……数字なら何でもいい）
- もしあなたが人事で、技術がまったくわからなかったとして、この履歴書を読んで、この人が何をやっている人なのか、おおまかに説明できるか？
正直なところ、エンジニアの履歴書作成における最大の障壁は、「書き方がわからない」ことではなく、「技術さえすごければ十分で、履歴書は適当でいいだろう」と思い込んでいることです。しかし現実には、どれだけ技術がすごくても、書類選考を通過できなければ、それを披露する機会すら訪れません。ある午後を使って、自分の履歴書を上記の原則に沿って見直してみてください。アルゴリズム問題を10問解くより、はるかに投資対効果が高いはずです。
もし見直してもまだ効果に自信が持てないなら——自分の書いたものを客観視するのは難しいものです。履歴書を DeepResume にアップロードして診断してみてください。技術キーワードの網羅性、成果の定量化、表現の明確さという3つの軸でシステムがチェックし、どこをさらに強化できるかをお伝えします。