事業開発見習い日記

東京でBDやってる人の日記

BD組織の種類とスタートアップが気をつけること

Actually, Founders Should Engage Corporate Development | Andreessen Horowitz

Andreessen Horowitzのブログからの抜粋。大企業のBusiness Developmentの組織の位置づけには2つあるらしい。

  1. Executionだけの場合(エンタープライズ系の企業に多い)
  2. Strategyも持つ場合(コンシューマ系の企業に多い)

1番目のタイプでは、事業部が主導になってディールが行われる。事業部の部長/本部長が「あの企業と何かやれないか」「やる目的はXXだ」と言うのを受けて、BD組織がディールを実行する。既存事業の強化が目的であることが多い。

2番目のタイプでは、BD部門が主導になって、戦略を書いた上で、ディールを実行する。主に事業ポートフォリオの観点から、足りていない機能を獲得するなど、非連続的な成長を、事業とは独立に考える。コンシューマインターネットはほぼ全部これだ。

2番目のタイプでは、必ずしもコア事業の強化ではないため、どのような会社を買いに行くのかは外からは予測が難しい。

 

そして、大企業のBD部門が、(買収でなく)戦略投資を行う場合には、下記の4つのシナリオが多いそうだ。

  1. They have negotiated or have line-of-sight to a commercial deal, and would like to make an investment to fully realize the benefit of that deal.(戦略提携がセットになり、投資はその戦略提携を実現するために行うと考えられている。)

  2.  They want the startup to work on their platform or in their ecosystem. (自社の経済圏に引き入れたいと思っている。)

  3. The technology or space is highly relevant to them, so they would like to use strategic investment as a path to acquisition. (非常に近い領域で投資する。そして買収の足がかりとして使いたいと考えている。)

  4. They are after purely financial returns.(純粋なファイナンシャルリターンは二の次としている。)

そのうえで、対象となるベンチャーにはこう警告している。

Implications for startups:

We typically advise our founders to avoid scenarios #3 and #4, because it can complicate M&A processes. Or, it can lead to an uncomfortable situation if your investor decides instead to compete with you!
#3と#4は避けたほうがよい。M&Aのプロセスが複雑になる上に、のちのち翻って競合化する恐れがあり、ビジネスが危険な状況に陥る可能性がある。

Startups should be fine with reasons #1 and #2, however, because a partner with “skin in the game” as an investor is more motivated and has aligned interests. (A strategic investor that appears on your cap table, but nowhere in your business, is harder to explain — and it’s something you will be asked by subsequent investors, whether financial or strategic.)
#1と#2は、問題ないはずだ。戦略投資は、提携に関してコミットメントを明らかにしているだけで一貫している。(逆に、株主リストに事業会社がいるのに何も提携していないのは説明が難しい。後のラウンドで投資家に質問されるだろう) 

いずれにしろ、変な組み方さえしなければ、スタートアップが大企業のBDと会話をしても、特段害をなすことはないと書かれている。少なくとも、通常の提携の窓口にもなりうるし、中長期的な関係を持つ上では必要なことだろう、ということだ。

 

Last Mover Advantage

 “First mover isn’t what’s important — it’s the last mover. Like Microsoft was the last operating system, and Google was the last search engine.” - Peter Thiel 

http://pando.com/2012/04/19/peter-thiel-on-the-last-mover-advantage/

Peter Thielが3年くらい前に"Last Mover Advantage"という概念の話をしている。普通競争戦略で学ぶのはFirst Mover Advantage(先行者利益)だが、ITの世界ではLast Moverが勝っているというのだ。そういう理由は下記にある。

The trick however, is to enter the market late enough so as to not be crushed by future competitors, but not so late that the market is already closed off to new entries. A balancing act that is easier to perceive in retrospect, but is something that startups must keep in mind when considering what market to enter, and when to enter.

つまり、「将来の模倣者が現れて負けるほど早く入りすぎず」、かといって「すでに参入しても勝ち目がないくらい遅くない」状態で入り、勝ち切るというものである。勝ち切ったらWinner Takes Allになるため、Last Mover Advantageだというわけだ。

いろいろな話に展開できそうだが、ここでは2点だけ言及しておこう。

 

ひとつは、Lastと言われるのは結果であること。先行する競合の試行錯誤をすべて学習している。ただ学習しきって、勝ち方がわかった時にはすでに遅すぎる状態に入っており、結局そばにいながら最速で追いかける準備はできている必要がある。かつ、より筋をとらえたプロダクトを適切なタイミングで出せなければならない。

決済におけるApple Payは非常にそれに近い。paypass, payWave, Google Wallet, ISIS, Squareの現状を見た上で、最適なタイミングで出せていると思われる。Last Moverになる可能性を秘めている。

 

もう一つは、最近のFundingトレンドがそれに近くなっていると感じること。タクシー配車におけるUberの巨額のファンディングは、ともすれば後続する競合のLyft等を殲滅するための資金であるとも考えられる。つまり、後続を谷に突き落として、Last Moverの地位を確立するための資金だということだ。こうできていれば、ただのタクシー配車の先にある、物流のマーケットや、自動運転車によるタクシー業界のディスラプトなど、ネクストステップにある領域で優位な地位を"享受"できる。

このとき、少なくとも地理的に遠いと、あるカテゴリーのLast Moverを狙うのは難しいと思う。中国で発展したサービスならなら中国国内で上記のことが起こる。西海岸なら西海岸で起こる。

インターネットによって情報の共有は早くなったといえども、結局はインフォーマルなネットワークで進むことが多いと思う。基本的にインターネットに乗るのはずいぶん後になってからというのが実際のところだ。

自信の拠り所

組織を率いる人間にとって、自信を身につけることは極めて大事だ。

自信のなさそうな態度は、部下の不安を煽るし、求心力を失う。正しいことを主張しても仕事相手には信用してもらえないし、何なら「自分より格下だ」と即断されてしまって、中身を聞いてもらえないことも多々ある。人の印象を決めるのは非言語情報が9割とかっていう研究結果があるそうだが、自信がなければいい印象を与えることは出来ない。

 

しかしながら、どう自信をつけていくか、というのは人によってずいぶんかわるらしい。自信のより所といってもいい。

(著しく自己認識がずれている人はおいておいて)、ふつう自信は過去の体験をより所として蓄えられていく。そして過去の体験には外的な経験と内的な経験の2つがある。

外的な経験は、かんたんにいえば他者からの評価で、昇進したという事実、他の人に褒めてもらった(表彰された)という事実、自分の持っている肩書、給料などである。「自分を認めてほしいという欲求(=承認欲求)が強い人ほど、これを軸に自信が形成されやすい。

一方、内的な経験は、「自分はこれができるようになった」「ここまで体得した」という自分の実感から形成されるものである。誰がなんと言おうが、偉い人がなんと言おうが「自分があっている(だって、あそこがXXXで◎◎◎だから▲▲だということはわかっている)」と主張できる。プロフェッショナルな気質の人ほどこちらの割合が強い。

 

そして、「この2つタイプの経験のうち、どっちで多く自信をつけてきたか」というのが、職種によってずいぶんパフォーマンスに影響すると思っていて、例えば、営業職の場合は、承認欲求が強い(=他者からの評価を求める)ほうがパフォーマンスがでやすい。そういう人は目標へのコミットメントの情熱は強く、最短経路で目標に到達しようと邁進する。

他方、エンジニアとか研究職はほぼ100%後者であって、今までやってきた実装やトライしたアイディアの多さ、バグに苦しめられた経験、難しすぎる理論の理解に苦しんだ経験など、自分の経験が自信の拠り所になっている。

 

事業開発の仕事はどういう割合の人がいいかと、2:8くらいのバランスが一番いいんじゃないかと思っている。

前者がほとんどの人は、向いてない。なぜなら、事業開発は会社がやったことがないことを検討するからだ。

常にトップは新領域の知見が乏しく、うまく目標を表現できないのが一般的なはずで、それに対してBD担当は、言われた目標を達成できそうな「プラン」だけを持っていくのではなく、「より適切な目標とそれに対する戦略筋、そして実行可能なプラン」のセットをまるごと持って行くことを求められている。(まるでお題を無視しているかのようだ)

 

他者からの評価だけで自信を形成してきた人は、間違った目標に突進してしまうか、もしくは全く目標を与えられていない状態に右往左往してしまって、何をしていいかわからなくなる。

後者だけでも困る。内的な経験による自信は、タコツボ化する可能性が高くて、自分の専門以外興味がない、となりがちだったり、他者の意見を気にしなさすぎたりする。

M&Aは会社と会社をくっつける作業であって、少なくとも様々なモチベーションと思考、インセンティブを持った人間がいることを想像でき、なぜその思いに至ったかを理解できなければならない。組織や人事に対して興味が無い人間だと、実行可能なプランを描けない。

 

なんで後者が8かというと、評価とかマネジメントとかがなくても正しく動かなければならないから。M&Aには一般的にわかりやすい定量指標がないし、達成基準の定義も難しい。買ったあと数年立ってやっと成功かどうかわかるようなものなので、人事評価自体が難しい。重要な事は、ディールの時に確実に正しい判断を下す状態を保つことが必要で、そのためには、評価にあまり興味のないような人が、議論と調査を尽くして深い理解が得ていく必要がある。

逆に、評価欲しさに戦略を描くとろくなことにならない。例えば評価者の仮説がまちがっているとその方向にみんな実現するよう動いてしまうし、未知の領域ではいかようにでも案件を正しそうに見せることができてしまい、モラルハザードを起こす。

 

トップから目標を与えられた時点で、本当にやりたいゴールの状態は何かを深堀りして聞き出し、もっと適切な目標を提示し返す、というところもBDのミッションに入っているとすると、人事評価を重視する人間だと少しむずかしいところがあるのかもしれない。

 

うーん、もう少しわかりやすい文章を書きたい・・

BD(事業開発)の人は何で起業しないのか

ブログを見てくれている友人から「大企業のBDをやる人のモチベーションは何なのか」「なんで起業しないのか」と質問をもらった。

つまり、なんでサラリーマンなんかの薄給で、承認を取らなければならない人がたくさんいて、すごい面倒くさそうな仕事をやっているのか、ということである。うんうん、間違いない。

いくつか考えてみた。

 

スピードとテーマの数

大企業の事業開発のほうが数多くのことが出来る。

ベンチャーは一度やってしまったら、少なくとも数年から10年はコミットする。新しい市場だと、市場自体が立ち上がるのにも相当な時間がかかる。そして、もちろん取り組むのは1つの課題だ。

BDだと年間で数件行うこともできる(PMIがあるからどういう関わり方をするのかにもよるが)。

テーマも多岐にわたる。既存事業とのシナジーを生み出して、買収先と既存事業の双方を成長させられるか考え、グループ全体のエコシステムをつくり上げる、という作業だから、あんまり領域に境界はない。コンサルタントが「いろんな業界について学べるのが楽しい」というのとちょっと近いかもしれない。

 

解きたい問題とケイパビリティ

ベンチャーで成功するためには、自分が心から解きたいと思っている問題と、それを実現するのに必要なケイパビリティが必要だ。下記にもあるが、これは真実だ。実際に実現できるという証明は非常に重要で、それは強いバックグラウンドだったり、プロトタイプを制作することだったりする。

素晴らしいアイディアの持ち主で、それを素晴らしい事業計画に落とし込めるというだけの起業家は消えて行く。この種の起業家は、それがEvan Williamsのように既にエグジット経験がある人材でない限り、もう見向きもされないと断言。 

Uberなど60社に出資するエンジェル投資家が定義する各種資金調達ラウンドと、ファウンダーがすべきこと - THE BRIDGE(ザ・ブリッジ)

だから、BD担当から起業する場合は、ほぼ役割上CEOしかできないし、非常に強力なチームを構成出来ることが必須条件になる。

加えて、強い問題意識が必要だ。まあここについては、普段からたくさんの企業に会うから、やりたい領域も見つかるのかもしれない。

 

サービス開発としての買収

大規模投資を含むようなBDをするインターネット企業のといったらもう、海外を合わせても100社はないくらいの規模かもしれないが、そういう会社でしかできないこともある。"Change the world"をするのに、ベンチャーだけで突破する場合もあれば、大企業が主体になって変えていくときもある。

下記のGoogleの買収リストの内、統合された先を見てほしい。("Used as or integrated with")

List of mergers and acquisitions by Google - Wikipedia, the free encyclopedia

ほとんどのサービスがスタンドアローンで残るのではなく、統合されている。こういう買収は、新規領域に進出とかっていうのではなく、より良い自社サービスを提供するためのプロダクトの強化であり、チームの強化であって、サービス開発の一環といえる。

ベンチャーの場合は、そこまでのアセットはない。組むか買えるくらい大きくなるかしかないのである。

純粋に「世の中に新しいサービスを提供する」という観点から見ると、起業も買収も手段でしかない。(他にいろんな観点があるから実際にはそれだけではないけれど)

 

報酬について

これについては、もはや慣れてしまっていて、インターネット業界でBDをしているとだいたい「Co-founder & CXO」に会う。有望な会社の多くは、過去に創業者が何社か既にやっていたことのある人物で、目の飛び出るような資産を持っていることが多い。

だから「誰と会っても自分より金持ちで、しかもケタがだいぶ違う」という状況が永遠に続くし、やっぱりけっこう悲しい気分になる。 

でも報酬を理由にやめるなら、たぶん既にやめている。やめない人にとっては逆に報酬は決定的な要因にはならない。

 

ロイヤリティ

それでも辞めない人は何なのかということをいうと、やっぱり「この会社にいることを決めた人」という回答が正確に表していると思う。

普通それって、経済的に安泰だから居続けるとか、もう歳だから居座るっていうネガティブな響きがあるけど、BDに携わる人はたいてい出世コースにいるような幹部職が多い、というのが普通なので、純粋にこの会社にいたいからいる、のほうが近い。

(うちの会社みたいに、職位もないし経験も少ない人間が関わっている事自体が珍しいし、他社じゃあんまり見たことない)

普通にBDをしてきた人なら、「この会社を今後どうしていくか」っていう経営側の思考になっている人が多いはずだから、少なくともBD担当が辞めるといったら、相当の理由が裏にある。ポジティブな理由がほとんどだろうが、そうでなかった場合には、何かを重大な問題があるに違いない。

 

こんな感じ。

有事のマネジメントと平時のマネジメント

とある日本企業でメガディール(クロスボーダー)を何件も経験した人の話を聞いた。その中で事業開発のマネジメントに関することが触れられていたので、思い出しながら書いてみる。たくさん示唆のあった話の中から、ここだけ取り出すのも非常に失礼かもしれないが、こういう基本的なところは大事だなと思ったので書いてみよう。

事業開発の組織のマネジメントは「有事のマネジメント」で、通常の事業の「平時のマネジメント」とはまったくちがう。

「平時のマネジメント」は階層でなりたっている。上に行けば行くほど多くの情報が集約され、意思決定は逆に上から下に下ろしていく。

不要な情報を下におろしてはいけないのは、各々が役割と目標を持っており、それに向かって全力を尽くしてもらうためだ。不用意な情報共有は、チームの混乱を招き、モチベーションを低下させる。そして、おまけに変な尾ひれがつく。

意思決定も広い範囲を見ている人が最も重要な判断を下すべきだ。それでないと組織が変な方向に向かってしまう。結果として、意思決定の影響度合いが、組織の階層と一致するようになっている。

一方で、「有事のマネジメント」は、タスクフォースである。重大な問題が起こった時のエスカレ先みたいなイメージだ。関与する社員が限定されるかわりに、完全な情報共有が行われることが望ましい。BDもこちら側だ。

なぜこんなことをするかというと、いくつか理由はある。

  • 圧倒的にスピードが大事。階層を切っているとまあ遅くて失敗する。共有もれも頻繁に発生する。
  • 意思決定が広範囲にわたり、問題を人に切り分けられない。たいていの問題は、システムと人事のトレードオフだったり、税務とガバナンスのトレードオフだったり、法務と買収価格のトレードオフだったりして、1人の専門家で片付く問題が存在しない。情報共有の階層を分けると、文脈を踏まえない検討をしてしまったりして、まず確実に最適解に至らない。
  • チームメンバーを信頼している証拠になる。メンバーとしては共有されない情報についてはサポートのしようがない。また、共有されていないことがあるとわかると、少なくとも共有されていないこと自体が、進行上の問題点として認識する。そして自分のアウトプットにも100%の自信を感じなくなる。(なぜなら正しい前提と文脈を踏まえてるとは思えないから)。また他人の判断ミスもカバーしようがなくなるので、結果として「それについては自分の責任範囲ではない」と言うようになってしまい、チームの求心力の低下を招く。
  • 社外に対して足並みをそろえる必要がある。当たり前だが、会社同士の交渉の場合、一丸となっていないと、交渉相手として信頼関係を築けない。

 事業開発組織は、基本的にリーダー(意思決定者)とメンバーしかおらず、階層は存在しないのが望ましい。意思決定のやり方は合議で決定するのが望ましい、というか、全ての専門的な観点を兼ね備えて判断する必要があるから、合議の上でリーダーが判断する、という方法しかない。

たぶんこんな感じだったはず。

モラルのステップ

事業開発のような、非常に経営に近く、あいまいで、かつたくさんの要素がある意思決定を求められる部門では、とにかくモラル(倫理観、道徳性)が意思決定に大きな影響を及ぼす。基本的な能力だけではチームビルディングができないし、どの段階にいるかですっかり結論が変わってしまう。

このあたりのことをもやもやしている時に読んだ組織行動論の本、組織行動のマネジメントにヒントになる概念が書いてあったので紹介したい。*1

書かれているのは、人は社内で昇進をするに従って、モラル(倫理感, 道徳性)のステップを刻んでいく、ということである。本はずいぶん抽象的に書いてあるので、ざっくり言い換えて書く。会社員には6つのステップがあるらしい。

  1. 「怒られるのを避けるためにルールを守る。」これは研修中の新人とかの段階である。怒られたくないから遅刻をしない、というステージ。
  2. 「直接自分の利益になるように行動する。」これはメンバーに多い段階。自分の仕事は終わったんだから早く帰りたい。経費は許されている限り使い込まなければ損だ、と思う。
  3. 「上司や同僚に好かれるような行動を取る。」ここでは、XXさんがこう思っているからこうした、という指示待ち、もしくは同調で動くステージ。メンバーから係長課長くらいまで存在する。自分の意志はほぼ考慮していない。
  4. 「決められたものを維持するための行動を取る。」組織で一度決められたルールに厳格で、その通りに運用する。もしくは、与えられた目標を忠実に守り、評価基準に正直に動く。しかし、その結果悪いことが起こっても、特に責任は感じない。俺は正しい、俺は達成した、と主張できる。メンバーから部長、本部長くらいまで存在する。
  5. 「多数派の意見に関係なく、正しいと思うことをする」決められたことであっても組織のルールや目標がおかしいと思ったら、意義を申し立て、変える努力をする。それは自分の利益不利益に関係なく行う。ふつう、上級管理職や取締役などで、事業を管理する役割からこの観点を学ぶ。
  6. 「仮に現行法に触れたとしても自分が正しいと信じるものに従う」業界を引っ張る会社の社長や、起業家が持つ観点。今ならUberやAirBnBなんか良い例だろう。より良い世界を信じて法律と戦っている。"Change the World"の価値観である。オープンソースの概念もこれだ。一見いち企業に不利なこともやってのける。Teslaの技術特許開放はこれにあたる。

また、合わせて

  • ステップバイステップでしか上がっていかない。突然飛び越えることはない。
  • 普通の大人は4番でとまる。

と書かれている。

で、ここからは自分が感じたことだが、

(職級にしたがって上がると考えれば)普通の管理職は4〜5番だし、本部長役員は5番だし、社長は5番以上が要求されているのかもしれないが、事業開発をする人間については、ヒラから役員まで全員少なくとも5番目でないと成り立たないんじゃないか、ということである。理由はたくさんある。

  • 与えられた目標はないし、与えられても間違っている可能性も小さくない。
  • 経営目標のXXだけできれば、XXの観点は考慮しなくていい、というサボり方が基本的にできない。これをやるとたいていブーメランで帰ってくるため、時間の無駄。
  • 1ミリでも自己の出世を考えてサラリーマンが提案したものは、他社の正しい提案にまず負ける。さくっと短期で自分の成果になるものと、会社がやるべき重要投資案件がピッタリ合うことは基本的にあり得ない。
  • 自分に加え、上司や同僚の意思決定も間違っていることが日常で、その状況で伝書鳩になると関係者をよけい混乱させる。
  • 事業開発担当が面会するのは基本的に6番の経営者や起業家であり、少なくともその概念を心から理解できなければいけない(事業開発は最も経営者に会う職業の一つ)
  • 6番の考え方に慣れ親しんだ事業開発メンバーを相手にするには、少なくとも5番以上の倫理観はないとチームの求心力を保てない。最悪のケースは、幻滅してやめてしまうことすらある。(市場価値が高い人が多いため離職リスクは元々高い)

 

ちなみにこのモラルのステップは、仕事の能力とは関係がない。職位が高ければ経験も多く積んでいるし、たぶんモラルも高くなるが、結果論であって、本質的には関連しない。

チームビルディングが苦手でも非常に高い倫理観を持って正解を見つけようとしてる人はいるし、逆にわからないなら「わからない」と正直に答えることが、事業開発においては近道だったり評価されたりする。

ちなみに、一向になんの努力もしないで6番になってる人は「地獄のミサワ」と呼ぶ。

 

 

Amazon.co.jp: 【新版】組織行動のマネジメント―入門から実践へ: スティーブン P.ロビンス, 髙木 晴夫: 本

 

*1:※ちなみにこの本はたくさんのアイディアが乗っててよいのだが、漢字が多くて抽象的なままずっと続くので、本気の人しかおすすめしないw

ブラックスワンと「新規事業開発」

ナシーム・ニコラス・タレブの書いたベストセラー、ブラック・スワンという書籍の中で「講釈の誤り」というアイディアが紹介されている。アマゾンのジェフ・ベゾスの本にも出てくる

インターネット業界のような、とにかく毎年市場に激変が走る業界の会社にとって陥ると致命的になってしまう罠を、的確に言い表している概念だったので、ここに紹介しておこう。実際にこういう悩みはいろんな会社の方から聞いたりする。特に大企業が多い。でも国や規模を問わない気がしている。参考になる人もあるだろう。

ブラック・スワンとは、名の通り黒い白鳥のことで、オーストラリアで20世紀に発見された。それまでは「白鳥は白い」という当たり前すぎる概念を根底から覆した事件だった。

本書が指摘するのは、その事件の特徴であり、現実社会で起こりうる類似する現象を指す。著者が「ブラック・スワン」的な現象だと呼ぶのは

  • 第一に、今まで観測できたことのない異常なこと
  • 第二に、起こることで非常にインパクトがあること
  • 第三に、起こった後には、誰でも簡単に説明できてしまうこと(!)

である。

そして「講釈の誤り」とは、人間が持っている「物事を単純化して理解してしまう」性質であり、複雑な現象に対して、考える次元を減らし、もっともらしい因果関係やストーリー(=講釈)を作って理解しようとする無意識のやっつけ的行動を指す。

・XXは幸せそうな夫婦生活を送っているように見えた。彼は奥さんを殺した

・XXは幸せそうな夫婦生活を送っているように見えた。彼は遺産を手に入れようとして、奥さんを殺した

前者は事実を並べただけで主張はない。後者は、理由付けがありイメージがわきやすい。「遺産を手に入れようとして、」という講釈は正しいとは限らないが、少なくとも記憶に残る。

奥さんを殺す理由は他にも考えられるが、何の理由が正しいかを証明するのは難しい。結局、「遺産を手に入れようとして」という仮説のもと、必要な裏付けを追い求め、見つかれば、そのような主張を「正しい」と感じられる。(追認の誤り、と本書で紹介されている)

 

こうして、

  • 本当は正しいかわからないがとりあえず単純化されて理解しやすい物語を、シンプルに「正しい」と感じてしまうことで物事の本質を見誤り(講釈の誤り)、
  • 物語に沿う事実を探して見つけてくることで、より確信を深め(追認の誤り)
  • その結果、想定はしていなかったけど、よくよく後から考えたら当たり前じゃん、てなるようなディスラプトが、当初無視していたところから起こる(ブラック・スワン

とされている。

 

こうした現象は、結構身近に潜んでいる。あり得そうな例を考えてみよう。

1.否定するのが最もリーズナブル

いつも企業の上層部は、新規技術や業界動向のキャッチアップが遅いということになっているものだ。確かにそういう話はよく聞く。うちの会社は幸いそんなことはないのだが、これはなぜ起こるのか。

それは、部下が選択的に情報を上げるからである。企業の求める「業界変化」は、直近で財務に影響を与える、現状の近似を延長したものであって、部下が、いくらインパクトがでかかったとしても、5年くらい先に影響をあたえるものを「これが来ます」と進言でもしたら、少なくとも「なぜ来るのか」と執拗にその理由を責められるだろう。ただ、それを正しいとする事実は当然ない。結果、答えに窮してしまい、「なんだ、テキトーに発言するな」とばかりに、その部下の信頼性が下がる、ことになってしまう。

少なくとも政治学を多少勉強した人間なら「これは来ません」とはっきり否定しておくべきだ。少なくとも新しい技術に関してなら、普及しないことを支持する数字は幸いなことに死ぬほど見つかる。非常に簡単である。「市場が小さい、コストが高い、使いたいという人がいない、こういう機能がない、犯罪が起きている、セキュリティが信頼できない」など、いくらでもある。無限に「理由付け」できる。

でも「来ることを証明できる事実がないことは、来ないと言っているわけではない。」 こういう見誤りは特に、長期間(5~10年間)にわたってものすごく大きなインパクトを与えるものについて、よく起こる。

今ならBitcoinとかが、そのあたりの題材だろう。昔だったら、iPhone, Facebook, Twitterだったかもしれない。

当時、iPhoneは、識者の中でも日本国内で売れて50万台、100万台という見方が大方だった。なぜなら赤外線通信とおサイフケータイが使えないから。

だが、来ないことを現在の事実で「証明」しても、あんまり意味がない。結局、思ってもみない形で普及したりしちゃうからだ。Bitcoinの基幹技術であるBlockchainだけが普及したりするかもしれないが、誰も考慮に入れていない。考慮にいれるほど理解してない。

また、Bitcoinがダメでも、次の仮想通貨が流行るかもしれない。それを作り上げる人たちはまあ確実にBitcoinに習熟したチームだ。それはチームの技術的優位になりうるし、非常にアイディアの実現能力・遂行能力が高いと評価されるはずだ。

でも、今からそんな可能性を考慮することは社内では全く求められてない。まずもって「妄想」「バカ」呼ばわりされるリスクが大きすぎる。

こうして「来ない」という簡便な物語を使ってしまう。

新規技術が来るかどうかなんてのは、占いのようなものではなくて、たくさんの勇気ある起業家やVCや為政者が、どうにかして新しい技術を普及させようと努力している、というのが現実である(そりゃ当たり前なのだが・・・)。流行るかどうかは、結構その業界全体のがんばりに依存している。

がんばりによって、変わらないと思われている法規制も変わる。少し流行ればカスタマーの意識も変わる。変数に置くのをついつい無視したくなるインフラコストや端末性能も変わる。全くカバーしていないクリティカルな基幹技術も出てくる。また、強力な提携が可能になるサービスも同時に立ち上がったりする。違う地域のアイディアが突然入ってくる(中国発、EU発など)

こういうところがブラック・スワンになりうる。

企業の大部分の意思決定層で、「XXが大きな市場らしい」となるのは、ベンチャーが数年潜った後に急成長する時である。検討部署が立ち上がるが、既に当該がんばってきたベンチャーは、ある程度Exitを視野に入れるような段階になっていて、話にならない。

この状態になると、第三の「後からなら、だれでもなんとでも言える」というやつになる。

急成長するタイミングで「XXの衝撃」みたいな日本語記事が出てしまって「知っているか、XXはすごいのだ」と社内で話題になったりするらしい。

たぶん、投資なり自主開発なり、対応を考えるなら時期が3~5年遅い。今メディアで話題になっているベンチャーは2009-2011年ごろ創業のものが多い。つまりその時期には構想/実験していたということだ。もっと言えば、2008-2010には基幹技術が学会で発表されていたりする。実は、遡れば準備時間は結構ある。Deep Learningは例えばまさにそんなタイムフレームだ。

ちなみに、電機メーカーの場合は、R&Dの現場は論文のところからカバーできてはいるのだが、製品開発と分断されていて、対事業部営業で同じ状況になる。推測するに、精度や性能を上げるものは採用されるが、既存の製品ラインを壊すような変化をもたらすものは少なくとも様子見となるのではないだろうか。

余談だが、ふつうは、堂々と「来ない」とスパッと言い切れる人が評価される傾向にある。上司の立場では、自分がわからないことに関しては、堂々と意見を言ってくれる人間ほど信頼ができる。こういう場合、言語情報より非言語情報が強い。「少なくとも裏がなさそうだ」と判断しやすいというガバナンス上の理由もある。

こうして、【サラリーマン的正解】=【講釈の誤り】がなりたってしまう。

これを防ぐには、単純化の誘惑と短期目線に負けないメンバーとマネージャーで戦略チームを構成するのが一番だが、そんなマネージャーが評価されるかどうかはわからない。マネージャーも誰かの部下だし、そんな長期の仕込みは残念ながら昇進に反映されないからだ。

結果的に大企業はメディアの外圧待ちになってしまうことが多い。最近ではけっこうテック系メディアも充実して和訳が早くなっているから、もしかしたらタイムラグは短くなっているのかもしれないが。

 

 

2.「フィージビリティ・スタディ」でないプロトタイプ

フィージビリティ・スタディ、と称して、限定機能や試験サービスをリリースすることはよくある。

でも、これも1個目のブラック・スワンが起こる理由と同じだけど、あくまで今の環境のもとに、その機能が流行るか試しているだけで、実験環境としては、不十分だったりする。

iPhoneが無い時代にTwitterのような「短いウェブログ」を実験した人は、筋は良かったかもしれないが、流行る証明にも流行らない証明にもならなかっただろう。

サーバコストが高くブロードバンド環境もオープンソースのライブラリも揃っていない時代にYoutubeをやろうとした大勢の人たちも、同じである。

オンラインユーザーが少なすぎて初期投資に耐え切れなかったウェブバンだってそうだ。(でも2014年に注目を浴びたのはこういう領域である)

いずれも、本気でベンチャーとしてやるなら非常に価値あるトライなのだが、F/Sでやって可能性を検証するといっているなら設計段階ですでに大きなミスを犯していることになる。

 

****

じゃあどういう姿勢で挑めばいいんだろうか。それは、過去や他分野から「できるだけ深く学び」「できるだけ多く学び」「できるだけ機動的に」「自分の信じるところのものを最高のクオリティで作る」しかない。たぶん。

時流は読めるだけ読む、でもあとは信じて作る。どうしても自分でカバーできなかったところだけが、運に任せてしょうがないところ、という割り切りをするんじゃないだろうか。たぶん。

こういうトライを促進できたら、きっとすごくいい会社だと思う。つまり「読めるだけ読む」ための色んな専門家が揃っていて「信じて作ってみる」ような姿勢を促進する社風があって、「最高のクオリティで作る」ための優秀なプロダクトチームがいるというような。

でも日本に住んでる人だけでも、面白い人もいっぱいいると思う。1箇所にまとまればいいんだけど。

Amazon.co.jp: ブラック・スワン[上]―不確実性とリスクの本質: ナシーム・ニコラス・タレブ, 望月 衛: 本

フルスタック・スタートアップ

Full stack startups | cdixon blog

Andreesseen HorowitzのGPのChris Dixonが、Full stack startupという概念を紹介している。Full stackとは、ソフトウェア開発の用語で、アプリケーションからインフラまで全部の要素を持つ、ということで、この場合は「既存企業に依存せずに、すべての要素を自前で持つスタートアップ」のことを指す。

F-1で言うところのフルワークス参戦みたいなものだ。

フルスタックアプローチを取るスタートアップの事例として、電気自動車のTesla Motor, アイウェアブランドのWarby Parker、タクシー配車のUber、髭剃りのHarry's、空調コントローラのNest、それからBuzzfeedやNetflixなどが挙げられている。

Chris Dixonによれば、多くのFull stack startupは、過去に同じ問題に取り組んだベンチャーの祖先を持つが、それらは、部分的なアプローチ(Partial stack)で挑んで、失敗したか、小さくまとまってしまっていた。

Partial stackアプローチは次のような特徴を持つ。

  • Bad product experience. Nest is great because of deep, Apple-like integration between software, hardware, design, services, etc, something they couldn’t have achieved licensing to Honeywell etc.
    (悪いUXをもたらす。Nestがすごいのはソフトウェア、ハードウェア、デザイン、サービスを深いレベルで統合するからである。)
  • Cultural resistance to new technologies. The media industry is notoriously slow to adopt new technologies, so Buzzfeed and Netflix are (mostly) bypassing them.
    (慣習的な新規技術への抵抗に遭う。例えばメディア産業はとにかく新技術の導入が遅い。BuzzfeedやNetflixは多くの部分でバイパスしている)
  • Unfavorable economics. Your slice of the stack might be quite valuable but without control of the end customer it’s very hard to get paid accordingly. 
    (経済条件の悪さに直面する。自社プロダクトは価値あるものなのだが、エンドユーザーへのコントロールを持たず、十分な収益を得られにくい。薄く入るだけだとマージンが低い)

 一方Full stackアプローチはこうかかれている。

The full stack approach lets you bypass industry incumbents, completely control the customer experience, and capture a greater portion of the economic benefits you provide.
(フルスタックアプローチは、既存業界の面倒なことをスキップし、UXを完全にコントロールをできる。そして経済的に収支が合う)

 だが、当然ながら、課題もある。

The challenge with the full stack approach is you need to get good at many different things: software, hardware, design, consumer marketing, supply chain management, sales, partnerships, regulation, etc. The good news is that if you can pull this off, it is very hard for competitors to replicate so many interlocking pieces.
(フルスタックアプローチの課題は、全ての要素で秀でていなければいけないことである。ソフトウェア、ハードウェア、デザイン、マーケティング、SCM、販売、提携、規制。もしうまく行けば、競合企業は、このような複雑に絡み合った体制をコピーすることは非常に難しい。)

こう書くと、経済学の教科書に出てきそうな、シンプルなバリューチェーンの垂直統合のようだが、そう簡単な話ではない。自前化すれば、コスト上のメリットが得られる、という類のものではない。

ここからは持論だが、何が違うのかといえば、フルスタックアプローチは、分業の連結ではなく、ひとつの統合されたワークフローだからだ。

日本語ではあまり話題になっていないのだが、Steve Jobsの90年台のインタビューの中で、エンジニアリングについて述べている。

There’s just a tremendous amount of craftsmanship in between a great idea and a great product. And as you evolve that great idea, it changes and grows. It never comes out like it starts because you learn a lot more as you get into the subtleties of it. And you also find there are tremendous tradeoffs that you have to make. There are just certain things you can’t make electrons do. There are certain things you can’t make plastic do. Or glass do. Or factories do. Or robots do.
(素晴らしいアイディアと素晴らしい製品の間には、膨大な職人的努力がある。アイディアを進化させるにつれて、それは変化するし、深くなる。当初のアイディアが形になることはまずない。それは、微細なところまで入り込み、深く学習するからだ。そしてやがて、作りたいものにはとてつものないトレードオフがいくつも存在することに気づくだろう。我々は電子にやらせられないことがある。プラスチックも、ガラスも、工場も、ロボットも。)

Designing a product is keeping five thousand things in your brain and fitting them all together in new and different ways to get what you want. And every day you discover something new that is a new problem or a new opportunity to fit these things together a little differently.
(製品をデザインするとは、いわば5000個の制約を頭のなかに詰め込み、やりたいことを実現するために、何とかして全部を調和させる作業である。毎日新しいことを発見するが、それは新しい課題になるかもしれないし、チャンスになるかもしれない。)

つまり、Full stack startupでは、ハードウェアの性能設計とソフトウェアの設計が並列におかれる。設計で逃げるところと法規制をロビイングして変えに行くことが、同じ俎上に乗る。実現したいデザインのために、OSのコア部分を大改修する。そういった決断が必要になる。

 

こんなことできる経営者って世界でもなかなかいないのだ。一人でやるのはほぼ不可能だが、専門家がよって集まればそれでいいってものでもない。だいたい、最先端に翻訳家なんていない。

 

日本語しか喋れない包丁職人とドイツ語しか喋れないシェフが一緒に最高のナイフをつくろうとしたら、誰が通訳するのか。そりゃ、研磨と溶接とドイツ料理と日本語とドイツ語が、かなり深くわかってる人でないとできないでしょう。でもそんな理想の通訳なんてどの会社あたっても連れてこれない。

 

結局は、専門家が他の専門を理解するしか、方法はないみたいだ。日本は総合職という不思議な制度によって、まず専門家が育たないから、ここまでの人材が育ちにくい。

ドイツに住んでたことがあって、料理が好き、位の人では、どちらの専門家にも信頼されないだろう。

ごあいさつ

東京で事業開発してる人のブログです。

2年ほど前にiOSエンジニアから突如事業開発にチェンジして、しばらくブログをやめていましたが、再開したいと思います。

主に、インターネット業界の事業開発案件、投資案件、業界動向、経営について書いていきたいと思います。

よろしくおねがいします。