初期マイクロソフトの成功要因
さすがにid:shi3zはよく分かっていらっしゃる。わざわざプラットフォームって言葉を使う奴ほど自分の都合しか考えてないのが問題なんだよね。相手の都合を考えて必要なものを提供し、時に結果的にネットワーク効果が働いてプラットフォーム的な位置付けになることはあっても結果に過ぎない。BASICだってDOSだってWindowsだって同じじゃないかな。
プラットフォームをつくるときに、自分の都合を優先して考えてはいけない。
ただそれだけのことだと思う。
追記: 事実関係が微妙に違っていた模様。詳細はwikipedia:QDOS参照。 Thx > id:finalvent
ちょうどいい例なのでDOSを取り上げてみよう。DOSって今時のOSと違ってメモリ管理もタスク管理もデバイス制御も中途半端にしかやっていなかったので、プラットフォームといえるかは微妙だけど米国では最初からIBM互換しかなかった。日本では同じMS-DOSをつかっていてもPC-98とかFM-Rとか諸々あってソフトに互換性はなかった。
ところでマイクロソフトはDOSより前にXenixというUNIX互換OSを売っていたけれど、PC向けBASICの開発を依頼してきたIBMがCP/Mクローンを探していると知って近所のSeattle Computer Productsから86-DOSを持ってきた。IBM PC向けのOSとしてはマイクロソフトの供給したPC-DOSの他、UCSD PascalやDigital Research CP/M-86といった選択肢があった。
結果的にDOSが成功した理由は様々だが、他よりも安く早く発売され、当時のデファクトだったCP/Mとの互換性がCP/M-86と比べて優れていたことが大きい。またIBM PCがプラットフォームとして大成功した要因として、オープンな設計と汎用部品の組み合わせで豊富な互換機が登場したことが大きいが、互換機が生まれたのは、マイクロソフトがIBMと独占契約をせずDOSを再販したこと、86-DOSの権利をマイクロソフトに売ったSeattle Computer ProductsのTim Pattersonが、Phoenix Technologiesを設立してIBM互換BIOSを供給したことが大きい。顧客であるIBMの都合に合わせつつ、互換機をつくりたい新興ハードウェアベンダも応援したからこそプラットフォームが形成されたのであって、自社のXenixに拘泥していたらDOSもIBM PCアーキテクチャも今のような姿ではなかっただろう。
もう少し遡って、86-DOSをつくったCSPはなぜ直接IBMに売り込めなかったのだろうか。マイクロソフトがIBMのPC開発プロジェクトを知ることができたのは、BASICで高いシェアを握っていたからだ。1970年代のマイクロソフトは言語ベンチャーで、BASICを皮切りにマクロアセンブラ、Cobol、Fortran、LISPなどの言語を各社のコンピュータ向けに供給していた。IBMはBASICの供給を受けるために、早い段階でマイクロソフトに計画を明かし、BASICの移植向けにプロトタイプを貸し出す必要があったのだ。一方で自社のGazelleという8088マシン向けに細々と自社OSを開発したSCPは、IBMがPC市場に参入することを知る術がなかった。
もうひとつ、IBMと独占契約を結ばなかったことが非常に戦略的には重要だったが、これは創業の契機となったアルテア8800を開発したMITS社との係争が教訓になっていた。当初マイクロソフトはMITS社と独占契約を結んで、共同創業者のポール・アレンはMITSのソフトウェア担当VPに収まっていた。けれどもGEやシティバンクといった優良顧客やアップルと直接契約を結ぼうとした時この独占契約が障壁となった。幸いビルゲイツの父親が弁護士で、契約書の瑕疵ををみつけ、新しくつくり直したBASICなら他社に供給できると整理して事なきを得た。過去にこういった経緯があったので、IBMと独占契約を結ばず、早くから互換機市場の育成に力を貸した。IBMからみてマイクロソフト以外にも選択肢のある環境で、大口取引先の足を掬いかねない戦略を取るには勇気がいったはずである。IBMは互換機の攻勢に懲りてPS/2やPC RTといった別のアーキテクチャを模索したが移行に成功しなかった。皮肉ではあるが、System/360でプラットフォームやラインナップといった概念を生んだIBM*1でさえ、プラットフォームを意識した途端に失敗している。マイクロソフトだって、1990年代末にはHeilstorm構想でOpen-IDの発想を先取りしていたにも関わらずPassportのプロトコルをオープン化せず、フェデレーションもやらずに失敗し、.NET構想の初期段階では重要なパートナーであるVBプログラマやWindows APIのエキスパートに対して混乱を招くようなメッセージを送ってしまったのだから、プラットフォームの罠って実に業が深い。
ところでプラットフォームってコンピュータ科学よりは経営学に根ざした概念だが、プラットフォームの罠の背景には、この経営学の研究手法が大きく影響している気がする。彼らは成功した企業から学ぶが、これは工場に於ける持続的な生産性向上へ向けた工夫などを研究するには使えるけれども、ネットワーク効果の高い産業領域に於いては、結果として彼らが今の立ち位置をレバレッジして勝ち続ける動学を説明することはできても、他のプレイヤーではなく彼らがそのポジションに辿り着いたことの成功要因は明らかにできないのではないか。レイヤー間の相互依存性がある領域でティッピングポイントを超えた特定の技術がエコシステムを形成してプラットフォームとなることは確率的に起こるけれども、それは結果であって、そのための必要条件は明らかに出来ても充分条件は明らかにできない。
また技術の局面によっては、関係者を増やさない方が成功する場合だってある。例えば近年だとAppleや任天堂は、外部のソフトウェア・パブリッシャーに依存しないことで、俊敏さと革新を実現している。けれどもこれが戦略かといえば、Appleのスティーブ・ジョブスなんかLisaとかNeXTとか、失敗もやらかしている訳で、彼の個性としか説明できないところもあるだろう。任天堂だって、DSスゲー、Wii Fitスゲー、革新的！って思うけれど、バーチャルボーイとかファミリートレーナーの末裔*2かも知れないし。マイクロソフトも同様で、プラットフォーム抽象がWindowsではうまくいったが、その少し前には同じアプローチが原因で、MultiwordがWord Perfectに負け、MultiplanがLotus 1-2-3に負けている。社風に根ざしている以上は、成功に繋がることも裏目に出ることもある訳だが、誰もが注目するのは成功だけなのである。
そういった意味で経営学者はIT関連のケースをつくるときに、成功事例の共通性を抽出するだけでなく、もっと失敗事例も取材すべきだと思うのだが、成功したプロジェクトでは功労者が山ほど名乗り出るのに対して、失敗したプロジェクトについて洗いざらい経緯を話して貰うことは非常に難しいし、どの失敗事例を何のために取り上げるか、選定段階から非常に苦労しそうな気もする。どちらにしても市場で充分なプレゼンスを得られた段階で初めて外部性を活かした戦略を立て得るのであって、影も形もない段階からプラットフォーム云々という発言があったら悪い兆候だ。経営学の手法に懐疑的な私だが、少なくとも成功事例の初期段階での戦略に着目した場合「プラットフォームをつくるときに、自分の都合を優先して考えてはいけない」という清水さんの結論は至言である。そして過去プラットフォーム形成に成功した多くの企業が、途中から欲をかいて失敗した歴史からも学ぶべきことがある。
*1:異なる規模のコンピュータで同じソフトウェアが走るというラインナップ戦略ではGEの方が先行しており、本当にSystem/360がプラットフォーム戦略の嚆矢だったかについては研究を要する。ひょっとするとQWERTYのような都市伝説かも知れない。
*2:こういうリスクを取れるから、革新的なことができるんだと思うんですよね。ファミリーコンピュータ ロボットとか買いましたよ、僕も。また任天堂がロボットつくる日は来るのかなぁ。
