キャリアメディア / 職務経歴書

プロダクトデザイナーの職務経歴書の書き方｜書類通過率を上げる実例テンプレート

職種：プロダクトデザイナー ｜更新日 2026/7/4

プロダクトデザイナーの職務経歴書は、単なる業務履歴の羅列では機能しない。採用担当者・採用マネージャー・エンジニアリングマネージャーがレビュアーとして関わるケースが多く、それぞれが異なる視点で書類を読む。その前提を踏まえた上で、「何を作ったか」ではなく「どのように問題を解き、何をどれだけ動かしたか」が伝わる構成にすることが、通過率を上げる本質的な条件となる。

本稿では、プロダクトデザイナーとしての職務経歴書に求められる構成・記述の粒度・ポートフォリオとの連携方法を、実際の記述例の型と合わせて解説する。

なぜプロダクトデザイナーの職務経歴書は難しいか

デザイナーの仕事は成果物が視覚的に見えるため、「ポートフォリオで見せれば十分」と考えやすい。しかし書類選考の段階では、ポートフォリオへのリンクがあったとしても職務経歴書が先に精読されるケースが多い。採用側がポートフォリオを開くかどうかの判断も、職務経歴書の記述に左右されやすい。

また、「プロダクトデザイナー」という職種は会社によって定義の幅が広い。UI制作に特化した役割から、リサーチ・情報設計・仕様策定まで担うProduct Design（0→1から運用改善まで）まで、実態は大きく異なる。職務経歴書では自分の関与範囲を明確にしないと、読み手に「このデザイナーは何ができるのか」が伝わらない。

さらに、数値で成果を示すことが難しい職種でもある。だからこそ、「指標の変化」「プロセスへの貢献」「チームへの影響」を言語化する技術が求められる。

職務経歴書の基本構成

プロダクトデザイナーの職務経歴書は、以下の構成が読みやすく、評価されやすい。

1. 職務要約（サマリー）

冒頭に3〜5文程度で、自分のキャリアの軸・専門領域・強みを簡潔に示す。採用側がここで「この人は何者か」を把握できれば、以降の詳細記述の読み方が変わる。

記述例の型：

「BtoB SaaSプロダクトのデザインに約5年携わってきました。主にデータ可視化・業務効率化ツールの設計を担当し、ユーザーリサーチから情報設計・UIデザイン・実装サポートまで一貫して関与してきました。直近では5名規模のデザインチームのリードとして、デザインシステムの整備とプロセス改善を主導しました。」

このサマリーで「業種・プロダクト種別・担当範囲・チームでの役割」の4軸を押さえると伝達効率が高まる。

2. スキルセクション

スキルは単なるツール名の列挙ではなく、カテゴリごとに整理する。

ツール名だけを並べると「その人がどのレベルで使えるのか」が伝わらないため、「デザインシステムの設計・運用（Figma）」のように用途と紐づけて記述することを推奨する。

3. 職務経歴（プロジェクト単位で記述）

ここが職務経歴書の核心部分となる。在籍企業・期間・担当プロダクトを示した上で、プロジェクトごとに以下の構造で記述する。

職務経歴の記述で差がつくポイント

「課題→アプローチ→成果」の型を徹底する

多くのデザイナーが「○○のデザインを担当しました」で終わってしまう。採用側が知りたいのは、そのデザインがどのような問題を解くものだったか、どのようなプロセスで進めたか、結果として何が変わったかだ。

記述例の型（プロジェクト単位）：

担当プロジェクト：管理画面のリデザイン（202X年4月〜202X年10月）

課題： 既存の管理画面は複数の機能追加を経た結果、ナビゲーション構造が複雑化し、新規ユーザーのオンボーディング完了率が低下していた。カスタマーサクセスへの問い合わせの約3割が操作方法に起因するものだった。

アプローチ： 既存ユーザー8名へのインタビューと、CS経由の問い合わせログの定性分析を実施。情報アーキテクチャを再設計し、ナビゲーションを3階層から2階層に整理。エンジニア2名・PM1名と週次の仕様確認MTGを設定し、実装との乖離を最小化した。

成果： リリース後3ヶ月でオンボーディング完了率が約15ポイント改善（社内計測ベース）。CS問い合わせの操作関連比率も低下傾向が確認された。

この型は、採用側がデザインプロセスの質・ビジネス貢献の理解・コラボレーション能力を同時に評価できる構造になっている。

数値がない場合の表現方法

必ずしも数値で成果を示せるとは限らない。その場合は以下のような代替表現を活用する。

「数値を作れなかった」ではなく「どのような影響があったかを言語化する」という姿勢が重要で、この部分の表現力もデザイナーとしての能力のひとつとして評価される。

関与範囲の明示

プロジェクトの全体像に対して、自分がどの部分を担ったかを明記する。「担当しました」だけでは、企画から実装サポートまで一人で担ったのか、分業体制の中の一部を担ったのかが判断できない。

記述例：「UI設計（ワイヤーフレーム〜ビジュアルデザイン）を単独担当。リサーチはリサーチャーと共同実施、実装サポートはフロントエンドエンジニア2名と協働」

ポートフォリオとの連携設計

職務経歴書とポートフォリオは別々の媒体ではなく、補完関係として設計する。

職務経歴書には「構造・プロセス・成果の言語情報」を、ポートフォリオには「ビジュアル・思考の可視化」を配置する。職務経歴書のプロジェクト記述の末尾に「詳細はポートフォリオのXXページ参照（URL）」と明記しておくと、採用側のポートフォリオへの誘導効率が高まる。

また、ポートフォリオへのリンクは職務経歴書の冒頭（氏名・連絡先付近）にも掲載する。採用担当が書類をスキャンする際、冒頭でリンクを見つけられる方が確認されやすい傾向がある。

シニアとジュニアで変わる記述の重点

職位・経験年数によって、評価される記述の重点が異なる。

シニアになるほど「個人の手を動かした量」より「チームや組織にどう影響を与えたか」が評価の重心になる傾向がある。シニア志向のポジションを目指す場合は、メンタリング・採用貢献・デザイン基準の整備といった組織貢献も記述に含める。

よくある質問

Q. ポートフォリオがあれば職務経歴書は簡略化してよいですか？

書類選考では職務経歴書が主要な判断材料になるケースがほとんどです。ポートフォリオへの誘導を意識しながらも、職務経歴書単体で「何ができるか・何を成し遂げたか」が伝わる記述を維持することが重要です。簡略化はむしろ選考通過率を下げるリスクがあります。

Q. 副業・個人プロジェクトは記載すべきですか？

本業での実績が不足している場合や、異なる領域への越境を示す目的では有効です。ただし「個人プロジェクト」であることを明示し、本業の職務経歴と混在しない構成にすることが読みやすさの観点から推奨されます。関与範囲・技術スタックも明記しておくと誤解が生じにくくなります。

Q. 在籍中のプロダクトに関する情報はどこまで書けますか？

NDA（秘密保持義務）の範囲は企業・契約ごとに異なります。プロジェクトの性質・手法・成果の傾向は記述できるケースが多いですが、具体的な数値や社名入りの詳細はポートフォリオ同様、選考プロセスが進んだ段階でのみ開示する形が一般的です。職務経歴書段階では「詳細は面談にて」と添えておく表現が活用されています。

Q. 職務経歴書の適切なページ数はどれくらいですか？

経験3年未満であれば1〜2ページ、それ以上のキャリアであれば2〜3ページが読まれやすい範囲の目安です。ただし、プロジェクト数が多い場合でも重要度の高い案件に絞った記述にし、詳細はポートフォリオに委ねる構成が合理的です。長ければ詳細に見えるのではなく、読まれなくなる可能性が高まります。

まとめ

プロダクトデザイナーの職務経歴書は、「何を作ったか」ではなく「どのような問題をどのように解き、何が変わったか」を構造的に示すことが評価の基盤となる。スキルの列挙・担当業務の羅列ではなく、課題・アプローチ・成果の型でプロジェクトを記述し、関与範囲を明示することで、読み手の理解コストを下げながら自分の実力を正確に伝えることができる。ポートフォリオとの役割分担を意識しながら、職務経歴書単体で選考を突破できる完結性を持たせることが重要だ。数値の有無より、思考の質と言語化の精度が問われる職種であるからこそ、記述そのものがデザイン能力の一端を示す場でもある。自分のキャリアの市場価値を客観的に整理したい場合や、書類の表現に迷う場合は、プロダクトデザイナーの転職市場に詳しいキャリアアドバイザーへの相談が判断の精度を上げる一助になることも多い。