mysql:10755
From: "zen kishimoto" <"zen kishimoto" <zen@xxxxxxxxxx>>
Date: Wed, 5 Jan 2005 22:56:11 -0800
Subject: [mysql 10755] 良い製品を作るには
http://dev.mysql.com/tech-resources/articles/a-good-product.html 良い製品を作るには Arjen Lentz著 この記事は実社会でオープンソースを作成しマーケティング する際に関連すると思われる私の考えや観察を述べます。 この記事は2004年9月にメルボルンで開催されたAUUG Annualアニュアル コンファレンス(1)で私がキーノートで講演した「どうやって象を 食べるか。」という題材に基づいています。 当然ながら観測は主観的で、私の考えは現在の私の意見を反映 しています。私は今までにも意見を変えてきましたので。私の 意見に対するコメントやこれから派生する議論を楽しみにしています。 実際のところそれが目的です。時々MySQLを例に引きますが、 意見はMySQLだけに当てはまるものではありません。 私にとってはオープンソースの支持者、特に開発者はオープンソース にはマーケティングへも製品開発にも工数が掛からないと思いかち であるように見受けられます。伝道の一種のように見られる オープンソースのメッセージは抗しがたいので、メッセージを 一旦聞くと聴衆は「光を見て」その宗教を信じるようなものです。 しかし、実社会はそうは反応せず、伝道師は大いにがっかりして いやになります。 フリー・オープンソースは成長著しい市場で、私達の多くは 開発者として、ベンダーとして、プロバイダーとしてまたは コンサルタントとして関わっています。既存の語句の、決定 プロセスとか解析方法は「クローズソース」環境の一部です。 習慣というものは緩やかに変化します。そのため、私達は 市場の現状を把握して、私達が思う方向へ導ける ように対応しなければなりません。 私達は長期のプロセスを考えるべきです。そのプロセスは 実はたくさんの注意を払わなければならないステップから なっています。１つ１つのステップ自身も大きなマイルストーン といえます。これらのステップの速度は個人個人のユーザに よります。幸運なことに、ユーザを何種類かのグループに大きく 分けることができます。しかし、重要なことはそれぞれ のユーザのグループ毎に違った対応が必要だということです。 つまり、かなり大きくことなった市場に対処しなければ ならないということです。 どの様な製品を売ろうとしていますか。「売る」というのは 「他の人に使って貰う」という意味で、お金が介在するかどうか は関係ありません。全てのオープンソースは同じでは ないので１つだけの製品を扱うということではありません。オープンソースは ビジネスモデルと同様開発モデルにも使用できます。たくさんの 組み合わせが在りえるので、全部を１まとめにすることは出来ません。 更に、クローズソースの製品を全て排除して市場をオープンソースとクローズ ソースの対立に持ち込むのが賢明でしょうか、それとも私達 が提供するものに関してはそのようなことに特に焦点を当てないのが 賢明ではないでしょうか。 製品とは 歴史的にみて、オープンソース王国の開発者は自分達のニーズを 満たすためにソフトを書いてきました。この良い例がApacheで 最初はウエブの専門家のグループ(2)によって書かれました。 これは現在のオープンソースの状況とは根本的に違います。 現在はもっと多くのオープンソースのユーザに対してかなり 少ない開発者という構図です。私はこれはこの分野が成長した からだと思っています。それは全ての人が開発者になりたい と言うわけではないということです。しかしながら このことで状況は変化しました。開発者同士でコードを 交換するならば、ドキュメントや使い勝手ということ は大きな問題ではありません。しかし、サポートのことを忘れては なりません。普通のユーザはかなり異なった期待を持っているもの です。 時として人はある会社は他人のした仕事で金儲けをするというふうに 言います。そういった会社はオープンソースのコンポーネント の全部か一部を元にした製品か製品とサービスを販売します。 これは問題でしょうか。 私はソースのつまったtarball (アーカイブ) (例えクリーン・コンパイル してクリーン・インストールできても）は製品とは言えないと思います。 あちこちにたくさんのtarballがあります。しかし製品は少ないです。 たいていの場合、tarballは単に更に大きなコンポーネントか完全な パッケージを形成できるコンポーネント(ライブラリー) を含んでいるだけです。 実際の製品をつくるということは、ライブラリーやパッケージは簡単に インストールできるためのプロセスやドキュメンテーションや （私が３年前にMySQLに参加した時、私だけがテクニカルライター でした。それからコミュニティ・リレーションの部門に移りました。 今はMySQLは5人のフルタイムのテクニカルライターを雇っています。） サポートとマーケティングのチャネル（このおかげで将来の お客様がオープンソースの存在とその価値を知ることができるわけですが） を必要とします。ディストリビューションについても述べておきます。 但し、インターネットがあればディストリビューションは殆ど無料 で行うことができます。 ここで述べておきたいのは、たくさんの有益なコンポーネント は実際には商業的には独立した製品とは言いがたいということです。 幾つもの異なったコンポーネントを使う権利を入手しなければならない 企業はその累積された経費に唖然としてしまうでしょう。そのために 最終の製品の価格を吊り上げ、潜在市場の大きさも縮小してしまうでしょう。 簡単に言えば、 これらのコンポーネントが無料でなければ（オープンソース かどうかは別にして）それとそれから派生する製品は存在し得ないという 結論に達すると思います。それ自身はなかなか面白い点だと思います。 オープンソースは多くの機能を与える技術を提供します。そして多くは LGPLもしくはBSDスタイルのライセンスで提供されます。 オープンソース技術を利用して商業的に意味のある完全な 製品を提供できる会社は多くの投資をしていると思います。 私は実際にコンポーネントと残りの配分を示すことの できる例を持ってはいませんが、実際プロトタイプが出来たときは それが製品開発プロセスのほんの最初の段階であることを知っています。 それで私は製品開発に多くの工数をつぎ込んだのは製品を開発した会社だと 推測します。もちろん、そうだからといってコンポーネントの 開発者の値打ちが下がるというものではありません。 実際、このことで他の興味深い点に気づきます。 異なったコンポーネントの開発者は開発費をプールして 分け合うことができます。例えば、ユーザ・インタフェースの設計 やドキュメント、製品のマーケティングなどです。多くの場合 そうすればそれぞれの個別のコンポーネントを意味のある（安い） 製品とすることができるくらい価格を下げることができます。 そしてその恩恵を実際の開発者に還元できます。これは今日 私達が見ていることなった市場のニーズを満たし、開発者の 新しい役割のニーズも満たします。しかしながら、これは開発者 が自分達の考えをしっかりと持っているのでこのように 説得できるかは大きな挑戦です。 ライセンス ライセンスの問題は感情的な反応を引き出す問題です。 Free Software Foundationが押しているGPLライセンスと BSDスタイルのライセンスの間には基本的な考え方に 違いがあります。ある意味ではその違いはクローズ・ソースと の差くらいあると言っていいかもしれません。 私はいわゆる最良のライセンスというものはないと思います。 ある特定の状況には１つもしくは複数のライセンスが適します。 その際は１つを選択しなければなりません。その結果、場合に よってはクローズライセンスが適当かもしれません。 もし完全にコードを所有しているか、LGPLかBSDタイプの ライセンス付きのコンポーネントであれば、貴方は製品を 同じようなオープンソースのライセンスで提供できます。 その選択にはクローズ・ライセンスで提供することも含みますが。 SleepycatやMySQLのような第二世代のオープンソースの会社は 実行可能なビジネスモデルを所謂「デュアル・ライセンス」の 概念で打ちたてました。MySQLの50%以上の収入はライセンスからの 収入(3)で残りはそれに付随するサービスから成り立っています。 ある製品は完全なクローズ・ソースモデルでないと成立しません。 そうです、残念ですが。これはどれだけ議論しても変えることは できません。しかし、境界は移動していると考えられ、以前に 増してもっと多くのソフトがオープンソースのライセンスで 提供されることができるようになってきています。コモディティ の市場はこの傾向を示しています。最初にOS、そしてデータベース サーバ。。。オープンソースはソフトのスタックに沿って 上昇しています。そしてオフィース・スイート（ワードプロセシング、 スプレッドシート、プリゼン）などを考えればコモディティのベース も拡張しています。 注: ソフトの市場はコモディティ化する時期に来ていると 言われています。これは別にオープンソースのおかげ という訳ではありません。逆に、コモディティ化の波(4)が オープンソースを可能にしたのです。そのオープンソースが 更にコモディティ市場を成長させるビジネスモデルに 適していたということでしょうか。それはあまり関係がありません が私には興味深いことです。 個人的にオープンソースというとてつもない大きな概念を 売り込むよりも特定の製品を販売する方が 良いと思っています。例えば、Red Hat Enterprise Linuxはオープン ソースを使用することを躊躇う会社に受け入れられています。 概念を強調するより、Red Hatは製品がもたらす恩恵に焦点を 当てました。同じことをお勧めします。もしお客様がこの製品を 選択するのであれば、そのビジネス関係が更にもっと深い 話合いに繋がるでしょう。 良く言われるオープンソースの利点は * 信頼: 全てのコードが開示されていて、なんら隠し事がない。 * セキュリティ: たくさんの人々が見るので問題を早急に発見・解決 このほかにも利点はありますが、それが全ての製品と全ての 場合に適応されるわけではありません。どれがあなたの対象として いる市場に一番適しているかを慎重に考えてください。 孤児化 ある種類のクローズ・ソースの製品は寿命がきた時、コミュニティは その製品を提供する会社にコードをオープンソースで提供する ように求めています。これは例えばアクティブなコミュニティが ある古いOSやレガシーのアプリの場合に起こりました。 他の会社はもう、そのコードで（十分な）収入を得ることが出来なくなった ときにコードをオープンソースで提供します。そういった会社は プレスリリースを出して、今やオープンソースの動きに アクティブに参加していると主張したりします。 しかし、コミュニティ からの十分なサポートがなければ、私はこれを孤児化と呼びます。これは 本当の意味でのオープンソースではありません。もちろんそれでも 何らかのメリットはあります。。。というのもコードが完全に なくなってしまうわけではありませんから。ユーザはなんらかの 恩恵を受けるでしょうし、研究の材料にもなるでしょうから。 開発 オープンソースは単にライセンスではありません。それは 開発のモデルでもあります。既存の今までのビジネスモデルの会社は これに合わせるために内部の構造を大幅に調整する必要 があります。このプロセスはなかなか困難です。新しい スタートアップの方に利点があるでしょう。 上記のことから、なんでもかでもオープンソースと いうタグを貼ってそれで成功する訳ではないということが 分かると思います。新しい製品を開発しようとしているのであれば オープンソースは考えに値するオプションです。 ライセンスの形態に関わらず、ソフトの開発のある側面が 適用されます。例えば、対象市場に初期の製品のサンプルを 提供してフィードバックに注意深く耳を傾ければ、最終製品 は高品質のものになります。この概念はE-ビジネスの戦略(5)と いう本の11章「実際に機能する製品開発の方法」に詳細に 書かれています。この本は数年前に出版されたものですが 価値のある情報を提供すると思います。 製品の初期のサンプルには限られた機能しかありません。 それが重要なのです。オープンソースとして提供しようと してソフトを開発している個人や会社の人とよく話しをします。 その場合製品が完成するまでお客様は製品を見ることができません。 完全に秘密裏に開発されるのです。確かに開発者にとっては 完成していないものをお客様（になるかも知れない人）に 見せるのは怖いことですが、これを恐れずにこの機会を捉える ことを切にお勧めします。もちろん、最初からその特定の お客様ようにカスタマイズすることは避けなければなりません が、コードがあまり書かれていない状態ではある部分（または 全体）の設計はやり直しやすいです。 例として、マイクロソフトはInternet Explorerを開発した 時この戦略を使いました。ウインドウとバンドルすることは 別にしても、ユーザのフィードバックを取り入れていたので すぐに受け入れられました。その後この製品がどうなったかに 付いては触れまでもないでしょう。重要なことはInternet Explorerの開発の この一点を見ることで、成功裏に終わる製品を開発することに 適用することができ、無視するにはもったいないことです。 そのほかのオープンソースの恩恵のほか、最初のコマーシャル リリースのコードの品質とセキュリティが大いに改善されます。 例えば、MySQLのライセンスのモデルは素晴らしいフィードバック と大きく異なったテスト環境を与えてくれ、GPLのライセンスで 利用するユーザにもコマーシャル・ライセンスで利用する ユーザにも同等に恩恵を与えます。新しい機能はMySQLのアルファ リリースのプロセスで早いうちに利用可能となります。 この本は新しい版をたびたびリリースすることを薦めています。 でもそれだけでは終わりません。この本でのリサーチによれば 異なった版からのフィードバックは開発者の注意をそぎ、プロセス を複雑にするかもしれないと続けます。最初やってみることが もちろん一番大切です。これはオープンソースのプロジェクトに一番 関連があると思います。その多くは新しい製品の版をすぐにつくりたがり ます。しかし、それは組織構造にもよります。 あなたとあなたのユーザ がどのレベルまで耐えられるかを決定する必要があります。 フォーカスと多様性 オープンソースのプロジェクトにたびたび欠けているものは フォーカスだと思います。開発者は広範囲の人々の問題 を解決しようとして誰にも適さない製品や必要以上に複雑な ものをつくってしまいます。問題は開発者が対象となる人々 を十分考慮していないことです。一旦これを考えて決定すれば 製品は全く違ったものになります。あまり特殊化するべきでは ありません。柔軟性を持たせるのは必要ですが、フォーカスと いうことも忘れないでください。対象市場を絞って、製品のスコープ を決定して特定の問題の解を開発してください。 最初「多様性」を違う項目で話そうと思っていました。しかし、 「フォーカス」とこの話はうまくミックスします。フォーカスすれば 全てのマーケットを対象とするわけには行きません。あいたところは 他の製品でカバーします。例えば、KDEとGNOMEを考えてください。 どちらもフォーカスを良く考えているとは思えないのであまり良い 例ではありませんが。それでもそれぞれは異なったグループに 対しています。もちろん幾分どちらにも属するグループはありますが。 ある人はこの重なったところを取り出して、「競合」と呼びます。 これはオープンソースの分野では良くあるようです。私はこれは 良いことだと思うので「多様性」と呼びます。異なった解を研究 するのは革新するための素晴らしい方法だと思います。うまく行く 考えもあれば他の大きなプロジェクトに吸収されてしまうものもあり また完全に消え去るものもあります。 多分これは難しいことでしょうが。もし誰かが「Linuxのディストリビューション ではどれは一番良いですか。」と尋ねたら、多様性のことを 話ましょう。また聞いた人がどんなユーザなのかも考えましょう。 それでオプションを限りましょう。 また次の機会に誰かがあなたが開発しているアプリケーションに 新しい機能を追加するように頼んだら、勇気をだして「No]と 言いましょう。そうしたら、もっと良い製品ができるかも知れません。 References 1. AUUG Annual Conference 2004 http://www.auug.org.au/events/2004/auug2004/ 2. How Apache Came to Be http://httpd.apache.org/ABOUT_APACHE.html 3. The MySQL AB development and business models http://www.mysql.com/company/ MySQL State of the Dolphin, AUUG 2003: speaker notes, slides http://dev.mysql.com/get/Downloads/Presentations/stateofdolphin-backgrounder.pdf/from/pick http://dev.mysql.com/get/Downloads/Presentations/mysql-state-of-dolphin-2003-09-04.pdf/from/pick 4. The Industry Standard: Guest Blog: Ross Mayfield: http://www.thestandard.com/movabletype/rossmayfield/archives/000399.php Tech Commodities 101, Commoditized software: fact or fiction? (ZD Net) http://news.zdnet.com/2100-9595_22-5272787.html 5. Strategies for E-Business Success, Erik Brynjolfsson & Glen L. Urban, editors, MIT Sloan Management Review, Center for eBusiness@MIT, ISBN 0-7879-5848-4 http://ebusiness.mit.edu/ --------------------- Zen Kishimoto zen@xxxxxxxxxx IP Devices, Inc. (408) 567-9391 2175 De La Cruz Blvd., Suite 10 (801) 720-8847 (FAX) Santa Clara, CA 95050