実証実験で終わる商談の原因｜検証を契約につなげる

「検証までは進むのに、そこから契約に至らない」「実施して終わり、という形が続いている」——新しい仕組みを提案している企業が繰り返す停滞です。検証で終わるのは、結果が悪かったからとは限りません。何をもって次に進むのかを、始める前に決めていないことが原因です。この記事では、検証を契約につなげる設計を整理します。

結果が良くても止まるのはなぜか

検証まで進むということは、相手の社内で一定の合意ができているということです。予算も人も動いています。それでも本契約に至らない案件が多くあります。

止まる理由を先方に尋ねると、たいてい「社内で検討中」という答えが返ってきます。これは断りの言葉ではなく、実際にそのまま止まっていることが多いのが実情です。

技術的にうまくいったかどうかと、事業として進めるかどうかは別の判断です。

前者は現場の担当者が判断できます。後者は、予算を持つ立場の人が判断します。この2つの判断者が違うことが、話が止まる構造的な理由です。

現場の担当者は「良かった」と言います。しかしその人には、本番の予算を通す力がありません。

一方で決裁する側は、検証の結果を見ていません。報告書が回ってくるだけです。

その報告書に、精度の数字と技術的な所感しか書かれていなければ、判断のしようがありません。

必要なのは、この投資が業務にどう効くのかという説明です。

これが用意されていないと、検討の順番待ちに入ったまま年度が変わります。

売る側としては、この構造を前提に検証を設計する必要があります。

誰が判断するのかを先に確かめる

検証を始める前に、最終的に誰が判断するのかを確かめます。現場の担当者だけと話を進めていると、この確認が抜けがちです。

聞き方としては、「本番の導入を決めるとき、どなたの承認が必要になりますか」という形が自然です。

この質問に即答できない相手は、社内の道筋が見えていない状態です。

その場合、検証と並行して社内の合意形成を手伝う必要があります。

判断する人が分かれば、その人が何を見て決めるのかも聞けます。

そこから逆算して、検証で取るべきデータが決まります。

検証そのものが目的になっている

止まる案件に共通するのが、検証を行うこと自体が目的になっている状態です。新しい技術を試してみたい、という動機で始まっています。

この場合、解決したい業務上の課題が曖昧なまま進みます。何をもって成功とするかも決まっていません。

結果として、精度が出たかどうかだけが評価の対象になります。

しかし、精度が出たことは、業務が改善することを意味しません。

たとえば判定の精度が9割を超えたとします。それでも、残り1割を人が確認する必要があるなら、業務の量は変わりません。

この点を検証の前に詰めていないと、終わってから気づくことになります。

売る側は、この確認を相手に委ねてはいけません。相手も気づいていないことが多いためです。

検証の企画の段階で、どの業務が、どれだけ楽になるのかを一緒に言語化します。

「月20時間かかっている確認作業を、5時間にする」といった形です。

この数字が置ければ、終わったときの判断が明確になります。

課題を聞き出す質問

課題を言語化してもらうには、質問の仕方に工夫が要ります。「何にお困りですか」と聞いても、抽象的な答えしか返ってきません。

有効なのは、具体的な作業について聞く形です。「その確認作業は、月にどれくらいの時間がかかっていますか」といった問いです。

時間や件数で答えられる質問にすると、相手も答えやすくなります。

数字が出てくれば、そこが成功の基準の土台になります。

答えが出てこない場合は、その業務を実際にやっている人に聞く必要があります。

管理する立場の人は、現場の実際の工数を把握していないことが多いためです。

成功の基準を数字で置く

検証を始める前に決めるべきものは、成功の基準です。ここが曖昧だと、終わってから議論が始まります。

基準は、技術の指標ではなく業務の指標で置きます。精度が何パーセントかではなく、作業時間が何時間減るかです。

置き方	例	判断のしやすさ
技術の指標だけ	判定の精度が90パーセント以上	業務が改善するか分からず判断できない
業務の指標	確認作業が月20時間から5時間になる	費用と比べて判断できる
費用の指標	年間の削減額が導入費用を上回る	決裁の場でそのまま使える
基準を置かない	やってみて考える	終わってから議論が始まり止まる

下の2つで置ければ、決裁の場でそのまま使えます。上の1つだけだと、判断のしようがありません。

基準を置くことを渋る相手もいます。外すのが怖いためです。

その場合は、達成できなかったときにどうするかも一緒に決めておきます。

「基準に届かなければ、条件を変えてもう一度試す」という取り決めです。

これがあると、基準を置くことへの抵抗が減ります。

失敗を許容する枠組みを先に作っておくのが、話を進める要点になります。

基準を多く置きすぎない

基準は多いほど厳密になりますが、実務では逆効果になります。

5つの基準を置くと、そのうち1つが未達だったときに判断が止まります。

「4つは達成したが1つは届かなかった」という結果を、どう扱うか決められません。

基準は1つか2つに絞るほうが、判断が明確になります。

残りは参考の指標として扱い、判断には使わない形にします。

この区別を、開始前に文書で共有しておきます。

実際のデータで試しているか

検証でよくある落とし穴が、整えられたデータだけで試すことです。見本として渡されたデータは、たいてい綺麗に揃っています。

ところが実際の業務で扱うデータには、欠けや誤りや表記の揺れが含まれます。本番で動かすと、まったく違う結果になります。

整えられたデータでの成功は、本番での成功を保証しません。

この差が、本番に進めない理由として後から浮上します。相手の社内でも「実際には使えないのでは」という声が出ます。

防ぐには、検証の段階で実際のデータを使わせてもらうことです。

守秘の壁があるなら、一部を加工した形でも構いません。少なくとも、揺れや欠けが含まれた状態にします。

見本のデータだけで進めると、検証が終わってからもう一度検証することになります。

この二度手間が、時間切れの原因になります。年度をまたぐと、案件そのものが消えます。

最初から現実に近い条件で試すほうが、結果的に速く進みます。

運用の費用まで見ているか

もう1つ見落とされるのが、運用にかかる費用です。導入の費用だけを見て、その後の負担を計算していないことがあります。

毎月の利用料、保守の工数、データを整える作業。これらが積み上がると、削減した効果を上回ることがあります。

この計算を検証の段階で示せると、決裁の場での説得力が上がります。

売る側にとっては、費用を明かすことになるので言いにくい部分でもあります。

しかし、後から発覚するほうが信頼を損ないます。先に出しておくほうが安全です。

3年間の総額で比べる形にすると、判断がしやすくなります。

既存の仕組みとの繋ぎこみ

運用の費用として見落とされやすいのが、既存の仕組みとの繋ぎこみです。

検証では単体で動かせても、本番では他の仕組みとデータをやり取りする必要が出てきます。

この作業に、想定外の工数がかかることがあります。

検証の段階で、繋ぎこみの範囲と難易度を確認しておきます。

相手の情報システム部門に、既存の仕組みの構成を聞ければ理想的です。

ここが不明なまま本番の見積もりを出すと、後から金額が膨らみます。

責任者がいない案件は進まない

検証が止まる案件には、相手の社内に責任者がいないという共通点があります。

担当者はいます。しかしその人は、実行する役割であって、進めるかどうかを決める立場ではありません。

責任者とは、その業務の成果に責任を持つ人のことです。改善すれば評価され、しなければ困る立場の人です。

この人が関わっていない検証は、誰の課題も解決しません。

誰も困っていない改善は、予算が付きません。当然の帰結です。

売る側としては、検証の企画の段階でこの人を巻き込みます。

最初の打ち合わせに同席してもらう、成功の基準を一緒に決める、といった形です。

難しければ、せめて中間の報告の場に呼びます。

結果が出てから初めて登場する形だと、その人にとっては他人事のままです。

巻き込むタイミングが早いほど、進む確率が上がります。

責任者が見つからない場合

話を聞いても、責任者が見つからないことがあります。

その業務が誰の担当でもなく、なんとなく続いている状態です。

この場合、検証を進めても本番には至りません。誰も困っていないためです。

別の業務に対象を移すか、案件そのものを見送る判断もあります。

無理に進めると、時間と工数だけを消費して終わります。

早い段階で見極めるほうが、双方にとって損が少なくなります。

進んだ後の計画を先に作る

検証が成功したときに何が起きるかを、先に描いておきます。ここを用意していない案件が、判断の場で止まります。

必要なのは、進むと決めた後の計画です。予算はいくらか、いつまでに何をするか、誰が担当するか。

この計画がないと、決裁する側は「進めた場合に何が起きるか」を想像できません。

想像できないものには、判を押せません。

売る側から、この計画の草案を提示するのが有効です。相手の社内で作るのを待っていると、たいてい作られません。

内容は、進んだ後の90日程度を目安にします。1年先まで書くと、精度が落ちて信用されません。

最初の90日で何を立ち上げ、どこまで動かすか。この範囲なら具体的に書けます。

あわせて、必要な体制も書きます。相手の社内で何人が、どれだけの時間を使うことになるか。

この負担を先に示すと、検討の場での議論が具体的になります。

隠しておくと、後から発覚して信頼を損ないます。

段階の区切りを決めておく

検証から本番までを、いくつかの段階に分けます。それぞれの区切りで、何を満たせば次へ進むかを決めます。

たとえば、限定した部署での試行、全社への展開、他の業務への横展開といった段階です。

各段階の入口に条件を置くと、判断が小さく分割されます。

一度に大きな判断を求めるより、小さく分けたほうが通ります。

決裁する側にとっても、途中で止められる形のほうが承認しやすくなります。

この設計を売る側から提案すると、相手の負担が減って話が進みます。

最初の段階を小さくする

最初の段階は、可能な限り小さく設計します。1つの部署、1つの業務、限られた人数です。

小さければ、承認に必要な金額も下がります。決裁の権限が現場に近い層で済むこともあります。

金額の大きさが、そのまま承認の難しさに比例します。

小さく始めて実績を作れば、次の拡大は通りやすくなります。

売る側としては、最初の金額が小さくなるので抵抗があるかもしれません。

しかし、大きな契約を狙って止まるより、小さく始めて広げるほうが確実です。

現場が置き去りになっていないか

検証が成功しても、現場が使わなければ意味がありません。ここでつまずく案件も多くあります。

原因は、検証を情報システム部門だけで進めていることです。実際に使う現場の人が関わっていません。

導入してから「操作が煩雑で使えない」という声が出ます。

現場が反対に回ると、どれだけ効果が示されても進みません。

売る側としては、検証の段階で現場の人に触ってもらう機会を作ります。

短い時間でも構いません。実際に操作してもらい、感想を聞きます。

そこで出た不満は、本番までに直せる貴重な情報です。

また、現場の人が「これなら楽になる」と感じれば、社内の推進役になってくれます。

決裁の場で現場から支持されている施策は、通りやすくなります。

使う人の声を集める工程を、検証の設計に組み込んでおきます。

検証を設計する手順

ここまでの内容を、実際の進め方に落とし込みます。商談で検証の話が出た時点から始めます。

この5工程を、検証の提案書の中に組み込みます。

提案の時点でここまで示せると、相手の社内での通りが良くなります。

同時に、こちらの本気度も伝わります。検証を売るのではなく、本番までを一緒に見ている姿勢が示せます。

無償で行うべきか

検証を無償で提供するかどうかは、売る側にとって悩ましい判断です。

無償にすると、相手は始めやすくなります。稟議も不要な場合があります。

一方で、無償の検証は優先度が下がります。相手の社内で後回しにされ、進まないことがあります。

費用を払っている案件のほうが、相手も真剣に取り組みます。

少額でも有償にすると、相手の社内で予算が付いた案件として扱われます。

担当者にも、成果を出す動機が生まれます。

判断の目安は、相手が本気で検討しているかどうかです。

情報収集の段階なら無償で構いません。本番の予算を確保する前提なら、有償にする価値があります。

無償を求められたときは、その理由を聞いてみます。

予算の都合なのか、社内の承認が取れないのか。答えで相手の状況が読めます。

期間をどう決めるか

検証の期間は、短すぎても長すぎても問題が起きます。

短すぎると、十分なデータが集まりません。判断の材料が足りず、もう一度やることになります。

長すぎると、担当者の熱が冷めます。人事異動で担当が変わることもあります。

3か月を超える検証は、途中で止まる確率が上がります。

目安としては、1か月から3か月の範囲に収めます。

業務の周期も考慮します。月次の処理を検証するなら、最低でも2周期は見る必要があります。

繁忙期を含めるかどうかも、事前に相談します。

繁忙期にしか起きない問題は、通常期の検証では見つかりません。

期間を決めるときは、いつ報告するかも同時に決めます。

終わってから日程を調整すると、そこで数週間が失われます。

報告の場をどう作るか

検証の結果を伝える場は、実質的に最後の商談の場です。ここの設計が甘いと、それまでの努力が活きません。

まず、決裁する立場の人に必ず出席してもらいます。担当者だけの報告会にしないことです。

報告の内容は、業務の指標を中心に組み立てます。技術の説明は補足に回します。

冒頭の3分で、基準を満たしたかどうかを述べます。

結論を後回しにすると、聞いている側の集中が続きません。

そのうえで、進んだ場合の計画を示します。ここが本題です。

その場で次の日程を決められると、話が止まりません。

「持ち帰って検討します」で終わらせないための工夫が要ります。

たとえば、次回の打ち合わせの候補日をその場で押さえます。

空白の期間を作らないことが、案件を生かし続ける条件です。

やりがちな失敗

検証を提案する側が陥りやすい失敗をまとめます。

• 技術の指標だけで成功を定義する：精度が出ても業務が改善するか分からず、判断できない
• 現場の担当者だけと進める：決裁する立場の人が結果を見ておらず、報告書だけで判断することになる
• 見本のデータだけで試す：本番のデータでは動かず、もう一度検証することになる
• 進んだ後の計画を用意しない：判断の場で次の絵が描けず、検討の順番待ちに入る
• 期間を半年以上に設定する：担当者の異動や熱の冷めで、途中で止まる

4つ目が、売る側の失敗として最も多いものです。検証の成功だけを目標にしてしまいます。

検証は目的ではなく、本番に進むための手段です。

検証の提案書に、本番の計画まで含めておくのが本来の形です。

この一手間があるかどうかで、契約に至る確率がはっきり変わります。

運用の決めごと

検証の案件を扱うときの、社内の決めごとを整理します。

• 検証を提案する前に、決裁する人が誰かを確認する
• 成功の基準は業務の指標で置く。技術の指標だけにしない
• 期間は3か月以内。長い場合は段階に分ける
• 報告の場には、決裁する立場の人に必ず出席してもらう
• 報告の資料に、進んだ後の90日の計画を必ず添える

この5つを、検証の案件の標準の進め方として共有します。

あわせて、検証の提案書の様式も統一しておきます。目的、基準、期間、体制、進んだ後の計画。この5つの欄を作ります。

様式があれば、書き漏れが減ります。営業ごとの品質のばらつきも抑えられます。

案件が止まったときの原因も、様式に沿って振り返れます。

営業ごとに進め方が違うと、成功する案件と止まる案件の差が分析できません。

型を決めておけば、止まった案件の原因も特定しやすくなります。

実務での目安

判断のための目安をまとめます。

• 検証の期間は1か月から3か月。業務の周期を2回以上含める
• 成功の基準は1つか2つ。多いと評価が曖昧になる
• 決裁する立場の人には、開始時と報告時の最低2回は同席してもらう
• 進んだ後の計画は90日分。1年先まで書かない
• 報告から次の打ち合わせまで、2週間以上空けない

この範囲で設計すれば、止まる確率がかなり下がります。

検証まで進んだ案件は、失注させるにはもったいない段階にあります。

技術の話に集中しすぎず、判断する人の立場から設計を見直すことが要点です。

止まった案件を追う

止まってしまった案件も、諦める必要はありません。

多くの場合、予算の時期が合わなかっただけということがあります。

次の年度の予算編成の時期に、改めて連絡する価値があります。

検証まで進んだ相手は、他社より圧倒的に理解が進んでいます。

一から説明する新規の相手より、はるかに近い位置にいます。

止まった案件の一覧を作り、予算の時期に合わせて再接触する運用を持ちます。

よくある質問

相手が成功の基準を決めたがりません

外すのが怖いという心理が背景にあります。基準に届かなかった場合の扱いを一緒に決めると、抵抗が減ります。「届かなければ条件を変えて再度試す」といった取り決めを、開始前に文書にしておいてください。

決裁する人に会わせてもらえません

担当者が社内で調整できていない可能性があります。無理に会おうとせず、担当者が社内で説明しやすい資料を用意する形に切り替えます。業務の指標と費用の比較を1枚にまとめると、そのまま回覧してもらえます。

実際のデータを出してもらえない場合はどうしますか

守秘の制約がある場合が多いので、一部を加工した形を提案します。氏名や金額を置き換え、揺れや欠けの構造だけを残す形です。それも難しければ、検証の結果に「見本のデータでの結果である」という但し書きを明記します。

検証の費用はどれくらいが適切ですか

一概には言えませんが、本契約の金額の1割程度を目安にする例があります。金額の多寡より、相手の社内で予算として扱われることに意味があります。無償にするなら、期間と工数の上限を明確に決めておいてください。

検証が失敗したときはどうすべきですか

原因を切り分けて共有します。条件の問題なのか、技術の限界なのかを分けて示すことが誠実な対応です。条件の問題なら、次の提案に繋がります。技術の限界なら、その旨をはっきり伝えたほうが信頼が残ります。

まとめ

検証が契約に繋がらないのは、技術の問題ではないことがほとんどです。

目的が曖昧なまま始まり、成功の基準が技術の指標だけで置かれています。

責任者が関わっておらず、現場も巻き込まれていません。

そして、進んだ後に何が起きるかの絵が用意されていません。

この4点を設計の段階で押さえるだけで、止まる確率は大きく下がります。

検証は目的ではなく、本番に進むための手段です。提案の時点で本番までの道筋を示せるかどうかが、分かれ目になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。