大企業が新しいサービスに参入して失敗する理由が紹介されていました。

ベンチャーやスタートアップが新しいビジネスを生み出して、それが儲かりそうな雰囲気になってくると資本を持った大企業が参入してきます。

資本があるし、リソースも潤沢、ネームバリューもあるのでうまく行きそうですが失敗することのほうが多いように感じます。その理由のひとつを紹介している記事を見つけました。

多くの企業が新分野に挑戦する際に「スタックの誤謬」を犯し、その結果、劇的に失敗する。

伝統あるデータベース企業が「アプリ化なんか簡単だ」と思ったり、バーチャル・マシンの企業が「ビッグ・データなんかなんということもない」と思ったりするのがよい例だ。われわれはこういう考え方を「スタックの誤謬」と呼んでいる。

スタックの誤謬とは、企業がこれまで積み重ねてきたさまざまなレイヤーの上にもう一段レイヤーを重ねる〔スタックする〕ことを「ごく簡単だ」と思い込むことと定義できる。

〔日本版注〕漫画フキダシ：心理学者「心理学などというのは社会学の応用分野にすぎない」、生物学者「心理学などというのは生物学の応用分野にすぎない」、化学者「生物学などというのは科学の応用分野にすぎない」、物理学者「結局すべての科学は物理学の応用分野にすぎない。一番偉い学問をやっていてよかった」、数学者「おお、なんだきみらはそこにいたのか。まるで見えなかったよ」

漫画のクレジット： XKCD

数学者は往々にして自然界は結局数学の方法で描写できると信じている。つまり、数学者に言わせれば「物理学なんて応用数学の一分野にすぎない」etcというわけだ。

「ただのアプリにすぎない」―スタックの誤謬

実はビジネスの世界でもわれわれは似たような幻想に陥っている。データベース企業は「SaaSアプリなんてデータベースの簡単な応用分野にすぎない」と思っている。こういう幻想は、データベース企業にSaaSアプリを作り、ライバルとの競争に勝ち抜き、新事業を成功させるのは簡単なことだという誤った安心感を与える。

歴史が教えるとおり、下位のテクノロジー要素を苦労して開発したのはそれらのテクノロジーのベンダー企業だったにもかかわらず、クラウドのIaaS分野を支配しているのはオンライン通販から出発したAmazonだ。個別要素技術の開発のパイオニアだったVMwareはAmazonにはるかに引き離され、トップをうかがうどころではない。AWSのサーバーはすべてVMWareが開発し、現にそのコア・コンピテンシーである仮想化テクノロジー上で作動している。にもかかわらずこの市場のかけ離れた1位はAWSだ。またOracleはCRMのSaaS分野でSalesforceに勝てない。Oracleとしては「Salesforceなど単なるデータベース・アプリのユーザーにすぎない」と思っているだろう。実際SalesforceはOracleのデータベース・ソフトウェアを使っている。

Appleはチップを設計し、プログラム言語を作るといった上流から世界の都市に展開されたショップまで、市場の垂直統合に大きな成功を収めてきた。にもかかわらずスタックの誤謬と無縁ではいられない。Appleは一見単純なアプリ―写真共有や地図―を作るのがいかに難しいかを発見しているところだ。

振り返ってみるとこうした例は数多い。 IBMはIBM PCの設計、製造に成功したがそのハードウェアのレイヤーの上にスタックすべきソフトウェアのレイヤーについては深く考えることがなく、結果としてMicrosoftにOS市場を明け渡すことになった。

1990年代にOracleのファウンダー、ラリー・エリソンはSAPがERPを売ってグロテスクなまでに巨大な利益を得ていることに気づいた。ERP（統合基幹業務パッケージ）は各種業務プロセスを自動化するソフトウェアだが、その実体はいくつかのテーブルとそれらを接続するワークフローだ。エリソンは数千万ドルを投じて市場参入を図ったが、結果はまだら模様だった。最後にOracleは顧客管理、人事管理などの優秀なシステムで知られるPeopleSoftとSiebelを買収してアプリ市場で地位を確立することに成功した。

大企業がスタックの誤謬の罠に陥り続ける理由は?

スタックの誤謬はある意味で人間性の本質に基づくものだ。われわれは自分が熟知している分野こそ価値があると考えたがる。読者が仮に巨大なデータベース企業でチップを設計しているとしよう。CEOがあなたに「われわれはIntelやSAPと競争できるだろうか？」と尋ねたとする。「私がチップを開発したのはRDBソフトを走らせるためでそれ以上のことは分かりません」と正直に答えるエンジニアはまずいないだろう。逆に、それまでに蓄積されたチップ設計のノウハウをもってすれば、その上にERPアプリを走らせるという新たなレイヤーを重ねるのは簡単だと考えるに違いない。ERPなどといっても所詮はテーブルとワークフローにすぎない。

成功を阻むボトルネックは、ツールの詳細を知らないことによるのではなく、顧客のニーズを理解できないところに存在する。データベースのエンジニアは顧客が必要とするサプライ・チェーンの管理についてほとんど何も知らず、企業がどんなソフトを必要としているか理解できない。もちろんそうした分野を知っている専門家を雇い入れることはできる。だがそれは〔その企業の〕コア・コンピテンシーを向上させることにはならない。

プロダクト・マネージメントというのはどういうものを作ればいいかを知るというアートだ

イノベーションというのはスタックを下に降りる方が〔既存の知識を利用できるので〕がはるかに容易だ。逆にスタックを上に重ねるのは驚くほど難しい。

エンジニアがスタックを下に降りる場合、自分自身がそうした基礎となるスタックのユーザーであり、何が必要なのかを体験から熟知している。たとえばAppleは次世代のコンピューター・チップに何が必要とされるかを正確に知っていた。Appleは当初からチップ設計の技術を持っていたわけではない。しかし重要なのは顧客ニーズであり、Appleはその部分をよく理解していた。テクニカルな能力が必要ならライセンスを買うことも専門家を採用することもできる。しかし市場のニーズを根底かから正確に把握する能力は金を出せば手に入るというものではない。

これがAppleが半導体の設計と製造で成功を収める一方、マップ・アプリでは失敗した理由だ。

Google、Facebook、WhatsApp

Googleが別の良い例を提供してくれる。Googleはメールと検索の分野で圧倒的な地位を築いており、われわれの興味、関心がどこに向いているかを正確に知っている。しかし、一見するとささいなことに思える「それを利用したアプリ」を作ることができない。つまりソーシャル・ネットワークづくりで失敗している。

これはスタックの誤謬のもっともはなばなしいサンプルかもしれない。既存のレイヤーの上に新たなレイヤーをスタックしていくことは可能だ。難しいのはどんな新しいレイヤーを重ねたらいいのかを知るのが難しいことだ。

プロダクト・マネージメントというのはどういうものを作ればいいかを知るというアートだ

スタックの誤謬という現象は、大企業が一見すると自明なテーマ、つまり熟知している分野なので少し手をのばすだけで十分につかみ取れそうなにテーマに挑んでは失敗する理由を理解するための重要なヒントになる。その答えはおそらく、何（what ）をすべきかがどのように（how）すべきかより100倍も重要だという点にあると思われる。