業務系OSSの実態とその可能性 （OSS白書、2005年8月）
OSSは、近年Linuxの利用がビジネス分野で拡大していることから大きな注目を浴びているが、最近はMySQLやPostgreSQLのようなDBMS、OpenOfficeのようなデスクトップ・ソフトウェアから業務系ソフトにまでOSSの利用は拡大している。業務系のOSSとしては、外食産業向け食材受発注システムの「セルベッサ」、美容院向けWebPOSシステムの「フランシーヌ」、外食産業の座席予約管理システムの「ガラガラドア」、日医総研が開発した「日医標準レセプトソフト」などがあるが、ここでは、セルベッサを事例にして業務系OSSの可能性を展望する。
セルベッサとは
セルベッサは、ニユートーキヨーが1998年にテンアートニに開発を委託し、1999年に完成した外食チェーン向けの食材受発注システムである。食材を指定した発注のほか、レシピによるメニュー発注や納品後の検品、仕入状況照会、棚卸入力なども可能になっている。ニユートーキヨーは、このソフトウェアを1999年11月にOSS化すると発表した。
システム面から見るとセルベッサは、Linux上で動くJavaサーブレットであり、オープンソースであるApacheとTomcatが動くWebサーバーが必要である。しかし、食材を発注する店舗や、その発注を受ける企業（食材の仕入先）には特別なソフトウェアや機器は必要としない。インターネットに接続されたパソコンと一般的なブラウザがあればセルベッサを利用できる。また、サーバーを自社に設置しなくてもセルベッサのASPサービスを利用するという手段もある。ちなみに、当初のセルベッサはDBMSにOracle 9iを利用しているが、最新版のセルベッサはオープンソースのDBMSであるPostgreSQLを利用しており、ほとんどOSSだけの環境で利用できるシステムとなっている。
セルベッサの普及状況
ニユートーキヨー以外の企業でセルベッサを最初に利用したのは、東京、名古屋などに10店舗を展開するステーキハウス・チェーンのアウトバックステーキハウスジャパンである。当時、ニユートーキヨーが食材の仕入れを三友小網（現在の三井食品）に集約しようとしていたこともあり、三友小網の親会社である三井物産がセルベッサのASPサービスを2000年5月に開始した。この第1号の利用企業がアウトバックステーキハウスジャパンである。
2000年9月にはカプリチョーザやトニーローマを経営しているWDIが、2000年10月には定食屋チェーンを展開する大戸屋が、三井物産のASPユーザーとなっている（ただし、アウトバックステーキハウスジャパンと大戸屋は現在、セルベッサを利用してない）。
自社専用のサーバーでセルベッサの利用を始めた最初の企業は、ダイニングバーや居酒屋など多種類の飲食店を展開するダイナックである。ダイナックのシステム担当者が講演会でセルベッサの存在を知り、2000年10月から自社の業務にあわせてカスタマイズを始め、2001年4月に本稼動させている。カスタマイズを担当したのは、セルベッサを最初に開発したテンアートニであるが、運用段階に入ってからコムテックコンサルティング（現在のオープンソース・ジャパン）が担当している。ちなみに、ダイナックのシステム担当者によれば、このカスタマイズでプログラムの大部分を書き直すほどの作業を行っているが、それでも自社で新規にシステム開発を行った場合に比べてコストは半分程度で済んだという。
2002年10月には名古屋を中心に外食チェーンを展開している浜木綿が、公開サイトからダウンロードしてセルベッサの利用を始めている。サポートしたベンダーは名古屋のソフトリンクである。
さらに2003年10月にはR&D外食ネットがセルベッサのASPサービスを実施しており、現在、しょうすけグループの出井商事、総合食品卸のクサマ、中国家庭料理チェーンの希須林などが、このASPサービスを利用している。
セルベッサをOSS化した狙い
ニユートーキヨーがセルベッサをOSS化した狙いは2つある。
第1の狙いは、業務系ソフトの開発・運用・メンテナンスに要するコストを可能な限り低く押さえつつ、可能な限り良質なシステムを構築することである。まず、OSS化すると宣言することにより、開発者が他人に見られても恥ずかしくないソースコードを書くことを心がけるようになり、これを通じてソフトウェアの質が向上することが期待できる。また、OSS化することによって利用企業が増えれば、潜在するバグの発見も多くなり、バグの少ないシステムになることが期待できる。さらに、他企業がセルベッサを改良すれば、その改変されたバージョンのソースコードもGPLに従って公開されることになり、ニユートーキヨーは機能強化されたバージョンを無償で入手できることになる。つまり、最初の開発コストを負担すれば、その後の保守費用や機能強化費用を削減できると同時に、ソフトウェアの質の向上も期待できるのである。
第2の狙いは、特定のベンダーやソフトウェア技術者に依存しない関係を生み出し、システムがメンテナンス不能になるというリスクを低減できることである。理論的にはソースコードと関連ドキュメントがあればソフトウェアがメンテナンス不能になることはないはずであるが、現実にはそのソフトウェアを開発した企業が倒産したとか、開発を担当した技術者がいなくなったなどの理由によってメンテナンス不能になるケースがある。業務ソフトをOSS化し、それをサポートするベンダーが増えれば、メンテナンス不能になるリスクを大幅に低減できる。
これらの目標は、おおむね達成されている。例えば、現在ニユートーキヨーが利用しているセルベッサのバージョンは、三井物産がASPサービスのために開発したバージョンであるが、これには棚卸帳票機能などが追加されている。つまり、ニユートーキヨーは追加費用をかけずに機能強化版を入手できたことになる。また、現在セルベッサをサポートする企業は少なくとも3社あり、メンテナンス不能になるリスクはかなり低下している。
異なるバージョンの存在
セルベッサはGPLに基づくOSSであるが、そのソースコードを管理している組織やコミュニティは存在していない。現在、実在するメールアドレス（アドホックなフリーメールのアドレスでも可）を登録すれば、誰でも公開ウェブサイトからセルベッサのソースコードをダウンロードできるが、ダウンロードされたセルベッサが実際に利用されているのかどうかは誰も把握していない。つまり、現在把握できている企業のほかにセルベッサを利用している外食チェーンやITベンダーが存在する可能性がある。
したがって、バグ情報についても組織的な情報共有が行われているわけではなく、主要な関係者によってボランタリに情報共有されているにすぎない。
こうしたことから、セルベッサのソースコードにはいくつかの亜種が発生している。資料2はセルベッサのバージョンとその利用企業、サポートベンダーの関係をまとめたものであるが、ニユートーキヨーや三井物産が利用しているバージョン2の他に、ダイナックが利用しているPostgreSQL版、R&D外食ネットが利用しているRPM版、浜木綿が利用している浜木綿版が存在していることになる。
業務系OSSの特徴
セルベッサの事例をみると、Linuxに代表されるインフラ系OSSとセルベッサのような業務系OSSには本質的な違いがあることがわかる。
たとえば、前述のようにセルベッサではいくつもの異なるバージョンが存在しているが、利用上特に問題にはなっていない。しかしインフラ系OSSの場合には、異なったバージョンいくつも存在すると、その上で動くソフトウェアとの整合性やネットワークを通じた相互運用性に支障が発生する。このため、インフラ系OSSでは団体やコミュニティ、オリジナルベンダーによるバージョン管理が行われている。しかし、業務系OSSの場合には、数多くの亜種が存在していても利用企業にとってはまったく問題がない。
また、業務系OSSの場合、あるユーザーによって追加された機能が、他の大多数の利用企業にとって利用価値がない可能性がある。インフラ系OSSの場合、利用者が必要とする機能はかなり共通的であるが、業務系OSSの場合、必要とする機能は企業によって異なることが多い。つまり、改変したバージョンのソースコードを公開することによってフィードバックしても他の利用企業から感謝されないということが起きる。
さらに、インフラ系OSSの場合には、バグの発見やその修正、機能強化などがボランティアによって行われているが、業務系OSSの場合にはボランティアによるバグの修正、機能強化はほとんど期待できない。それは、インフラ系OSSのようなコミュニティが存在していないことや業務系ソフトの世界ではOSSに興味を持っているソフトウェア技術者が少ないため、ソフトウェアの品質向上や機能強化に貢献しても個人の評価が高まらないことが原因だと考えられる。
業務系OSSのメリット・デメリット
セルベッサをOSS化したニユートーキヨーの狙いについては前述したとおりであるが、ここでは、最初に当該ソフトをOSS化すると決めた利用企業（オリジナル利用企業）、そのソフトを開発した企業（オリジナル・ベンダー）、当該業務系OSSを利用する企業（二次的利用企業）、当該業務系OSSの改変や運用をサポートするベンダー（二次的ベンダー）の４者に分けて、そのメリット・デメリットを整理してみよう。
1) オリジナル利用企業のメリット・デメリット
オリジナル利用企業のメリットは、まず、OSS化したソフトウェアの利用企業が増えれば「バグ情報の共有によって品質の向上が期待できること」、他の企業がプログラムを改変すればGPLにしたがってそのソースコードを公開することになるので、「機能強化されたバージョンを無償で入手可能になること」である。また、開発されたソフトウェアをOSS化すると宣言することによる「開発者のモラルアップ」が期待でき、それによってより質の高いシステムが入手できるというメリットもあるだろう。さらに、サポートする企業が増えれば、「特定のベンダーや特定の技術者に依存しないですむ」状況になり、サポート企業の倒産などによってシステムのメンテナンスができなくなるというリスクを回避することができる。
一方、オリジナル利用企業のデメリットは、そのソフトウェアが競争優位の源泉になるようなものでないことを前提にすれば、あまり考えられない。強いて言えば、「初期開発費用を1社で負担することになる」ので、二次的利用企業に比べてIT投資コストが大きくなることや、「利用企業や二次的ベンダーが増えないと先に挙げたメリットを享受できない」という点がデメリットかもしれない。
2) オリジナルベンダーのメリット・デメリット
オリジナル版を開発したベンダーのメリットは、利用企業の増加とともに、「機能拡張やメンテナンス、運用サポートといったビジネスの機会が増える」ことにある。しかし、一方で同様の「業務システムを新規に開発する機会が失われる」ことになり、ベンダーとしては全体の市場規模を縮小させることになる。また「ソースコードを公開しなければならない」ので、競合ベンダーにもプログラムの手の内を見せることになる。
3) 二次的利用企業のメリット・デメリット
OSS化された業務アプリケーションを利用するユーザー企業は、無償でソフトウェアを入手できるため、「IT投資コストの削減が可能」である。
問題は、「サポートしてくれるベンダーを捜す必要がある」ことと、まだ普及がさほど進まない段階では「パッケージソフトに比べてバグが多い可能性がある」こと、「機能追加や改修が必要なことがある」ことである。
セルベッサに見られるように、ダウンロードしたソフトウェアはカスタマイズや機能追加が必要になる可能性が高いが、それでもスクラッチから業務アプリケーションを開発することに比べれば、費用はかなり安くなるだろう。
4) 二次的ベンダーのメリット・デメリット
OSS化された業務アプリケーションが対象とする分野にあまり詳しくないベンダーにとっては、「ソースコードや関連ドキュメントを学ぶことによって、当該分野に新規参入できる」というメリットがある。また、全てのベンダーにとって、「機能拡張やメンテナンス、運用サポートといったビジネスの機会が得られる」ことになる。しかし、その一方で、同様の業務システムを「新規に開発する機会が失われる」ことになり、ベンダーとしては全体の市場規模を縮小させることになる。また、「GPLに従ってソースコードが公開されている場合には、改変した部分や機能追加した部分もソースコードを公開しなければならない」という点もデメリットかもしれない。
業務系OSSの普及経路
このようなメリット・デメリットを前提に業務系OSSの普及経路を考えると以下のようになると考えられる。
利用企業が業務系ソフトウェアをOSS化すると決めて開発した場合、オリジナル利用企業は、二次的利用企業や二次的ベンダーが増えないとOSS化のメリットは享受できない。したがって、オリジナル利用企業が普及活動をすることは極めて合理的である。
一方、オリジナルベンダーは、その業務系OSSが普及すれば、新規開発機会が減少するので、普及活動をしない方が望ましい。しかし、オリジナル利用企業が積極的に普及活動をするという前提に立てば、普及活動をしなければ、その業務系OSSの機能拡張、メンテナンス、運用サポートの受託といったビジネス機会を他のベンダー（二次的ベンダー）に奪われることになってしまう。したがって、オリジナル利用企業が普及活動をするなら、オリジナルベンダーも普及活動をするという戦略をとることが合理的だということになる。
仮に二次的利用企業が増えて、オリジナルベンダーが受容能力的に対応できなくなる、ああるいは地理的な制限から二次的利用しようとする企業をサポートできないケースが出てくれば、その二次利用企業の働きかけによって、当該業務系OSSをサポートするベンダー（二次的ベンダー）が生まれてくるだろう。また、オリジナル利用企業にとっては、二次的ベンダーが生まれることは大きなメリットであるので（特定のベンダーに依存しない状況をつくり出せることになるので）、他ベンダーにサポートを勧めることになるだろう。
業務系OSS増加の可能性
セルベッサは、現在のところ、利用企業が業務系ソフトをOSS化すると決断した希な事例である。しかし、業務ソフトのOSS化によるオリジナル利用企業の利害得失を考えると、その業務ソフトが持続的な競争優位の源泉になりうるものでない限り、デメリットよりメリットの方が大きい。
現在、ほとんどの企業が独自に開発した業務系ソフトを非公開にしているが、それは公開するメリットとデメリットを考えて決断したわけではなく、非公開であるのが当然であるという先入観にとらわれているからではないだろうか。
利用企業が増えれば、当該ソフトウェアに潜在するバグが発見されて、ソフトウェアの品質が向上する可能性がある。また、サポートベンダーが増えれば、特定のベンダーや技術者に依存しないで済む状況になる。さらにOSS化を宣言することによって開発者のモラルがアップすることや、GPLによって機能強化版を無償で入手することも期待できる。
逆に、業務系ソフトをOSS化することによってオリジナル利用企業が失うものはあまりない。ライバル企業が無償で利用できるため、IT投資コストの削減を通じて企業競争に不利に働くという面があるが、OSS化された業務系ソフトをダウンロードして利用するまでにかかるコストを考えると、それほどに大きなデメリットにはならないだろう。
また、オリジナル利用企業がOSS化を決断すれば、そのメリットを最大化するために二次的利用企業を増やす活動をすることになるという前提に立てば、オリジナルベンダーも普及に協力することが合理的な選択となる。二次的利用企業が増えれば二次的ベンダーが増える可能性も出てくる。
つまり、そのソフトウェアが持続的な競争優位の源泉になるようなものでなければ、業務系ソフトをOSS化することは、極めて合理的な選択なのである。現時点では、ほとんどの企業が開発した業務系ソフトを非公開にしているが、それは業務系ソフトをOSSにするという発想や文化がなかったからである。業務系ソフトを非公開したからといって、それが何の価値を生むわけではない。業務系ソフトをOSS化することのメリットが社会に浸透していけば、業務系ソフトをOSS化する企業が増加するのではないだろうか。
（注）本稿は、EJBコンポーネントに関するコンソーシアム 市場流通のための研究会が作成した「市場流通のための再利用事例研究報告書（テクニカルレポート）」（2005.7.25）の一部を転載、翻案したものである。
参考文献
竹田陽子、米山茂美 2002「[ビジネスケース] セルベッサ ニユートーキヨーの食材発注システムはなぜ公開されたのか」一橋ビジネスレビュー 2002年 Winter pp.2-21
湯澤一比古 2004 『オープンソースじゃなきゃ駄目』（イデア教養文庫01）イデア出版