大企業がスタートアップと勝負するべきではない

Atsushi Takayama
4 min readJan 13, 2019

--

「大企業でイノベーションが生まれない理由」って何だろう?を突き詰めていくと、「大企業がイノベーションを生む必要なんて無いのでは?」と思い始めました。

ここでいう大企業というのは、プロダクトマーケットフィットができて急拡大フェーズもしばらく続いて社員数もそれなりになった後の会社のことです。100→1000フェーズぐらいのイメージです。

スタートアップの強みの一つは、社員がまだ少なくて固定費がかからないことです。そのため、大企業と同じ売上規模を目指す必要がありません。成長が止まったら雇用を増やさなければ良いだけです。

大企業の新規事業はそんな生ぬるいことは言ってられません。少なくとも本業の数割の収益を目指すのが至上命題です。そもそもゲームの前提も勝利条件も違うので、スタートアップに憧れて闇雲に新規事業をやるべきではありません。

もちろん、大企業でありながら完全に事業をピボットしてから急拡大した会社は最高にクールであることは言うまでもありません。日本だとmixiとかLINEの例があります。

その他大勢の「普通の」大企業にできることは、せいぜい次の2つなのではないかと。

スタートアップ界隈全体を凌駕するスピードでPDCAを回す

スタートアップのもう一つの強みは、既存のシステムの「技術的負債」に縛られずにゼロからシステムを作れることです。しかも、その時点で最もアジャイルなツールを選べます。

逆に、大企業にとって既存システムはスタートアップが喉から手が出るほど欲しい「既に検証済みの仮説」であり、「プロモーション費をかけなくても得られるデータ」です。

ここを最大限に利用しない手はありません。

そういうわけで、大企業が取るべき戦略は、既存システムの開発人数を単純に増やすのではなく、既存システムを土台として、その上で最速でPDCAを回せる環境を整えることです。

ウェブサービスであれば

  • 誰でも簡単にABテストできる仕組みを整える(chankoなど)
  • ログデータ収集基盤とBI環境を整える(例えばBigQueryとTableauなど)
  • UIコンポーネント集を作ったり、ページの構成を決めてしまってバックエンドエンジニアがフロントエンドのコードをほとんど書かないでもPDCAできる状態にする
  • APIを規定してフロントエンドエンジニアがバックエンドのことを知らずにPDCAできる状態にする(SwaggerやgRPCやGraphQLなど)
  • レコメンド枠を作ってレコメンドエンジニアだけでPDCAできる状態にする

等々、とにかく少人数チームが自分たちの守備範囲だけでPDCAできる状態を作ります。つまり、「制約を与えてスピードを出す」ということです。

ABテストを使い倒すことで、開発人数が増えてもコアを極限までシンプルに保つことができます。

Zyngaという会社がそういう方式でゲームを作ってるのが話題になりましたが、これを超絶な大規模でやっているのがFacebookなのだと思います。彼らは「タイムライン」という形にたどり着いた後は、ひたすらそのアイテムの順番や内容をPDCAしまくってます。FacebookからGraphQLやReactNativeが出てきた理由がわかりますね。

PDCAチームを仮説に合わせて柔軟に作れるのも大企業の大きなアドバンテージ

10年20年を決定づけるような長期的なトレンドを見逃さず集中的に投資する

長期的なトレンドを俯瞰してみると、「絶対に揺るがないトレンド」が見えることがあります。

例えば今後10年でいえば、高齢社会やインドの経済成長や5Gなど。あと上に書いたような開発スタイルの変化ですね。世の中はテクノロジーを利用してより単位労働時間あたりの収益が増える方向に向かっています。

そういうのが自分たちのビジネスドメインにどう影響を及ぼすのか、というのを突き詰めて考えて、先手を打つべきです。

これはスタートアップもしつこいほどアドバイスされていることですが、自分たちのビジネスドメインの長期的将来を常に考えているから見えることもあります。

それこそが大企業の幹部の仕事なのです。

「起業の科学」はとても良い本です。大企業にとっては、敵を知るための本です。

--

--

Atsushi Takayama

NewsPicksで2020年からCTOを、2022年からはFellowをしています。その前はピクシブでCTOをしていました。Courseraでイリノイ大学の大学院をやっています。