去年、友人の履歴書を添削したことがあります。中規模のインターネット企業でバックエンドエンジニアとして2年ほど働いていた彼は、転職活動を1ヶ月以上続けても面接にほとんど呼ばれませんでした。履歴書を見せてもらったら、職務経歴の欄がこうなっていました。
注文システムの日常開発と保守を担当。要件レビュー、API開発、バグ修正に参加し、テストと連携してバージョンリリースを実施。
私は言いました。「これ、職務経歴じゃなくて、勤怠記録だよ。同じポジションの人なら誰でも、システム名を変えるだけで自分の履歴書にコピペできるじゃないか」と。
これが大多数の人に共通する問題です。職務経歴に書くことがないのではなく、2年かけてやってきたことを、誰でも書ける一行にまとめてしまっているのです。
面接官が職務経歴で見ているもの
まず視点を変えて考えてみましょう。HRや現場の面接官が履歴書をスクリーニングするとき、1枚あたりの滞在時間はせいぜい10〜20秒です。職務経歴の欄は最も長く目を留める部分ですが、彼らが本当に探しているのは「あなたが何をしたか」ではなく、次の3つの情報です。
- どんな環境で働いてきたか——大手か、小規模チームか？成熟した事業か、ゼロからの立ち上げか？
- その中であなたはどんな役割を担ったか——案件を引っ張る人か、ずっとタスクを受け取るだけの人か？
- あなたが去ったとき、何が残ったか——正常稼働するシステムを維持したのか、それとも何らかの指標を実質的に変えたのか？
3つ目の質問がとりわけ重要です。多くの人は「在職中に何をしたか」ばかりを書きますが、面接官が本当に気にしているのは「あなたが何をしたことで、状況が以前とどう変わったか」です。この2つは似ているようで、書き上がる内容は大きく違います。
たとえて言いましょう。あなたがレストランに料理人として応募するとき、「毎日、野菜を切り、炒め物を作り、鍋を洗いました」とは書かないはずです。「調理場のホットラインを担当し、ピーク時には1回の食事提供で80品を出し、3ヶ月で看板メニューの返品率を6%から1.5%に下げました」と書くでしょう。後者こそが見てもらいたい内容です。
理屈は難しくありませんが、いざ履歴書に落とし込む段階で多くの人が忘れてしまいます。以下、実際に遭遇した5つの事例を紐解きます。業界もキャリア段階もそれぞれ異なりますが、根底にある問題は驚くほど共通しています。
事例1：経験はあるのに「何でもやりました」状態
背景： Aさん、フロントエンドエンジニアとして2年半。シリーズBのスタートアップに在籍し、フロントエンドチームは3人のみ。彼はあらゆることに手を出していました。履歴書にはこう書かれていました。
社内の複数プロダクトラインにおけるWebフロントエンド開発を担当。バックエンド管理システム、H5キャンペーンページ、ミニアプリ等を含む。ReactおよびVue技術スタックを使用し、プロダクトチームやバックエンドチームと連携して要件開発を実施。コンポーネントライブラリの構築とメンテナンスに参加。
一見すると問題なさそうですが、よく読むと欠点が見えてきます。いろいろ書いてあるのに、何も明確に伝わっていません。「複数プロダクトライン」はいくつ？「コンポーネントライブラリの構築」はあなたが主導したのか、それとも既存のものを使っただけか？「プロダクトチームやバックエンドと連携」——それはどのフロントエンドエンジニアもやっていることで、情報価値がありません。
彼の実態はかなり優秀でした。バックエンド管理システムは彼一人でゼロから構築し、H5キャンペーンページで最も成功した案件はPVが100万を超え、コンポーネントライブラリも彼が主導して立ち上げ、後に他の2人のフロントエンドメンバーが使うようになっていました。
しかし、これらの情報は履歴書に一言も反映されていなかったのです。彼に「盛る」才能がなかったのではなく、これらの情報が「価値がある」とそもそも気づいていなかったのです。
改善後：
社内バックエンド管理システムのフロントエンドアーキテクチャ（React + TypeScript）を単独で構築。プロジェクト初期化からリリースまで全工程を担当し、運営・カスタマーサポート・データの3業務ラインの日常利用を支える。
チーム内コンポーネントライブラリの整備を主導。フォーム、テーブル、モーダルなど業務共通コンポーネント30以上を整備し、チームメンバー全員が導入。新規要件の開発効率が大幅に向上。
マーケティング用H5キャンペーンページ開発を担当（Vue）。単一キャンペーンの最大PVは120万超、キャンペーン期間中のオンライン障害ゼロ。
この版は「何をやったか」ではなく「どの程度までやり遂げたか」を示しています。面接官はこの人の技術スタック、単独での実行力、そしてチームへの影響力を一目で把握できます。Aさんはこの版で2週間投げ続けたところ、面接の打診が約3倍に増えました。
事例2：転職回数が多く、不安定に思われるのを恐れて薄く書いた
背景： Bさん、3年間で3社を経験し、うち1社はわずか7ヶ月でした。転職回数が多すぎて書類選考で落とされるのを恐れ、各社の経歴を短く曖昧に書いて、「目立たなければ気づかれないだろう」と考えていました。
結果はまったくの逆でした。曖昧に書けば書くほど、面接官はむしろその経歴を注視します。なぜなら、ポジティブな情報が何も得られないので、悪い方に想像せざるを得ないからです。
彼の7ヶ月の経歴はこう書かれていました。
ECプラットフォームのキャンペーンモジュール開発に参加。フラッシュセールやグループ購入などの機能のAPI実装を担当。
私は彼に、この経歴はいったい何だったのか尋ねました。すると、その会社には7ヶ月しかいなかったものの、プロジェクト単位の契約だったというのです。入社時点でプロジェクトはまさに開始直後で、彼はフラッシュセールモジュールの設計からリリースまでの全工程を担当。プロジェクトが完了した時点で退職しました（会社の事業方向の変更に伴い、HRとの合意の上での退職）。この7ヶ月間は、実は彼の3年間の中で最も技術的に成長した期間だったのです。
改善後：
入社後、フラッシュセールモジュールの設計・開発を単独で担当。在庫事前引き当て、流量制限制御とサーキットブレーカー、非同期発注などのコアロジックを実装。リリース後、ダブル12（12月12日）の大型セールを支え、ピークQPS 4500以上を記録し、在庫超過販売事故ゼロ。
グループ購入モジュールのAPI開発を同時に担当。グループ作成、参加、成立コールバックまでの全フローをカバー。リリース初月のグループ購入注文比率が15%に到達。
ご覧の通り、隠そうとするよりも、きちんと説明した方がずっと効果的です。特に短期間の経歴は、曖昧にすればするほど面接官の疑念が深まります。具体的に書けば、むしろ理解してもらえます——本当に手を動かした人でなければ、この粒度では書けないからです。
ここでついでに言っておきます：転職回数の多さそれ自体は致命傷ではありません。致命傷になるのは「転職回数が多い＋それぞれの転職で何を蓄積したかが履歴書からまったく読み取れない」ケースです。各経歴に明確な能力成長の軌跡が見えれば、面接官は転職回数だけで落としたりはしないものです。
事例3：同じ会社に5年以上在籍
背景： Cさん、従来型のソフトウェア企業でJavaエンジニアとして6年勤務。履歴書の職務経歴は1行のみで、そこに7〜8個のバレットポイントが並んでいました。ざっとこんな感じです。
- XXX管理システムの開発に参加
- YYYモジュールの保守を担当
- 要件元と連携してZZZ機能の反復開発を実施
- ……
6年も在籍してこの書き方は大きな問題です。同じ場所に長くいるほど、「ずっと同じことをやってきた」ようには決して書いてはいけません。面接官が「6年間で職務経歴が1行、しかも役職や業務の深さに何の変化も見られない」という状態を目にしたら、第一印象は「この人は6年間ずっと足踏みしていたのか」です。
しかしCさんの実態はまったく違いました。在籍した6年間のうち、最初の2年は業務開発、次の2年は基盤アーキテクチャグループに異動してミドルウェア開発、最後の2年は再び業務ラインに戻り、3人の小さなチームを率いて新規事業の探索に取り組んでいたのです。
改善後：3つのフェーズに分割：
シニアJava開発エンジニア（直近2年）
3名のチームを率いて新規事業ラインをゼロから立ち上げ。システムアーキテクチャ選定、コアモジュール開発、チーム技術規約の整備を担当。事業リリース後、現在まで安定稼働中。Java開発エンジニア / 基盤アーキテクチャ（中間2年）
基盤アーキテクチャグループに異動し、全社共通メッセージミドルウェアの二次開発と保守を担当。クラスタのメッセージ滞留と消費遅延問題を解決し、日量1,000万件超のメッセージフローを支える。Java開発エンジニア / 業務ライン（最初の2年）
全社コア業務システムの開発に参加。注文、在庫などのモジュール設計・実装を単独で担当し、要件分析からリリースまで全工程をフォロー。
同じ会社、同じ人でも、3つのフェーズに分割すると、面接官が見るのは「技術的な深みが増し、職責の範囲が拡大してきた人」です。これは長期在籍の候補者にとって最も重要なシグナルです。
似たような状況にある方は、同じ会社を異なるフェーズに分け、役割の変化で成長を示してみてください。正式な昇進でなくても、やっていることが変わったり、負っている責任が変わったりした時点で、分割して書いて構いません。
事例4：キャリアチェンジ、前職の経験が今の応募先と関係ない
背景： Dさん、3年間オフラインイベントの企画運営に携わった後、インターネット業界のユーザー運営職に転職したいと考えていました。彼の当初のやり方は、「イベント企画」の経歴を無理やり運営に寄せて書くことでした。「新規獲得」「アクティブ化」「リテンション」といった単語を並べましたが、どれも表面的で、無理にこじつけた感が否めませんでした。
彼と話してみてわかったのは、運営の視点で十分に書ける経歴があるのに、彼はずっとそれを「イベント企画の一部」と思って気に留めていなかったことでした。
オフラインサロンイベントの全体統括を担当。会場手配、資料準備、現場運営、イベント振り返りを含む。
この文章がインターネットのユーザー運営とどうつながるのか、彼自身はまったく見えていませんでした。しかし、私がいくつか質問すると、すぐに見えてきました。参加者はどう集めたのか？（答：オンラインコミュニティから募集した）何人集まったのか？（平均で毎回80〜120人）参加者は来た後に何かフォローアップがあったのか？（コミュニティに引き込んでいて、転換率は約30%）イベントからコンテンツは生まれていたのか？（毎回ゲスト講演があり、記事とショート動画にしていた）
改善後：
オフラインサロンを20回以上企画・運営し、累計2,000人以上のユーザーにリーチ。オンラインコミュニティから参加者募集と選考を行い、回ごとの参加率は85%以上を安定的に維持。イベント後はコミュニティへの誘導とコンテンツ配信によって、参加者のコミュニティ転換率30%を達成。
ゲスト講演の内容を記事とショート動画に編集し、WeChat公式アカウントと動画アカウントで配信。コンテンツ累計60本以上を制作し、平均再生・閲覧数3,000以上。
この版が成立しているのは、運営用語を無理に追加したからではありません。「集客→来場→受け入れ→転換→コンテンツ配信」という一連の流れが、そのままユーザー運営のコアファネルに対応しているからです。キャリアチェンジをする人が最も避けるべきは用語のこじつけであり、最もやるべきは、自分のやってきたことを応募先の職種の言葉で翻訳し直すことです。ただしその前提として、自分のやってきたこととその職種との本当の接点をまず見つける必要があります。
事例5：職務経歴に期間を書かない、または年しか書かない
この事例は手短ですが、言及する価値があります。職務経歴に「2019 - 2021」と年しか書かない、あるいは時期をまったく書かない人に、少なからず遭遇してきました。理由を尋ねると、たいてい次のような答えが返ってきます。
あまりに短い期間があって見栄えが悪いから。
1〜2ヶ月のブランクの説明が難しいから。
通算の実務期間が短く見えるのが怖いから。
正直なところ、これらの懸念は理解できます。しかし、時期を書かないことは、書くことよりもはるかに危険です。面接官は欠けている時間情報を見たとき、デフォルトの仮定として「あなたは私に知られたくないことがある」と受け取ります。「書き忘れたんだな」とは考えません。この仮定が一度形成されると、その後のすべての経歴に対する信頼が割り引かれてしまいます。
もし本当に短い経歴やブランク期間があるなら、より良い対処法はこうです。期間はそのまま書き、その期間に何をしていたかも履歴書に書く。たとえフルタイムの仕事でなくても。
たとえば、2ヶ月のブランクがあるなら、こう書けます。
2023.04 - 2023.06 | 個人学習期間：分散システムの講座を集中的に受講し、関連する個人プロジェクトを2つ実装。
これは空白のままにしておくよりはるかに良い印象を与えます。面接官はブランクそのものを恐れているのではなく、ブランク期間に何もしていなかったこと、あるいはさらに悪く——隠そうとしていることを恐れているのです。
いますぐ使える6つの書き換え原則
事例を一つひとつ自分の履歴書と照らし合わせるのが面倒なら、まずはこの6つの原則を覚えて、自分の職務経歴を見直してみてください。
1. 職務記述書ではなく、個人の成果を書く
悪い例：バックエンド管理システムの開発と保守を担当。
良い例：バックエンド管理システムのフロントエンドアーキテクチャを単独で担当。ゼロから構築して納品し、運営・カスタマーサポートの2業務ラインの日常利用を支える。
2. 「参加」ではなく、自分が何をしたかを明確に書く
悪い例：注文システムの最適化に参加。
良い例：注文検索パスの最適化を主導し、コアAPIのP95を820msから140msに短縮。
3. 各経歴に少なくとも1つの数字を入れる
数字は必ずしも「何%改善した」である必要はありません。担当したシステムのカバーユーザー数、処理したデータ量、作成したAPI数、サービス提供した業務部門数、またがった部署数、率いたチーム規模などでも構いません。
どうしても数字が見つからない場合は、少なくとも「範囲」を書きましょう。たとえば「注文・決済・返金の3つのコアフローをカバー」なら、「バックエンド開発に参加」よりはるかに具体的です。
4. 同じ会社に長くいる場合は、フェーズに分けて書く
必ずしも役職名の変更がなくても分けられます。やっていたことが変わった、負っていた責任が変わった、技術スタックが刷新された——どれも分割の根拠になります。
5. 短期間の経歴は隠さない
その期間に何をやり、何を学んだかをきちんと書く方が、空白よりも安全です。面接官が恐れるのは「未知」であって、「既知」ではありません。
6. 職務経歴の粒度を経験年数に合わせる
新卒：具体的なタスクとスキルを書く。
3年以上：自立性とビジネスへの影響を書く。
5年以上：「自分の仕事がチームや事業ラインに与えた影響」を示せるとベスト。
書き直した後のセルフチェック、5項目で十分
- 各職務経歴に、チーム全体ではなく「あなた個人の貢献」が見える項目が少なくとも1つある
- 数字を入れる余地がある箇所には数字を入れ、どうしても数字がない箇所は少なくとも具体的な範囲を書いている
- 「参加」「協力」「連携」の3語が出てくるたびに、別の言葉に置き換えられないか自問した
- 同じ会社に3年以上在籍している場合、フェーズで分割している
- 3ヶ月以上の時間的な空白がある場合、その理由またはその期間に何をしていたかを説明している
ここまで読んでも自分の書き方に自信が持てない場合は、DeepResume にアップロードして診断を受けてみてください。成果の定量化、キーワードの網羅性、ATS対応度の3軸から各経歴の補強ポイントを分析し、具体的な修正の方向性を示します。