Developer Experience転職ガイド

Developer Experienceは、開発者が日々触る環境、テンプレート、フィードバック、自己解決の導線を整える役割として求人に現れます。プラットフォームエンジニアは実行基盤、CI/CDはパイプラインそのもの、テックリードはプロダクト側の技術判断が中心です。転職では、自分が動かしたのが「開発者の一日の摩擦」か「基盤の稼働」か「機能の方針」かを先に分けてください。

開発者の摩擦

起動、認証、環境差、待ち時間など、実装以外で止まる地点です。基盤障害そのものではありません。

フィードバック

テスト、レビュー、プレビューなど、変更の結果が返る経路です。パイプライン部品の所有とは違います。

自己解決の導線

文書、テンプレート、内部ポータルで、問い合わせなしに進める道です。

黄金パス

推奨される始め方とデプロイの道です。強制するか選択するかが求人で分かれます。

開発基盤領域でも、実行基盤、パイプライン、技術判断、開発者体験が混ざります。このページは開発者が日々触る環境とフィードバックに焦点を当て、プラットフォームは実行基盤、CI/CDはパイプライン、テックリードは技術判断の読み方に譲ります。

• 中心の問い：Developer Experience側は「開発者は止まらず次に進めるか」。隣接側は「基盤は持つか / パイプラインは通るか / 何を作るか」。
• 成果物：Developer Experience側は「テンプレート、導線、摩擦の除去」。隣接側は「実行基盤 / パイプライン定義 / 技術方針」。
• 利用者：Developer Experience側は「社内の開発者」。隣接側は「アプリ実行環境 / ビルド実行 / プロダクトチーム」。
• 成功の見方：Developer Experience側は「自己解決できたか」。隣接側は「稼働 / 成功実行 / 出荷判断」。
• 混同しやすい求人：Developer Experience側は「Platform＋DevEx名」。隣接側は「基盤専任 / パイプライン専任 / EM・TL」。

DevEx求人は、テンプレート、ローカル起動、フィードバック、内部ポータル、自己解決などのキーワードが並びます。クラスタ製品名より、開発者が止まる地点、問い合わせの減らし方、基盤チームとの分界が読み取れるかを見てください。

• 開発者の摩擦または自己解決導線を1例説明できる
• 実行基盤運用やパイプライン所有と混同していない
• テックリードの方針権限と分界できる
• 確認できない生産性数字を書いていない
• 黄金パスの強制範囲が求人で分かる

job tagのIT関連職で実装と横断推進の距離を対応づけます。IPAのDX資料は標準化の考え方の参照です。Kubernetesの公式概要は実行基盤側の入口であり、DevExという肩書の公式定義ではありません。

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

1. 01
   摩擦1例

   止まる地点、原因、導線の直し方を一般化して書きます。

2. 02
   黄金パス

   推奨と例外申請を1枚にします。

3. 03
   基盤との境界

   クラスタ運用はプラットフォーム寄りとして分けます。

4. 04
   CIとの境界

   パイプライン所有はCI/CD寄りとして明記します。

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

• 職種名より、開発者体験・実行基盤・パイプライン・技術判断のどれが主かを固定する
• 摩擦と自己解決導線の有無を確認する
• プラットフォームとCI/CDへ隣接を切る
• 黄金パスの強制範囲を聞く
• 確認できない生産性数字は経歴から外す
• 相談先を2系統にし重複応募を避ける

DevEx求人はプラットフォーム、SRE、テックリードに分類されることがあります。ハイクラス向け相談先を2系統使い、同じ求人を「実行基盤」「パイプライン」「技術判断」「開発者体験」で分類してください。

• ハイクラス・開発者体験

  導線改善が独立している求人。生産性数字ではなく摩擦1例を面談で確認します。

• プラットフォーム隣接

  基盤兼務が厚い場合。プラットフォームと併せ、オンコール比率を伝えます。

• CI隣接

  パイプラインが主の求人。CI/CD側として分類し、体験の有無を確認します。

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

• プラットフォームと同一視

  実行基盤はプラットフォーム寄りです。開発者の摩擦がなければDevExの説明になりにくいです。

• CI/CDと混同

  パイプライン所有はCI/CD寄りです。フィードバックの導線を先に置いてください。

• 生産性数字の断定

  確認できない改善率は書かないでください。摩擦と自己解決の具体例1つを深く書いてください。

応募前1週間は、摩擦1例と導線1例、プラットフォーム/CI/テックリードとの境界を経歴に明記します。

1. 01
   月〜火：摩擦と導線

   摩擦1例を職務経歴用に清書します。

2. 02
   水〜木：求人分類

   3件を実行基盤・パイプライン・技術判断・体験で分けます。

3. 03
   金：面談質問

   所有、黄金パス、問い合わせ経路を各2つ書き出します。

4. 04
   週末：経歴整理

   稼働改善だけの記述を摩擦除去の話に置き換え、重複表を作ります。

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

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

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

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

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

   標準化の考え方を黄金パスの説明に使う 一方で、DevEx肩書の定義には使わない

3. 03
   Kubernetes Documentation — Overview

   実行基盤側の入口として、プラットフォーム領域との分界を見る 一方で、クラスタ必須の断定や合格率には使わない

• 手順1：職種名より、開発者体験・実行基盤・パイプライン・技術判断のどれが主かを固定する
• 手順2：摩擦と自己解決導線の有無を確認する
• 手順3：プラットフォームとCI/CDへ隣接を切る
• 手順4：黄金パスの強制範囲を聞く
• 手順5：確認できない生産性数字は経歴から外す
• 手順6：相談先を2系統にし重複応募を避ける