監修：平野 哲也（株式会社オンリーストーリー 代表取締役）

検証結果は悪くないのに、追加検証の要望だけが積み重なる商談は珍しくありません。

PoCが終わる条件と、本導入を判断する条件は別物です。

PoCの終了と本導入の判断は異なる

検証結果は悪くないのに、PoCが終わっても本導入の話が進まない。

追加の検証を求められ、当初の目的が分からないまま期間だけが延びている。

BtoBのIT・SaaS商談では、試すことには合意できても、その後に何を判断するかが決まっていない場合があります。

PoCは、実現可能性や適用可能性を限られた範囲で確かめる検証です。

本導入では、それに加えて、業務で継続して使えるか、担当や費用を確保できるかなどの判断が必要になります。

そのため、技術的に動いたという結果だけで、購入や全社展開が決まるとは限りません。

本記事では、営業の立場から、PoC開始前に決める評価基準、検証中の変更管理、終了後の判断の進め方を解説します。

PoCから本導入に進まない主な原因

PoCが本導入に進まない背景には、製品の力不足や顧客の意欲だけでは説明できない要因があります。

ここでは、試す目的、成功条件、検証担当者と導入判断者のつながり、本導入時の運用、費用と導入範囲という五つの観点から主な原因を整理します。

自社の商談がどこで止まっているかを確認する手がかりにしてください。

原因1 試す目的が曖昧になっている

まず試してみるという合意だけで始めると、結果を見ても成功かどうかを判断できません。

新しい技術を知りたいのか、特定の業務に使えるか確かめたいのか、導入候補を絞りたいのかで、必要な検証が変わります。

目的が情報収集なら、それ自体は問題ではありません。

ただし、営業側だけが受注を前提として準備を進めると、期待がずれます。

開始時点で、今回の検証がどの判断につながるのかを合わせる必要があります。

原因2 成功条件が後から追加される

当初は処理できればよいという話だったのに、終了時には別の業務や大量のデータへの対応まで求められることがあります。

必要な条件が検証を通じて明らかになることはありますが、評価範囲を更新しなければ、いつまで経っても完了できません。

当初の条件で確認できたことと、新しく検証すべきことを分けて扱いましょう。

原因3 検証担当と判断者がつながらない

現場の担当者が試用していても、予算や運用を判断する責任者が結果を確認する予定になっていない場合があります。

その状態では、検証レポートを渡しても、次にどこで検討するのかが決まりません。

誰が結果をまとめ、誰が導入の可否を判断し、どの場で確認するのかを整理します。

営業がすべての関係者に直接会うことだけが方法ではありません。

担当者を通じて必要な判断事項を確認し、結果が届く経路を合意することも重要です。

原因4 本導入時の運用が未検討

PoCでは詳しい担当者が支援して動かせても、通常業務では同じ体制を続けられないことがあります。

誰がデータを準備し、エラーを確認し、結果を業務へ反映するのかが未定なら、本導入は判断しにくくなります。

検証時だけの特別対応と、本導入後の標準的な作業を分けて示しましょう。

原因5 費用と導入範囲が後回し

無料や小規模な検証に合意できても、本導入の費用や対象人数を検討していない場合があります。

最終見積もりを最初から確定する必要はありませんが、想定する規模と費用の考え方は共有しておきます。

検証終了後に初めて大きな費用が必要だと分かると、別の検討を最初から始めることになります。

開始前に導入判断の確認表を作る

PoCを本導入の判断につなげるには、何が分かれば導入を決められるかを開始前に顧客と合意しておくことが重要です。

ここでは、解決したい業務課題の絞り込み、評価する項目と測定方法の決め方、合格・追加確認・見送りの条件の用意について説明します。

あわせて、技術・業務・運用・費用に分けた評価項目の表、問い合わせ対応の検索支援を検証する仮例、時間削減を測るときに作業範囲をそろえる考え方も紹介します。

解決したい業務課題を一つに絞る

検証対象を広げすぎると、どの結果が重要なのか分かりにくくなります。

たとえば、社内文書の活用全体を改善するという目標より、問い合わせ担当が必要な規程を探す業務を対象にする方が確認しやすくなります。

対象とする利用者、データ、作業の始まりと終わりを整理します。

関連していても今回扱わない業務は、対象外として明記します。

評価する項目と測定方法をセットで決める

精度が高い、使いやすいという表現だけでは、評価者によって結論が変わります。

何を一件として評価するか、誰が確認するか、どのデータを使うかを決めます。

人の判断が必要な項目では、正しいとする条件や、意見が分かれたときの確認方法も整理します。

検証後に都合のよいデータだけを選ばないよう、対象を選ぶ考え方を先に合意しましょう。

合格・追加確認・見送りの条件を用意する

成功か失敗かの二択だけでは、一部の条件を満たした結果を扱いにくくなります。

想定範囲で本導入へ進める、対象を限定すれば進める、重要な未確認事項がある、現時点では見送るという選択肢を用意します。

追加確認する場合も、何を確認すれば結論を出せるのかを決めます。

延長すること自体を次の行動にしないことが大切です。

評価項目は技術・業務・運用・費用に分ける

観点	確認する内容	判断のために残す情報
技術	想定条件で必要な処理ができるか	対象データ、処理条件、成功と不成功の結果
業務	現在の作業に役立つか	作業手順、確認や修正を含む負担、利用者の評価
運用	継続して利用できる体制があるか	担当、例外対応、日常の作業、支援範囲
費用	想定範囲で費用を負担できるか	利用規模、費用の前提、追加対応の条件
判断	導入の可否を決める経路があるか	判断者、確認する場、必要な資料と予定

すべての項目をPoC内で実測する必要はありません。

実測できる項目、資料で確認する項目、本導入の前に別途確認する項目を分けておきます。

未確認であることを明示できれば、そのまま導入へ進めると誤解されることを防げます。

仮例 問い合わせ検索支援の検証

以下は評価設計を説明するための仮例であり、実際の製品性能や導入実績を示すものではありません。

社内規程を探す作業について、検索支援サービスが使えるか確かめる場面を考えます。

対象は、よくある問い合わせと、判断が難しい問い合わせを含めて選びます。

簡単な質問だけで構成すると、実業務で困る条件を確認できないためです。

評価では、必要な規程へ到達できたか、誤った情報を示していないか、担当者の確認や修正にどれだけ作業が必要かを分けて見ます。

たとえば30件を評価し、24件で必要な情報へ到達できた場合、その評価集合における到達割合は24件÷30件×100で80％です。

ただし、この数値だけで全業務の80％に対応できるとは言えません。

選んだ質問の範囲、難易度、データの状態に限った結果であり、未評価の業務へそのまま広げないことが重要です。

また、残る6件に重大な誤案内が含まれるなら、単純な平均だけでは判断できません。

誤りの種類や影響を確認し、人の確認が必要な範囲を整理します。

合格とする割合や許容できない条件は、この例の数字を流用せず、対象業務の影響を踏まえて顧客と決めましょう。

時間削減は前後の作業範囲をそろえる

処理時間が短くなっても、結果の確認や修正に時間がかかれば、業務全体では削減にならない場合があります。

比較する際は、入力準備、処理、確認、修正、最終的な完了までのどこを測るかをそろえます。

導入前はすべての作業、導入後は自動処理部分だけという測り方では、同じ条件の比較になりません。

担当者の慣れや案件の難易度にも影響されるため、対象条件を記録します。

少ない件数で得た時間差を、そのまま全社の年間削減額として断定しないようにしましょう。

将来の試算を示す場合は、対象件数、利用割合、確認工数などの仮定を明示し、実測と分けて扱います。

検証中は変更と未確認事項を管理する

PoCの検証中には、追加要望や途中で見つかった制約によって、当初の条件が変わることがあります。

ここでは、追加要望と今回の範囲の関係の確認、途中結果の共有、データ不足と効果がない結果の区別について解説します。

追加要望と今回の範囲の関係を確認する

別部署でも使いたい、対象データを増やしたいという要望は、新しい可能性でもあります。

ただし、そのまま現在のPoCに組み込むと、検証条件や終了日が変わります。

当初の目的に必要な変更なのか、本導入後や次の検証で扱う内容なのかを分けて相談します。

追加する場合は、評価項目、必要工数、期限、判断への影響を更新します。

途中の結果も共有する

終了直前まで課題を伏せると、顧客が対応を検討する時間を取れません。

途中で見つかった制約や、用意したデータでは確認できない項目を共有します。

途中経過は最終結果と混同しないよう、現時点の確認範囲であると明示します。

営業担当者は、技術担当者の結果を都合よく言い換えず、顧客の判断にどう影響するかを一緒に整理します。

データ不足と効果がない結果を分ける

必要なデータが揃わず評価できなかった場合、それは性能が低いという結果とは異なります。

一方で、評価できなかった項目を成功扱いにすることもできません。

未評価の理由と、評価を行うために必要な条件を記録します。

追加で確認する価値があるかは、その項目が導入判断にどれだけ重要かを基に判断しましょう。

終了報告は結果と次の判断をつなげる

終了報告は、検証結果を並べるだけでなく、顧客が次の判断に進むための資料として作ります。

ここでは、成功した画面だけを並べない報告の考え方と、報告書に含める項目を紹介します。

成功した画面だけを並べない

報告書では、最初に合意した目的と対象範囲を示し、評価項目ごとに結果を整理します。

成功、不成功、未評価を分け、判断の根拠となる条件を残します。

よい結果だけでなく、制約や本導入前に解消すべき点を示すことが、顧客の検討を支えます。

報告書に含める項目

• 検証の目的と、対象業務・対象データ
• 評価項目、判定条件、測定方法
• 確認できた結果と、その根拠
• 未達の項目と、想定される影響
• 未評価の項目と、確認できなかった理由
• 本導入時に必要な担当・作業・費用の前提
• 選択肢と、それぞれに残る確認事項
• 次に判断する人、場、予定

この構成であれば、検証に参加していない責任者も、何が分かり、何が残っているかを追いやすくなります。

営業資料として見栄えを整える前に、合意した条件との対応が抜けていないかを確認しましょう。

終了後の選択肢を四つに分ける

PoCの終了後は、本導入するかしないかの二択ではなく、複数の選択肢から次の判断を選びます。

ここでは、予定した範囲での本導入、対象を限定した導入、論点を絞った追加検証、保留または見送りの四つについて、それぞれ確認することを解説します。

選択肢1 予定した範囲で本導入へ進む

必要な条件を満たし、運用体制と費用の確認も進められる場合は、具体的な導入計画へ移ります。

対象人数、開始に必要な準備、顧客と提供側の役割を整理します。

PoCで営業や技術担当が代行した作業についても、本導入では誰が担うかを確認します。

選択肢2 対象を限定して導入する

一部の業務では有効でも、すべてに広げるには課題がある場合、部署や用途を限定する選択肢があります。

限定した範囲で顧客の目的が達成できるか、残る業務との併用が可能かを確認します。

全社展開を約束したような説明をせず、今回導入する範囲と将来の検討を分けましょう。

選択肢3 論点を絞って追加検証する

追加検証が必要なら、導入判断を止めている項目を明確にします。

同じ条件で同じ作業を繰り返すだけでは、結論が変わらない可能性があります。

新しいデータ、異なる運用条件、必要な担当者の評価など、何を変えて確認するかを決めます。

追加分にも終了日と判断条件を設定します。

選択肢4 保留または見送りにする

必須条件を満たせない、運用を担えない、現時点の優先順位が低い場合は、保留や見送りを選びます。

検証で導入しない理由が明らかになったことも、判断に必要な成果です。

保留の場合は、予算方針や運用体制など、何が変われば再開するかを記録します。

見送る場合も、確認済みの結果を残し、同じ条件の検証を繰り返さないようにします。

本導入が止まったときに営業が確認する質問

PoC後に本導入の検討が止まったときは、止まっている論点を顧客と一緒に整理することが大切です。

ここでは、検証結果、運用、判断の進め方の三つについて、営業が確認するときの質問例を紹介します。

検証結果について

今回の結果のうち、導入判断に十分な項目と、追加確認が必要な項目を教えていただけますか。

当初の確認条件から、変更が必要になった点はありますか。

運用について

本導入した場合、日常の確認や例外対応はどの部署が担当する想定でしょうか。

現在の体制で難しい作業があれば、具体的に確認させてください。

判断の進め方について

次に結果を確認する場と、その際に必要な資料を教えていただけますか。

追加の検証が必要な場合、何を確認できれば判断に進めるでしょうか。

これらの質問は、顧客を急かして結論を迫るためではなく、止まっている論点を整理するために使います。

担当者が答えられない項目は、社内で確認するための形に整えましょう。

PoCの営業管理で残しておきたい情報

開始日と終了日だけでなく、当初の目的、判断条件、延長理由、終了後の状態を記録します。

PoCから本導入への割合を確認する場合は、開始時期や終了時期をそろえた案件群で、観察期間を定めます。

今月の本導入件数を今月のPoC開始件数で割るだけでは、違う案件群が混ざる可能性があります。

また、検討中、限定導入、見送りを区別し、未決着を自動的に失敗として扱わないようにします。

延長が多い場合は、技術的な課題なのか、開始前の目的が曖昧だったのか、判断会議が決まっていなかったのかを振り返ります。

件数を増やすだけでなく、導入判断に必要な情報を揃えられたかを確認することが重要です。

本導入を判断できるPoCを設計する

PoCから本導入に進まないときは、検証の成否だけでなく、目的、評価条件、運用、費用、判断の経路を確認しましょう。

開始前に確認表を作り、検証中の変更を記録し、終了後の選択肢まで合意しておくことで、次に整理すべき論点が見えやすくなります。

営業活動全体で、課題や導入方針を話し合える責任者との接点が不足している場合は、決裁者マッチングを検討する方法もあります。

接点づくりに関心がある場合は、onlystoryのサービス案内を確認してみてください。

PoC自体の評価条件や導入後の体制は、顧客と提供側で具体的に整理する必要があります。

まずは現在進行中のPoCについて、終了日に誰が何を判断する予定かを確認することから始めましょう。

---

よくある質問

Q. PoCの期間はどのくらいが適切ですか

A. 期間の長さより、評価に必要なデータが集まる範囲で区切ることが重要です。

対象業務を一つに絞り、測定方法まで決めてから日程を置きます。

期間を先に決めてしまうと、評価に必要なデータがそろわないまま終了日を迎えることがあるため注意しましょう。

Q. 追加検証を求められたら受けるべきですか

A. 導入判断を止めている項目が特定できている場合は有効です。

論点が曖昧なまま期間だけ延ばすと、同じ状態が繰り返されます。

受ける場合は、追加で確かめる項目と、結果が出たら導入を判断する場を先に合意しておきます。

Q. PoCは無料で実施すべきでしょうか

A. 費用の有無より、本導入時の費用と対象範囲を事前に共有できているかが重要です。

無料で実施する場合も、導入時の前提条件は開始前に提示します。

費用の前提を共有しないまま進めると、検証後に初めて本導入の金額が問題になり、判断が振り出しに戻りやすくなります。

Q. 現場の評価は良いのに決まらないときは何を確認しますか

A. 検証結果を確認する責任者と、その場が予定されているかを確認します。

本導入後の運用担当や費用の前提が未検討のまま止まっていることもあります。

判断する人と場が決まっていなければ、結果の報告日に責任者が同席できるよう日程を調整しましょう。