自社製品がなくても、FDE はできるのか？
最近、ずっと考えていることがある。自社製品を持たない会社にも、本当の意味での FDE は成り立つのだろうか。
私の答えは「成り立つ。ただし、プロダクト企業よりも条件は厳しいかもしれない」だ。
「顧客の課題から出発する」と言うだけでは足りない。従来のコンサルティング会社や SIer、受託開発チームも同じことを言える。顧客ごとの課題が、毎回個別に立ち上げ、個別に開発し、個別に保守するプロジェクトになるのなら、FDE という名前に替えても仕事の性質は変わらない。
FDE が本当に特別なのは、エンジニアが顧客の現場に入ることだけではない。現場でのデリバリーが、次に問題を解くときの組織のやり方を変えていくことにある。
プロダクト企業の FDE には、明らかな強みがある。使い慣れ、磨き込まれた一連の機能が、すでに手元にあることだ。権限管理、データ接続、モデルの呼び出し、デプロイ、モニタリングといった厄介な部分は、自社プラットフォームですでに大半が解決されているかもしれない。FDE は土台からつくり始める必要がなく、その顧客に本当に固有の部分へ時間を使える。
SIer も、各ベンダーのプラットフォームを利用して同じような機能を得られる。だが、それはかえって FDE に高い能力を求める。それぞれのプラットフォームに何ができるかだけでなく、限界はどこにあるのか、いつどれを選ぶべきか、どう組み合わせるか、そして、どれも選ぶべきでないのはいつかまで理解しなければならない。
しかし、プロダクトには引力もある。
顧客が「営業効率が低い」と訴えていても、調べてみれば、原因は承認プロセスが長すぎることかもしれない。CRM のデータが乱れていることかもしれないし、二つのシステムをつなぐ、ごく普通の同期コードが欠けているだけかもしれない。AI が役立つとは限らず、まして Agent が役立つとは限らない。
ところが FDE が Agent の会社から来ていると、いつの間にか問いが「自社の Agent でどう解決するか」に変わりやすい。
危険なのは、エンジニアがハンマーを持っていることではない。どのエンジニアにも、使い慣れたツールや技術上の好みはある。本当に危険なのは、組織がハンマーを売るという目的を課題の診断に紛れ込ませ、本来は開かれていた問いから、調査を始める前に一種類の答えしか残らなくなることだ。
自社製品がこの顧客に合わないとき、FDE にはそれを手放す能力があるか。そして組織から、その許可を与えられているか。
答えが「ない」なら、その人が顧客の課題に対して負える責任は、実のところかなり限られている。むしろ、高い能力を持つプロダクト導入担当者に近い。もちろん、その役割にも価値はある。ただ、私が考える FDE との間にはまだ距離がある。
とはいえ、反対に「完全に中立な技術選定」を追い求めるのも現実的ではない。
プロダクトによる制約がなければ、理論上の解空間は確かに広くなる。プロセスを変えてもよいし、コードを書いても、SaaS を組み合わせても、さまざまなモデルやオープンソースのコンポーネントを選んでもよい。だが、解空間が広いからといって、判断が自動的によくなるわけではない。別の見慣れた結末に至ることもある。どの課題にも、個別のカスタムソリューションをつくる価値があると考えてしまうことだ。
最初の顧客で一度つくり、次の顧客では別のメンバーがまた一からつくる。プロジェクトは納品され、売上は伸びても、次の同種の課題を組織が解くコストは下がらない。知見はあるエンジニアの頭の中にとどまり、コードは顧客のリポジトリに閉じ込められ、プロジェクトが増えるたびに保守の負担も増えていく。
この状態では、やはり FDE よりもプロジェクト型のサービスに近い。
使うほどシステムがよくなることは、FDE が生み出すべき結果ではあるが、それだけで FDE を定義するには足りない。優れたプロダクトチームやプラットフォームチームもシステムを継続的に改善できるし、コンサルティング会社も手法やテンプレート、コンポーネントを蓄積できる。さらに厄介なのは、一つのアーキテクチャによって、あらゆる課題を同じソリューションへ押し込む作業ばかりが効率化されることもある点だ。複利は能力を増幅するが、判断の誤りも増幅する。
FDE がより特別なのは、二つのフィードバックループが同時に存在することだ。
一つ目は、顧客の現場におけるループだ。FDE が受け取るのは、整理された要件ではなく、「効率が悪すぎる」「これは使いにくい」「AI で何とかできないか」といった曖昧な不満であることが多い。その言葉を検証可能な問いに戻し、変えるべきプロセス、書くべきソフトウェア、やるべきでないことを見極める。そして解決策を実際の環境に入れ、使われ方を見ながら修正を重ねる。
二つ目は、組織学習のループだ。一度のデリバリーが終わったら、現場で検証された知見を顧客プロジェクトから抽出し、次のデリバリーに持ち込み、それがなお有効かを確かめる必要がある。
蓄積されるものが、すぐに完成したプロダクトになるとは限らない。権限モデル、データインターフェースの契約、再利用できるコンポーネント、一連の評価ケース、あるいは複数の現場で検証されたアーキテクチャ上の判断にすぎないこともある。
アーキテクチャは、こうした学習を受け止める一つの方法ではあるが、複利を生む唯一の源ではない。局所的でしかない要件もあり、無理にプラットフォームへ押し込めばプロダクトを汚すだけだ。コードを再利用できないプロジェクトでも、評価手法や失敗パターン、「いつ、やるべきでないか」という判断は残せる。何がその顧客だけの特殊事情で、何がすでに繰り返し現れ、何がプラットフォームに欠けている汎用機能を示しているのか。それを見分けることこそ難しい。
自社製品を持たない会社にとって、二つ目のループはとりわけ重要だ。それだけでチームが FDE であると証明はできないが、少なくともプロジェクトのたびに同じ地点からやり直してはいないと示せる。ただし、プロジェクト間に実際に移転可能な部分があることが前提になる。毎回まったく異なる課題に向き合うのなら、いわゆる複利は、抽象的な方法論だけになりやすい。
Platform–Delivery Flywheel、つまり「プラットフォームとデリバリーのフライホイール」が表すのは、FDE という役割の定義ではなく、二つのループがともに働いた結果だ。似た課題に向き合うとき、次のデリバリーはより速く、より安定したものになるか。少なくとも、未知の要素を減らせるか。
これにはエンジニアリング能力だけでは足りない。組織は FDE に十分な技術上の意思決定権を与え、さらに、現場の知見を顧客プロジェクトから抽出する責任を誰かが担わなければならない。そうでなければ、いわゆる「学習」は耳あたりのよい言葉にすぎず、プロジェクトが終わっても何も変わらない。
この観点から見ると、プロダクトと FDE の関係は、単純にどちらが先かで決まるものではない。
先にプロダクトをつくり、FDE がそれを複雑な顧客環境へ持ち込む会社もある。現場で明らかになった課題は、またプロダクトの境界を変えていく。
一方、開かれた問いから始め、何度ものデリバリーを通じて共有コンポーネントやプラットフォームの機能を徐々に育て、最後にプロダクトへ至るチームもある。
どちらの道も成り立つ。プロダクトと FDE を本当につないでいるのは、現場の知見が組織へ還流するかどうかであり、会社が最初から販売できるプロダクトを持っているかどうかではない。
デプロイのたびにエンジニアリング能力を消費するだけなら、FDE はやがて高価な受託開発へと退化する。すべての課題で自社製品の有用性を証明しなければならないなら、今度はデリバリー能力を持った営業へと退化する。
ハンマーそのものが問題なのではない。本当の試練は、目の前にあるものは釘ではないと判断する資格があるか。そしてハンマーを置いたあと、次に臨むときには今回よりも力をつけているかどうかだ。