生粋のFDEとは何か。20数年前の炎上プロジェクトで学んだこと

最近、FDE(Forward Deployed Engineer)という言葉が、やっと流行ってきました。

エンジニアが顧客の現場に入って、その場で設計して、作って、運用まで見る。そういう働き方のことです。

僕はこのサイトのあちこちで「生粋のFDE」と名乗っています。

生粋とは何なのか。少し昔の話をします。

2人で始めたプロジェクト

20数年前、あるプロジェクトで、最初は僕と部下の2人で現場の方々と一緒に進めていました。

要件定義から開発、そして保守運用まで。

現場の人と話して、決めて、作って、直す。それを2人で回していました。

そこから話が大きくなりました。

他部門を巻き込む一大プロジェクトが発足し、全体で数十億円の規模になり、人員が大量に入ってきました。

僕はそれまでやってきた部分のプロジェクトリーダーになりました。

短い期間で全体を作り直すので、開発者も大量に必要になりました。

そして、全体が炎上しました。

いろんなレベルの開発者が集められて、統制が取れない。二度手間も多い。とにかく大変でした。

そこで得た知見

システム開発は、可能な限り少人数のほうがいい。

これがあのプロジェクトで得た知見です。

そして、それが僕には合っていました。

その後、それを証明するために、数人でまあまあな規模の製品を作り上げました。

何が言いたいかというと、システム開発はできる限り少人数でやったほうがうまくいく、ということです。

現場に足を運び、その場で設計する

もう一つ、僕にはアジャイル開発が合っていました。

現場に足を運ぶ。その場で設計する。帰って自分で作る。

修正も、現場の人と話しながら直して、ビルドして、また感想をもらう。

そうやって、自分の開発スタイルを確立していきました。

要件定義書を書いて、承認をもらって、開発チームに渡して、数か月後に納品する。

そのやり方とは、最初から違うところにいました。

AIで変わったのは、実装の速さだけ

現代はAIのおかげで実装のコストが低くなりました。

僕の実感は、「ただ実装が速くなっただけ」です。

なので、現代でいうFDEは、僕が昔からやっていることと何ら変わらないなと思っています。

現場に行く。その場で設計する。自分で作る。現場の人と話しながら直す。

このサイクルは20年以上前と同じです。

変わったのは、実装のスピードや、データ化といった付帯作業がすごく速くなったこと。

それだけです。

だから「生粋」

FDEという名前がつく前から、このやり方しかしてこなかった。

流行ったから始めたのではなく、炎上の中で身につけて、証明して、20年以上続けてきた。

それが、僕が「生粋のFDE」と名乗る理由です。