tech venture business » Page 'お客さん内部が競合ということも'

お客さん内部が競合ということも

あっという間にもう2月ですね。ブログの方も頑張らないと、とちょいと気を引き締めつつあります。

さて、最近は新しいプロジェクトも幾つかスタートしているのですが、並行して顧客開拓にも引き続き奮闘しています。私は直接の営業担当ではなくその術を学び中ではあるのですが、良い製品やサービスを持っていても新しいお客さんを得ることはなかなか難しいものだな、と日々感じています。

皆さんは自社の製品やサービスの営業をする時に、どの様な障壁にぶつかりますか?競合している他のベンチャーですか? それともブランドもありサポート体制もしっかりしている大手でしょうか?

私が以前コンサルティング業をしていた時によく遭遇し、今のM&Aアドバイザリー業でもたまに遭遇するのが、「うちは自前でやれるから」という潜在顧客からのお言葉です。敵は競合他社ではなく実は顧客自身であった、というケース。これはサービス業だけでなく様々な業界業種にも当てはまると思うのですが、如何でしょうか?

そうした場合にどの様に対処するかということに関して、度々引用しているOnStartupsブログに興味深いエントリーがあったので意訳してご紹介します。筆者の企業向けソフトウェア業での経験に基づき、顧客の側での決断は、しばしば“should we buy this software from Company A or Company B”ではなく“Do we buy this from Company A or do we build it ourselves?”ということがあるとして、以下の対処法をあげています。

①Accept That They Can Do It: 確かに顧客自身で出来るということを認めよ

「顧客企業は巨体すぎて我々のように素早く動き問題を解決する事ができない」「自分達が理解しているほどには顧客はこの問題に関して理解がない。これは難しい問題で彼らにはできっこない」「彼らはたくさんのITリソースを抱えているが、この部署は社内でプロジェクトの承認を受けられることはないだろう」等のような様々な理由から、ベンチャーである我々は顧客が自力で出来る訳が無いと思ってしまいがちである。しかしこの考え方は危険である。それはあなたが間違っているからではなく、こういった顧客からの反発に対処する最悪の方法は、顧客が本当は自力ではできないと納得させようとすることだからだ。これに対処する鍵は、顧客が自力ではすべきではない、と納得させることなのだ。

②The Core Competency Argument: コア・コンピタンスの論拠

すべきではないことの理由付けとして適しているのはこのシンプルな質問をすることだ。「恐らくご自分でこのソフトウェアを開発/統合することは出来るでしょうが、それって本当に御社のビジネスなんでしょうか?」「御社がビジネスを成長させ差別化をはかる上で、この問題を解決することは本当に自社の貴重な時間とリソースを費やして行うべき事なのでしょうか?」この議論に様々な理由をつけて反対する会社もあるが、そういう会社はさくっと諦めるということもあり得るだろう。

③The Heroes and Legends Argument: ヒーローと伝説の人の論拠

こうした「買うか作るか」の状況に遭遇している場合、意思決定者がIT部門の上の方の人であることが多々あるため、その人の立場になって考える事が重要である。その際に有効なのは、これは派手でも面白くもないので自力でやりたくないと思わせることである。「これはかなり泥仕事ですよ。こんな退屈なプログラムを作るのに本当にこの数年を費やしたいんですか?もし成功したとしても、このプロジェクトは役員があなたをヒーローだとか伝説的だと思うようにできるものですか?このプロジェクトは社内の最も優秀なリソースを引き入れられるものですか?」といった問いかけは効くことが多い。なぜなら、IT部門の人は醜く退屈で時代遅れなことをするのを嫌い、より社内で認識され組織にとって計測可能なインパクトがあるような、かっこよく面白いことがしたいからだ。(これはまたボーナスにも結びついていることが多い)

④The Risk / Reward Argument: リスクと報酬の論拠

ベンチャーには顧客企業より有利なことが1つある。それは、この解決しようとしている問題こそが、ベンチャーが全時間を費やしているものだということだ。一方、顧客企業は同時に百もの他の心配事やプロジェクトがある。早期のベンチャーの場合、顧客企業よりもはるかに安くこの問題を解決できる。皆が自社で開発するよりもあなたのソフトウェアをライセンスした方が安上がりなことは分かっているが、問題はむしろコストではなくて、コントロールできない事とそれによるリスクであることが往々にしてある。そのリスクを軽減することができれば自分の方に好機は訪れ得る。その方法は色々とあるが例を上げれば、私は顧客に自力開発のプロジェクトを遂行するのと並行して、R&D予算で自社のソフトウェアをライセンスすることを勧めたことがある。本当に自力開発するとしても、バージョンアップした当社のプロダクトから学ぶ事もあるかもしれないからという理由だったが、結局顧客のプロジェクトは上手く行かずに当社のその後7年における最良の顧客となったのだった。

如何でしょう。ソフトウェアの例を引いてはいますが、結構使えることがあるのではないでしょうか。バックオフィスをサポートするような製品の場合はコストの面が最大の関心であることは多いですが、顧客の製品やサービス自体に深く関与する類の製品の場合は、時間と精度ということが決断の非常に大きな要素になると思います。顧客にとって差別化された自社製品を早く市場に投入することは、競争に勝つ上で非常に重要ですし、誤れば開発のコストだけでなく更に大きな損害を被る事になります。こういったケースでは、この時間と確実性の観点を強調するのも効果的だと思います。

実はこの「買うか作るか」という悩みは、製品やサービスだけでなく、大手の企業がテクノロジーベンチャー企業自体を買収するかどうかの決断にも当てはまります。通常、ライセンスを得るのではなく買収という形をとるのは、自社で完全にコントロールしたいという目的が最大のモチベーションです。自社がそのテクノロジーを掌握する事で競合他社はアクセスを遮られるので優位に立てるという場合や、自社の足りない部分を迅速に補強することでより早い市場展開が可能になる、等のケースがあります。日本ではこうしたM&Aの形はまだ少ないですが、シリコンバレーや他の欧米企業が頻繁に行っているこのアプローチを、日本企業は一考されても良いのではないでしょうか。

顧客開拓において、他にどの様な障壁に遭遇しているか、また障壁をどの様に乗り越えているか等の経験談をお寄せ頂けると嬉しいです。

ではまた。

2 comments to “お客さん内部が競合ということも”

  1. TVBさん(省略しました)、先日はどうもでした。楽しかったです。また飯食べに行きましょう。

    お客さんの内部が競合他社という場合は、特に大手を相手にしていると多々ありますね。
    ただ、特に日本の大手企業の場合は部署間で意思疎通がなかったりもしますので、「知らなかった」という場合や、部署間でも取引がある場合は、「同じ会社から調達するよりも安い」という理由でお付き合いが始まる場合もあります。

    ただ、大手企業の場合は、「他から持ってこなくても、自分達でできる」ということもあるかと思いますし、実際にそうである場合も多いのですが、すぐにエンジニアをアサインできる状態ではない場合が多々あります。
    「やろうと思えばできるけど、今はリソースがない。しかし、できればその製品をすぐに活用したい」という状況が多い感触があります。

    米国の場合も基本はそうなのですが、イチから作ることに関しては、日本企業に比べると考えない場合が多い感触があります。
    TBVさんの先日のお話の通り、それにかかる期間を冷静に見つめて、そのテクノロジーを独占保有することが自社の今後にとって有益であると判断した場合は、買収する形になるのがほとんどでしょうね。
    日本企業の場合、テクノロジーで買収という形になることは一部サービス業等を除き、ほとんどないような気がします。
    この辺で先日面白い話を聞いたので、次回お会いした際にでもお話しますよ。

    ではでは。

  2. 中川さん

    こちらこそ、先日はどうも。面白いお話を色々と伺い、大変刺激的でした。ぜひまたご一緒させて下さい。

    >部署間でも取引がある場合は、「同じ会社から調達するよりも安い」という理由でお付き合いが始まる場合もあります。

    そうなんですか。同じ会社の方が高いって、中々飲み込めないものがありますね。

    よく欧米の方に「日本企業にはとても大きなNIH (not invented here)の問題があると思う」と言われることがあります。私はそういった傾向がある会社もあると思うが、どちらかというと会社に対する帰属意識というところから発するもので良いものであれば吸収する素地はあると思うし、逆にアメリカではエゴっぽい意味でNIHの特徴を強く持つ会社や部署があると思うと応えています。

    こういったご経験はありますか?

Leave a comment

XHTML - You can use:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>