良く聴き、良く訊き、良く効け。そして作れ。
前編は、FDEとは、「変革先導者」である、というお話をしました。今回は、そのために求められる「ふるまい（ビヘイビア）」について考えていきましょう。
FDEは、観察者である。｜良く聴こう
まず、FDEは、良き観察者である必要があります。Forward Deployed であることの最大の意味は、これであると言っても過言ではないと思います。
顧客の現場に赴き、顧客が何を考えていて、顧客が何を欲しているのかを、観察から導き出します。そのためには、顧客の話していることを、しっかりと聴く姿勢「傾聴」が求められます。
しかし、単に「言われたとおりに理解する」ということでは足りません。顧客が「この機能がほしい」と言ったとき、FDEはその言葉を丸飲みにはしません。
- なぜその機能が必要なのか。
- 今は何で代替しているのか。
- その作業で誰が困っているのか。
- その困りごとは一時的なものなのか、構造的なものなのか。
こうした観点で考えます。
FDEは、質問者である。｜良く訊こう
同時に、FDEは、良き質問者であらねばなりません。
相手の言ったことをそのまま受け取ってはいけませんが、それよりも、勝手な解釈で物事を進めることの方が害悪です。
こういうことではないか。もしかしたら、こういう観点が抜けているのではないか。自分の中に生じた視点や疑問を、相手にぶつけて確認する必要があります。いわゆる仮説思考ですね。
自分の理解があっているかどうかを確認する（仮説を検証する）と共に、相手から、真意を引き出すことが大切です。表面的な言葉を信じないということは、深層に深く切り込む質問を投げかけるということなのです。
FDEは、考察者である。｜良く効こう
そうして、顧客が実際に困っていること、あるいは、日々の業務で起こっていることを白日の下に照らし出した上で、業務分解を行います。
具体的には、顧客の業務を、入力、判断、処理、例外、承認、出力に分解します。
- 誰が、いつ、何を見て、何を決めているのか。
- どの情報が不足しているのか。
- どの作業が二重化しているのか。
- どこで人間の判断が必要で、どこは機械に任せられるのか。
FDEは、現場の流れを、仕組みとして実装可能な粒度まで解きほぐしていく必要があります。
この際に「どのプロセスを、どのように変化させたいのか」という観点で、良く効く打ち手を考察するのです。
FDEは、試行者である。｜最初からパーフェクトを求めない
「Done is better than perfect.（完璧を目指すより、まず終わらせろ）」という名言がありますが、FDEの行動原理もそうあるべきです。すべてを完全に理解してから作りはじめて、ファーストリリースから完璧なものを作ろうとするのは、現実的ではありません。
むしろ、すべてを理解しきることはできない、という前提に立つべきです。要件が完全に固まるのは、もっとずっと先のことだと捉えます。
そうした前提を持った上で、「ここを自動化すれば作業時間が減るのではないか」「このダッシュボードがあれば意思決定が早くなるのではないか」「このデータ連携があれば二重入力が消えるのではないか」といったような「効果的な“解決策”の仮説」を置きます。
ここが、FDEをFDEたらしめるポイントなのですが、解決策の仮説を、コードで試します。
聴いたこと、訊いたことを、議事録や提案書にまとめて終わりにしない。
実際に、動くものを作り、たとえ粗くても、現場が触れる形にする。
これが、FDEの価値です。
実際に触れるものが手元に届いた瞬間、議論の質が変わります。
抽象的な要望が、具体的な違和感に変わるからです。
「これは便利だが、実際にはこの順番では使わない」
「この項目は見たいが、毎回入力はしたくない」
「この判断は自動化できそうだが、最後は人が確認したい」
こうした反応は、資料だけでは出てきません。動くものを現場に提供し、試してもらうことで、初めて出てきます。
つまりFDEは、観察→質問→考察→試行というループを回す人なのです。
FDEとAIコーディングとの相性の良さ
ここまで読んだ方の多くは「それ、理想的だけど、実現するのは難しくない？」とか、あるいは「そういうことに取り組んでいた人は、昔からいるんじゃない？」などといった疑問を感じることでしょう。
そうなんです。そう思いますよね。しかし、これこそが「なぜ、いま、FDEが注目されているのか」という問いにつながるポイントです。そう、生成AIの台頭です。
生成AIによって、コードを書く速度は爆発的に上がりました。プロトタイプも作りやすくなりました。以前なら数日かかったものが、数時間で形になることもあります。これは大きな変化です。
しかし、だからといってエンジニアの価値が単純に下がるわけではありません。むしろ、「何を作るべきか」「どのように実現するか」を見極めることができれば、その価値は大きく増加します。
AIは実装を速くします。
しかし、現場の曖昧な課題を勝手に構造化してはくれません。
- どの業務にAIを入れるべきか。
- どの判断は人間に残すべきか。
- どのデータを使ってよいのか。
- AIの出力を誰が確認するのか。
- 誤りが起きたとき、業務上どう扱うのか。
- 既存の運用をどこまで変えるのか。
これらは技術だけの問いではありません。業務、組織、責任、信頼の問いです。FDEが、コードだけでなく、その周辺状況に歩み出す存在であるという話を思い出してください。FDEは、まさに、現実社会とソフトウェアをつなぐ接点になるのです。
つまり、AI時代のFDEは、単にAIを使って速く作る人ではありません。AIを、現場の業務に接続する人であるべきです。
FDEに、万能の夢を見るな。
しかしながら、FDEを美化しすぎてもいけません。便利なオールラウンダーだと捉えるのは危険です。
この仕事は、非常に消耗しやすい仕事です。顧客の近くにいるため、要望を直接受けます。技術も見ます。業務も見ます。導入も見ます。短期的な成果も求められます。その一方で、長期的にはプロダクトとしての一貫性や保守性も考えなければなりません。
そうした広範な守備範囲の中で、「とりあえずFDEに頼めば何とかなる」という状態は、大きな問題につながります。
もちろん、顧客にとっては素晴らしいことでしょう。コミュニケーションパスが1本になり、しかも、知りたいことがすぐに返ってくるわけですから。
しかし、「なんでも引き受ける役割」になると、FDEは個別対応の水底に深く沈んでいきます。顧客ごとの特注開発が増え、プロダクトへの還元が弱くなり、本人の負荷だけが高まります。そうなると、FDEは価値を生むどころか、組織の歪みを吸収する緩衝材になり、そして近い将来に確実に破綻します。
FDEを活かす組織、が必要
FDEが活躍するためには、組織設計が重要になります。
- FDEが現場で得た知見をプロダクトに戻す仕組み。
- 個別対応と標準機能化を切り分ける判断軸。
- 開発チームとの接続。
- 成果指標の設計。
- 顧客価値とプロダクト価値を同時に見るための場。
FDEを活かすためには、FDEを「孤独なオールラウンダー」にしないことです。むしろ、現場で得てきた複雑に絡み合った情報、それでいて、他では手に入れられない貴重な情報を、組織全体の学習に繋ぐ役割を担わせなければいけません。
組織のバックアップを受けて、最前線で戦え
戦争において、兵站（ロジスティクス）が勝敗の鍵を握る、というのはよく言われるお話です。FDEにとっても同様です。
FDEを便利に消費するようでは、（たとえ顧客にとっては便利で有用であっても）持続性が低い組織となってしまいます。
おそらくこれからの時代に問われるのは、FDEという肩書きそのものではありません。
FDE的な思考回路を、どれだけ多くの人が持てるかです。
つまり、
- 仕様を待つのではなく、現場に問いを立てること。
- 要望をそのまま作るのではなく、その背後の構造を見ること。
- 完璧な理解を待つのではなく、小さく作って反応を見ること。
- 個別の対応を、次のプロダクト学習へ変えること。
FDEは、職種名である前に、一つの態度、ふるまい、ビヘイビアとして取り扱われるべきです。
不確実な現場に近づき、技術で試し、実際に活用されるところまで踏み込んでいく行動様式です。
この態度は、AI時代においてますます重要になるはずです。
なぜなら、作る速度が上がるほど、「何を、どこに、なぜ作るのか」がより鋭く問われるようになるのですから。
