UI/UXデザイナーの職務経歴書の書き方|書類通過率を上げる実例テンプレート

職種:UI/UXデザイナー |更新日 2026/7/4

UI/UXデザイナーとして転職活動を進める際、書類選考の通過率は職務経歴書の構成と表現の精度に大きく左右される。ポートフォリオと職務経歴書の双方を提出する職種である以上、「ポートフォリオがあれば職務経歴書は簡潔でよい」と考えるのは誤りだ。採用担当者は職務経歴書でプロセスの言語化能力・ビジネス貢献の理解度・スコープの広さを評価し、ポートフォリオで視覚的アウトプットを確認する。両者は補完関係にある。

本記事では、UI/UXデザイナーの職務経歴書において書類通過率に影響を与える構成の考え方、各セクションの記述ポイント、そして実例に準じた記述の型を解説する。


UI/UXデザイナーの職務経歴書が他職種と異なる理由

エンジニアやコンサルタントと比べ、UIUXデザイナーの職務経歴書には特有の難しさがある。成果を数値化しにくいプロセス業務が多く、「良いデザインをした」という事実だけでは評価の根拠にならない。

採用企業が職務経歴書で確認したい観点は、大きく以下の三点に整理できる。

この三点が言語化されていない職務経歴書は、ポートフォリオの質にかかわらず「業務の解像度が低い人材」と判断されやすい傾向がある。


職務経歴書の全体構成

UI/UXデザイナーの職務経歴書は、以下の順序で構成するのが一般的に有効とされている。

セクション目的推奨ボリューム
職務要約自身のポジション・強みを一段落で示す100〜150字
スキル・ツールセット技術スタックと習熟度を一覧化する箇条書き5〜10項目
職務経歴(時系列)各社での役割・業務・成果を記述する1社あたり200〜400字
担当プロジェクト詳細代表的な1〜2件を深掘りする1件あたり300〜500字
資格・学歴証明可能な事実のみ記載最小限

職務経歴書全体の分量は、経験年数3〜5年で2枚(A4)、5年以上で2〜3枚が目安となりやすい。枚数よりも「一読して業務イメージが伝わるか」を優先したい。


各セクションの記述ポイント

職務要約

職務要約は採用担当者が最初に読む箇所であり、「読み続けるかどうか」の判断に影響する。ここでは自分のデザイン領域・強み・経験年数をコンパクトにまとめる。

避けるべき表現の例: 「ユーザー中心設計を大切にし、デザインで課題を解決してきました。」

この種の記述は、UI/UXデザイナーを名乗る人物であれば誰でも書ける内容であり、差別化にならない。

有効な記述の方向性: 「BtoB SaaSプロダクトのデザインを5年間担当。初期リリースから機能拡張フェーズまでのUI設計・ユーザーインタビュー設計・デザインシステム構築を経験。現在はPMとの要件定義段階からデザインプロセスに関与するポジションを担っている。」

このように、業態・フェーズ・工程の範囲・現在のポジションを具体化すると読み手の解像度が上がる。

スキル・ツールセット

ツール名だけを列挙するのではなく、活用場面や習熟度を添えることで差が出やすい。

記載の一例:

「Photoshop・Illustratorが使えます」のみの記述は、プロダクトデザイン系のポジションでは訴求力が低い傾向がある。プロトタイピングツール・リサーチツール・コラボレーションツールを整理して示すことが望ましい。

職務経歴(時系列)

各社の記述では以下の要素を含めることを推奨する。

  1. 事業概要と自分のポジション — 会社規模・事業ドメイン・チーム内での役割
  2. 担当した業務の範囲 — フェーズ別・機能別に箇条書きで整理
  3. 具体的な成果・変化 — 数値が取れるものは数値で、取れない場合は定性的な変化を記述

成果の記述は「〇〇を改善した」で終わらず、「改善の結果、どのような変化が確認できたか」まで言及することで、デザインとビジネス成果の接続を示せる。


実例の型:プロジェクト詳細記述

以下は、担当プロジェクト詳細セクションの記述テンプレートに準じた型である。実際の数値や固有の状況は自身の経験に置き換えて活用されたい。


【プロジェクト名】 管理画面UIリニューアル(BtoB SaaS)

【背景・課題】 既存管理画面はβ版の設計をそのまま拡張し続けた結果、ナビゲーション構造が複雑化。カスタマーサクセスへのサポート問い合わせのうち、操作方法に関するものが一定の割合を占めていた。

【自分の役割と担当範囲】 UIデザインリードとして、PMおよびエンジニア2名と協働。ユーザーインタビュー設計・実施・分析から情報アーキテクチャ再設計・UI設計・プロトタイプ検証・開発移行後のQAフォローまでを担当。

【プロセスの概要】

【成果・確認できた変化】 リリース後、同カテゴリの問い合わせ件数に減少傾向が確認された。また、CSチームへのフィードバックでは「新規ユーザーのオンボーディング説明が短縮された」との報告があった。定量計測の設計が不十分であった点は今後の課題として認識している。


この型のポイントは、成果を誇張せず「確認できた変化」として記述し、課題も正直に添えている点にある。採用担当者は誇張を敏感に察知するため、客観的・誠実な記述の方が信頼性を得やすい傾向がある。


書類通過率に影響しやすい表現の違い

以下に、通過率に差が生じやすい表現の比較を示す。

修正前(伝わりにくい表現)修正後(具体性がある表現)
UIデザインを担当しました新規機能のUI設計をFigmaで担当。PMから要件定義段階で関与し、ワイヤーフレームから高忠実度プロトタイプまで一気通貫で対応
ユーザビリティ改善に取り組みましたユーザーインタビュー5件を実施し、主要タスクのステップ数を見直し。デザイン変更後の行動ログで完了率の変化を確認
デザインシステムの整備を行いましたコンポーネント〇〇点を定義・Storybook連携を担当。デザイン〜実装間の認識齟齬削減を目的とし、エンジニアとの定例でルール策定
チームに貢献しましたデザインレビュー体制を整備し、週次フィードバックセッションを主導。ジュニアデザイナー2名のプロセス定着を支援

「担当しました」「取り組みました」で止まる記述は、何をどう行ったかが伝わらない。動詞の後に「何を・どのように・どのような結果として」を補う意識を持つことが有効だ。


よくある質問

Q. ポートフォリオがあれば職務経歴書の記述は簡略でも問題ないか?

企業によって選考の優先順位は異なるが、一般的には職務経歴書で業務の全体像を把握し、ポートフォリオで視覚的な質を確認するという読み方が多い。職務経歴書が簡略すぎると、ポートフォリオを確認する前に選考から外れる可能性もある。両者を補完関係として設計することを推奨する。

Q. 数値での成果が示せない場合はどう記述すればよいか?

計測の仕組みがなかった・計測できる立場になかった場合は、定性的な変化(チームの反応・業務フローの変化・後続プロジェクトへの影響)を誠実に記述する方が、不確かな数値を盛り込むよりも評価されやすい傾向がある。「定量計測が不十分だった点は課題として認識している」と添えることも、メタ認知の高さを示す手段となりえる。

Q. 経験年数が浅い場合(1〜2年)はどのように記述するとよいか?

担当できた工程の範囲は限定的であっても、「何をどのような目的で、どのように実施したか」を丁寧に記述することが重要だ。工程の全体への理解を示すために、自身が担当した範囲と他メンバーが担当した範囲を明確にし、チームの中でどう機能したかを伝えるとよい。担当工程の少なさは経験年数から判断されるため、過度に補おうとする必要はない。

Q. 職務経歴書にポートフォリオのURLを記載してよいか?

記載することは一般的に有効だ。ただし、URLが機能しているか・閲覧に制限がないかは提出前に必ず確認する。NotionやBehanceなどを使用している場合、アクセス権の設定ミスが原因で採用担当者が閲覧できないケースは少なくない。加えて、パスワード保護をかける場合はパスワードを職務経歴書内に明記しておくと親切だ。


まとめ

UI/UXデザイナーの職務経歴書は、ポートフォリオの補足資料ではなく、業務プロセスの言語化能力とビジネス理解度を示す独立した書類として位置づける必要がある。各プロジェクトの記述では「役割・プロセス・成果の変化」を構造的に伝えることが、書類通過率に影響する主要因となりやすい。成果の誇張よりも誠実な言語化が、経験豊富な採用担当者には響く傾向がある。スキルセットの記述においても、ツール名の列挙に留まらず活用場面を添えることで、実務イメージの解像度を高められる。自身の経験の棚卸しと合わせて市場における自身のポジションを確認したい場合は、専門的なキャリア相談を活用することも一つの選択肢となりうる。

監修

松岡 良次

株式会社エージェントベスト代表。大手人材会社およびスタートアップ人材企業にて、IT・スタートアップ・メガベンチャー企業の採用支援に従事。独立後はIT・スタートアップ・コンサル領域に特化し、20〜30代のキャリア支援を行う。(厚生労働大臣許可 13-ユ-316964)