FDEのプロトタイピング術｜1日で動く物を見せる
FDEのプロトタイピングは、一般的なソフトウェア開発のプロトタイピングとは目的が違います。私たちが「1日で動くものを見せる」のは、技術力を誇示するためではありません。顧客の目の前で動くものを見せることで、言葉だけでは伝わらない課題の解像度を一気に上げるためです。私は日本FDE協会の会長として活動していますが、これまでのキャリアで最も実感してきたのは「動くものの前では、誰もが本音を話す」ということでした。
この記事を読めば、顧客の現場で素早くプロトタイプを作り、フィードバックを得るための具体的な手順がわかるようになります。FDEの基本を先に知りたい方は「FDEとは？SE・SIerとの違いを実践者が解説」もあわせてご覧ください。
なぜFDEにとってプロトタイピングが最重要スキルなのか
要件定義書を待たないという選択
従来のシステム開発では、要件定義→基本設計→詳細設計→実装という流れが一般的です。しかしFDEが入る現場では、そもそも「何を作るべきか」が決まっていないことがほとんどです。顧客自身が課題を正確に言語化できていないケースも多い。だからこそ、まず動くものを作って見せることが出発点になります。
製造業のクライアントに入ったとき、先方から「生産データを活用したい」と漠然とした相談を受けました。要件定義書を書こうとしたら半年はかかるでしょう。私はその日のうちに、既存のCSVデータを使った簡易ダッシュボードを作って見せました。すると先方の工場長が「この数字、リアルタイムで見られたら判断が変わる」と即座に反応してくれた。この一言で、本当に必要なものの方向性が一気に定まりました。
プロトタイプが変えるのは「会議の質」
プロトタイプがない会議では、参加者がそれぞれ違うイメージを頭の中に描いて話しています。言葉だけの議論は空中戦になりがちです。動くものがあれば「ここをこうしたい」「この機能は要らない」という具体的な話ができる。私の経験上、プロトタイプを持ち込んだ会議は、持ち込まなかった会議と比べて意思決定のスピードが3倍以上速くなります。
3つのプロトタイピング手法——場面ごとの使い分け
FDEの現場で使うプロトタイピング手法は大きく3つに分かれます。重要なのは「どれが優れているか」ではなく、場面に応じて使い分けることです。
手法 | 所要時間 | 適した場面 | メリット | 注意点 |
|---|---|---|---|---|
ペーパープロト | 30分〜2時間 | 初回ヒアリング・画面遷移の確認 | その場で描ける・修正コストゼロ | 非エンジニアには完成形が想像しにくい |
ノーコードツール | 半日〜1日 | 業務フローの検証・データ入力画面 | 実際に触れる・データ連携も可能 | 複雑なロジックには向かない |
コード実装 | 1日〜3日 | API連携・データ処理・分析系 | 本番に近い動作確認ができる | 作り込みすぎると捨てにくくなる |
ペーパープロトは「顧客と一緒に描く」
ペーパープロトの最大の価値は、顧客を巻き込めることです。私はヒアリングの場にホワイトボードマーカーと付箋を持ち込み、話を聞きながらその場で画面の流れを描いていきます。「こんなイメージですか？」と確認しながら進めると、顧客も自分の手で修正を加え始める。この共同作業の時点で、プロジェクトの方向性の半分は決まっています。
ノーコードは「今日中に触れるもの」を作る道具
ノーコードツールは、非エンジニアの顧客に「実際に操作してもらう」ために使います。SaaS企業のプロジェクトでは、午前中のヒアリングで課題を整理し、午後にはノーコードで業務フローの簡易版を組んで見せたことがあります。「これ、明日から使えますか？」と聞かれたときが、FDEとして最も手応えを感じる瞬間です。
コード実装は「捨てる前提」で書く
プロトタイプとしてコードを書くときに最も重要なのは、「このコードは捨てる」と最初から決めておくことです。きれいな設計やテストカバレッジよりも、動くものを最速で見せることを優先します。AIプロダクトの開発では、Pythonスクリプト数十行でデモ用のAPIを組み、顧客に触ってもらうことがよくあります。本番実装は、顧客のフィードバックを得てからゼロから書き直す。この「捨てる勇気」がプロトタイプの速度を決めます。
FDE的プロトタイピングの進め方——5つのステップ
ステップ1：顧客の「一番痛い課題」を1つ選ぶ
プロトタイプで見せるべきは、顧客が最も困っていることへの解決案です。全体像を見せようとすると中途半端になります。「10ある課題のうち、明日解決したいものはどれですか？」と聞いて、1つに絞る。この問いかけ自体が、顧客の思考を整理する効果もあります。
ステップ2：既存データを使って最速で組む
プロトタイプのデータは、本番データでなくて構いません。顧客が普段使っているExcelやCSVを借りて、それをそのまま流し込むのが最速です。金融機関のプロジェクトでは、先方がトレーダー向けに使っていたスプレッドシートをそのままデータソースにして、分析ダッシュボードのプロトタイプを1日で作りました。
ステップ3：「完成度60%」で見せる
100%のものを見せると、顧客は「もう決まったもの」だと思ってフィードバックをくれなくなります。あえて粗い状態で見せることで「ここをこう変えてほしい」という具体的な意見を引き出す。中小企業の経営者にプロトタイプを見せたとき、「この画面、もっとシンプルにできない？」という一言から、機能を半分削って使いやすさが劇的に向上した経験があります。
ステップ4：フィードバックは「その場で」反映する
顧客からのフィードバックを持ち帰って翌週修正する、では遅い。可能な限りその場で修正して見せ直す。「こうですか？」「いや、もう少しこう」というやり取りを目の前で繰り返すことで、顧客との認識のズレがゼロに近づきます。
ステップ5：次のアクションを具体的に決めて終わる
プロトタイプを見せた場のゴールは、感動させることではなく「次に何をするか」を決めることです。「では来週までにこの機能を本番レベルで実装します」「まずこのデータの精度を検証します」——具体的なアクションが決まれば、プロジェクトは確実に前に進みます。
プロトタイピングでやりがちな失敗
失敗1：作り込みすぎて捨てられなくなる
プロトタイプに3日以上かけたら、それはもうプロトタイプではありません。時間をかけるほど「もったいない」という心理が働き、本来捨てるべきコードをそのまま本番に流用してしまう。これが後々の技術的負債になります。
失敗2：顧客不在で作ってしまう
自分の頭の中だけでプロトタイプを作ると、顧客が本当に欲しいものとズレるリスクがあります。私自身、Eコマース事業の立ち上げ時にこの失敗をしました。「技術的にいいものを作れば売れる」と思い込み、顧客のフィードバックなしに開発を進めた結果、最初の半年は売上がほぼゼロ。市場調査とヒアリングを徹底するようになってから事業が軌道に乗りました。FDEのプロトタイピングは、常に顧客と一緒に行うものです。
よくあるご質問
Q. プロトタイプと MVP（Minimum Viable Product）はどう違いますか？
A. プロトタイプは「検証のための試作品」で、使い捨てが前提です。MVPは「最小限の機能で実際にユーザーに提供する製品」です。FDEの現場では、プロトタイプで方向性を確認してからMVPの開発に進むという流れが多いです。
Q. ノーコードツールは具体的に何を使いますか？
A. 案件の内容によりますが、業務フローの検証にはBubbleやRetool、データの可視化にはStreamlitやGoogleスプレッドシート＋Apps Scriptを使うことが多いです。大切なのはツールの選択よりも「今日中に見せられるか」という判断基準です。
Q. プロトタイプを見せたら「これで完成ですよね？」と誤解されませんか？
A. よくある懸念ですが、見せる前に「これは方向性を確認するための試作品です」と一言伝えるだけで解決します。むしろ粗い状態で見せることで「まだ変えられるんだ」と安心して意見を出してくれる効果があります。
FDEの技術やスキルについてもっと知りたい方へ
FDEという働き方の全体像を知りたい方は、こちらの記事もご覧ください。
日本FDE協会
FDE（Forward Deployed Engineer）の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。