技術的パートナーシップの危険性(キャズム前のスタートアップの場合) (a16z, Martin Casado)

 

初期のテクノロジ系スタートアップのほぼ全ての会社が、ある時期、他のテクノロジ企業との提携(パートナーシップ)というアイデアに魅力を感じることになります。通常、この原動力となるのは「ある提携を結び、他の会社のリソースを使ったり、既存プラットフォームがもつトラクションを引き出したりすることにより、信頼性、売上、実用最小限の製品 (MVP) を迅速に、しかも自社だけで行うよりも簡単に向上させられる」という、胸おどる非常に魅惑的なアイデアです。リソースに乏しく、プロダクト・マーケット・フィットを示す再現可能な本物の証拠を得ようと奮闘しているスタートアップにとって、それはとても魅力的な案に映るでしょう。

問題は、初期または「キャズム前の」市場である場合、この技術提携はめったにうまく行かない点です。[「技術提携」とは、具体的に言うと、基幹となるビジネスモデルがテクノロジ製品の販売である企業との提携を指します。他企業の製品に関する再販サービスまたは付加価値サービスが基幹のビジネスモデルとなっている流通ルートとの提携は違います。例えば、AWS、Google、Microsoft、Cisco、VMware、Salesforceやその他の製品スタートアップとの提携はどれも技術提携となるはずです。一方、付加価値再販売業者、再販業者、コンサルタント、インテグレーター、流通業者との提携は技術提携ではありません。]

技術提携には「たいていは得られる利益よりも負担の方が重い」 という欠点もあります。実際にはとてつもなく膨大なリソースが必要となり、自社の秘密を漏らし、顧客との関係に損害を与え、自社の今後の戦略的関係にとって毒となるような負担付き条項を結んでしまう可能性があります。私はこの間違いを何度も犯し、そのあらゆる結果に対して代償を支払わなければなりませんでした。私が極めて懐疑的、そして被害妄想的な視点からこの記事を書く理由は、そもそも初めてテクノロジ企業を創業するような人の目には、提携が魅力的に映り過ぎる点にあります。そのため、私はこの記事でややネガティブな意見を述べたいと思います。そして、私自身が無駄にした時間をあなたが節約できることを願います。

他のスタートアップとの提携

自社の準備が実際に整う前、または市場の自社に対する受け入れ準備が整う前の段階で、スタートアップが市場参入の手段として技術提携を利用しようとすることはよくあります。その製品は全ての機能が完成していないかもしれません。コミュニティかまだ小さいかもしれません。あるいは、最もよくあることとしては、市場を開拓する力が存在しない、または成熟していないかもしれません。この時点において、協働できる他のスタートアップを見つけ出すことこそ一つの解決策かもしれないと、創業者が信じることがよくあります。提携にかけ算の効果 (2×2 = 4、やった! ) があることを期待しているわけです。「プラットフォームを相互にサポートする」というのが典型的な案です。各々が単独でターゲットにしている顧客の上位集合をどのスタートアップも利用できるようにすることで、実現可能な最大の市場規模を成長させることを目的としています。

ほとんどの場合、これは全くうまく行きません。共同の取り組みによる付加価値もわずかにあるかもしれませんが、スタートアップを困難に陥れるあらゆる要素も増幅します。これは2乗のリスクです。スタートアップは生き残るために必要なことはなんでもやるでしょう (なぜならそうすべきだからです! )。すなわち、方向転換、隣接市場への参入、製品製造の打ち切り、市場開拓モデルの転換、オープンソース化、展開モデルの転換、価格決定モデルの転換など、枚挙にいとまがありません。スタートアップに関して唯一信頼できる点と言えば、この手の転換が行われる可能性の高さでしょう。多くの場合、これこそが実際のかけ算的な状況です (0.2 x 0.2 = 0.04......なんてこった! )。

共同の取り組みによる付加価値もわずかにあるかもしれませんが、スタートアップを困難に陥れるあらゆる要素も増幅します。これは2乗のリスクです。

リスクの増幅は問題の一つに過ぎません。たとえ大規模な変化によって計画が大きく狂わないような最も安全なケースだったとしても、たいてい起こることと言えば……何も起こらないことです。一方もしくは両方がリソースを費やしたあと、基本事業を優先するために、そのプロジェクトが中止になるでしょう。他方、二つのスタートアップが顧客のトラクションをなんとかして手に入れると、その後に両社が仲たがいする場合も時々あります。その理由は顧客の管理についてだったり、分割された収益の向上についてだったりします。または製品の問題について相手側を責める結果となる場合もあります。

また、このような状況ではいつも、逆選択バイアスが起こりがちです。あるスタートアップにあなたの企業と提携するためのリソースや時間がある場合、その事実こそがそのスタートアップは市場の需要についていこうとして全力を出していないということを、かなり良く示唆しています。Niciraを立ち上げた当初、私たちは新しいOpenStackの企業全てと提携しようと試みました。それから10年経った現在、10社程度のうち残っているのは1社のみです。その1社も私たちが有意義な提携についての話し合いをもったことのない企業でした。彼らは事業の構築に忙しかったのだろうと推測します。

大企業との提携

スタートアップと提携するスタートアップは、かなり急速に明らかな悪化状態へと陥りがちです。他方、大企業は並外れて魅力的な提携先に思えます。大企業には正式な提携プログラムや確立されたブランドがある場合が多いのです。その大企業が市場内の大手であるならば、直ちにイノベーションを起こす準備のできた潜在的な顧客ベースを有しています。そうでないない場合も、その企業には大がかりな市場開拓のための取り組みを始動できるリソースがあります。避ける理由など、どこにもないように思えます。

ですが、現実は厳しいものです。大企業が提携を利用する唯一の目的は、極めて利己的な目標を推し進める点にあります。大企業がいずれスタートアップと対立することになれば (これはよく起こります。あなたの企業が成功し、顧客行動に影響を及ぼし始めている場合は特にそうです)、その提携がすぐさま不利益となるでしょう。共有された知識、与えられたアクセス権、生まれた依存関係は、今やどれもがあなたのスタートアップに対抗する手段として使われます。そしてそれは今後も続きます。

また、大企業は自らが提携している相手とその理由についてよく知っています。大企業の取り組みの大半は他の大企業に向けられたものです。そのような状況において、大企業は競争または協調的な緊張緩和を繰り広げている場合が多いです。大企業がスタートアップとの提携から多くの価値を手に入れることはまれです。そのような提携を行う場合、その一般的な目的はPRです。つまり、自社の新しいプラットフォームや製品の地位を向上させるために行います。大企業はあなたのスタートアップのロゴを自社のプレゼン資料やウェブサイトに追加することや、あなたのスタートアップに注目が集まることで十分に満足します。これはその大企業にとって、実際に全く合理的な行動です。スタートアップの一団がその提携について得意げに話して回ることが、大企業にとっては良いPRやマーケティング活動となります。多くのロゴを追加することで勢いを感じさせられます。

しかし、私たちの業界の歴史では、友好的な提携を結んだあとでさえ、大企業が中小企業に付け込もうと自らの相対的優位性を利用してきた事例が散見されることを覚えておくのも重要です。

提携を結ぶ前に活用できる優れたメンタルモデルとは、「提携を結ぶことが戦略上重要であるならば、『開発か購入か』の判断を開始する。戦略上重要でないならば、それを優先しない」と想定することです。したがって、 何かをやり終えるほど十分な資金力が供給されることは考えにくいとも言えます。どちらにしても、その結果はスタートアップにとって好ましいものではありません。運が良ければ、リソースを無駄にするだけで、何も得られません。運が悪ければ、あなたの会社に対する特別なアクセス権を有した競合相手を生み出してしまいます。

とは言え、提携が必要な場合も時にはありますし、名案と言える場合さえあります。例えばNiciraの場合、さまざまなLinux流通業者、ハイパーバイザ販売業者、クラウド統合管理業者との提携なくしては展開できませんでした。そのため、その先に待ち受けるものを知りながら提携に踏み切りました。常に想定すべきは以下のことです。

  • 提携先はあなたの会社から情報を得る機会を利用します。
  • 提携先は敵対する好機と捉えれば、そうします。
  • あなたの会社が顧客へ接する機会を与えると、提携先は自らの計画を推進するためにそれを利用します。
  • 提携先が戦略上重要な基準点を譲ったり、戦略上重要な得意先と接する機会を与えることはまずあり得ません。
  • 提携先は提携条件、またはあなたの会社が目当てとする技術や経路を変更することによって、あなたの会社を潰すことに良心の呵責を感じません。

忘れてはならないのは、その巨大な提携組織がもつ「マッスルメモリー」はその他の大企業との複雑 (たいていは競合的な) 関係を通して得られたものだということです。笑顔を浮かべながら刺すような行動が予想されるうえ、相手はその経験を積んでいます。

一般的な提携モデル

テクノロジ企業2社が結ぶ提携形態として想定されるものは数多く存在します。以下にスタートアップとそれ以上の規模を誇る企業との間で見られた最も一般的なモデルを取り上げます。また、そこで警戒すべき部分も強調しています。

プラットフォームの統合

構造化された型通りの提携プログラムを通して、自社よりも大きな企業が有するプラットフォームと統合される 「特権」 を与えられたスタートアップを目にする機会は多くなるでしょう。この種の提携により、スタートアップにはパッケージ管理システムのごとく、本来は機密扱いとなるAPI、文書、販売経路へのアクセスが許可されることがよくあります。一部のプラットフォームはこれを相互運用のための要件とし、技術上 (例えばコードサイニング)、または契約上 (例えば、誰かがサポートされていない拡張を実行した場合、サポートを無効化すること) のどちらかの形でそれを強制します。また、主にそのプラットフォームならびにその参加者との相互利益につなげることを目的に、提携をマーケティング手段として利用するプラットフォームもあります。

このようなプラットフォームの統合はスタートアップにとっては望ましく見えることがよくあります。なぜなら、それが自らの製品をより成熟したものに見せてくれるとともに、大企業とより深く、より意義深い (とそのスタートアップが信じる) 関係性を築き上げ、大企業が実際に販売する類いのものとスタートアップの製品をつなげてくれるためです。ですが、プラットフォームがもつリスクとは実は、スタートアップが背負い得るリスクの中でも唯一最大のものと言えます。

大企業は自社開発のサービスを、自社プラットフォーム内で優位な立場に立たせて収益化できる力を常に温存しています。与えられる「特別な」アクセス権は何であれ、いつでも無効にされかねません。そのため、あなたの会社はそれを実行する方法についての情報を提携先に伝えているだけではありません。魅力的な市場を築くことに成功した場合には、提携先が敵対してくることをほぼ確実なものにしています。歴史上、このような事例は使い古されていると言っていいほどにあふれています。Microsoftとそのブラウザ、Appleと音楽、Amazonと幾つものAWSサービスなどです。忘れてはならないのは、大企業にとって、プラットフォームを向上させるために何かを無償で提供することは理に適っているということです。たとえそれが、そのプラットフォームのユーザーを全滅させることになったとしてもです。とても大きな数字にとても小さな数字をかけ合わせると、やはり大きな数字になります。

そうは言っても、プラットフォームの統合が必須であり、避けられない場合も多くあります。例えば、Red Hat Enteprise Linuxをサポートしない場合、企業向けにデータセンター・ソフトウェアを販売するのは困難です。このようなケースでは、明白な (しかし重要な!) 統合のルールを適用します。すなわち、業界標準インターフェースをしっかりと守り、非公開インターフェイスや機密インターフェースよりも公開インターフェースを常に優先するというルールです。これにより、あなたの会社のアクセス権を無効にすることがはるかに難しくなります。そして運が良ければ、異なるプラットフォーム間での移植性も高まるかもしれません。

最後に、そして最も重要な点として、あなたの会社がこの道を進まなければならない場合、大企業との提携を左右する最も強い力は集客力です。提携中の企業が適切かつ必要なリソースをあなたの企業との提携に割り当てること、そしてあなたの企業を悩ませないことを徹底するために、できるだけ多くの顧客を集めましょう。提携を拒んだ、あるいは過度な負担を強いる条項を要求してきた提携先の大企業が、私たちの企業と一緒に働かない限り、自社の大口顧客の一つが契約を更新しない恐れがその後出てきたとき、方針を180度変えるという状況を私は何度も経験してきました。結局、いつでも顧客こそが最大の力を有しています。

結局、いつでも顧客こそが最大の力を有しています。

マーケットプレイスへの参加

その他でスタートアップが魅力を見い出す提携の機会は自社製品をより大きな企業のソリューション・マーケットプレイス (AWS Marketplace、RedHat Ecosystem、Cisco Marketplace、GoogleのCloud Launcherなど) の販売リストに加えてもらうことです。これは顧客をあなたの会社の製品に呼び込むことで販売速度が増加するという考え方によって正当化されるのが普通です。ですが、実のところ、市場カテゴリを作るという状況において、それはめったに起こりません。このようなマーケットプレイス内でのあなたの会社の存在感は単純に、顧客にあなたの会社のソリューションがもつ価値を知らせるほど十分なものではありません。それどころか、購入者との直接的な関係を確立するための価値ある膨大な機会を失うかもしれません。

初期の市場においては、その顧客との話し合いを推進することが非常に大切です。この目的とは、その問題空間に対する顧客の見方を理解すること、そして自社を評価する基準を設定することの2つです。オンラインマーケットはこれに不利に作用する可能性があります。なぜならば、オンラインマーケットは接触の少ない販売を実現するために構築されていることが多いので、自社を紹介する方法に制約があるからです。例えば、オンラインマーケットはそのマーケット内でロゴを整理する方法に基づき、あなたの企業と競合するセットを規定するかもしれません。あるいは、価格設定を公表する他の企業と一緒にあなたの企業をリストに載せたというだけで、あなたの企業とってはあまりにも単純な価格設定モデルが強いられる可能性もあります

市場への参加が初期段階のエンタープライズ向け企業について言えば、(a) 自社がターゲットとする顧客ベースにおいて、そのようなマーケットプレイスを通じて購入するという購買行動がすでに存在している場合、または (b) 重要なプラットフォーム上で活動するためにはマーケットプレイスへの参加が厳密な要件となっている場合、でない限りはオンライン上のマーケットプレイスへの参加は避けるべきでしょう。あなたがその市場の理解し、自社製品について業界内で会話する機会を設け、拡張可能な販売モードを目指してまい進するべく活動する中で、オンラインマーケットへの参入について考えられる否定的側面はその肯定的側面よりもはるかに大きなものです。

共同での市場開拓 (間接的)

ここで言う「間接的な市場開拓」とは、セット売りまたはOEMという形で自社製品を別の製品企業に渡し、その販売力で重労働を代わりにしてもらうような提携を指します。多くのスタートアップは「私たちはBrocadeやIntelのようになって、販売力なしで数十億ドルを稼げるはずだ! 」と考え、これを究極の戦略だと見なしています。

残念ながら、これはあなたの会社を無意味なものにする、途方もなく大きな方法でもあります。早期市場において、OEMやセット販売で既存製品と関係することは 極めて高い自己破壊効果のある仕組みです。これが失敗する場合、考えられる過程は限られています。

  • あなたの企業が価格設定を直接管理できないせいで、自分自身の市場の売り上げを減らします。
  • 手に入れるのにふさわしいだけの価値を引き出せなくなります。その価値を証明するための関係性を持たないことが原因です (早期の市場において、この関係性には深い技術的な話し合いが含まれることもよくあります)。
  • セット売りにより、自社製品がシェルフウェアとなる可能性がはるかに高くなります。これはつまり、更新料を得る可能性が驚くほど低くなるということです。
  • アップセル、市場拡大、クロスセルに関する顧客管理の視点を得られません。
  • ブランドのスティッキネスを得られません。あなたの会社がそのソリューションを動かしていると顧客が知らないためです。そのため、ひとたび市場が成熟すると、よりコストの低いソリューションへと簡単に取って代わられる可能性があります。

ここで伝えたい教訓はとてもはっきりしています。すなわち、早期の市場において、特に難解なテクノロジの場合、顧客管理を失えば、自分の会社を失ってしまうということです。他の製品企業との提携形態として考えられる全てのものの中で、これは最も危険なものです。規則には必ず例外がある、というのは真実です。そして一部のスタートアップはこのような提携から驚異的な成功を達成しています (創業間もないVMwareは顕著な例の一つです)。ですが、これを実行するのは、自社を一つの提携先に縛り付けず、また直接販売を維持できるような並外れて好ましい契約をまとめられる場合に限るべきです。Diane GreeneがVMwareについてOEM戦略を始動させたとき、彼女はDell、HP、IBM、Ciscoとの非独占的なOEM関係を結ぶことができました。そして彼女はこれを行いながら、私たちの業界でかつてないほど最高の企業向けソフトウェア販売チームを築き上げました。その他にはほとんど誰もそのような成功を達成できていませんし、あなたも達成できない可能性が高いでしょう。

共同での市場開拓 (直接的)

共同市場開拓の提携モデルにおいて、スタートアップは自社の販売力をより規模の大きな製品企業と連携させることになります。その基本的なアイデアとは、自社製品を提携先に代わりに扱ってもらいながらも、独立したSKUとして販売すること (前述の間接的な手法とは逆) か、または両社の販売チームが得意先と関わる共同販売の動きをとるかのどちらかです。このモデルが魅力的なのは、販売能力の向上と既存の顧客ベースへの接触を期待できる点にあります。

あらゆる提携モデルの中で、これこそ私が最上だと思うものです。例えば、(かつてVMWareに買収された) NiciraはPalo Alto Networksとの強固な販売提携を結んでいました。ですがこのモデルは市場がもっと成熟した状況で最適となりがちですし、双方からの現実的な関与があって初めて機能すると言って間違いありません。私たちの直接的な共同市場開拓の取り組みは大半が失敗しました。多くは戦略的統制ないし顧客内シェアに関する顧客をめぐる争い、あるいは展開で起きた問題に対する責任追求を含んだ厄介な口論へと変化していきました。

繰り返し述べます。顧客こそが提携を進めるうえで最高の手法です。市場開拓の提携は、一から作り上げる試みというよりも、その市場内にすでに存在するシナジーに対する協調的な反応促進剤と見なすべきです。そのため、より規模の大きな企業と共に共同直接販売の取り組みに従事するのは、拡張および反復が可能な販売を単独で確立していると考えており、さらに自分の会社にその分野における十分な経験があって自社製品が提携予定の企業が有する製品と自然に連携するだろうと分かる場合に限るべきです。

また、あなたの会社は (a) 提携先がその提携に十分に尽力すること、および (b) その販売チームが実際に自社に役立つこと、の2点を確保したいと望むはずです。この場合は通常、あなたの会社を取引に参加させ、その取引を成立させることに対して、その販売チームに何らかのインセンティブを与えることが重要です。これを行うための仕組みは数多くあります。その最も一般的な仕組みはSPIF (販売実績インセンティブ基金、報奨金) を与えて提携先の販売チームがあなたの会社を取引に参加させたり、あなたの会社の製品販売を助けるように仕向けることです。他方の会社に対して自社製品に対する製品固有のノルマを約束させることがよりいっそう効果的です。

提携は現場で成功する時もあれば、失敗する時もあります。行動は常に事業に従うことになり、あなたの会社の提携先がその提携によって儲けられるか否かによって決まります。VMWareがあれほどの成功を収めた多くの理由の一つは、VMwareが1ドルを稼ぐごとに、提携エコシステムが8ドルを稼いだ点にあると私は確信しています。とは言え、どれほど意志や構造、あるいは努力があったところで、何も存在しなければプロダクト・マーケット・フィットは生まれないでしょう。そしてどれほど事業開発のミーティングや重役の言質があったところで、競合的な要素が現場に自然と存在しているならば友好的な関係も生まれることはありません。そのため、提携による共同市場開拓を利用する目的はすでにその分野で有機的に実証されている製品のシナジーを加速させることにとどめ、シナジーを生み出そうとしないことが大切です。

* * *

まさに一見するととても魅惑的に思えるからこそ、技術提携はあれほどよく行われ、あれほどあちこちで過ちを犯しています。もちろん、時には提携も機能します。そして慎重に実行された場合には、双方に恩恵を与える可能性もあるため、提携の話し合いを受け入れる価値はあります。しかし、結局のところ、その市場の自然な吸引力を自社の提携戦略を進めるために活用し、裏切りを警戒し、自社が実利に関する実用的な可能性を得られるように徹底するべきです。さもなくば、報酬を受け取ることなく会社を事実上売ってしまうことになりますし、それを行うために多くのリソースを浪費することでしょう。

 

著者紹介 (本記事投稿時の情報)

Martin Casado

Martin Casado は Andreessen Horowitz のジェネラルパートナーです。彼は以前、2012年に VMWare に買収された Nicira の共同創業者で CTO でした。VMWare で、Martin はNetworking and Secruity Business のVPならびにGMでした。

記事情報

この記事は原著者の許可を得て翻訳・公開するものです。
原文: The Perils of Tech Partnerships (for Pre-Chasm Startups) (2018)

BFORE (Biz FOR Engineers) はスタートアップに関するノウハウを届けるエンジニア向けのメディアです

運営元