FDEの動き方を身につけるには、普通のエンジニアがSESから成果責任へシフトした4つの実践

2026年8月11日 2026年10月3日 16分3秒

「FDE（Forward Deployed Engineer）という職種に興味はあるが、具体的にどうすればその動き方が身につくのか分からない」。「自分はずっとSESや受託開発で仕様書通りに作ってきたが、クライアントのビジネス現場に入り込んで成果を出すエンジニアへステップアップするには何を始めればいいのか」。

前回の記事（FDEとSESの違いとは？工数提供と成果責任、月額単価40万と150万の決定的な境界線）では、FDEとSESの根本的な違いは「工数提供」か「成果責任」かという契約と役割の性質にある、という話をしました。

では、その「成果責任」を果たせるFDE的な動き方は、どうやって身につければよいのでしょうか。

私自身、最初からFDEとして動けていたわけではありません。 Webエンジニアとしてキャリアを始めた当初は、客先常駐のSES現場で「言われたチケットを仕様通りにこなす」ことだけを考えていました。実装は問題なくできても、クライアント組織の稟議の通し方や、情シスの巻き込み方、現場ユーザーの抵抗への対処法などは全く分からず、何度も案件を頓挫させそうになりながら現場で泥臭く学んできました。

先に結論から言うと、FDEの動き方は特殊なビジネスの才能ではなく、「仕事の視点」と「日常の小さな習慣」を少しずつ切り替えることで、誰もが後天的に身につけられる技術です。

この記事では、普通のエンジニアだった私がSESから成果責任のFDEへシフトする過程で「これが決定的な分岐点だった」と確信している4つの実践ステップと、明日から現場で使える具体的な行動チェックリストを全公開します。

この記事の結論（先に3点）

「言われたことをやる」から「言われる前にボトルネックを潰す」へ: 今日のタスクを終わらせる視点から、「このプロジェクトが止まるとしたらどこで止まるか（稟議・情シス・現場定着）」を先回りして検知する視点へ切り替える。
技術会議の後の「雑談5分」で情報格差を埋める: 技術の外側にある「決裁者の懸念」「過去の差し戻し事例」「現場の本音」を質問フレーズで引き出し、プロジェクトの隠れた地雷を事前に把握する。
「小さく職掌をはみ出して巻き取る」経験を積む: 議事録の決裁者向けサマリー化、情シス申請書の下書き作成、操作デモ動画の事前作成など、今の現場にいながらできる「小さな越境」を積み重ねる。

適合する読者と限定事項

この記事が役に立つ人:
- 指示待ちの開発スタイルから脱却し、より上流や顧客のビジネスに近い位置で価値を出したいエンジニア
- 将来的にFDEやフリーランスとして高単価（月額150万円〜）の案件を獲得したい人
- 「実装力はあるのに、なぜかプロジェクト全体がうまく進まない」と現場で悩んでいるテックリード
限定事項:
- 営業やコンサルティングへの職種転換を勧めるものではありません。「コードが書けるエンジニア」という強みを最大限に活かしながら、現場定着までコミットするための実務指南です。

実践1：「言われたことをやる」から「言われる前に潰す」へ

SES的な仕事の進め方では、「確定した要件や指示があって、それを納期通りに正確にこなすこと」が最高の評価基準になります。

しかし、FDE的な動き方の最初の分岐点は、指示が来る前に「次にプロジェクトが止まりそうなボトルネック」を自分で見つけて先回りして潰すことです。

作業単位ではなく「障害単位」でプロジェクトを見る

このシフトを起こすために必要なのは、タスクの捉え方を変えることです。

従来の視点: 「今週のスプリントで、このAPIと画面コンポーネントの実装を終わらせる」
FDEの視点: 「この機能が予定通り実装できたとして、本番リリースまでに何が原因で止まるか？」

日本企業のAI導入やDXプロジェクトにおいて、プロジェクトが止まる原因の9割はコードの外側にあります。具体的には以下の「3大ボトルネック」です。

flowchart LR
    A["1. 稟議・予算の壁\n（決裁者が納得せず承認が止まる）"] --> B["2. 情シス・セキュリティの壁\n（規約・データ保護で審査が止まる）"]
    B --> C["3. 現場定着の壁\n（業務が面倒で誰も使わず止まる）"]

現場で使える「事前検知チェックリスト（5項目）」

スプリントの開始時や設計フェーズにおいて、私は常に以下の5つの問いを自分に投げかけています。

データアクセス: 「このAIモデルに食わせるデータは、本番環境で誰の承認を得れば取得できるか？（申請に何週間かかるか）」
セキュリティ規約: 「クライアントの情シス規約上、外部API（Azure OpenAIやAnthropic等）へのデータ送信は許可されているか？」
既存システム連携: 「認証基盤（SAML / Okta / Azure AD等）との連携に必要な設定情報は、誰が持っているか？」
決裁フロー: 「このPoCから本番開発へ移行する際、どの会議体でいくらの予算承認が必要になるか？」
現場の運用負荷: 「このツールを使うことで、現場担当者の日々の入力工数は本当に減るのか？（二重入力になっていないか）」

指示を待つエンジニアは、機能が完成してから「情シスの申請が通っていないのでデプロイできません」と報告します。 FDEは、開発初週の時点で情シス窓口にコンタクトを取り、申請書のドラフトを投げて審査期間を前倒しします。この「先回り」ができるかどうかが、成果責任の第一歩です。

具体的なFDEの1週間のスケジュールや動き方は、FDEの仕事内容と1週間のスケジュールでも詳しく解説しています。

実践2：技術以外の会話に混ざる（情報格差を埋める立ち回り）

エンジニアとして現場に入ると、意識しなくても技術の会話（アーキテクチャ、フレームワーク、ライブラリの選定）は自然と耳に入ってきます。

しかし、「稟議が今どの段階にあるか」「事業部長が何を懸念しているか」「現場のキーマンがなぜ協力的でないのか」といった情報は、意識して取りに行かないと絶対に耳に入ってきません。

打ち合わせ後の「雑談5分」で本音を引き出す

私がSESからFDEへシフトできた最大のきっかけは、**「会議が終わった直後の5分間、技術以外の会話に混ざる」**ことを習慣にしたことでした。

定例ミーティングのアジェンダが終わった後、オンライン会議からすぐに退出せず、事業部門の担当者や情シスの窓口にちょっとした質問を投げかけるのです。

私が現場で実際に使っている、本音を引き出す3つの質問フレーズを紹介します。

フレーズ1（事業担当者へ）

「今回の機能、来月の役員会で報告されると思いますが、役員の方々から一番突っ込まれそうな懸念点ってどのあたりですかね？」

事業担当者は、上層部への報告に常に不安を抱えています。エンジニア側からこの質問を投げると、「実は『コスト削減効果の根拠を数字で出せ』と突っ込まれそうで……」といった本音が出てきます。これを聞き出せれば、開発者側でアクセスログや自動集計の仕組みを先に仕込み、役員向けの数字をプレゼントすることができます。

フレーズ2（情シス担当者へ）

「御社のセキュリティ審査をスムーズに通したいのですが、過去に他のAI案件や外部ツールが差し戻しになった事例って、どういう理由が多かったですか？」

情シスを「開発を止める敵」とみなすのではなく、「プロジェクトを安全に着地させる味方」として頼る姿勢を示します。過去のNGパターン（例：「個人情報のマスキング基準」「ログの保存期間」）を事前に教えてもらうことで、手戻りを完全にゼロにできます。

フレーズ3（現場オペレーターへ）

「画面の操作イメージを作ってみたんですが、日々の業務の中で『ここを入力するのが一番だるいな』と感じる部分はどこですか？」

現場のユーザーは、仕様書を見てもピンときませんが、「だるい作業」についてはいくらでも話してくれます。そこをピンポイントで自動化することで、リリース初日から「これは本当に助かる！」と熱狂的に使われるツールになります。

日本企業特有の組織の壁や、稟議・情シスの構造については、日本企業でFDEをやって分かった3つの理由でも生々しく記録しています。

実践3：「動くもの」と「稟議で通るもの」の違いを意識する

エンジニアが最も陥りやすい罠が、「技術的に優れた動くもの（プロトタイプ）を作れば、組織の承認は自動的についてくる」という思い込みです。

ハッカソンや個人の受託開発であれば、「動くもの」が正義です。しかし、大企業や中堅企業の組織内では、「技術的に正しく動くもの」と「組織の中で稟議が通るもの」は全く別物です。

決裁者（役員・部長）が本当に見ている3つの視点

デモ画面でどんなに滑らかにLLMが回答を返しても、決裁者の机に書類が載ったとき、彼らが見ているのは以下の3点だけです。

費用対効果（ROI）の説明が社内で通るか: 「このツールに年間数百万円払って、誰のどの作業が何時間減るのか。その浮いた時間は会社の利益にどう跳ね返るのか」。
セキュリティとコンプライアンスの責任境界: 「万が一、顧客情報や社外秘が漏洩したとき、誰がどう責任を取る設計になっているか」。
失敗したときの損害が限定されているか（撤退ライン）: 「もしこのAIが期待通りの精度を出せなかった場合、会社はいくらの損害で即座に撤退できるか」。

成果物を「決裁者の視点」でセルフレビューする

FDEとして動くための訓練として、私は自分が実装した成果物を提出する前に、必ず**「もし自分が決裁者なら、どこを突っ込んでこの起案を却下するか？」**という目でセルフレビューを行っています。

デモを見せるときも、画面の美しさをアピールするのではなく、

「なお、個人情報は送信前に正規表現でマスキングしているため、外部規約にも抵触しません」
「月額のAPI費用は最大でも◯万円でハードリミットを設定しており、予算超過のリスクはありません」といった、決裁者が会議で説明するための武装（エクスキューズ）をセットで添えるのです。

技術のデモに「稟議を通すためのロジック」を1枚添えられるエンジニアは、現場で圧倒的な信頼を獲得します。

実践4：小さく「巻き取る」経験を積む（越境の第一歩）

「FDE的な動き方を身につけたいが、今の現場では要件定義や顧客折衝の権限が与えられていない」と感じる人も多いはずです。

しかし、最初から大きな権限を持つ必要はありません。 自分の職掌（コードを書くこと）の枠を、ほんの1ミリだけ外側へはみ出して「小さく巻き取る」経験を積むことからすべてが始まります。

明日から今の現場でできる4つの「巻き取りアクション」

巻き取りアクション	通常のエンジニアの行動	FDE的な越境行動
① 会議議事録の要約	メモを取るか、聞くだけで終わる	打ち合わせ直後に「決定事項・次回ToDo・残余リスク」を1枚のMarkdownにまとめてSlackに投げる
② 情シスの申請書	「情シスへの申請をお願いします」と顧客に丸投げ	規約を自分で読み込み、申請書の記入欄（システム構成図やデータフロー）を下書きして顧客へ渡す
③ 操作デモ動画の作成	リリースノートのテキストを書いて終わり	Loomや画面録画ツールで「1分でわかる新機能の使い方動画」を撮り、現場Slackに共有する
④ エラー時のFAQ作成	例外処理でエラーログを出して終わり	ユーザーが遭遇しやすいエラーの対処法を1枚のFAQにまとめ、問い合わせ窓口の手間を先回りして減らす

こうした「誰もやりたがらないが、誰かがやらないとプロジェクトが止まる隙間の仕事」を自分から拾いにいく。この小さな巻き取りの積み重ねが、クライアントから「あのエンジニアは、コードを書くだけでなくプロジェクト全体を前に進めてくれる」という評価を生み、やがてFDEとしての大型案件や高単価契約へとつながっていきます。

現代のFDEの強力な武器：Claude CodeなどのAI活用

ここまで読んだ方の中には、「そんなに色々な調整やドキュメント作成まで巻き取っていたら、肝心の実装時間がなくなってしまうのでは？」と不安に思うエンジニアもいるかもしれません。

まさにその通りで、従来の開発環境では「実装」と「組織調整」の両立は極めて過酷でした。

しかし現在、私たちにはClaude Codeをはじめとする自律型AIコーディングツールという強力な武器があります。

実装工数を1/3に削り、組織調整に時間を再投資する

私の会社（Nogawa L.prince合同会社）では、「1人法人1000馬力化計画」として、日々のテスト・品質検査・下書き作成・監視などの定型業務を徹底的にAI社員とスクリプトへ委譲しています（詳細は1人法人1000馬力化計画 AI社員名簿・座席表を参照）。

FDEの実務現場においても、

要件からのボイラープレートコード生成
ユニットテストやリファクタリングの自動化
議事録からのタスク抽出やドキュメント下書き生成などをClaude Codeに任せることで、コード実装にかける時間を従来の1/3に圧縮しています。

そして、AIによって生み出された貴重な時間を、「顧客との対話」「稟議の根回し」「情シスとの調整」「現場オペレーターのフォロー」という、人間にしかできない高付加価値な活動に全力投入する。これこそが、令和の時代にエンジニアが「1000馬力」の成果を叩き出すための最も洗練されたFDEの立ち回りです。

まとめ：FDEの動き方は、今日から現場で始められる

普通のエンジニアがSESから成果責任のFDEへシフトするための4つの実践を振り返ります。

言われる前にボトルネックを潰す: タスク単位ではなく「プロジェクトがどこで止まるか」の視点を持つ。
技術以外の会話に混ざる: 会議後の5分間で「決裁者の懸念」「情シスの本音」「現場の悩み」を拾い上げる。
動くものと稟議で通るものの違いを意識する: 費用対効果・セキュリティ・撤退ラインを成果物に添える。
小さく職掌をはみ出して巻き取る: 議事録要約や申請書ドラフトなど、隙間の仕事を自分から拾う。

FDEになるために、会社を辞めたり、いきなり独立したりする必要はありません。明日出社して、定例会議の後に「何か上層部への報告で懸念点はありませんか？」と一言尋ねてみる。それだけで、あなたのFDEへのシフトはすでに始まっています。

コードが書けるという圧倒的な武器を持ちながら、組織の壁を越境してビジネスを前へ進める。そんな「成果を背負えるエンジニア」への第一歩を、ぜひ今日の現場から踏み出してみてください。

企業のAI導入をFDEとして支援しています。ご相談はサービス紹介ページから。