Growth Engineer転職ガイド

Growth Engineerは、実験基盤、イベント計測、登録や課金などのファネル実装、結果の技術的な読み解きを担う役割として求人に現れます。PMは企画と優先順位、フロントエンドはUIの品質、Martechは広告やCDPの基盤が中心です。転職では、自分が動かしたのが「実験と計測の実装」か「何を作るかの企画」かを先に分けてください。

実験基盤

ユーザー割当、フラグ、結果集計までを再現できるようにした仕組みです。施策アイデアそのものではありません。

イベント計測

画面操作やサーバー側の出来事を、分析可能なイベントとして設計・実装することです。広告ピクセル運用とは違います。

ファネル実装

登録、活性化、課金などの経路を、計測可能な状態でプロダクトに組み込む作業です。

統計判断の分担

有意差や早期終了を誰が決めるかの線です。エンジニアが実装だけか、判断まで持つかが求人で分かれます。

成長施策でも、企画、UI実装、広告基盤、実験計測が混ざります。このページは実験基盤・計測・ファネル実装に焦点を当て、プロダクトマネージャーは企画、フロントエンドはUI実装、MarTechは広告・CDP基盤の読み方に譲ります。

• 中心の問い：Growth Engineer側は「実験と計測は再現できるか」。隣接側は「何を作るか / UIは良いか / 広告基盤は動くか」。
• 成果物：Growth Engineer側は「フラグ、イベント、ファネル実装」。隣接側は「仕様 / 画面 / CDP・広告連携」。
• 数字との距離：Growth Engineer側は「計測定義と実験結果の技術検証」。隣接側は「KPI目標 / 見た目の改善 / 配信成果」。
• 個人情報：Growth Engineer側は「イベント設計での最小化」。隣接側は「要件 / 画面項目 / 広告識別子」。
• 混同しやすい求人：Growth Engineer側は「PM兼Growth、広告運用」。隣接側は「企画職 / UI職 / マーケ基盤」。

Growth求人は、A/B、フィーチャーフラグ、イベント設計、ファネル、計測タグなどのキーワードが並びます。施策名より、実験の割当、統計判断の担い手、個人情報の取得範囲が読み取れるかを見てください。

• 実験基盤または計測設計を1例説明できる
• PMの企画と広告運用を混同していない
• 個人情報の取得範囲をイベント単位で言える
• 統計判断の担い手が求人で分かる
• 確認できない改善率を書いていない

job tagのIT関連職で実装と企画の距離を対応づけます。個人情報保護委員会の公開情報は計測イベントの取得範囲の入口です。IPAのDX資料は施策とシステムのつなぎの参照に使えます。Growthという肩書の公式定義ではありません。

Growth Engineerでは、ツール名の羅列より、自分が判断した範囲の説明が先です。秘密情報は一般化し、確認できない数字は書きません。

1. 01
   実験1例

   仮説、割当、計測、終了条件を一般化して書きます。

2. 02
   イベント1例

   取得項目と最小化の判断を残します。

3. 03
   PMとの境界

   企画だけの記述はプロダクトマネージャー寄りとして分けます。

4. 04
   Martechとの境界

   広告基盤はMarTech寄りとして明記します。

Growth Engineerの応募可否は、肩書や媒体の並び順ではなく、次の順で切り分けます。

• 職種名より、実験実装・企画・UI・広告のどれが主かを固定する
• イベントの個人情報範囲を確認する
• 統計判断と優先順位の権限をPMと切り分ける
• Martechの広告基盤とプロダクト実験を混ぜない
• 確認できない改善率は経歴から外す
• 相談先を2系統にし重複応募を避ける

Growth求人はフロント、PM、データ、マーケに分類されることがあります。Webエンジニア向け相談先を2系統使い、同じ求人を「企画」「UI」「計測実験」「広告」で分類してください。

• Webプロダクト系

  実験基盤がコードにある求人。フロントエンドと併せ、UI品質との比率を伝えます。

• データ計測寄り

  イベントスキーマが主の場合。個人情報の範囲を先に一文で伝えます。

• マーケ隣接

  広告タグが混ざる求人。MarTechとの分界を面談で確認します。

相談先を複数使う場合は、企業名・求人ID・応募経路を一覧にして重複応募を防いでください。転職支援とスカウトでは受けられる支援が異なるため、同じ基準で単純比較せず、目的に合う窓口を選びます。

• PMと同一視

  企画と優先順位はプロダクトマネージャー寄りです。実験と計測の実装がなければGrowthの説明になりにくいです。

• 広告運用と混同

  配信と予算はMartech寄りです。プロダクト内の実験基盤を先に置いてください。

• 改善率の断定

  確認できないCV改善は書かないでください。計測定義と実験1つを深く書いてください。

応募前1週間は、実験基盤と計測1例、PM/フロント/Martechとの境界を経歴に明記します。

1. 01
   月〜火：実験と計測

   実験1例とイベント定義を職務経歴用に清書します。

2. 02
   水〜木：求人分類

   3件を企画・UI・実験・広告で分けます。

3. 03
   金：面談質問

   権限、個人情報、統計判断を各2つ書き出します。

4. 04
   週末：経歴整理

   広告運用語彙を計測実装語彙に置き換え、重複表を作ります。

Growth Engineerの用語は、公式資料の定義と求人票の言葉がズレることがあります。次の表で、経歴に書く粒度と求人票での確認先を揃えてください。

Growth Engineerでは、媒体記事より公式資料を先に開き、分からない点だけを相談先と公式窓口に分けます。

1. 01
   厚生労働省 職業情報提供サイト（job tag）IT・通信の仕事

   実装職と企画職の距離を対応づける 一方で、求人数や年収の断定には使わない

2. 02
   個人情報保護委員会

   計測イベントの取得範囲を面談で確認する入口にする 一方で、適法性の断定や個別助言の代わりにはしない

3. 03
   IPA デジタルトランスフォーメーション（DX）

   施策とシステムのつなぎ方を説明する参照にする 一方で、Growth肩書の定義には使わない

• 手順1：職種名より、実験実装・企画・UI・広告のどれが主かを固定する
• 手順2：イベントの個人情報範囲を確認する
• 手順3：統計判断と優先順位の権限をPMと切り分ける
• 手順4：Martechの広告基盤とプロダクト実験を混ぜない
• 手順5：確認できない改善率は経歴から外す
• 手順6：相談先を2系統にし重複応募を避ける