成功を予測する POC と、全員の時間を無駄にする POC

概念実証（POC）が答えるべき問いは1つです。この製品は、自社の環境における自社固有の課題を解決するのか。ところが実際には、B2B の POC の多くは別の問いに答えています。このベンダーのセールスエンジニアは、自社のロゴ入りで見事なデモを披露できるのか、という問いです。

有用な POC と芝居じみた POC の差は非常に大きなものです。その違いを見分けられない買い手は、質の低いデータで高額な意思決定を下すことになります。評価の間は誰もが軽く流していた連携の複雑さが、契約から6か月後に、誰も予算を組んでいない6週間の IT プロジェクトとして姿を現すのです。

これはベンダーの倫理の問題ではありません。ベンダーは POC を、失敗の要因を洗い出すためではなく、受注するために組み立てます。本当に確かな判断材料を生む評価を設計する責任は、買い手にあります。Harvard Business Review による B2B の購買意思決定の調査は、評価基準を事前に定める買い手のほうが、ベンダー主導のデモに頼る買い手よりも長期的に良い成果を得ることを、以前から指摘しています。

POC が見せかけになっている5つのサイン

より良いプロセスを設計する前に、芝居じみた POC がどのようなものかを知っておきましょう。これらのパターンはありふれており、大型の評価であれば、たいていの買い手が少なくとも2〜3つには出くわします。

ベンダーが管理するデータ。 POC が、ベンダーのサンプルデータ、あるいはベンダーが用意した御社データの無害化版だけで動いています。エッジケース、過去の不整合、標準外のフィールド名を抱えた御社の実データは、システムに一度も触れません。デモがきれいに見えるのは、データがデモのために整えられているからです。

書面の成功基準がない。 POC の前に、評価するのは「使いやすさ」と「連携能力」だと全員が合意します。しかし、それが何を意味するかは誰も書き留めません。6週間後、ベンダーが首尾を尋ねると、推進者は「かなり良かった」と答えます。ところが調達部門と IT 部門は、まったく別の期待を抱いていて、それが表に出ることはありませんでした。

すべてのセッションをベンダーが進行する。 有用な POC では、御社のチームが実際に製品を使います。芝居じみた POC では、毎週火曜にベンダーのセールスエンジニアが御社のチームに製品を実演します。ユーザー自身が作業をしていなければ、使いやすさを評価したことにはなりません。評価したのは、ベンダーのプレゼン能力です。

スケジュールを調整しないままの範囲拡大。 POC は、CRM 移行の評価として始まります。3週目になると、ベンダーは「すでにセットアップ済みで、プラットフォーム全体の価値をお見せできます」と、マーケティングオートメーションモジュールの評価も提案してきます。範囲は倍になりました。スケジュールは変わっていません。当初の範囲に対する評価の深さは、半分に削られました。

失敗とはどういう状態かの議論がない。 よく設計された POC は、どのような結果なら購入しないのかを事前に定めています。購入だけが唯一あり得る結果であるかのように全員が動いているなら、それは評価ではありません。振り付けられたクロージングです。

有用な POC が事前に定めておくべきこと

POC の質を最も左右する要因は、最初のベンダーキックオフの前に、買い手が POC設計ブリーフを書いたかどうかです。ほとんどの買い手は書きません。そのブリーフに盛り込むべき内容は次のとおりです。

書面の成功基準。 「使いやすいかを見たい」ではありません。書面の基準とは、たとえば次のようなものです。「ユーザーのオンボーディング：パイロットユーザーの80%が、5営業日以内にサポートの介入なしで最初のコアワークフローを完了する」。あるいは、「CRM 連携：連携元の CRM におけるすべてのディールステージの変更が、15分以内にこのプラットフォームに反映される。10日間の観察期間で検証する」。これらは反証可能です。合格か不合格かが決まります。合格したかどうかを議論する必要はありません。

デモデータではなく実データ。 御社の実データは、最良のストレステストです。POC を始める前にベンダーが御社のデータ構造を理解する時間が必要なら、それは構いませんが、POC そのものは、最も乱雑な部分も含めて、御社の実データの代表的なサンプルで実施すべきです。この過程で浮上する連携上の疑問は、いずれにしても契約後に表面化したはずです。稼働開始後の10週目より、2週目に見つけるほうがはるかに有利です。データクレンジングと重複排除のガイドは、POC 前の準備として有用です。きれいなデータは、乱雑なデータが隠してしまう本当の連携の問題を、より早く明らかにします。

連携スコープの定義。 POC を始める前に、このツールが接続する必要のあるすべてのシステムを列挙します。「いつかあるかもしれない」ものは対象外です。基本ユースケースの成立に必要な連携だけを挙げます。連携ごとに、誰が担当するのか（IT、ベンダー、共同）と、受け入れ基準を定めます。そうすれば、のちに案件（と導入）を潰す、隠れた連携の複雑さが見えてきます。

意思決定のスケジュール。 POC には終了日があり、その終了日は、購買委員会が POC の結果に基づいて決定を下すために再び集まる日です。次のステップを計画するための「振り返りコール」ではありません。意思決定のための会議です。会議が延期されれば POC もそれに合わせて延長されますが、評価のあとに決定が続くという期待は、最初から確立されています。

役割と責任。 御社側で POC を担当するのは誰でしょうか。ベンダー側の主要な窓口は誰でしょうか。パイロットのワークフローを実行する責任者は誰でしょうか。これが重要なのは、買い手側の誰も明確なオーナーシップを持たず、全員が本来の業務を続けるなかで評価が裏で進んでいると、POC は運用面で失敗するからです。

ベンダーのインセンティブ問題

ほとんどの購買ガイドがはっきり言わないことがあります。ベンダーは、POC が成功することを望んでいます。それは不誠実ではありません。合理的な行動です。ただし、ベンダーの言う「成功」と御社の言う「成功」は、一致しないかもしれません。

ベンダーにとって POC の成功とは、契約の成立です。御社にとって POC の成功とは、「これは自社で機能するのか」という問いへの正確な答えです。目的が違えば、行動も変わります。

ベンダーは次のように動きます。

• うまく機能する機能へと誘導し、限界が露呈するユースケースからは遠ざける
• 契約後であれば数週間かかるブロッカーを、POC 中は素早く解消する
• 通常の顧客には提供されない専任のサポートリソースを、評価期間中に投入する
• セールスエンジニアが解決できると確信しているため、連携の複雑さを楽観的に説明する（実際に導入チームが取り組むと、そうはいかないことが判明する）

この傾向は、CRM の POC で特に目立ちます。Rework と HubSpot CRMのような比較をすれば、ベンダーがデモで控えめに扱いがちな、構造上の機能差を浮かび上がらせることができます。

これはどれも嘘ではありません。影響の大きい評価に、ベンダーが最良のリソースと最も経験豊富な人材を投入した当然の帰結です。契約後、御社は通常の顧客になります。

つまり、最も楽な道を受け入れるのではなく、POC に積極的にストレスをかけるべきだということです。最も乱雑なデータを使いましょう。うまく機能するか最も自信が持てないユースケースについて尋ねましょう。似たような連携の課題を経験した顧客リファレンスとの会話を依頼しましょう。ベンダーのカスタマーサクセスチームが選んだ顧客ではなく、コミュニティや人脈を通じて自分で探した顧客がよいでしょう。

最も多い3つの POC の失敗

POC が生み出すはずのシグナルを繰り返し弱めてしまう失敗パターンが3つあります。

スケジュールを調整しないスコープクリープ。 見せかけの診断で触れましたが、さらに掘り下げる価値があります。POC のスコープクリープは、ほとんどの場合、善意から生まれます。ベンダーはより多くの価値を見せる機会だと考えます。推進者は、当初計画していなかった機能を評価したがります。委員会の誰かが「X の扱いも見られますか？」と尋ねます。個々の依頼は妥当に見えます。しかし積み重なると、当初のユースケースを深く検証するのではなく、すべてを浅くなぞる評価になってしまいます。

対策：POC設計ブリーフに署名したあとのスコープ追加には、スケジュールの延長を伴う書面の修正を必須とします。無償の拡張は認めません。

成功基準のドリフト。 POC は明確な基準で始まります。3週間が過ぎても、ベンダーは連携基準を満たしていません。話し合いが持たれます。基準は「理想目標」あるいは「フェーズ2」と言い換えられます。POC の終わりには、当初の基準は、「有望なシグナル」や「導入ロードマップ」についてのより穏やかな物語に置き換えられています。

対策：POC ブリーフに署名したら、当初の成功基準は固定します。購買委員会が正式に修正することはできますが、ベンダーが推進者との非公式な会話を通じて一方的に再交渉することはできません。

評価期間中の推進者の離脱。 POC を設計した人が退職したり、優先度の高いプロジェクトに異動したり、この決定をもう担当しない役職に昇進したりします。POC は、組織的な知見を失ったまま続きます。新しい評価オーナーはブリーフを書いておらず、当初の成功基準を理解しておらず、ベンダー主導の再定義に流されやすくなります。

対策：POC の社内オーナーは1人ではなく2人にします。バックアップのオーナーには、最初に基準とアプローチを共有しておきます。主担当が去っても、評価をゼロからやり直す必要はありません。

POC設計ブリーフのテンプレート

ベンダーの POC を始める前に、この1ページの構成を使ってください。

1. ビジネス課題の記述。 1段落で書きます。解決しようとしている具体的な業務上または売上上の課題は何か。「レポートを改善したい」ではありません。たとえば次のように具体的に書きます。「営業チームは、CRM と予測ツールの間でパイプラインデータを手作業で照合するのに週6時間を費やしており、その結果、予測誤差が平均22%に達している」。

2. 成功基準（書面）。 3〜5つの基準で、それぞれ反証可能なものにします。それぞれについて、何を測るのか、どう測るのか、何を満たせば成功とみなすのかを定めます。

3. 連携要件。 基本ユースケースに必要なすべてのシステム接続です。それぞれについて、担当者と受け入れ基準を定めます。

4. パイロットの範囲。 どのチームが、何人で、どのワークフローを担うか。POC の期間中に、通常業務のなかで、実データを使って何を行うかを定めます。

5. スケジュール。 開始日、終了日、主要なチェックインのマイルストーンです。意思決定会議の日程は、POC を始める前に決めておきます。

6. 失敗条項。 1段落で書きます。どのような結果になれば、先へ進まないのか。これは最も有用なセクションですが、多くの買い手が飛ばしてしまいます。これを書くことで、本当は何を懸念しているのかが明確になります。

7. 役割。 主担当とバックアップの評価オーナー、ベンダー側の主要な窓口、IT 連携の担当者、最終レビューの意思決定者リストです。

ソフトウェア POC が備えるべき5つの成功基準

カテゴリーにかかわらず、エンタープライズ向けソフトウェアの POC には、次の5つの基準が何らかの形で含まれているべきです。

コアワークフローの完了率。 ユーザーは、パイロット期間内に、ベンダーのサポートなしで、主要なワークフローを自力で完了できるか。しきい値を設定しましょう。10日目までに80%の完了率が、妥当な出発点です。

連携のレイテンシと信頼性。 必要なすべての連携で、データが定義された時間内（たとえば15分）に、定義された信頼性（たとえば POC 期間中99%以上）で同期されるか。ベンダーに尋ねるのではなく、自分で能動的にテストしてください。

エッジケースへの対応。 自社の環境における標準外の状況を表すユースケースを、3〜5つ特定します。POC の間に、それらを明示的に実行しましょう。ツールが自社のエッジケースに対応できなければ、今テストしておかない限り、契約後に初めてわかることになります。

サポートの対応品質。 POC の間に、簡単な問い合わせではなく、本物のサポートリクエストを送ってみましょう。中身のある回答を得るのにどれだけ時間がかかるか。誰が回答するか。回答は技術的に正確か。契約後のサポート品質は、エンタープライズ向けソフトウェア購入のなかで最も過小評価されがちな要素であり、CRM 導入の展開においても最も明確なシグナルの1つです。

データポータビリティの検証。 POC が終わる前に、システムからデータをエクスポートしましょう。入れたものをすべて、実際に使える形式でエクスポートできることを確認します。ベンダーロックインの問題は、データベースがいっぱいになってからより、契約がまだ空のうちのほうが評価しやすくなります。TrustRadius の B2B Buying Disconnect レポートは、データポータビリティと連携品質が、契約前にもっと厳密に評価しておけばよかったと買い手が考える上位の要因であることを、一貫して示しています。

理想的な POC とは

信頼できる購買シグナルを生む POC には、いくつかの共通点があります。短く、4〜6週間で、終わりが決まっています。実データと実際のワークフローで実施されます。成功基準は、ベンダーのセールスエンジニアが最初のコールに参加する前に書かれています。評価オーナーには「ノー」と言う権限があり、購買委員会の全員がそれを知っています。RevOps 成熟度モデルは、段階ごとにその組織的な準備がどのようなものかを説明しています。レベル3以上の RevOps 機能を持つチームは、通常、その手前の段階にあるチームよりもはるかに体系的な POC を実施します。

また、ベンダー主導ではなく、買い手主導で行われます。ベンダーは支援し、買い手が舵を取ります。これは運用上の大きな違いであり、多くの買い手が意識して確立しなければなりません。放っておけば、ベンダーがその空白を埋めてしまうからです。Forrester のテクノロジー購買調査も、これを裏づけています。体系的で買い手が主導する評価は、ベンダー主導の評価よりも、導入12か月後の満足度スコアが大幅に高くなります。

契約前に本当の問題を浮かび上がらせる POC は、贈り物です。ほとんどの買い手は、その場ではそう受け取りません。成約したかった案件を複雑にする、厄介な評価に見えるのです。しかし代替案は、常により高くつきます。契約に署名して、導入中にそれらの問題を発見するほうが、評価中に表面化させるよりも、はるかに混乱を招きます。

関連記事

• 新しい B2B 購買委員会：会議室に本当にいるのは誰か：POC の結果を承認しなければならないステークホルダーたちです
• ミッドマーケット企業におけるソフトウェアスプロールの本当のコスト：POC での近道が、大規模な連携負債につながるとどうなるか