Skip to content
Published on

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

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

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

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

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

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

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

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

  • この問題にこの技術は本当に通用するのか。
  • 顧客のデータは想定どおりきれいなのか、それとも地獄なのか。
  • 顧客が本当に欲しいのは、こちらが想像したそれで合っているのか。
  • この方向に半年を投資する価値があるのか。

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

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

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

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

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

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

  • 時間を区切る: 「二日以内に結論を出す。」スパイクは無限に長引かせてはいけません。
  • 問いを明確にする: 「通用するかしないか」というイエス/ノーの問いを立てます。
  • 成果は知識である: 成功すれば自信を、失敗すれば方向転換を得ます。どちらも得です。

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

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

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

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

  • 負債であることを記録する: 近道をした場所に印を残します。プロトタイプを発表するときも「この部分はデモ用の仮対応です」と正直に明かします。
  • 中核ロジックと仮対応を分ける: 本当の価値を証明する中核部分（たとえば抽出ロジック）にはそれなりに気を配り、周辺部（認証、保存、UI）は思い切って雑にします。
  • 戻せるようにしておく: あとでこの近道を取り除くとき、どこに手を入れればよいかを明確に残しておきます。

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

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

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

  • 認証/権限: デモでログインの流れは、たいてい価値ではありません。トークンをひとつ埋め込むだけにします。
  • 設定値: 顧客名、しきい値、カテゴリの一覧などは、ひとまずコードに埋め込みます。あとで設定に切り出します。
  • 周辺の統合: まだつないでいない外部システムは、偽のレスポンスで真似します。

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

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

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

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

  • 顧客のデータで実演する: こちらのサンプルデータでいくらよく動いても、顧客は他人事として聞きます。顧客自身のデータが動いた瞬間、ようやく自分事になります。
  • 最も印象的なひとつの流れだけを仕上げる: 十の機能を中途半端に見せるより、ひとつの「ワオ」の流れをなめらかに仕上げます。デモは広さではなく深さです。
  • 最初の30秒で勝負する: 顧客の注意力は短いものです。ログイン、設定、オンボーディングで時間を引き延ばさず、開いた瞬間に核心の価値を見せます。
  • 本物の結果を見せる: モックアップ画面ではなく、本当に計算された結果でなければなりません。顧客は本物と偽物を見事に嗅ぎ分けます。

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

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

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

  • デモであることを明確にする: 「これは価値をお見せするためのプロトタイプで、裏には仮対応がたくさんあります」と先に言います。
  • プロダクションまでの残りの仕事を見せる: デモの裏に必要な本当の作業（エラー処理、規模拡張、セキュリティ、統合）の一覧を一緒に提示します。
  • 「氷山」のたとえを使う: デモは水面上に現れた氷山の頂で、プロダクションは水面下の巨大な本体だと説明します。

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

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

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

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

  • 中核ロジックは活かし、外側は入れ替える: プロトタイプで本当に検証されたのは中核の価値ロジック（抽出・マッチング・計算）です。この部分はよく磨いて活かし、ハードコードした認証・保存・UI・統合はきちんと作り直します。
  • 意図的な負債をひとつずつ返す: 先に残しておいた負債の印を地図として、仮対応を正式な実装にひとつずつ置き換えます。
  • プロトタイプを仕様書として使う: プロトタイプ自体が「顧客が欲しいもの」の最も正確な仕様です。書き直すにしても、この生きた仕様を基準にします。
  • 境界を引き直す: どこまでがこの顧客だけの個別対応で、どこからが製品に入れる一般機能なのかを、このとき判断します。（このテーマは次の記事で深く扱います。）

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

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

  • デモが何週間も長引く: 数日であるべきプロトタイプが何週間にもなれば、それはもうプロトタイプではなく、方向のないプロダクションです。
  • 捨てるコードに愛着が湧く: 「これよく書けたのに惜しい」という気持ちが湧いたら危険信号です。プロトタイプは捨てられてこそ自由です。
  • 偽のデータでしかうまく動かない: 顧客の本物のデータで崩れるなら、まだリスクを検証できていません。
  • 誰もアハを感じない: デモを見ても顧客が冷めているなら、問題や価値の仮説そのものが間違っている可能性があります。

おわりに

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

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

参考資料

Discuss on Twitter • View on GitHub