“曖昧な現状”を“解決可能な問い”にする変革先導者
Forward Deployed Engineer、略してFDE。昨今注目を集めているこの言葉を初めて耳にしたときには、「顧客対応もできるエンジニアのことだな」と理解する人も多いかもしれません。
そもそも、Forward Deployed Engineer という言葉は、「Forward（前線＝顧客先）」に「Deployed（配置された）」「Engineer（エンジニア、技術者）」、という意味ですから、客先で活躍するエンジニアのことだと理解するのは当然のことでしょう。
たしかに、FDEは現場に入って顧客と話し、その課題を理解する役割を担います。また、必要であればコードも書き、プロトタイプを作り、既存システムと繋ぎ、新しい仕組みを導入するための地ならしをします。
しかしながら、FDEは、単なる「顧客の近くで働くエンジニア」でもなければ、「技術に明るい顧客対応者」でもありません。FDEとは、顧客の現場にある未整理の課題を、技術によって解決可能な形に変換する役割です。
つまり、FDEは「解決する人」であるよりも前に、「問題を発見し、課題として明確化する人」であるべきなのです。多くの場合、現場の問題は、最初から解けるような分かりやすい形にはなっていません。何が問題なのか、どこから手を付けるべきなのか、が曖昧な状態になっているものです。
そのため、
- 何が起こっているのか
- 誰が困っているのか
- なぜ、その状態になっているのか
- それは業務の問題なのか、システムの問題なのか（どこで切り分けられるのか）
- その中で、システムによって解消すべきことはなんなのか（システム以外の解決策で良いものはあるのか）
こうした問いを顧客に投げかける必要があります。こうした問いを投げかけ、また、顧客と一緒に問題・課題を定義し、共に解決策を模索するのがFDEの役割です。
要件を抽出することが最初の一歩
従来のソフトウェア開発においては、あらかじめ要件が存在していました。正確に言えば、要件定義フェーズが存在し、業務要件が明らかにされ、それを実現するためのシステム要件が明確になります。その要件に従って仕様を固め、仕様通りに実装するという分業可能な複数のステップで構成されていたわけです。
もちろん、そうはいっても、実際には、事前に詰め切れていないことや開発中に仕様変更が発生するなどの問題は起こっていたわけですが、それでも「何を作るか」がある程度定まってから、エンジニアが本格的に動くという前提がありました。
しかし、現在の現場では、この前提は完全に崩れ去っています。
何かを作りたい、新しい何かを作ろうというタイミングでは、残念ながら「まだ、要件が存在していない」のです。
業務というものはExcelやSpreadsheet、Slack、メール、口頭確認、属人的な判断、古い基幹システム、手作業の運用によって複雑に繋がっています。
経営・マネジメントは効率化やAI活用による業務の高度化・効率化を求めます。
一方、現場には、変えたいが変えられない事情があります。担当者ごとに眠っている暗黙知もあります。例外処理もあります。表向きの業務フローと、実際に回っている業務フローが違うこともあります。
この状態で、「要件を出してください」と口を開けて待っていても、いいシステムは作れません。
こちら（つまり開発側）から要件を探しに行く、つまり、現場を観察し、対話し、試作し、それに対する反応を見ていくことで、少しずつ形にしていく姿勢が求められます。FDEは、まさにこの「要件になる前の状態」を扱います。
FDEは「変換する」仕事
FDEを「ビジネスと技術の橋渡し役」という風に表現する人もいます。この表現は便利で分かりやすいと思うのですが、単に「橋渡しする」という表現にしてしまうと、その役割の本当の難しさが伝わりにくいように感じます。
あるいは、「顧客の発言を技術者向けに翻訳して伝える」、あるいは、「技術的な制約を顧客に説明する」という「通訳」の仕事という表現でも、少し表層的になってしまうかもしれません。それだけでは、FDEの役割としては不十分なのです。
先ほどもお伝えした通り、FDEは、現場の曖昧な課題を観察し、業務の流れを分解し、どこに技術を差し込むべきかを見極めなければなりません。そして、その上で、小さく動くものを作ります。実際に動くものを現場に投入し、それがどのように使われるのかを確認します。使われないのであれば、なぜ使われないのかを考えます。
便利な機能なのに実際には使われないのならば、そこには別の理由があるのではないか？と考えることになります。画面設計が悪いのかもしれません。操作性に問題があるのかもしれません。権限設計・設定が実態に即していないのかもしれません。場合によっては、その業務を変えるぞ、という意思決定が行われていない勇み足の変革だったのかもしれません。
このような観察を行うにあたっては、FDEがみるべきものは、コードだけでは足りません。FDEは「現場の状況」「組織の状況」を理解しなければならないのです。
コンソール画面から目を離し、現実社会に目を向ける
FDEは、コードだけではなく「周囲の状況」を取り扱う必要がある。
この点が、通常のソフトウェアエンジニアとの最も大きな違いだと言えるでしょう。
もちろん、FDEにも高い技術力は必要です。コードを書けないFDEは、そもそもエンジニアなのか？という話になるわけですが、単にコーディングができるというだけではやはり不十分で、API、データ連携、認証、インフラ、既存システムとの接続、セキュリティ、保守性。そうした技術的要素を理解し、適切に判断することが求められます。
そして、さらにもう一段「外側」に踏み出していく必要があります。すなわち、
- 誰が意思決定者なのか。
- 現場のどの作業が本当のボトルネックなのか。
- どの機能なら最初に使ってもらえるのか。
- どこまで作れば価値検証ができるのか。
- どの部分を作り込み、どの部分を一時的に割り切るのか。
- 個別顧客のための対応を、どこでプロダクトの学習に変えるのか。
こうした問いを持ちながら実装するところに、FDEの「新しさ」があると言えるでしょう。
後編へ続く
