Skip to content
Published on

個別対応からプラットフォームへ：FDEの成果を製品化する

🇰🇷KO🇺🇸EN🇯🇵JA
필사 모드
Authors

はじめに — 一顧客からすべての顧客へ

先の二つの記事では、フォワードデプロイドエンジニア（FDE）とは何か、そして使い捨てプロトタイプで一顧客をどうアハ体験まで連れて行くかを語りました。この記事では、その次の問いに取り組みます。一顧客のために作った個別対応を、どうやってすべての顧客のためのプラットフォームへ育てるのか?

これはFDE組織が存在する理由であり、最も難しい挑戦です。やり方を誤れば、会社は顧客の数だけ異なるコードの塊を抱えたコンサルティング会社になってしまいます。うまくやれば、現場から汲み上げた洞察が会社の中核製品になります。実際、多くの優れたB2B製品が、まさにこの経路で生まれました。

FDEとプロダクトのフィードバックループ

FDEの本当の価値はコードではなく、情報にあります。FDEは会社のなかで顧客の現実を最も深く知る人です。どんな問題が繰り返されるか、どんなデータが実際に存在するか、顧客が何に感動し何に苛立つか — そのすべてがFDEの頭のなかと指先に積み上がります。

健全な組織では、この情報がプロダクトチームへ流れます。

  • FDE → プロダクト: 「五社の顧客が全員この機能を手で作ってくれと言った。これは製品になるべきだ。」
  • プロダクト → FDE: 「その機能を一般化して作った。次の顧客には個別対応ではなくこれを使ってみてくれ。」

このループが回ると、FDEは毎回ゼロから作る必要が減り、プロダクトは想像ではなく現場の証拠でロードマップを立てます。逆にこのループが切れると、FDEは永遠に同じものを繰り返し作り、プロダクトは実需とかけ離れた機能を築きます。

N人の顧客からパターンを見つける

製品化の出発点はパターン認識です。一顧客の要望はただの要望ですが、複数の顧客から繰り返される要望はシグナルです。

FDEがパターンを捉える感覚は、こんな問いから生まれます。

  • 異なる顧客に同じコードをコピー&ペーストしていないか。
  • 顧客ごとに名前が違うだけで、本質的に同じ流れを作り直していないか。
  • 複数の顧客が言い方は違うが実は同じ問題にぶつかっていないか。

三つ目が特に重要です。顧客Aは「契約書のリスク点検」を望み、顧客Bは「ベンダー文書のレビュー」を望むと言いますが、下を見れば、どちらも「長い文書から特定の条件を探して印をつける」という同じ骨格かもしれません。表面の語彙ではなく下の構造を見る目、それが製品化の第一歩です。

設定と抽象化として抜き出す

パターンを見つけたら、次はそのパターンを変わる部分と変わらない部分に分けることです。変わらない部分はエンジン（製品）になり、変わる部分は設定（config）に抜けます。

契約書の条項抽出を例にとりましょう。顧客ごとに違うのは、おおよそ「どの条項を探すか」「どのカテゴリに分類するか」「どの形式で書き出すか」くらいです。抽出するという行為そのもの、モデルを呼んで結果をパースする骨格はすべて同じです。

だから個別対応のコードをこう変えます。顧客ごとの違いをコードではなく宣言的な設定へ押し出します。

# customers/acme.yaml — 顧客ごとの設定（変わる部分）
customer: acme-corp
clause_types:
  - indemnification
  - termination
  - liability
output_format: csv
risk_threshold: 0.7
notify_channel: "acme-legal-slack"

# customers/globex.yaml — 別の顧客、同じエンジン
customer: globex-inc
clause_types:
  - data_privacy
  - auto_renewal
output_format: json
risk_threshold: 0.5
notify_channel: "globex-procurement-email"

エンジンは、この設定を読んで動く、顧客に依存しないひとつのコードです。

# engine.py — すべての顧客が共有するエンジン（変わらない部分）
def run_extraction(config: dict, documents: list[str]) -> list[dict]:
    results = []
    for doc in documents:
        clauses = extract_clauses(doc, config["clause_types"])
        flagged = [c for c in clauses if c["risk"] >= config["risk_threshold"]]
        results.extend(flagged)
    export(results, fmt=config["output_format"])
    notify(config["notify_channel"], summary=summarize(results))
    return results

これで新しい顧客が来ても、コードを新しく書くのではなくYAMLを一枚追加します。個別対応が製品の設定へと昇格したのです。これが「個別対応からプラットフォームへ」の具体的な姿です。

三の法則：いつ一般化すべきでないか

ここで最もよくある間違いは、早すぎる一般化です。最初の顧客の要望を見た瞬間に「これはきっとみんなが欲しがる」と大げさな抽象化を築き始めます。そしてたいてい、その抽象化は間違っています。二番目の顧客は一番目と微妙に違うものを望み、急いで築いた抽象化はかえって足かせになります。

そこで古い知恵があります。**三の法則（rule of three）**です。

  • 一度目: ただ作る。この顧客だけのために、個別対応で。
  • 二度目: 似たものをまた作る。だがまだ一般化しない。代わりに二つの事例の共通点と相違点を観察する。
  • 三度目: 三度目に同じパターンが現れたら、いよいよ抽象化する。三つの実際の事例が手元にあるので、何が本当に共通で何が顧客ごとの変奏なのかを、根拠を持って知っている。

三の法則の核心は、抽象化をデータに基づいて築くという点です。一つの事例から想像で築く抽象化は賭けであり、三つの事例を観察して築く抽象化は設計です。二度コピー&ペーストする程度の重複は、間違った抽象化という大きな負債よりはるかに安いのです。

「重複は間違った抽象化よりはるかに安い。」— この格言は、FDEの製品化の判断で特に重く響きます。

速く作ることと、みんなのために築くことの緊張

FDE組織の中心には、根本的な緊張があります。

  • 一方には目の前の顧客がいます。今四半期に契約を成立させるには、いますぐこの顧客の問題を解かなければなりません。速さがすべてです。
  • 他方には未来のすべての顧客がいます。毎回個別対応で作れば、会社はスケールしません。再利用できる製品を築かなければなりません。

この二つはしばしば衝突します。いまの顧客のための最速の道はハードコードですが、みんなのための最良の道は一般化だからです。成熟したFDEと組織は、この緊張をなくそうとするのではなく、意識的に管理します。

  • まず顧客に勝つ、だが痕跡を残す: 今回は個別対応で速く解きつつ、「これは三度目の類似事例だ」といったシグナルをプロダクトに残します。
  • 一般化はプロダクトの仕事に渡す: FDEが現場で毎回一般化までやろうとすれば、どちらもうまくできません。FDEはパターンを捉えて渡し、プロダクトがそれを製品にします。
  • 一回性と繰り返しを区別する: ある顧客の要求は、本当にその顧客だけのものです。そういうものは一般化せず個別対応のままにするのが正しい。すべてを製品化しようとする欲こそが、製品を壊します。

いつ一般化すべきでないか

三の法則とは別に、最初から一般化が答えではない場合があります。

  • 本当にその顧客だけのものであるとき: 特定の規制、特定のレガシーシステム、特定の組織構造に縛られた要求は、他者に再利用される余地がありません。無理に製品に押し込めば、製品が複雑になるだけです。
  • まだパターンが見えていないとき: 事例が一つだけでは、それがパターンなのか偶然なのかわかりません。待ちます。
  • 中核の価値でないとき: 周辺の些細な便利機能まで全部を一般化する必要はありません。製品の中心の価値に資源を集中します。
  • 一般化のコストが利益を超えるとき: 柔軟な抽象化はタダではありません。保守の負担、複雑さ、そして間違うリスクを一緒に買います。二、三社ならそのままにするほうが良いこともあります。

優れた製品はフォワードデプロイドな仕事から生まれる

このすべての話はひとつの結論に収束します。多くの優れたB2B製品は、机の上の想像ではなく、顧客の現場の繰り返しから生まれた。

パターンはこうです。FDEが複数の顧客で同じ問題を手で解くうちに、その繰り返しのなかから本当の需要を見つけます。その発見が設定と抽象化を経てひとつの機能になり、機能が積み重なって製品になり、製品がセルフサービスになって、ついにFDEなしでも顧客が自分で使えるようになります。すると、FDEは次の未開拓の問題へ移動します。

この好循環こそがFDEモデルの究極の目的です。FDEは自分を不要にする方向へ働きます。今日手でやることが明日の製品機能になり、その機能があるおかげで次の顧客にはもう手が要らなくなる。一顧客を救うことが、数千の顧客のための製品へと育つのです。

おわりに

個別対応からプラットフォームへの道は、自動では開きません。FDEとプロダクトのあいだの生きたフィードバックループ、複数の顧客からパターンを読む目、変わるものと変わらないものを分ける設計の感覚、早すぎる一般化を防ぐ三の法則、そしていまの顧客と未来の顧客のあいだの緊張を意識的に管理する成熟が必要です。

この三編の記事を貫くひとつのメッセージがあるとすれば、これです。**FDEは、顧客の最前線で本当の問題を解き、その経験をみんなのための製品として還元する橋である。**使い捨てプロトタイプで一顧客に勝ち、その勝利から学んだことをプラットフォームへ育てること — それがフォワードデプロイド・エンジニアリングのソフトウェアの作り方です。

参考資料

Discuss on Twitter • View on GitHub