商談用デモ版を作る：受注前に見せるMVPの作り方と注意点

商談用のデモ版は、「顧客が自分の業務に当てはめて、導入後の姿を具体的に想像できる」ことだけを目的に作ります。すべての機能を動かす必要はありません。顧客が最も知りたい2〜3の場面を、実際の業務に近いデータで、迷わず見せられることが大切です。反対に、デモの作り込みに時間をかけすぎると、受注前の投資が膨らむうえに、「もう完成している」と誤解されて、導入時の期待値の調整に苦しむことになります。

この記事は、法人向けの新規サービスを立ち上げようとしている事業責任者や営業責任者、受注前に顧客へ見せる試作品の開発を検討している方に向けて書いています。商談用デモの種類と選び方、デモで見せる場面の決め方、作り方の手順、商談での見せ方、作り込みすぎを防ぐ注意点、よくある失敗までを整理しました。

読み終えるころには、自社の商談に必要なデモの範囲を決められ、デモを使って受注や事前の合意を得ながら、その反応を本開発の判断に生かす進め方が分かるはずです。

商談用デモ版とは：受注前に「導入後の姿」を見せる道具

法人向けのサービスや業務システムを売るとき、資料や口頭の説明だけでは、顧客は導入後の姿を具体的に想像できません。特に、まだ世の中にない新しいサービスであればなおさらです。商談用デモ版は、この想像の差を埋めるための道具です。

新規事業でデモを作る目的は、大きく3つあります。

• 受注や事前合意を得る：実物に近いものを見せることで、導入の意思決定を後押しする。発売前の予約や、試験導入の合意を取りつけることもある
• 顧客の反応を集める：どの場面で顧客の目が変わるか、どこで質問が出るかを観察し、本当に必要な機能を見極める
• 社内の合意を取る：開発の予算を得るために、社内の決裁者に事業の姿を見せる

ここで注意したいのは、デモは「完成品の一部」ではなく「検証の道具」だということです。顧客の反応を見て内容を変えていくものなので、変えやすさを優先して作ります。MVPと似ていますが、MVPが実際に使ってもらって価値を確かめるのに対し、デモは見せて反応を確かめるもので、実際の業務で使われることは想定しません。

デモの種類と選び方

商談用のデモには、作り込みの度合いに応じていくつかの種類があります。

多くの新規事業では、初回の商談には静止画やクリックできる試作品、関心を示した顧客との2回目以降の商談には動くデモ、と段階的に使い分けるのが効率的です。最初から動くデモを作ると、関心の薄い顧客にまで手間をかけることになります。

クリックできる試作品を作るときは、画面のつながりを先に整理しておくと手戻りが減ります。整理の方法は画面遷移図の作り方が参考になります。

生成AIの普及でデモの作り方が変わった

近年は、AIの支援を受けた開発で、動くデモを短期間で作れるようになりました。以前なら静止画で済ませていた段階でも、実際に操作できるデモを用意できる場面が増えています。ただし、作れることと作るべきことは別です。手間が小さくなったぶん、つい機能を足したくなりますが、デモの目的に照らして範囲を絞る判断は、以前と変わらず必要です。

デモで見せる場面の決め方

デモの範囲を決めるときは、機能の一覧から考えるのではなく、「顧客がどの場面で導入を決めるか」から逆算します。

顧客の「今の困りごと」が解消される瞬間を選ぶ

顧客が導入を決めるのは、自分の困りごとが解消される瞬間を見たときです。たとえば、毎月の集計に丸一日かかっている顧客であれば、データを取り込んで数秒で集計結果が出る場面。電話での問い合わせ対応に追われている顧客であれば、問い合わせが自動で振り分けられる場面です。この「解消の瞬間」を2〜3つに絞り、デモの中心に置きます。

意思決定に関わる人ごとに見たい場面が違う

法人向けの商談では、現場の担当者、部門の管理者、決裁者、情報システム部門など、複数の人が導入の判断に関わります。

すべての立場に向けた場面を一度に見せる必要はありません。商談の相手に合わせて、見せる順番と時間配分を変えます。

見せない場面を決める

デモで見せない場面も、あらかじめ決めておきます。設定画面、例外的な処理、管理者向けの細かな機能などは、聞かれたら「本導入の際に用意します」と答えられれば十分です。見せない場面を作らないために、機能を中途半端に作るのは避けます。

商談用デモを作る手順

デモを作る手順は次のとおりです。最初の版は1〜2週間程度で作れる範囲を目安にします。

1. 想定する顧客像を1〜2つに絞り、その顧客の今の業務の流れと困りごとを書き出す
2. 困りごとが解消される「解消の瞬間」を2〜3つ選ぶ
3. 商談で話す順番に沿って、見せる画面と操作の台本を作る（5〜10分程度で見せられる長さ）
4. 台本に沿って、必要な画面と操作だけを洗い出す。それ以外は作らない
5. 顧客の業種に合った架空のデータを用意する。社名、商品名、数字は実在しないもので、業務の雰囲気が伝わるものにする
6. デモの種類（静止画、試作品、動くデモ）を決め、作る
7. 社内の人を顧客役にして、台本どおりに通しで見せる練習をする。詰まった箇所、伝わりにくかった箇所を直す
8. 想定外の質問への答え方を準備する（できること、できないこと、今後の予定）
9. 商談後に、顧客の反応と質問を記録する様式を用意する

手順3の台本が最も重要です。台本がないと、デモの範囲が際限なく広がります。台本に出てこない画面は、作らなくてよい画面です。

デモにかける手間の上限を先に決める

デモの開発にどれだけの時間と費用をかけてよいかは、受注できた場合の取引の大きさと、デモで得たい情報の価値で決まります。目安を立てるときは、「このデモで何社と商談し、何社の試験導入を得たいか」を先に決め、そこから逆算します。商談の予定が数社しかないのに、何週間もかけて動くデモを作るのは過剰です。逆に、多くの見込み顧客との商談が控えているなら、安定して動くデモに手間をかける価値があります。上限を決めずに作り始めると、改善の要望に応えるうちに、気づけば小さな本開発になっていることがあります。

デモ用のデータは「業務の匂い」がするものを

デモの説得力は、画面のデザインよりもデータで決まります。「テスト商品1」「サンプル太郎」のようなデータでは、顧客は自分の業務に重ねて考えられません。業種でよく使われる品目名、現実的な件数や金額の桁、よくある例外（返品、キャンセル、欠品など）を含めたデータを用意すると、顧客の質問が具体的になり、得られる情報も増えます。ただし、実在の企業名や個人名、他の顧客から預かった情報は使わないでください。

商談での見せ方と反応の集め方

デモは作るだけでなく、見せ方で効果が大きく変わります。

• 最初に顧客の困りごとを確認する：デモを始める前に、顧客の今の業務と困りごとを聞き、それに沿ってデモの順番を調整する
• 操作は営業担当が行い、顧客には画面を見てもらう：顧客に操作させると、想定外の操作で破綻する危険がある。ただし、最終段階では顧客に触ってもらうことも検討する
• 「これは開発中の画面です」と最初に伝える：完成品だと誤解されないよう、デモの位置づけを明確にする
• 顧客の言葉をそのまま記録する：「これは便利」「うちではこう使う」「これがないと困る」といった発言は、本開発の優先順位を決める貴重な材料になる
• 最後に次の行動を合意する：試験導入、追加の打ち合わせ、社内での検討など、次の一歩を決めて終える

商談後の記録と振り返り

デモの反応は、商談の直後に記録しないとすぐに薄れます。商談ごとに、次の項目を記録する簡単な様式を用意しておきます。

• 相手の業種、規模、参加者の立場
• 事前に聞いた困りごと
• 反応が大きかった場面と、そのときの発言
• 出た質問と、その場で答えられなかった質問
• 「これがないと導入できない」と言われた条件
• 合意した次の行動

数件の商談がたまったら、記録を並べて見比べます。複数の顧客で共通して反応が大きい場面は、本開発で最優先に磨くべき部分です。逆に、自分たちが自信を持っていたのに反応が薄い場面は、価値の伝え方か、価値そのものを見直す必要があります。こうした振り返りを繰り返すことで、デモは営業の道具であると同時に、顧客検証の道具にもなります。

顧客の声を集めて整理する方法はMVPでの顧客の声の集め方も参考になります。デモで集めた声は、そのまま要望として実装するのではなく、複数の顧客で共通する困りごとを見極めてから優先順位を決めます。

架空の例：建設業向けの日報・原価管理サービス

ある架空のチームが、中小の建設会社向けに、現場の日報から工事ごとの原価を自動で集計するサービスを企画したとします。

最初の商談では、日報の入力画面と原価の集計画面の静止画を並べた紙芝居で説明しました。反応を見ると、社長は原価の集計画面に強い関心を示した一方、現場監督は日報の入力に手間がかかることを心配していました。

そこでチームは、2回目の商談用に動くデモを作りました。台本は「現場監督がスマートフォンで日報を1分で入力する」「その日報が工事ごとの原価に自動で反映される」「社長が赤字の工事を一覧で確認する」の3場面だけです。工事名や資材名は、建設業でよく使われる名称を参考にした架空のものを用意しました。

このデモを見た複数の会社から試験導入の希望が集まりましたが、同時に「既存の会計ソフトに原価を送れないと使えない」という声が繰り返し出ました。チームはこれを本開発の最優先事項とし、デモで見せていた細かな日報の項目設定は後回しにしました。デモが、受注の後押しと本開発の優先順位づけの両方に役立った例です。

作り込みすぎを防ぐ注意点

商談用デモでは、作り込みすぎがいちばんの失敗の原因になります。次の点に注意してください。

• 完成品と誤解される：デモが完成品に見えるほど、顧客は「すぐに使える」と期待します。導入までの期間や、本番で追加される作業について、商談の場で必ず説明します。
• 個別の顧客向けに作り変え続ける：商談のたびに顧客ごとの要望を反映していると、デモが複数に分かれ、管理できなくなります。共通の台本を1つ持ち、顧客ごとに変えるのはデータと見せる順番だけにします。
• デモのコードを本番に流用する：デモは見せることを優先して作るため、データの保存、権限、エラー処理などが不十分なことが多いです。本開発に流用する場合は、どこを作り直すかを判断してから使います。MVPや本開発への移行の考え方はMVPから本開発への移行でまとめています。
• できないことを「できる」と言ってしまう：商談の勢いで、まだ作っていない機能を約束してしまうと、受注後に大きな負担になります。デモで見せたことと、これから作ることを分けて説明します。
• デモの準備に営業の時間が取られる：デモの環境の準備や不具合の対応に時間がかかると、営業活動そのものが止まります。安定して動く版を固定し、商談の直前に変更しないルールにします。

約束の範囲を文書に残す

デモをきっかけに受注や事前合意を得る場合は、何を、いつまでに、どの範囲で提供するのかを文書に残します。デモの画面をそのまま合意の根拠にすると、細部の解釈で食い違いが起きます。提供する機能、提供の時期、試験導入の条件、費用の扱いを、簡単な合意書や発注書に明記しておきます。契約の形式や内容は、必要に応じて専門家に確認してください。

よくある失敗と避け方

• 機能の一覧から作り始める：機能が多いほど良いデモになると思いがちですが、見せる場面が散らばり、印象に残りません。台本から逆算して作ります。
• 自社の言葉で説明してしまう：開発者や自社の用語で説明すると、顧客は自分ごととして理解できません。顧客の業務で使われている言葉に合わせて、画面の文言とデータを用意します。
• 反応を記録しない：デモの最大の価値は、顧客の反応という情報です。誰がどの場面で何と言ったかを、商談ごとに記録します。
• 一度作ったデモを更新しない：顧客の反応を受けても台本を変えないと、同じ質問に毎回つまずきます。数回の商談ごとに台本を見直します。
• デモ環境が不安定：商談の最中に動かなくなると、信頼を大きく損ないます。予備として、操作の様子を録画した動画を用意しておきます。

商談用デモのチェックリスト

デモを商談で使う前に、次の項目を確認してください。

• 想定する顧客像と、その困りごとが言葉になっている
• 見せる「解消の瞬間」が2〜3つに絞られている
• 5〜10分程度で見せられる台本がある
• 台本に出てこない画面や機能は作っていない
• 業種に合った架空のデータが入っていて、実在の企業名や個人情報を使っていない
• 「開発中の画面である」ことを説明する言葉を用意した
• できること、できないこと、今後の予定を答えられる
• 社内で通しの練習をし、詰まった箇所を直した
• 動かなくなった場合に備えて、操作を録画した動画がある
• 商談後に反応を記録する様式がある
• 受注や事前合意の際に、提供範囲を文書に残す手順がある

商談を重ねるたびに、このチェックリストも見直します。顧客から繰り返し出る質問は台本に組み込み、まったく反応のない場面は台本から外す、という調整を続けることで、デモは少しずつ商談で使いやすい形に育っていきます。

よくある質問

Q. デモはどの段階から作るべきですか？

顧客の困りごとについて、ある程度の仮説が立った段階で作り始めるのが目安です。仮説がないまま作ると、何を見せればよいかが決まりません。最初は静止画やクリックできる試作品から始め、関心を示した顧客が増えてきたら、動くデモに進みます。

Q. デモを見せて受注した後、すぐに提供できないと問題になりませんか？

デモの位置づけと提供の時期を、商談の段階で明確に伝えていれば問題になりにくいです。発売前の予約や試験導入の合意として扱い、提供時期と条件を文書に残しておきます。顧客にとっては、開発の段階から意見を反映してもらえることが魅力になる場合もあります。

Q. デモの開発を外注する場合、何を伝えればよいですか？

台本と、見せる場面ごとの画面のイメージ、使うデータの例を伝えます。「デモであり、本番の品質は求めない」「顧客の反応を受けて変更する前提である」ことも明確にします。変更のしやすさを重視した作り方を依頼すると、商談のたびの修正がしやすくなります。

Q. 顧客から実データでデモを見たいと言われた場合はどうすればよいですか？

可能であれば対応すると説得力が増しますが、データの取り扱いについて事前に合意が必要です。秘密保持の取り決め、データを保管する場所、デモ後の削除方法を決めてから受け取ります。個人情報が含まれる場合は、特に慎重に扱ってください。

Otsumuに相談できること

顧客の困りごとがはっきりしていて、社内にデザインツールや開発に慣れたメンバーがいる場合は、この記事の手順に沿って、静止画やクリックできる試作品のデモを自社で作ることができます。まずは台本を1本書き、見せる場面を2〜3つに絞るところから始めてみてください。

一方で、動くデモを短期間で用意したい、デモで集めた反応を本開発の範囲や優先順位にどうつなげればよいか分からない、デモから試験導入、本開発までを見据えて作り方を決めたい、といった場合は、事業と開発の両方が分かる相手と進めたほうが手戻りが少なくなります。

Otsumuは、自らも事業を手がける実践者として、目的から逆算して必要な場面に絞ったデモやMVPを、AIを活用した少人数・短期間の開発で形にしています。新規事業の爆速MVPシステム開発では、台本づくりからデモの開発、顧客の反応の整理、本開発の範囲の決定までを一気通貫で支援します。顧客の反応を集める段階を整理したい場合は、4週間で顧客検証を行う顧客検証 Sprint（98万円〜、税別・参考価格）もご用意しています。

商談用のデモをどこまで作るべきか迷っている段階からでも構いません。30分の無料相談でお気軽にご相談ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01