日本の大企業は、無料トライアルを始めない。
代わりにPoCを求める

▶ 60秒スライド要約 この記事の8枚版もあります。60秒で読めます。 スライドを見る →

Quick Answers

大企業のアカウントが、トライアルにまったく触れないのはなぜですか

トライアルからは、社内に上げられるものが何も出てこないからです。トライアルは一人が自分の中で「使える／使えない」を決めるための仕組みで、その判断が誰かに読まれることは想定されていません。大企業では、その個人的な結論と契約のあいだに、いくつもの読み手が挟まっています。PoCは期間・担当者・評価項目が決まっていて、最後にレポートが出ます。稟議に添付できるのはそちらです。トライアルとPoCは、そもそも別の読者に向いています。

では、PoCはサポート付きのトライアルということですか

管理のされ方が違います。PoCの中心は、開始前に合意する評価項目の一覧です。この一覧が、最終レポートに書けることの範囲を決めてしまいます。多くの場合、情報システム部門と、要望を出したユーザー部門が、自分たちが社内で説明できる測り方を使って作成します。開始前にその一覧を見ていなければ、製品はこちらが関与していない軸で採点されることになります。

TL;DR

日本語のトライアルページは公開済みで、登録もオンボーディングも動いている。それでも、経営会議で名前が挙がる大企業のアカウントは一度も使いません。代わりに、たいてい3回目の打ち合わせのあとで「まず実証実験というかたちで」という相談が来ます。これを「サポートを厚くした長めのトライアル」と読むと、そこから4か月が消えます。トライアルは、買い手が自分で判断するための仕組みです。PoCは、製品を一度も触っていない人たちの前で守れる文書を作るための工程で、期間と双方の担当者と評価項目がついてきます。そして評価項目を書いた時点で、レポートが何を言えるかはほぼ決まっています。書かれる場にいなければ、社内で説明責任を負う人たちが、自分たちが説明できる測り方だけで書くことになります。

Key Takeaways

• トライアルはセルフサービス、PoCは管理された工程。期間が切られ、双方の担当者名が入り、評価項目が事前に合意され、最後にレポートが出ます。読むのはその場にいなかった人たちです。
• 交渉の本体は評価項目。先方だけで作ると、先方が社内で説明できる測り方が並びます。既存製品との差がいちばん出る部分は、行として存在しないことがあります。
• 成果物はレポート。「現場では好評でした」は結果になりません。合意した項目ごとの数値と、その数値が出た条件・限界についての所見が要ります。日本語で。社内を回るからです。
• 無償にも値段がつく。設定作業と研修と日本語のレポートを6週間ぶん無償で出せば、それらの相場がそこで決まります。更新の話も、その数字から始まります。
• 最初の打ち合わせにたたき台を持っていく。評価項目、期間、終了条件、最終日に誰が何を書くか。

その会社では、トライアルのリンクは一度も押されない

日本語のトライアルページを公開して4か月。登録フローは動いているし、オンボーディングのメールも日本語で出ている。ドキュメントも機械にかけただけではなく、人が通してある。中堅企業のアカウントは使っています。個人のエンジニアも使っています。四半期ごとに経営会議で名前が挙がる大企業3社は、一度も開始していません。

代わりに届くのは、窓口になってくれている方からのメッセージです。丁寧で、少しだけ遠回しで、要点は「実証実験」という言葉に入っています。まず範囲を絞って、1部門で試すかたちにできませんか。担当の部署はこちらでつなぎます、と。

本社はこれを「関心はあるが手続きが面倒なだけ」と読みます。そして、その日のうちにトライアル用のアカウントを発行できます、期間の制限もありません、ソリューションエンジニアも付けます、と返す。悪い返答ではありません。ただ、何も動きません。2週間後に、少し言い方を変えた同じ相談がもう一度来ます。

ここまでの流れは、日本参入の現場で繰り返し見てきたパターンを合成したものです。特定の顧客企業や案件を書いたものではありません。

トライアルは「効くか」を聞き、PoCは「効いたと言えるか」を聞いている

セルフサービスのトライアルは、一人が自分の中で意見を作るための道具です。登録して、1週間ほど触って、判断する。その結論は文書にする必要がなく、その場にいなかった誰かに読まれることも想定されていません。部門長が決裁できる市場では、それで十分で、トライアルが評価そのものになります。

窓口の方が依頼してきているPoCは、別の読み手を向いています。その方は決裁者ではありません。出した結論は移動していきます。上長へ、情報システム部門へ、多くの場合は経理へ、金融系であればリスク管理や内部監査へ。その誰も、製品を開いてはくれません。読むのは製品についての文書のほうで、しかも数か月後に、同じ承認枠を争う他の申請と並べて読みます。

だから問いの形が静かに変わります。「これは効くのか」ではなく、「起きたことを、回覧に耐える形で書き残せるか」になる。これは製品への疑いではありません。日本の購買の他の場面と同じ構造です。目の前にいる人は、こちらがいない部屋で守らなければならない材料を組み立てている。本当の会議が会議の前に終わっているのと、同じ理由です。

評価項目を書いた人が、結論のかたちをほぼ決めている

報告までたどり着いたPoCの裏には、必ず評価の表があります。会社によって評価項目と呼んだり評価基準と呼んだりしますが、中身は地味です。数行から十数行、それぞれに確認する内容、測り方、目標値、結果、所見の欄。A4で1枚に収まります。そしてこれが、実質的に交渉の本体です。

放っておけば先方が書きます。書くのは、その表を社内で背負う人たち——情報システム部門と、そもそも要望を出したユーザー部門です。こちらを落とすための材料を作っているのではありません。守れる文書を作ろうとしているので、自分たちが測り方を知っていて、説明の仕方も知っている項目を書きます。

ここから2つのことが起きます。ひとつは、既存製品に対してこちらが本当に強い部分が、行として現れないことがある。表にない項目は、6週間どれだけ良い動きをしても採点されません。もうひとつは逆で、こちらが想定していない行が入る。別カテゴリのツールを評価したときの表を流用していることも珍しくありません。採点表の空欄や「対象外」は、説明を聞いていない読み手には印象が悪く残ります。

対策は地味です。たたき台を出す。日本語で4〜8行、提出物ではなく出発点として渡して、追加と削除をその場で相談する。この状況で「測り方の案を持ってきたベンダー」が疎まれることはまずありません。だいたいは、慣れている会社だと受け取られます。

成果物はレポートです

日本の大企業のPoCには3つがついてきます。3つめを軽く見ている会社が多い。

期間。開始日と終了日があり、終了日は技術的な理由で決まっていないことがほとんどです。報告書が社内の承認のタイミングに間に合うように置かれます。その承認のタイミングは、多くの日本企業では本社とずれた年度に紐づいています。2週間延びたPoCが、本来乗るはずだったサイクルを丸ごと1つ落とすことがあります。

体制。双方の担当者名です。日本側は、こちらの誰が、どういう立場で、どの時間帯にいるのかを知りたがります。「ソリューションエンジニアのチームが対応します」では、そのどれにも答えていません。名前と対応可能な時間帯を出せば、全部に答えたことになります。

レポート。ここが本題です。窓口の方はこれを社内の申請に添付し、その瞬間から、組織にとってはレポートのほうが製品になります。「現場では好評でした」は結果になりません。必要なのは、合意した評価表の各行に入った実測値と、その数値がどういう条件で出たのか、どこに限界があったのかについての所見です。文脈を知らず、好意的に読む理由もない経理の担当者が、6週間後に単体で読んで筋が通る文書であることが要件です。

そして日本語であることも要件です。理由はセキュリティチェックシートが日本語でなければならない理由と同じで、評価に関わっていない人たちのあいだを回るからです。こちらが日本語版を作らなければ、窓口の方が夜に作ります。そしてその方は、自分では出していない数値を社内に対して保証する側に回ります。

「結果を約束できない仕事」の契約の型は、すでに国内にある

この一連の流れが、こちらを困らせるために即興で作られているわけではないことは、知っておく価値があります。結果を事前に特定できない仕事のための言葉は国内にすでにあり、しかも公的機関が出しています。

IPA（情報処理推進機構）は、ユーザー企業とITベンダーのあいだの取引について、モデル契約書を公開しています。第二版のねらいとして書かれているのは、契約の時点で双方が仕様やプロジェクト管理の方法、そして検収の方法について共通理解を持つことです。着手前に受入れの判断基準を決めておくのは、この国では例外的な要求ではなく、前提のほうです。

事前に仕様を固めきれない仕事については、IPAはアジャイル開発版のモデル契約書を2020年3月31日に公開しています。こちらは準委任契約を前提にしており、あらかじめ特定した成果物の完成に対してではなく、ベンダーが専門家として業務を遂行すること自体に対価を支払う形です。契約を結ぶ前に、プロジェクトの目的とゴールが双方で明確になっているかを確認するチェックリストも付いています。

ここから読み取れることが2つあります。結果が保証できない探索的な仕事は、国内の参照モデルでも「有償」が普通だということ。そして、着手前に「何のための仕事か」「どう判断するか」を文書で合わせるのが、押しつけではなく想定されている形だということ。評価項目のたたき台と終了条件の案を持って行くのは、強引なのではありません。国内のやり方を読んできたベンダーの動き方です。

終わらない無償PoC

無償にするのが自然な判断で、その理屈自体は筋が通っています。まだ商談の途中で、製品はもう出来ていて、エンジニアの時間は契約金額に比べれば誤差です。好意で動いている段階に、お金の話を持ち込みたい人はいません。

無償のPoCが長引くと、2つのことが起きます。ひとつは、社内での重みが上がらないことです。何も承認していないので、誰も予算の行に名前を書いていないし、誰も判断に署名していない。他の探索的な取り組みと同じ棚に置かれ、窓口の方の熱量で持っているので、その方が異動すると止まります。

もうひとつは、誰も金額を言わないまま値段が決まることです。設定作業6週間、研修3回、日本語の報告書1本を無償で出したなら、それらの相場はそこで決まります。見積のプロフェッショナルサービス欄はその数字から始まりますし、1年後の更新の会話も同じ数字から始まります。そのときには同じ支援が期待されていて、しかも無償ではなくなっています。

有償にすると、社内で起きることが変わります。費用の承認が要るので承認者が関与し、窓口の方より上の階層でプロジェクトが認識される。それが有利に働くかどうかは会社によります。人員の無償提供より少額の費用のほうが通しやすい会社もあれば、この段階で費用の話を出すと会話が止まる会社もあります。できるのは、無償を既定にするのをやめて、案件ごとに決めることです。

そして有償でも無償でも、金額より終了条件のほうが効きます。最終日に何が出るのか、誰が書くのか、書き上がったあとにどの判断が行われるのか。最初の設定作業の前に、文書で。

最初の打ち合わせに持っていくもの

1. 評価項目のたたき台を、日本語で。4〜8行。確認する内容、測り方、何をもって結果とするか、データを誰が出すか。案として渡して、足すもの・落とすものを聞く。先方がこれを直す時間が、PoC全体でいちばん有益な1時間になります。
2. 終了日と、文書化した終了条件。「様子を見ながら」ではなく、最終日に誰が何を出し、そのあとどの判断が行われるか。PoCと無期限の無償導入を分けるのは、実質的にこの1点だけです。
3. 双方の担当者名と対応時間帯。朝10時の質問に誰が答えるのか。夕方4時に出た質問はどう扱われるのか。
4. 日本語のレポート雛形を、開始前に用意する。先に作ると、「必要になるのに今は出せない数値」がその時点で見つかります。後から作ると、その発見が終了後になります。1度作れば次から使えます。2社目のPoCは同じ構造を埋めるだけになり、3社目は差分の修正で済みます。
5. やらないことを書き出しておく。個別の連携開発、データ移行、常駐での研修。4週目に断ると立場を変えたように見えますが、0週目に決めてあれば単なる範囲の話です。

新しい人員が要る話ではありません。PoCを「製品が付随する文書作成のプロジェクト」として扱い、そこで作ったものを営業担当のフォルダではなく会社の資産として残す、という運用の話です。

その依頼が本当に伝えていること

用意したトライアルではなくPoCを頼まれたとき、窓口の方はすでに「この製品を入れたい」と決めていることが多くあります。PoCは疑っている工程ではありません。こちらの代わりに社内でしなければならない説明を、その方が組み立て始めた合図です。

そう考えると、この依頼は見た目より有利です。採点される前に、その説明の中身——評価項目、日程、誰が読むのか——を見せてもらえる立場にいます。買い手が一人で決める市場では起きないことで、そして多くの外資ベンダーは、その機会を「トライアルのほうが早いのですが」と説明することに使ってしまいます。

日本のパイプラインに「PoC」という段階で止まっている案件があるなら、見るべきは製品の利用状況の数字ではありません。こちら側の誰かが評価の表を見たことがあるか、そして「この日に誰かが何かを書く」という日付が決まっているか。どちらも「いいえ」なら、そのPoCは進行していません。開いているだけです。

Japan Readiness Check では、日本語で出している資料を社内の確認担当者と同じ読み方で追い、先方の評価や承認の手続きが「引用できるもの」を切らす地点をお見せします。

よくあるご質問