開発部の組織マネジメント会議で、部長からこんな提案がありました。
「CREって名前、変えませんか」
「名は体を表す」という言葉とともに切り出されたその一言を、私たちは議論の末に受け入れ、職能名を FDE（Forward Deployed Engineer） に変えることを決めました。
名前を変えた。仕事は同じ。でも、採用も、KPIの議論も、チームの自己認識も、少しずつ動き始めています。
この記事では、なぜ名前を変える判断に至ったのか、そして変えた先に何が見えるのかを書いてみます。
ContractS株式会社で開発部 Platformグループ FDEのマネージャーをしている佐藤です。「チームの名前と実態のズレ」に心当たりのあるマネージャーの方や、今後のキャリアを考えているエンジニアの方の参考になれば幸いです。
1. CREという名前の違和感
私たちのチームは長く CRE（Customer Reliability Engineering） を名乗ってきました。
CREはもともとGoogleが提唱した職種で、その本来の定義は「顧客システムの信頼性を保証する役割」——いわばSREの考え方を顧客側に向けたものです。名前だけを見れば、インフラやSREに近い信頼性エンジニアリングの仕事を想像する人が多いでしょう。
ところが、ContractSのCREが実際にやっていたのは主にこんな仕事です。
- 顧客の業務プロセス（BPMN）の設計・構築
- API連携・iPaaS統合の提案と実装
- AI-OCRのカスタマイズ
- 顧客折衝とプロジェクト推進
顧客の最前線に立ち、業務課題をヒアリングし、プロセスから設計する。必要とあれば自分たちでコードを書き、週単位でデリバリーする。本来のCREの定義とは、重なる部分もありますが、軸足がまるで違います。
この「名前と実態のズレ」は、採用の現場でも顔を出していました。「SRE的な人を募集しているんですか？」「カスタマーサポートですか？」——面談のたびに、まず誤解を解くところから始めなければならない。名前のせいで、候補者にも社内にすら、自分たちの仕事が正しく伝わっていなかったのです。
2. FDEという選択肢
代わりに浮かび上がったのが、FDE（Forward Deployed Engineer） という職種です。
FDEはPalantirが生み出した職種で、いまOpenAI、Anthropic、SalesforceといったAI・SaaS企業で急速に広がっています。その定義はシンプル——「自社プロダクトを持つ企業で、顧客の最前線に配置されるエンジニア」。
この定義は、私たちの仕事にそのまま当てはまりました。
そして重要なのは、独自定義をひねり出す必要がなかったこと。すでに業界で確立された概念をそのまま借りられる。外部に説明するときは「FDEです」のひと言で通じる。採用候補者が職種名を調べれば、その意味も役割も自分で理解できる。名前が、説明コストを肩代わりしてくれるのです。
3. リネームの経緯 — 組織の意思決定として
名前を変えるという判断は、誰か一人の思いつきで決まったわけではありません。
きっかけは、冒頭に書いた組織マネジメント会議での部長の提案でした。
正直に書くと、最初はモヤッとしました。「これは提案なのか、決定事項なのか」がわからなかったからです。自分たちのチーム名を、自分たちが関与しないところで決められたのだとしたら——そう思った瞬間、受け入れがたい気持ちが先に立ちました。CREという名前で積み上げてきたものへの愛着もあります。
でも、話を聞くうちに、これは「提案」であり「問題提起」であることがわかりました。そして、問題提起そのものには同意できた。決め手になったのは、こう問い返されたときです——「採用候補者に『CREです』と言って、正しく伝わっていますか？」。答えはNoでした。
議論のポイントは、おおよそ3つに整理できます。
- CREという名前が「保守的・リアクティブ」な印象を与えている — 実際の私たちは、顧客の課題に能動的に踏み込んでいくチームなのに、名前がその逆を連想させていた。
- 採用市場で正しく伝わらない — 候補者の解像度が上がらず、ミスマッチを生んでいた。
- すでに確立された概念（FDE）がそのまま使える — 独自定義のコストを払わずに済む。
これらを合議のうえで決定しました。トップダウンの号令でもなく、現場の独断でもなく、組織としてそう判断した。ふりかえってみると、このプロセス自体がよかったと思っています。
4. 名前を変えて、何が動き始めたか
リネームから日は浅く、劇的な変化を語れるフェーズではありません。ただ、すでにいくつか具体的な変化が起きています。
JDの書き直しで、言語が定まった。
FDE募集としてJD（ジョブディスクリプション）を書き直す過程で、「どんな人に来てほしいのか」をクリアに言語化できました。CRE時代は「SREっぽい人？ コンサルっぽい人？」と自分たちでも曖昧だったのが、「顧客の最前線でプロダクトを武器にアウトカムを出すエンジニア」と一文で言い切れるようになった。これは名前が変わったから自然に出てきた言葉です。
「効率×品質」への意識が明確になった。
FDEは時間を売るモデルではありません。「いかに少ない工数で、高い品質の成果を出すか」が価値になる。名前の変更を通じてこの方向性がメンバーにも伝わりやすくなりました。AIの活用も、この文脈で自然と推進力が増しています。
社内への説明が楽になった。
これはまだ道半ばですが、「FDE＝顧客の最前線に立つエンジニア」と一言で説明できるようになったのは確かです。CRE時代の「えーと、SREとは違って……」から始まる前置きが不要になっただけでも、地味に大きい。
5. FDEとSES・テクニカルサポートの違い
「顧客先に出ていくエンジニア」と聞くと、SESやテクニカルサポートと混同されがちです。ここは線を引いておきます。
SES は、時間を売るモデル。稼働時間がそのまま収益に直結します。 FDE は違います。プロダクトをパッケージで売り、かけた時間を圧縮するほど利益が出る。つまり「効率×品質」が成果。時間を多く使うことが価値ではなく、少ない時間で大きな成果を出すことが価値——インセンティブの向きが正反対です。
テクニカルサポート は、問い合わせに受動的に対応する役割が中心。 FDE は能動的です。顧客のビジネス課題を起点に、プロセス設計から開発まで一気通貫で担う。待つのではなく、踏み込む。
まとめ
職種のリネームは、「名前を変えるだけ」の作業ではありません。チームのアイデンティティを再定義する行為です。
名前と実態のズレは、採用のミスマッチを生み、社内の認知をゆがめ、メンバーのアイデンティティを揺らがせます。逆に、正しい名前はそれらを静かに整えてくれる。
名前が定まったことで、次のアクションも明確になりました。KPIの言語化、等級ごとの役割定義、オンボーディング設計——「FDEとして何ができたら一人前か」を言葉にする作業が、いま進んでいます。
名前を変えたのは、ゴールではなくスタートライン。ここからが本番です。
FDEに興味がある方はこちら 👉 募集要項
