FDEの1日はどんな流れ？現場のリアルな働き方
- 午前現場の担当者と対話し、仕様ではなく真の課題を定義する（課題のすり合わせ）。
- 午後午前に定義した課題を、ワークフローの設計・実装・テストで動く形へ落とし込む。
- 夕方エンドユーザーと協働で検証・改善し、現場で使われる状態を目指す。
- 「作る」と「届ける」を短いサイクルで往復する
- 課題の定義から現場での検証まで一貫して担う
- 顧客先訪問25〜50%（Anthropic求人）、対面と遠隔のハイブリッド
- デスクに籠って作り続け、自席で完結しやすい
- 仕様書を受け取って実装する立場になりやすい
- 顧客現場との距離が遠く、デスクワーク中心
FDEの1日はどんな流れ？
顧客との対話・設計・実装・現場での検証が1日の中で往復するのがFDEの働き方です。 デスクに籠って作り続ける通常の開発とは違い、FDE（Forward Deployed Engineer）は「作る」と「届ける」を短いサイクルで行き来します。1本のタスクを黙々と仕上げるのではなく、現場での気づきをその日のうちに設計へ戻すのが基本の動き方です。
以下は、Palantirが公開するFDEの実務内容をもとに再構成した代表的な1日です（実際の配分は案件で変わります）。
| 時間帯 | やること | ポイント |
|---|---|---|
| 午前 | 顧客と課題のすり合わせ | 真の課題を定義する |
| 午後 | ワークフローの設計・実装・テスト | 課題を動く形にする |
| 夕方 | エンドユーザーと検証・改善 | 現場で使われる状態へ |
「作る」と「届ける」を往復するとは？
FDEは実装だけで完結せず、課題の定義から現場での検証までを一貫して担うのが特徴です。午前に定義した課題を午後に動く形へ落とし込み、夕方にエンドユーザーへ届けて反応を確かめる。この一連の流れが1日の中で閉じているため、「作る側」と「使う側」の間に生じがちなズレを、翌週ではなくその日のうちに小さく直せます。作って終わりではなく、使われるところまでを自分の仕事の範囲として引き受けるのがFDEの立ち位置です。
1日の配分は案件でどう変わる？
午前・午後・夕方の比重は固定ではなく、案件のフェーズによって伸縮します。課題がまだ曖昧な立ち上げ期は午前の対話が長くなり、実装が中心の時期は午後の設計・テストが厚くなります。表に示した時間割はあくまで代表例であり、Palantirの公開情報を踏まえて再構成した目安です。実際の1日は、顧客のどのフェーズに立ち会っているかで形を変えると考えるのが実態に近い理解です。
午前は何をする？（課題のすり合わせ）
午前は現場の担当者と対話し、いま何が本当の課題かを見極める時間です。 FDEの仕事は与えられた仕様を作ることではなく、課題そのものを定義するところから始まります。ここで曖昧さを解きほぐせるかどうかが、その日の成果を大きく左右します。
なぜ仕様ではなく課題から始めるのか？
FDEは仕様書を受け取る立場ではなく、課題の輪郭を顧客と一緒に描くところから関わるからです。現場が「これが欲しい」と語る要望は、多くの場合その奥にある本当の困りごとの表れです。表面の要望をそのまま実装すると、動くけれど使われないものが生まれかねません。午前の対話でその奥の課題まで掘り下げるからこそ、午後の設計が的を外さずに済みます。課題定義を他人任せにしないことが、FDEの午前の核心です。
曖昧さを解きほぐすと何が変わる？
課題の曖昧さを午前のうちに減らせるほど、午後以降の手戻りが小さくなります。何を作るべきかが定まっていないまま実装に入ると、夕方の検証で方向性ごと覆る可能性があります。逆に、現場の担当者と課題の言葉をそろえておけば、設計・実装・検証が同じゴールに向かって進みます。午前の対話は単なる打ち合わせではなく、その日1日の精度を決める投資だと捉えるのが妥当です。
午後は何をする？（設計と実装）
午後は午前に定義した課題を、実際に動く形へ落とし込む時間です。 Palantirの公開情報では、FDEの日常は「ワークフローの設計・実装・テスト」や「プラットフォーム（例：Gotham）の設定による新機能の解放」と説明されています（Palantir公式ブログ）。
Palantirはどんな実装を挙げているか？
Palantirは、FDEの手を動かす仕事としてワークフローの設計・実装・テストと、Gothamのようなプラットフォーム設定による新機能の解放を挙げています。ここで重要なのは、ゼロからすべてを書き起こすとは限らない点です。既存のプラットフォームを設定して価値を引き出す作業も、FDEの実装の一部として位置づけられています。作るという言葉には、コードを書くことと、基盤を組み合わせて使える機能に仕立てることの両方が含まれます。
午前の課題定義がなぜ効くのか？
午後の設計・実装が空回りしないのは、午前に課題が定義されているからです。何を解くべきかが明確なほど、設計の選択に迷いが減り、テストで確かめるべき観点もはっきりします。午前の対話と午後の実装は切り離された工程ではなく、同じ課題を別の角度から進める連続した作業です。だからこそFDEは、対話と実装のどちらか一方に偏らず、両方を自分の担当範囲として往復します。
夕方は何をする？（現場で検証）
夕方は作ったものをエンドユーザーと一緒に試し、フィードバックを得て改善する時間です。 Palantirは「we actually implement the solution in collaboration with end-users（エンドユーザーと協働して実際に解決策を実装する）」と、その関与の深さを表現しています（同ブログ）。
エンドユーザーとの協働とは？
エンドユーザーとの協働とは、解決策を渡して終わりにせず、実際に使う人と並んで作り込むことです。Palantirの表現にある通り、FDEは解決策を「協働して実装する」立場に立ちます。現場で本当に使われる状態を目指すには、開発者の想定だけでなく、使う人の手の動きや業務の流れに合わせる必要があります。夕方の検証は、作ったものが現場に馴染むかを確かめる最後の仕上げの場です。
フィードバックをどう改善に回すか？
夕方に得たフィードバックは、翌日以降の午前の課題定義や午後の設計へと戻していきます。現場で試して見えた不足やズレは、次のサイクルで解くべき新しい課題になります。これがFDEの1日が単なる時間割ではなく、往復するサイクルである理由です。使われる状態に近づけるための改善が、また次の対話と実装を生み、日々の仕事が現場に沿って更新され続けます。
通常の開発職と何が違う？
最大の違いは、顧客現場との距離です。 FDEは自席で完結せず現場に入り込むため、出張の比重も高くなります。AnthropicのFDE求人では顧客先訪問25〜50%（Anthropic公式）、OpenAIの東京求人では週3出社と国内出張が想定されています（OpenAI公式）。
出張の比重はどれくらい？
FDEは案件によって顧客先へ足を運ぶ比重が大きく、通常の開発職より現場滞在が多い傾向があります。AnthropicのFDE求人では顧客先訪問が25〜50%程度と示され、OpenAIの東京求人では週3出社と国内出張が想定されています。数字は募集ごとに異なりますが、共通するのは「顧客の現場に入る」ことが前提になっている点です。デスクワーク一辺倒ではないことが、求人情報からも読み取れます。
リモートだけで働けるのか？
完全リモートだけで働くFDEは少数派です。顧客の現場に入り込む性質上、対面と遠隔を組み合わせるハイブリッドが一般的な形になります。実装は遠隔でも進められますが、午前の課題すり合わせや夕方の現場検証は対面の価値が大きい工程です。実務の進め方はFDEの実務、キャリア全体像はFDEのキャリアで解説しています。働き方の実像を、求人と現場の両面から確かめておくとイメージがつかめます。
