LabHub

ブログ

FDEプレイブック：使い捨てプロトタイプで勝つ

2026-06-30 · 16 分で読めます · #engineering#prototyping#fde

한국어English日本語中文

はじめに — スライドではなく、動くもの

フォワードデプロイドエンジニア（FDE）の世界で最も強力な武器は、よくできたプレゼン資料ではありません。顧客の本物のデータの上で実際に動くプロトタイプです。百ページの提案書よりも、顧客が自分のデータが画面で動くのを見る3分のほうが、はるかに大きな説得力を持ちます。

そしてこのプロトタイプの決定的な特徴はひとつです。捨てる前提で作る。プロダクションコードのように丹念に磨き上げるのではなく、価値を証明するためだけに素早く組み立て、証明が済んだら未練なく捨てます。この記事は、その「使い捨てプロトタイプ」でどう勝つかについてのプレイブックです。

なぜ使い捨てプロトタイプなのか

伝統的なエンジニアリングの感覚では、このアプローチは無駄に見えます。どうせ捨てるものをなぜ作るのか。答えは明確です。プロトタイプの目的はコードを残すことではなく、学びと確信を残すことだからです。

数日のプロトタイプが答えてくれる問いを考えてみてください。

これらの答えは、ドキュメントをいくら読んでも出てきません。実際に作ってみて初めて出てきます。そして答えを得てしまえば、その粗雑なコード自体はすでに役目を終えているのです。

スパイク：まずリスクを取り除く

アジャイルの世界にはスパイク（spike）という概念があります。不確実性が最も大きい部分を先に突く、時間を区切った探索的な作業です。FDEのプロトタイプは、本質的に巨大なスパイクです。

肝は最もリスクの高い仮定を真っ先に検証することです。プロジェクトが失敗するとしたら、どこで失敗するのか。その地点を先に攻めます。

たとえば「顧客のPDF契約書10万件から特定の条項を抽出する」というプロジェクトなら、最大のリスクはUIでも認証でもありません。モデルがその汚い実PDFから条項をきちんと抜き出せるかです。だからUIは後回しで、まず数日以内に本物のPDF数百件にモデルを回して精度を確かめるのが先です。それができなければ、残りは意味がないからです。

スパイクのルールは単純です。

意図的な技術的負債：借りるが、記録せよ

使い捨てプロトタイプでは、技術的負債は罪ではなく戦略です。ただし意図的でなければなりません。

「悪い負債」は知らぬ間に積み上がる負債です。「良い負債」は目を開けて借りる負債です。「いまは速さが大事だからここで近道をする。あとでプロダクションではこう正しくやる」と自分でわかって借りるのです。

意図的な技術的負債を扱う原則はこうです。

いつハードコードするのか

プロトタイプにおいてハードコードは恥ではなく、強力な技法です。問題は「どこを」ハードコードするかです。

原則はこうです。証明しようとする価値の外側にあるものは、すべてハードコードの候補である。

逆に、絶対にハードコードしてはいけないものがあります。デモの心臓、つまり証明しようとするその価値です。条項抽出のデモで抽出結果を手であらかじめ入れておけば、それはデモではなく詐欺です。顧客がその場で自分の文書を投げ込んだときに本当に動いてこそ、その瞬間がアハ体験になります。

以下はこの感覚をコードで表した例です。本当の価値（抽出）は実際に回し、それ以外は堂々とハードコードします。

# demo_extractor.py — デモ用プロトタイプ（捨てるコード）

# [ハードコードOK] デモの価値ではないもの
DEMO_CUSTOMER = "acme-corp"
FAKE_AUTH_TOKEN = "demo-token-do-not-ship"
TARGET_CLAUSE_TYPES = ["indemnification", "termination", "liability"]

def get_current_user():
    # [意図的な負債] デモでは認証を真似るだけ。プロダクションでは本物のOAuthに置き換える。
    return {"org": DEMO_CUSTOMER, "token": FAKE_AUTH_TOKEN}

def extract_clauses(pdf_text: str) -> list[dict]:
    # [本当の価値] ここだけは実際に動かなければならない。絶対にハードコード禁止。
    # 顧客がその場で投げた文書にも本当に動くことが、デモの核心。
    prompt = build_extraction_prompt(pdf_text, TARGET_CLAUSE_TYPES)
    response = call_llm(prompt)
    return parse_clauses(response)

def save_results(results: list[dict]) -> None:
    # [意図的な負債] デモではただのローカルJSON。プロダクションではDBに置き換える。
    import json, pathlib
    pathlib.Path("demo_output.json").write_text(json.dumps(results, indent=2))

アハ体験まで最短距離で

FDEのプロトタイピングの目標は、ただひとつに収束します。顧客をアハ体験までできるだけ速く連れて行くこと。アハ体験とは、顧客が「ああ、これがうちの問題をこう解いてくれるのか」を、頭ではなく目で理解する瞬間です。

この距離を縮める原則がいくつかあります。

期待値のマネジメント：デモはデモだと言え

使い捨てプロトタイプの最大のリスクは技術ではなく、誤解です。デモがあまりになめらかだと、顧客（そして時には社内の営業）は「ほぼ完成ですね、来週デプロイできますよね?」と考えてしまいます。数日のデモとプロダクションのあいだには数か月の距離があるのに、です。

だから期待値のマネジメントは、プロトタイピングに欠かせないもう半分です。

これをきちんとやれば、デモの感動を保ちつつ、非現実的なスケジュールの圧力をかわせます。

プロトタイプからプロダクションへ

デモが成功し契約が進むと、本当の問いが来ます。このプロトタイプのコードをどうプロダクションにするのか?

ここでよくある間違いが二つあります。ひとつはプロトタイプをそのままプロダクションに押し込むこと（仮対応がそのまま残って爆弾になります）、もうひとつは最初から全部書き直すこと（学んだことを捨てます）。良い答えはたいていその中間にあります。

アンチパターン：こういうときは止まれ

使い捨てプロトタイプも、使い方を誤れば毒になります。次のサインが見えたら、アプローチを見直すべきです。

おわりに

FDEのプロトタイピングは「雑に作る」ことではなく、「何を雑に作るかを正確に知る」技術です。最もリスクの高い仮定をスパイクで先に突き、価値の外側は堂々とハードコードし、顧客を自分のデータのアハ体験へ最短距離で連れて行き、デモはデモだと正直に言い、検証された中核だけをプロダクションへ昇格させます。

使い捨てプロトタイプの逆説は、捨てるものを作ったからこそ、かえって最も価値あるもの — 確信と方向と顧客の信頼 — を残す、という点です。次の記事では、こうして一顧客のために作ったものが、いかにしてすべての顧客のためのプラットフォームへと育つのかを語ります。

参考資料

原文を読む: https://www.youngju.dev/blog/2026-06-30-fde-throwaway-prototypes.ja

コメント

まだコメントはありません。

ログインするとコメントできます