StarOffice/OpenOfficeがMicrosoft Officeに勝てない理由
2005.12.17
このことは以前から書こうと思っていたのだが、誤解を招かずに説明するのが難しいので、しばらく棚にしまっておいた。しかし、今回「Blue Ocean Strategy」(日本語訳:ブルーオーシャン戦略)を読み始めて、なかなか良い表現を見つけたので、それを利用して説明する。
詳しくは、この本の第二章、「Analytical Tools and Frameworks(分析のためのツールとフレームワーク)」を読んでいただくのが一番良いが、あるマーケットを見たときに、既存の商品の「主要な要素(principal factors)」を抽出して、そこで真っ向から血みどろの戦いを挑むのが「red oceanの戦い」であり、逆にその要素から幾つかの項目を思い切って切り捨て、それとは別に新しい価値を生み出す要素を追加して、真っ向からの戦いを避けるのが「blue oceanの戦い」なのである。
この観点から StarOffice/OpenOffice を見ると、今の戦略がどのくらい間違ったものかが良く分かる。ファイル・フォーマットにしろ、豊富な機能にしろ、"big fat client"なアーキテクチャーにしろ、全ての面で Microsoft Office の後追いであり、新しい価値を生み出しているようには見えない。この戦略は、まさにこの本で言う所の「red oceanの戦い」であり、資金力のある Microsoft にかなうわけがなく、結局は「安かろう悪かろう」のニッチ商品に収まるしかない。
では、今からベンチャー企業が、この「オフィス・アプリケーション」市場に参入するとしたらどうするべきだろうか?私がCEOなら、迷うことなく以下の戦略を採る。
1.「Microsoft Office のファイル・フォーマットとの互換性」を100%捨てる
彼らのファイル・フォーマットを使い続ける限り、「後追い」の状況を強いられ、リーダーシップは採れない。それよりも、インターネットで標準となっている、PDF、RSS、HTMLなどのフォーマットを重視すべきである。これはエンター・プライズ・マーケットをターゲットとした時に、ななかな思い切って採れない戦略かもしれないが、「今インターネットで何が起こっているか」を良く理解している人ならば、分かるはずだ。10年後・20年後になっても Microsoft 独自のファイル・フォーマットがオフィス文書の標準フォーマットに留まっていられるとは、私にはどうしても思えない。
2.「機能の豊富さ」では勝負しない
オフィス・アプリケーションの基本機能という意味では、10年前にMicrosoftがリリースしたOffice95程度のもので十分である。それ以降に Microsoft が追加してきた機能は無視して、逆に「機能が少ないからこその使いやすさ」で勝負すべきである。
3.「ネットワーク機能」で新しい次元での価値を生み出す
ここに関しては、色々な戦術が考えられるので、あまり深くは突っ込まないが、例として挙げれば、「AJAXを使ってクライアント・ソフトウェアをダウンロードしなくても使える」、「全ての変更はサーバー側にundo可能な形で自動的に保存される(参照)」、「グループ内での文書管理が楽になる」、「ブログ・RSSとの融合」など、Microsoft Officeが今まで全く取り組んで来なかった部分での差別化をはかり、新しい価値を生み出すことが大切である。
誤解して欲しくないのは、私は決して「OpenOfficeなんて作っても意味がない」と言っているのではない点である。Microsoftの独占の牙城を崩したいという気持ちは分かるし、わたしとしても出来るだけに支援をしたい所だが、私には今のOpenOfficeの採っている戦略があまりにも間違っている様に思えるのだ。そこで、「余計なお世話だ」と言われるのを覚悟で、一度はっきりと指摘しておく必要があると考えたのだ。今からでも遅くないので、もう一度「今の戦略で本当に良いのか?」、「("big fat client software"である)StarOfficeのソースコードを元にして作ることがそもそも間違っていないのか?」を真剣に考えていただきたい。
Zopeジャンキー日記さんの、このへんのエントリーに、MS-Officeを超えるオフィスソフトへのヒントがあるかもしれませんね。
http://mojix.org/2005/12/12/223718
http://mojix.org/2005/12/17/224625
http://mojix.org/2005/12/18/102729
あと、satoshiさんが取り上げた無制限undo/redoやオートセーブ、それにネットワークにまたがったバージョンの枝分かれや文書再利用の管理、環境外部への文書リリースの管理なんて機能も求められるでしょうね。
Posted by: Baatarism | 2005.12.17 at 20:30
私もZopeジャンキー日記さんのエントリー、読みました。ファイル・システム上のidentifierでしかなかったはずのものがファイル名として定着してしまったのが、そもそもの誤りでしたね。Windows95で long fine name を導入した時に一度それを正すチャンスがあったのですが、私自身気が付きませんでした。
こんなことを書いていると、「Web2.0時代のOS」の話とかをしたくなりますね。次のエントリーはそれにしようかな…
Posted by: satoshi | 2005.12.17 at 21:09
3はともかく、1,2は、過去に一太郎Arkというものが…。
Posted by: ν即 | 2005.12.17 at 21:45
1のフォーマットについて、興味があるところなのでコメントします。
・OOoのflash, PDFへのexportはかなり幸せです。
・ファイルフォーマットがXML+zipなのが重要だと思っています。
・普通のAPIだけで操作できることはサーバでの自動生成/更新にかなり重要。
・1.0の頃から外部アプリ(pyOpenOfficeなど)からのファイル操作ができている。
・2.0でのOpenDocumentフォーマット標準化でフォーマット変更の不安が減った。
・ということで適切なライブラリがあれば様々なサーバ側アプリとの
連携(wikiOOoやNumSumOOo etc.)が期待できそうです。
・OOo 2.0 の XForms対応などはかなり先進的でおもしろいかとおもいます。
・使っている例は少ないですがDocBookなどのXML文書を変換して
OOo文書に取り込むなどもドキドキものです :-)
Posted by: mrwk | 2005.12.17 at 22:11
v即さん、一太郎Arkですか。やはり、1と2だけでは無理でしょうね。何かしら新しい次元の価値を生み出すものがないと…
mrwkさん、コメントありがとうございます。ファイル・フォーマットに関しては、OOoも私の理解以上に頑張っているようですね。しかし、何と言っても、"big fat client" になってしまった所が残念です。一番最初の計画では、thin client なマシンでも動作が可能な、今の AJAX ウェブ・アプリケーションに近い形を Java で実現するだったはず。それがいつの間にか100%がクライアント側で動くアーキテクチャーに変わってしまった。
Posted by: satoshi | 2005.12.17 at 22:26
上のコメント、インデントが消えて読みにくくなってしまいました。すいません。
個人的には現状のOOoは他プログラムでも生成しやすいフォーマットだということで、各種サービスでOOo形式の出力をサポートしていくと、自動処理できる主な内容はサーバで生成し、ユーザ毎に違う処理(紙のサイズや社内書式や実際のレンダリング処理など)はリッチなローカルで手作業という棲み分けがされるのではないかとおもっています。
firefoxに対するflockのように、ストレージ(文書管理、検索、バージョン管理、ワークフロー管理など)やテンプレートなどの素材などなど がオンラインサービスと連携するものができるとおもしろいですね。
subversionのblameコマンドのように、誰がいつどこを編集したかの履歴が見えるだけでも、かなり便利なはず :-)
Posted by: mrwk | 2005.12.18 at 20:54
ご存知かもしれませんがWritely
http://www.writely.com/
はワープロとして面白いと思いました。
日本語も使えますし、このような形式のものが
もっと増えると良いと感じましたが如何でしょう?
Posted by: mol | 2005.12.19 at 06:22
molさん、writely、いいですね~。こんな方向性が私としては圧倒的に好きですね。big fat client は Microsoft に任せておいて、新規参入組はこのくらい新しいことをしないといけないと思います。
Posted by: satoshi | 2005.12.19 at 13:49