メルカリの職務経歴書｜Job Group・事業・職種別の書き方

メルカリグループの求人は、Engineering、Product & Business、Corporateに分かれ、Mercari、Merpay、Mercoinなど事業ごとに扱う課題も異なります。最初にJob Group・事業・職種を一つ決め、本人の役割と成果を説明できる2〜3案件を選ぶことが、焦点を定める第一歩です。

公式Selectionページは、書式を任意としながら、職歴の要約、関わった事業・プロジェクト、役割、成果、メルカリで実現したい目標・ビジョンの記載を勧めています。本記事では、この案内を基準に過去の事実と応募後に担いたい責任を一貫させる方法を解説します。

最初にJob Group・事業・職種を一つ決める

複数職種へ同じ職務経歴書を送ると、技術、企画、事業、管理のどこで価値を出せる人か曖昧になります。募集ページから、Job Group、会社・事業、職種、対象プロダクト、主な責任、必須経験を書き出してください。

Job Group	主な職種	最初に示す証拠
Engineering	Software、ML、Data、SRE、Security等	利用者課題、設計・実装責任、品質・運用結果
Product & Business	PdM、BizDev、Sales、Marketing、Analytics、Design等	市場・利用者課題、優先判断、社内外合意、検証
Corporate	Finance、Audit/Risk、Legal、People等	経営・事業課題、制度・統制、運用変化

職種名だけでなく、Marketplace、決済・信用、暗号資産、越境、物流など成果の届け先まで決めます。応募先を固定した後で、隣接求人と要件を比較しましょう。

公式が案内する職務経歴書の5項目

公式Selectionページは、候補者像を判断しやすくする情報として次の内容を案内しています。指定された型へ機械的に当てはめるのではなく、応募職種に必要な事実を過不足なく示すために使います。

1. 職歴の簡潔な要約
2. 関わった事業・プロジェクト
3. 各案件で担った役割
4. 確認できる成果
5. メルカリで実現したい目標・ビジョン

要約は経歴年表の短縮版ではありません。応募職種に関係する責任、扱ってきた課題、強みを裏付ける案件を3〜5行で示し、詳細案件へ導きます。目標・ビジョンは最後に突然足さず、過去の案件から関心が生まれた理由へつなげます。

3つのJob Groupで職務経歴書の中心を変える

Engineeringは技術名より設計判断と運用を書く

バックエンド、モバイル、機械学習、データ、SRE、セキュリティでは責任が異なります。共通するのは、対象プロダクト・利用者、課題、本人の設計・実装、比較した案、品質・性能・運用の結果を示すことです。

使用言語やクラウドの一覧は技術欄へ置き、案件本文ではなぜその設計を選んだかを説明します。チームが決めたアーキテクチャと本人が担当した実装を混ぜないようにしてください。

Product & Businessは課題と優先順位を示す

Product Management、Business Development、Marketing、Data Analytics、Product Designでは、同じ「プロダクト成長」でも行動が違います。PdMは優先順位と開発合意、事業開発は機会発見と社内外の条件設計、マーケティングは対象と仮説、デザインは利用者理解と検証を中心にします。

施策や機能を実施した事実より、何を根拠に選び、実施後の結果から次の判断をどう変えたかが重要です。

Corporateは事業を支えた判断を具体化する

Finance、Risk、Legal、People等では、定型業務や処理件数だけを並べません。取引・決済・新規事業を進めるうえで、どのリスクや経営課題を特定し、選択肢を比較し、事業部と合意し、制度や運用をどう変えたかを書きます。統制と事業速度の両方をどう扱ったかも責任範囲を示す材料です。

Mercari・Merpay・Mercoinなどの事業差を反映する

事業・領域	主な課題の例	職務経歴書で確かめること
Mercari Marketplace	売買、検索、物流、サポート、広告等	どの利用者行動・取引工程を扱ったか
Merpay	決済、信用、加盟店、利用体験等	安全性・運用と利用拡大の責任境界
Mercoin	暗号資産関連の製品・事業・リスク	規制・リスクと事業判断をどう扱ったか
新規・周辺領域	Shops、越境、物流、新サービス等	仮説、顧客検証、開始後の学び

同じバックエンド、PdM、事業開発でも、成果の届け先が違えば選ぶ案件も変わります。一つの成功談を全事業へ使い回さず、応募先の利用者・取引・制約へ最も近い案件を先頭に置いてください。

STARで深掘りできる2〜3案件を選ぶ

公式Selectionページは、面接でSTAR methodを用い、過去の行動を深掘りすると説明しています。英語の見出しをそのまま書く必要はありませんが、次の四点を説明できる案件を選ぶと書類と面接がそろいます。

確認点	書く内容	面接で深掘りする内容
状況	事業、製品、利用者、期間、制約	なぜその課題が重要だったか
責任	本人の目標、権限、担当範囲	チーム内で誰が何を決めたか
行動	比較案、選択、実行、合意	反対意見、失敗、変更した判断
結果	数値、状態変化、残課題	再現性と次に変える点

成功の大きさより、本人のActionを具体的に説明できる案件を優先します。チーム成果はチーム成果と明示し、本人が決めたこと、実装したこと、合意を作ったことを分けましょう。

一案件を課題・責任・行動・結果へ分ける

1. 対象：事業、製品、利用者、期間
2. 課題：誰が何を完了・判断できなかったか
3. 責任：本人の権限、担当工程、成果物
4. 比較：選択肢、制約、採用しなかった案
5. 行動：設計、実装、提案、合意、運用
6. 結果：確認できる変化、数値、残課題

機密性の高い案件では、会社名、取引先、未公開金額を伏せても構いません。業界、利用者、課題、判断条件、自分の責任、状態変化を残せば、経験の再現性を説明できます。

職種別の成果指標と確認元

領域	指標候補	確認元の例
Marketplace開発	完了、継続、品質、性能、障害	利用データ、監視、課題管理
Fintech	決済、利用、信用、品質、運用	製品・運用記録、リスク管理
Product Management	利用、完了、継続、検証	要件、意思決定、分析記録
Data / ML	指標、精度、処理、実験、運用	分析、実験、監視、事業判断
Business Development	検証、提携、開始、利用、継続	契約、事業計画、運用記録
Corporate	決算、統制、リスク、採用、業務	制度文書、社内記録、運用実績

数値を出すときは対象期間、分母、比較基準、本人の寄与を添えます。数字を開示できない場合は、誰が何を実行・判断できるようになったかを具体的に書いてください。

弱くなる書き方と改善例

弱い表現	改善する方向
大規模サービスの開発に貢献	［対象機能・利用者］の［課題］に対し［設計・実装責任］を担い、［確認できる結果］を得た
プロダクトをグロース	［課題の発見元］から［優先判断］を行い、［関係者］と実行し、［公開後の変化］を確認した
新規事業を推進	［市場・顧客仮説］を［方法］で検証し、［本人が決めた条件］で開始し、［学び］を次の判断へ反映した
Valuesを体現	［対立・制約のある状況］で［本人が選んだ行動］と［結果］を示す

会社の言葉や大きな成果名を借りず、自分がした判断を動詞で示すことが改善の要点です。架空の数値や責任は加えません。

未経験・隣接経験を大きく見せない

メルカリを利用した経験、個人開発、学習、Valuesへの共感だけで、経験職のプロダクト・事業・管理責任を満たすとは判断できません。募集要項の必須経験を「直接ある」「隣接している」「まだない」に分けます。

足りない責任を言い換えで大きくせず、現職で利用者課題の把握、実行後の検証、他部門合意を担う選択もあります。応募可否は最新の個別求人で確認してください。

目標・ビジョンを過去の経験につなぐ

公式Selectionページは、メルカリで実現したい目標・ビジョンの記載を勧めています。「Missionに共感した」で終えず、過去にどの課題へ向き合い、どの判断から次の関心が生まれ、応募職種で何を担いたいかをつなぎます。

要素	確認する問い
過去	どの利用者・顧客・事業課題へ責任を持ったか
学び	結果や失敗から何を次の課題と考えたか
応募先	どのJob Group・事業の責任と関係するか
未来	入社後に何を担い、どの状態を作りたいか

目標は壮大さより、過去の経験から応募職種の責任へ自然につながることを重視します。企業の非公開の評価配点や合否条件は推測しません。

メルカリの職務経歴書でよくある質問

職務経歴書の書式は決まっているか？

公式Selectionページでは書式は任意と案内されています。応募時の最新案内を確認し、職歴要約、案件、役割、成果、実現したいことが分かる形にします。

複数ポジションへ応募できるか？

公式FAQでは同時応募が可能です。ただし複数の書類選考を通過した場合、原則として先へ進む一つを選ぶと案内されています。

STARは職務経歴書にそのまま書くべきか？

英語の項目名を並べる必要はありません。状況、責任、本人の行動、結果が読み取れ、面接で深掘りできる順序にします。

成果数値を開示できない場合はどうするか？

会社名や金額を伏せ、対象、課題、判断条件、本人の責任、状態変化を書きます。確認できない数字は作りません。

Valuesへの共感はどう書くか？

形容詞で自己評価せず、制約や意見差がある状況で自分が選んだ行動と結果を示し、応募職種で担いたい責任へつなぎます。

提出前に公式案内と職務経歴書を照合する

• Job Group、事業、職種を一つ決めている
• 職歴要約が応募責任と対応している
• 事業・案件、役割、成果を2〜3案件で説明できる
• チーム成果と本人のActionを分けている
• 目標・ビジョンが過去の経験からつながっている
• 数値の期間・対象・確認元を説明できる
• 提出直前に現行求人とSelectionページを確認している

上記がそろっているなら、自分で応募書類を整えられます。Job Groupや事業を選べない、プロダクトと事業開発のどちらで経験が伝わるか迷う、チーム成果と本人の行動を切り分けにくい場合は、応募前に第三者と整理する方法もあります。

応募先を一つ決め、公式が案内する5項目と2〜3案件を照合するところから始めてください。メルカリ向けの職務経歴書では、Valuesを飾ることより、過去の判断と次に担いたい責任の一貫性が重要です。

+

Engineeringは技術名より本番責任を具体化する

Engineering求人を読むときは、言語やフレームワークの一致だけで判断しません。Marketplace、Fintech、社内基盤では、守るべき利用者行動と運用条件が異なるためです。職務経歴書では、設計、実装、レビュー、リリース、監視、障害対応のうち、自分が最終的に責任を持った範囲を明記します。

経験領域	書類で示す判断	避けたい曖昧さ
バックエンド	データ整合性、API境界、性能、障害時の復旧	「大規模開発に貢献」だけで担当が不明
モバイル・Web	利用者の完了行動、品質、段階的な公開判断	画面数だけで利用者への変化がない
Platform / SRE	開発者体験、信頼性、標準化、運用負荷	導入技術だけで採用理由を説明しない
Security	脅威、予防、検知、対応、事業との合意	安全性を本人だけの成果として扱う

たとえば性能改善なら、処理時間の変化だけでなく、対象となる利用機能、計測条件、比較案、公開時の安全策まで残します。障害対応なら復旧の速さだけでなく、検知から判断、関係者連携、再発防止までの担当境界を示すと、面接でActionを説明しやすくなります。

Product・Data・Designは意思決定への接続を書く

Product Managementでは、機能を公開した事実より、どの利用者課題を優先し、何と比較し、公開後に何を確かめたかが重要です。ロードマップ全体を所有していない場合は、担当した課題領域と意思決定権限を区切ります。Dataでは分析資料の本数ではなく、指標設計や実験が製品・事業の判断をどう変えたかを示します。

Machine Learningの経験は、モデル作成と本番提供を分けます。学習データ、評価、プロダクトへの組み込み、監視のうち実際に担った範囲を記し、試作を継続運用の実績へ膨らませません。Designでは、調査した利用者、迷いや誤りが生じた場面、情報設計、開発との制約調整、検証結果を一本の流れにします。

職種	Before	Action	After
Product	優先課題が定まらない	定性・定量根拠を比較し合意した	検証対象と判断条件が明確になった
Data	部門ごとに指標解釈が異なる	定義と利用場面を整理した	同じ条件で判断できるようになった
Design	利用者が取引工程で迷う	調査、情報設計、検証をつないだ	完了できる行動が明確になった

Business職は市場・顧客・社内実行を分ける

Product & Businessの中でもBusiness Development、Sales、Marketing、PRでは成果の作り方が違います。Business Developmentでは、機会の発見、仮説検証、条件設計、社内外合意、開始後の検証を分けてください。Salesは対象顧客、提案課題、意思決定者、契約後の接続を示し、MarketingやPRはチャネル施策だけでなく、誰の認知・理解・行動を変えたかを書きます。

提携やキャンペーンの名称が大きくても、本人の判断が見えなければ再現性は伝わりません。「主導した」と書く場合は、論点を定義した、条件を比較した、反対意見を調整した、開始基準を決めたなど、主導の中身を動詞で説明してください。複数社の共同案件は、相手企業の成果と自社チームの成果、自分の寄与を切り分けます。

Corporateは事業を安全に進めた範囲を示す

Corporate求人へ応募する場合、制度名や担当業務の羅列だけでは、事業への貢献が読み取りにくくなります。Financeなら意思決定に必要な情報と締めの精度、LegalやRiskなら論点の発見と代替案、Peopleなら採用・配置・育成上の課題と運用結果を具体化します。

一方で、経営判断そのものを担当していないなら「経営を変えた」とは書きません。どの資料、統制、契約、採用プロセスを整え、誰が安全または迅速に判断できるようになったかに限定します。Fintech事業に関係する経験も、規制対応、リスク判断、運用設計のうち本人が担った部分だけを記載してください。

Selectionの公式5項目を一つの物語にする

公式Selection案内にある職歴要約、事業・プロジェクト、役割、成果、メルカリで実現したい目標・ビジョンは、五つの独立した飾りではありません。職歴要約で応募先に関係する責任を示し、案件で判断を裏づけ、最後にその経験から次に担いたい責任をつなぎます。

1. 応募するJob Group、事業、個別求人を決める
2. 必須条件と主な責任を自分の言葉で分解する
3. 対応する2〜3案件を選び、本人のActionを抜き出す
4. 確認可能なResultと残課題を整理する
5. 過去の学びから、応募先で担いたい責任をつなぐ

この順序なら、目標だけが壮大になることを防げます。MissionやValuesは会社理解の手掛かりですが、言葉を引用するだけで本人の適合を証明するものではありません。制約下で選んだ行動と結果から、仕事の進め方が読み取れるようにします。

複数応募でも職務経歴書の第一志望を決める

公式FAQは複数ポジションへの応募を認める一方、複数の書類選考を通過した場合は原則として先へ進む一つを選ぶと案内しています。これは応募数を増やす推奨ではありません。まず第一志望の求人を決め、その責任に合わせて要約と案件順を整えます。

別のJob Groupも検討するときは、同じ書類をそのまま提出せず、強調する判断を見直します。Engineering向けなら設計・品質・運用、Product向けなら優先順位と検証、Business向けなら顧客・市場・合意、Corporate向けなら統制と事業判断への接続が中心です。経験を作り変えるのではなく、実在する事実のどこを先に読んでもらうかを変えます。

公式情報10ページで応募直前に照合する

確認対象	公式ページ	職務経歴書への反映
現行求人一覧	Jobs	応募先と責任を確定
Engineering求人	Engineering Jobs	技術・品質・運用責任を照合
Product & Business求人	Product & Business Jobs	顧客・製品・事業責任を照合
Corporate求人	Corporate Jobs	専門領域と支援対象を照合
提出・選考案内	Recruitment Selection	推奨項目とSTARを確認
採用情報全体	Mercari Careers	応募日の案内を確認
Engineering組織	Mercari Engineering	技術組織の発信を確認
Culture	Culture	働き方の背景を確認
Mission・企業情報	Mercari, Inc.	目標との接続を確認
グループ会社情報	About Us	応募先の事業主体を確認

これらのページは役割が異なります。Jobsは現行の募集要項、Selectionは提出と面接の公開案内、組織・Culture・Missionは背景理解に使います。背景ページの表現で個別求人の必須条件を上書きせず、最終的には応募する一件の責任へ照合してください。

守秘義務を守りながら判断の解像度を残す

売買、決済、信用、セキュリティに関わる案件では、公開できない顧客情報や数値が含まれることがあります。伏せる対象を先に決め、業界、利用者、課題の種類、制約、本人の権限、選択肢、完了した節目は残します。「詳細非公開」だけでは経験が読めないため、機密に触れない抽象度で判断過程を説明します。

数値をレンジ化する場合も、社内規定に従い、比較基準や本人の寄与を説明できる範囲に限ってください。推測値で空白を埋めたり、チーム全体の取引額を自分の成果として扱ったりしません。面接で同じ説明を再現できる記述だけを残すことが、書類と選考の整合につながります。

+

MarketplaceとFintechで案件の選び方を変える

Marketplace向けでは、出品、購入、検索、配送、問い合わせなど、どの取引工程の誰を支えたかを明確にします。たとえば検索改善なら、モデルや画面の変更だけでなく、購入者が商品を見つけるまでの課題、出品者側への影響、品質を確認した条件まで書きます。物流やカスタマーサポートに関わる経験では、利用者向け機能と社内運用の双方に変化があったかを分けてください。

Fintech向けでは、決済や加盟店の利用拡大だけでなく、安全な運用やリスク部門との接続が案件選択の軸になります。ただし、金融サービスに関わっただけで規制対応の責任を持ったとは限りません。本人確認、審査、モニタリング、問い合わせ対応などのうち、自分が設計・実装・判断した範囲を限定し、専門部門が担った判断を切り離します。

両領域に共通する経験を使う場合も、「多くの利用者がいるサービス」という抽象度でまとめません。取引の成立を支えたのか、決済の完了を支えたのか、運用担当者の判断を支えたのかを特定します。応募求人の責任と近い順に案件を並べることで、職種名が同じでも事業上の役割が違うことを理解していると伝えられます。

面接で職務経歴書と同じ判断を説明できるか確認する

STARを使った深掘りに備えるなら、各案件について「なぜその課題を選んだか」「他にどんな案があったか」「反対意見や制約をどう扱ったか」「結果を何で確認したか」に答えられる状態にします。書類には結論を短く置き、面接用メモには採用しなかった案、途中の失敗、公開後に残った課題まで残しておくと説明がぶれません。

特にチーム成果が大きい案件では、意思決定者、実装者、分析者、運用者の関係を簡単に図解してから文章へ戻すと、本人のActionを分けやすくなります。自分が提案したが最終決定していない場合、提案内容と合意形成の範囲を書き、決裁権まで持っていたように見せないことが重要です。

提出前には、職歴要約、主要案件、目標・ビジョンが同じ応募先を向いているかを通読します。要約はEngineering、案件はBusiness、目標はCorporateというように軸が分かれた場合は、第一志望に関係する責任を中心へ戻します。複数の強みを持つことと、一つの書類で主役が定まらないことは別です。

最後に個別求人の必須条件を一行ずつ読み返し、「直接示せる案件」「隣接経験として説明する案件」「現時点では満たさない条件」に印を付けます。満たさない条件を曖昧な表現で隠さず、応募職種で再現できる判断と、追加で学ぶ必要がある領域を分けてください。書類の強さは項目数ではなく、応募先、本人の責任、確認できる結果が一貫しているかで決まります。

応募日の求人名、所属事業、Job Groupを職務経歴書の確認メモに残し、提出後に別求人へ取り違えないようにします。面接準備では、各案件がどの必須条件を裏づけるかを一文で答えられるか確認してください。説明できない案件は量を増やすために残さず、第一志望との関係が明確な事実へ絞る方が、選考を通じた一貫性を保てます。