新時代のソフトウェア提供モデルにどう対応すべきか

（2006年04月24日）

いまや、オープンソース・ソフトウェアはあらゆる分野に浸透している。Linux、MySQL、Perl、あるいはネットワーキング・ツールのSnortといったオープンソース・ソフトウェアを「導入していない」ユーザー企業を見つけるほうが難しいぐらいだ。一方、IBM、ノベル、オラクル、サンといったトップITベンダーも、オープンソースのプロジェクトやコミュニティ・ベースの開発プロジェクトに多額の投資を行っており、かのマイクロソフトでさえ、この“ゲーム”に参加しようとしている。では、そんなITベンダーの、オープンソースに対する“本音”はどこにあるのだろうか。それをきちんと把握しておかないことには、IT部門の責任者は、基幹業務用のエンタープライズIT環境にオープンソース・ソフトウェアを活用することなど、怖くてとてもできないだろう。

ニール・マカリスター
InfoWorld 米国版

　ITマネジャーなどユーザー企業のIT部門の人間は、ITベンダーが自社製品をオープンソース化することに対して懐疑的だ。ITベンダーの“本気度”を疑う理由は、もうかる製品（今でも十分に実用に堪えうる製品）であれば、ベンダーはオープンソース化など行わないのではないかという、単純な発想にある。つまり、オープンソース化するようなソフトウェアは、どうせ成功を収めることのできなかった製品か、きちんとメンテナンスされてこなかった製品だろう、要は体のいい投げ売りじゃないかと疑ってかかっているわけだ。

　だが、そう断じてしまうのは間違いだ。といっても、コミュニティからの支持を獲得するための真摯な試みとして、ベンダーが自社のソフトウェアをオープンソース化する場合もある──という正論を振りかざそうというわけではない（確かに、そういうケースもないわけではないが）。筆者は、ベンダーはそれよりももっと現実的な理由で、“本気で”ソフトウェアのオープンソース化に取り組んでいると信じているのである。

　その“現実的な理由”とは、「オープンソースが“ビジネス・モデル”として成熟してきた」ということだ。実際、オープンソース・モデルは今後数年以内に“標準”となる可能性が高い。

　そして、オープンソース・モデルが標準になるということは、ソフトウェアの開発や販売にまつわる従来のビジネス・モデルが標準の座を失うということでもある。ということはつまり、IT部門がエンタープライズ・ソフトを評価／調達しようとする際に用いていた従来の手法が有効性を失うということだ。エンタープライズ・ソフトにかかわる意思決定に際して、ITマネジャーには今後、コストや予算だけではなく、ソフトウェア開発環境などをも踏まえた新たな視点が必要になるのである。

“無償のソフトウェア”は
幻想にすぎない

　では、ベンダーは、オープンソース化によって、どのようなビジネス・モデルを構築しようとしているのであろうか。言いかえれば、IBMやオラクルなどが自社のソフトウェアを無償で提供しようしている裏には、どのような勝算が隠されているのだろうか。これに対する答えは至極単純だ。実は、彼らは、ソフトウェアを無償で提供しようなどとは考えていないのである（少なくとも巨視的に見た場合、ベンダーはソフトを無償で提供しているわけではない）。

　ここで、それを証明するために、あらためてソフトウェアのビジネス・モデルについて見てみよう。従来、広く用いられてきたのはシュリンクラップ契約型（ソフトウェアの購入者がパッケージの封を破ることで、使用許諾契約に同意したものとみなす契約方式）のソフトウェア流通モデルだが、このモデルは、エンタープライズ・ソフトウェアに適しているとは言い難い。エンタープライズ・ソフトウェアでは、ITインフラストラクチャの規模が大きく、込み入っているため、設置台数やCPUを単位とするライセンシング・スキーマで管理するには無理があるのだ（料金計算が複雑になるうえ、料金体系も実際の利用状況を正確に反映することができない）。こうした状況に業を煮やしたユーザー企業のCFO（最高財務責任者）たちが、独自の会計手法を用いるようになったほどである。

　そこで、サンなどのベンダーは、時代遅れになったシュリンクラップ・モデルを捨て、サブスクリプション契約型のソフトウェア流通モデルに移行するという決断を下した。サブスクリプション・モデルとは、ソフトウェア自体は無償で、顧客は、契約期間中のサポート、メンテナンス、統合支援などのサービスに対して料金を支払うという契約形態である。

　だが、ソフトウェア自体は無償になった（製品のライセンス料金を個別に支払う必要はなくなった）とは言っても、長期的に見た場合、必ずしも顧客がコストを節約できるようになったわけではない。決して、ベンダーに支払う料金が安くなったわけではないのだ。

　ここで、上述の、「（ベンダーは、オープンソース・モデルで）ソフトウェアを無償で提供しようなどとは考えていない」という表現を思い出していただきたい。そう、実は、サブスクリプション・ソフトウェア・モデルは、オープンソース・ソフトウェア・モデルと同じ考え方の上に立ったものなのだ。オープンソースとの違いは、コードを公開するか否かという点だけであり、ビジネス・モデルとしては、そっくりなのだ。サンなどが今まさに取り組もうとしているのは、このビジネス・モデルなのである。

　レッドハットやMySQL ABといった（オープンソース・ソフトウェアの）ベンダーは、現実に、無償ソフトウェアに対してエンタープライズ・レベルのサポートを提供することによって収益を得るというビジネス・モデルを構築している。しかも、これらのベンチャー企業は、現在も事業を拡大し続けている。これまで、それを横目に見てきたプロプライエタリー・ソフトウェアのベンダーたちが、ソース・コードを社内で厳重に保管することのメリットを、オープンソースという新しいパラダイムによってもたらされるメリットと比較して考えるようになったとしても、無理はあるまい。

コミュニティをどう“評価”するか

　オープンソースというソフトウェア開発の新しいスタイルは、ソフトウェア・ベンダーと顧客の双方に、コミュニティという開発者グループによる恩恵をもたらす。オープンソース・プロジェクトを取り巻くコミュニティこそ、オープンソースの血液と言えるものだ。当然のことだが、開発コミュニティによるサポートが受けられなければ、いかに優れたコードであろうと、衰退と停滞を余儀なくされてしまう。

　しかし、こうしたコミュニティを評価するという作業は、ユーザー企業およびそのITマネジャーにとって、ソフトウェア調達プロセス上の最も難しい課題となる可能性が高い。プロプライエタリーのエンタープライズ・ソフトウェアを購入する場合は、製品を開発・販売しているベンダーに対する評価を基に、最終的な意思決定を下せばよい。だが、オープンソース・プロジェクトを評価する場合には、さまざまな要因がきわめて複雑に絡んでくるため、特定のベンダーを評価するようなわけにはいかないのだ。つまり、企業がオープンソース・プロジェクトによって開発される製品の導入を決定する際には、経験を積んだITスタッフによるプロジェクトの十分な事前調査が必要になるわけである。そしてその事前調査では、ディベロッパー・コミュニティの組織、ガバナンスのモデル、最も積極的に活動しているメンバー、コードの変更が許されているメンバー、変更の頻度、コミュニティ内において意見対立があった場合の解決方法、コードのライセンス方法などに至るまで、すべてをチェックする必要がある。

　さらにITマネジャーは、ベンダーが、どんなかたちでコミュニティの形成にかかわろうとしているかについても注意しなければならない。純粋に自由放任主義で臨むベンダーもあれば、自社サービスの販売チャネルとしてコミュニティを利用してやろうと考えているベンダーもあるからだ。ITマネジャーとしては、オープンソースを促進するだけではなく、オープンソースと市販製品を明確に区別しようとしているベンダーを選ぶべきだ。

　いずれにせよ、ITに関する意思決定は、すべてがビジネス上の観点から下されるべきであり、オープンソース・ソフトウェアについても、将来性、安定性、拡張性、セキュリティなど、プロプライエタリー・ソフトウェアと同じ基準で評価するのが正解である。

（Computerworld.jp）